Subject: [Sipping] Relationship between SIP session and SDP session

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 May 2007 09:40:39 -0400

Vijay, Gonzalo and I have been having a side conversation on the 
following topic. After bouncing around it seems that this requires some 
list discussion to get more perspective and data.

(I've plagiarized from the private mail, but edited it.)

So far, we (at least some) have assumed that there is an implicit 1-1 
relationship between a SIP session (INVITE dialog usage) and the SDP 
session that is initiated by it.

A SIP session (a.k.a. INVITE dialog usage) is defined by its 
identifiers: To tag, From tag, and Call-ID.

An SDP session is defined (in RFC 4566) by the following identifiers 
from the o= line: <username>, <sess-id>, <nettype>, <addrtype>,
and <unicast-address>. (Everything except <sess-version>.)

When certain aspects of the SDP needed to be modified, the 
<sess-version> field of the o= line is to be incremented by one and 
everything else in the o= line is to remain the same (c.f. 
http://tools.ietf.org/html/rfc3264#section-8).

This defines a 1-1 relationship between a SIP session and the
SDP session.

Based on some limited queries it appears that many UA implementations 
generally ignore the o-line, otherwise following RFC 3264 procedures for 
modification of the session regardless of what the o-line might contain.

However at least one implementation has been encountered that takes 
special action when the SDP session (as defined above) changes. 
Apparently it treats this as if a new sip session had been established, 
with the SDP treated as an *initial* offer. (I don't know what it does 
if the SDP session changes in an answer.)

Changing the SDP session seems to be nonconformant with 3264, so neither 
behavior (treating as if unchanged or as a new sip session) is "right".

The question is: should we do anything about this? E.g.:
- reiterate that changing the SDP session is not allowed; or
- make a change to allow it. If so, define the expected behavior.
   (In this case we need to decide *which* behavior is valid.)

IMO we should reiterate that this is illegal, and at the same time 
suggest that implementations be forgiving if they encounter this, and 
specify that in that case the forgiving behavior is to act as if the SDP 
session was unchanged.

If we can reach some consensus on this quickly I think this decision 
would be appropriate to add to the offeranswer draft that is now being 
wrapped up.

	Paul

P.S. I could swear I exchanged email on this same subject with somebody 
in the last year or so, but I can't find it. If I did, I hope whoever it 
was will speak up.

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

---

From: [email-masked]
Date: Fri, 25 May 2007 18:11:33 -0400

Let me add this case -- obtaining music from a "music-on-hold
server".  In that scenario, a phone that wishes to put its end of the
call on hold sends an INVITE to a music-on-hold server.  From the 200
response to that INVITE, it takes the SDP and places that as the offer
in the hold re-INVITE for its original dialog.  (This seems to be what
is meant by section 2.3 of draft-ietf-sipping-service-examples-11,
although that was changed in the -12 version.)

This is similar to telephony applications where the entire source of
the media changes during the dialog.

I think the only workable solution is for UAs to treat SDP with
changed <session id>s as being entirely independent.

Dale

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Thu, 31 May 2007 23:02:32 +0200

Hi, 

>Vijay, Gonzalo and I have been having a side conversation on 
>the following topic. After bouncing around it seems that this 
>requires some list discussion to get more perspective and data.
> 
>So far, we (at least some) have assumed that there is an 
>implicit 1-1 relationship between a SIP session (INVITE 
>dialog usage) and the SDP session that is initiated by it.
> 

Doesn't 3261 allow to accept multiple 200 Oks (read: multiple To tags),
eventhough no such usage has been defined?

Or, would doing that also create multiple SIP sessions?

Regards,

Christer

> An SDP session is defined (in RFC 4566) by the following 
> identifiers from the o= line: <username>, <sess-id>, 
> <nettype>, <addrtype>, and <unicast-address>. (Everything 
> except <sess-version>.)
> 
> <sess-version> field of the o= line is to be incremented by 
> one and everything else in the o= line is to remain the same (c.f. 
> Based on some limited queries it appears that many UA 
> implementations generally ignore the o-line, otherwise 
> following RFC 3264 procedures for modification of the session 
> regardless of what the o-line might contain.
> 
> However at least one implementation has been encountered that 
> takes special action when the SDP session (as defined above) changes. 
> Apparently it treats this as if a new sip session had been 
> established, with the SDP treated as an *initial* offer. (I 
> don't know what it does if the SDP session changes in an answer.)
> 
> Changing the SDP session seems to be nonconformant with 3264, 
> so neither behavior (treating as if unchanged or as a new sip 
> session) is "right".
> 
> IMO we should reiterate that this is illegal, and at the same 
> time suggest that implementations be forgiving if they 
> encounter this, and specify that in that case the forgiving 
> behavior is to act as if the SDP session was unchanged.
> 
> If we can reach some consensus on this quickly I think this 
> decision would be appropriate to add to the offeranswer draft 
> that is now being wrapped up.
> 
> 	Paul
> 
> P.S. I could swear I exchanged email on this same subject 
> with somebody in the last year or so, but I can't find it. If 
> I did, I hope whoever it was will speak up.
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 31 May 2007 18:52:11 -0400

> Or, would doing that also create multiple SIP sessions?

That definitely results in multiple invite dialog usages. I think there 
is enough ambiguity in the term "session" that I hesitate to say for 
certain whether this is one or multiple sessions.

I think we would be safer to restrict ourselves to use of "invite dialog 
usage" and forgo use of "sip session".

	Paul