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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Dec 2003 16:27:38 -0500

Another old mail - apologies for the very late response.

Anders Kristensen wrote:

> 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?

Yes. I've added text to the spec which discusses this:

<t>From here, new parties can be added, removed, transferred, and so on,
as the controller sees fit. In many cases, the controller will be
required to modify the SDP exchanged between the participants in order
to affect these changes. In particular, the version number in the SDP
will need to be changed by the controller in certain cases. If the
controller should issue an SDP offer on its own (for example, to place
a call on hold), it will need to increment the version number in the
SDP offer. The other participant in the call will not know that the
controller has done this, and any subsequent offer it generates will
have the wrong version number as far as its peer is concerned. As a
result, the controller will be required to modify the version number
in SDP messages to match what the recipient is expecting.
</t>

> 
> 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?

It is as written - increment by one, which strengthens the requirement 
compared to rfc2327.

-Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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