SID

Hello,

The logic behind the DF, RND, NBO and SID fields is not defined well. Currently packet type IR-DYN is forced if there are 3 or more "dynamic fields" that changed. However, UO packets with Extension 3 can transmit changes for TTL, TOS, DF, NBO, RND. Those changes are counted as 4 changed fields, so UO with EXT3 is not used while it could be. It might save some bits. The logic behind dynamic fields should be reworked. I tried to do that on the master branch. See https://github.com/didier-barvaux/rohc/commit/ce2d85396ee0b18e7ce376d28aae12f1b83806a0

Please give the updated master branch a try, and tell me how it behaves for you.

Regards,
Didier

hello ,

   in https://github.com/didier-barvaux/rohc/commit/ce2d85396ee0b18e7ce376d28aae12f1b83806a0, the state is only changed when NACK and STATIC NACK not by the tmp.send_dynamic and tmp.send_static , is it
great?

Regards,
yiyuechan

Hello,

Yes, that's great! The compression state is not changed any more if some dynamic fields changed. The compression state only changes with feedbacks or with periodic refreshes. The smallest ROHC packet type is chosen in a way that ensures that every changed fields is transmitted several times to the decompressor, to gain the confidence that the information was correctly transmitted.

Regards,
Didier Barvaux

hello,

  if so, it seems the ROHC states have no impact, and
1. why the TTL, TOS, DF, NBO, RND changed or not is considered only in c_rtp_decide_SO_packet( ), not in c_rtp_decide_FO_packet( ) ?
2.the sid field acts in new Master code is the same as the old one?

Regards,
yiyuechan

Hello,

The ROHC compression states still have some impact: the compression state changes with ACK/NACK/STATIC-NACK feedbacks or with periodic refreshes. For example, whenever a context refresh occurs or a NACK is received, the compressor transits from the SO state to the FO state.
* In FO state, the c_rtp_decide_FO_packet() function may choose a packet type among IR-DYN, UOR-2, UOR-2-ID and UOR-2-TS. The packet types UO-1, UO-1-ID, UO-1-TS and UO-0 are forbidden because they cannot transmit enough information to refresh the context.
* In SO state, the c_rtp_decide_SO_packet() function may choose a packet type among IR-DYN, UOR-2, UOR-2-ID, UOR-2-TS, UO-1, UO-1-ID, UO-1-TS and UO-0. The decision is taken depending on the information that strictly need to be transmitted.

The TTL, TOS, DF, NBO and RND information cannot be transmitted by the UO-1, UO-1-ID, UO-1-TS and UO-0 packet types, so the function c_rtp_decide_SO_packet() shall check them, but not the funcion c_rtp_decide_FO_packet().

The SID information can be transmitted only by packet types IR and IR-DYN, so both the functions c_rtp_decide_FO_packet() and c_rtp_decide_SO_packet() shall check for it. The behavior is not exactly the same as in old code version. In the old code, a SID change caused a transition to FO state, and the FO state handled it by choosing a IR-DYN packet type. In the new code, a SID change does not cause a transition to FO state, but both FO and SO states handle it by choosing a IR-DYN packet type.

Regards,
Didier

hello,

       Thanks a lot!
       as for your answer：“The TTL, TOS, DF, NBO and RND information cannot be transmitted by the UO-1, UO-1-ID, UO-1-TS and UO-0 packet types, so the function c_rtp_decide_SO_packet() shall check them, but not the funcion c_rtp_decide_FO_packet().” pardon? I am sorry I dont see the much logic.
      yes, The TTL, TOS, DF, NBO and RND information cannot be transmitted by the UO-1, UO-1-ID, UO-1-TS and UO-0 packet types, they should be transmitted by the UOR-2*, In FO state, it can choose a packet type among IR-DYN, UOR-2, UOR-2-ID and UOR-2-TS In FO state, so these fields can be transmitted in c_rtp_decide_FO_packet() in FO state?

Regards,
yiyuechan

This question was expired because it remained in the 'Open' state without activity for the last 15 days.