Subject: [Sip] 3pcc draft: SDP seq-no issue

From: Anders Kristensen <[email-masked]>
Date: Fri, 17 Oct 2003 13:01:53 -0400

In the example in section 10.2 of the 3pcc draft, 
draft-ietf-sipping-3pcc-04.txt, the controller disconnects the callee 
(called party of b2bua or 3pcc call) by sending a re-INVITE with a 
connection address in the .invalid domain. Later on the called party is 
reconnected with the caller by using one of the 3pcc flows.

One problem with this, not mentioned in the draft, is that the 
controller has to bump up the o= SDP version number when sending the 
disconnect re-INVITE. Since the caller may not have to change its SDP in 
offer (5) and answer (16) it may not update its SDP version number, 
meaning the controller will have to rewrite it in (17) answer3' sent to 
the callee (and keep on doing it for any subsequent re-INVITEs).

It seems that SDP version numbers could be an issue whenever any of the 
flows is used after initial call establishment?

BTW, RFC 3264 has the following slightly curious formulation:

    When issuing an offer that modifies the session,
    the "o=" line of the new SDP MUST be identical to that in the
    previous SDP, except that the version in the origin field MUST
    increment by one from the previous SDP.  If the version in the origin
    line does not increment, the SDP MUST be identical to the SDP with
    that version number.  The answerer MUST be prepared to receive an
    offer that contains SDP with a version that has not changed; this is
    effectively a no-op.

Is "MUST increment by one" supposed to be interpreted to mean "by at 
least one" or is this really intended to strengthen the requirements of 
RFC 2327?

Thanks,
Anders

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip