Subject: [rohc] Update of RTP P and X bits

From: "Lajos Zaccomer \(IJ/ETH\)" <[email-masked]>
Date: Wed, 24 May 2006 09:40:37 +0200

Hi RoHCers,

The latest Implementers' Guide (version 19) clarified the update of RTP
P and X bits in sections 6.4 and 6.5 in a strange way, at least compared
to other fields and the significance of these two bits:
    - if 0, there is no need to send the optional packet part (but may
be sent for other reasons)
    - if 1, the optional packet part containing the P/X bit must be sent

This solution is optimized for the case when X = 0 and P = 0. This is in
contrast with RFC 3095 A.1.4 that says both P and X are application
dependent, even though X is expected to be 0 in most cases.

If P/X is 1, the optional packet part containing the P/X bit must be
included, even though the value is not changed. This means one
additional octet in EXT-3 for P bit and one additional octet in RTP
dynamic part for X bit. As a compensation, the solution may save one 
octet in RTP dynamic part for X bit if 0; however, even this is unlikely
to happen, as the TS_STRIDE is most probably sent in the establishment.
(As the value of P/X is not expected to change during the lifetime of
the packet flow, as said in RFC 3095 A.1.4, only the establishment
period is of concern.)

In case a CID is reused with the same X=1 value as of the previous
packet flow, it must be updated, even though it is not changed - because
of the value 1. Even if X=0, the optional part in the RTP dynamic part
is probably sent due to TS_STRIDE establishment - unless it is also the
same.

What is the advantage then? Is P=1 and/or X=1 really that unlikely that
it is worth deferring from the clean way of updating other fields not
function of SN to save one octet per thousands of packets? EXT-3 must be
quite common to cope with irregularities, therefore I'm not quite
comfortable with the idea to update a field based on its value instead
of being changed, as for all other fields not function of SN (except RTP
M bit, but that is reasonably explained in RFC 3095 A.1.4). This seems
to be additional complexity mainly to send more bytes in some cases.

Looking forward to reading your opinion and comments.

Best regards,
Zacco

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "carriez" <[email-masked]>
Date: Thu, 25 May 2006 21:11:45 +0800

Hi experts,

I have a question regarding whether the SIP/SDP static dictionary
should be announced in the returned parameter when the I-bit is set
to 0 in the incoming SigComp message?

RFC3320 section 9.4.9 defines that when the I-bit is set to 0 in the
requested feedback, it means the sending side still wishes to access
the locally available state items offered by the receiving endpoint,
and the receiving side should announce its local available in the
returned parameter defined in the same section.

While we intepretate that the SIP/SDP static dictionary defined in
RFC3485 is a MUST HAVE for all SIP endpoints that support SigComp. If
it is required to be there, is the overhead to advertise it necessary?

Thanks in advance.

Regards,
Carrie

---

From: "carriez" <[email-masked]>
Date: Mon, 29 May 2006 17:05:51 +0800

Hi experts,

Can anyone please help to answer my question below?

Thanks a lot.

Regards,
Carrie