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

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

Darshan Bildikar wrote:
> IMO the o line restriction needs to be relaxed because

Relaxing it is the easy part.

The problem is: what should be done when it changes? If behaviors are 
not all consistent in this case then we have not solved anything.

Apparently there are at least two different behaviors that have been 
observed in the wild.

Some of the cases you describe below could result in a need to change 
the mapping of payload type numbers. Given that 3264 explicitly states 
that these may not change, and that supporting changes can be 
technically difficult, how many existing implementations will support this?

I do have an open mind on how this comes out. But if this can only be 
solved by making a new extension, then I suspect that telling people to 
use INVITE/Replaces would be simpler.

> 1) It makes IOT of apps like CRBT and prepaid very difficult. A caller is
> initially connected to a media server and then to the callee (different o
> line). Workarounds that exist are:-
> 
> a) The AS providing the service (B2BUA) changes the o line i.e. put in it's
> own "o line".
> 
> b) Provide different "to tags" for provisional and final responses.
> According to the Sip IT 20 report 42% of UA's don't handle this case
> gracefully)

How many support doing the "right" thing when the session id changes?

We have already made a request to inquire about this at the next SipIT.
  	
> 2) I have yet to hear a convincing explanation on WHY the o line cannot be
> changed. Keep in mind that we allow *all* other SDP parameters to change
> including the remote target. 
> 
> What I don't understand at all is WHY applications need to work around this?
> It makes no sense to me. 
> 
> I personally know ONLY ONE implementation that actually enforces this
> restriction i.e. reject re invite requests if the "o line" changes

I suspect we will find that many implementations just don't look at the 
o-line at all, and act as if it is unchanged except for an increment in 
the version number, applying all the restrictions of 3264 regarding 
changes to the session.

But that won't interoperate correctly with the implementation(s) that 
expect a change in session id to mean that a new session (in the 3264 
sense) is to be started.

	Paul

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Friday, May 25, 2007 7:11 PM
> To: sipping
> Cc: Vijay K. Gurbani; Gonzalo Camarillo
> Subject: [Sipping] Relationship between SIP session and SDP session
> 
> 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
> 

_______________________________________________
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: Robert Sparks <[email-masked]>
Date: Fri, 25 May 2007 14:01:35 -0500

The remapping of payload types is just an instance of the issues that  
we'll have to mine through if there's
to be any semantic continuity across the session-id changing at all  
(If there isn't, then the invite-replaces
model Paul talked about earlier is equivalent to what we'd end up  
with - we'd just be optimizing signaling
and simplifying any problems around accepting the replaces). There  
are reasons you can't, for instance,
remove m-lines in an update to a session - we'd still have to satisfy  
the requirements that caused things
like that to come into existence.

And the conversation so far is just clipping the top of the iceberg.  
When you add some of the more
gnarly 3pcc scenarios (where you want to build an SDP based on input  
from two different places) this
goes off into territory that not a lot of people have really looked  
hard at. Jonathan, for one, has been
down this road and you can see him cringe when you start asking about  
the things at the edges.

I'm expecting to fully plumb this, we're in for a long long analysis  
that will (re)expose places where
SDP as we're currently using it comes up short. The work that  
Flemming is doing will hopefully help.
(A random thought - I don't think session timer (the spec) really  
cares if the session-id doesn't change
across the whole session - it just looks to see if the (session- 
id,version) tuple hasn't changed since
the last SDP it saw. Now whether implementations care or not, I can't  
even speculate right now.)

I will be checking into what the implementations that show up at  
SIPit do. That's going to be in November,
so I'm trying to think of reasonable ways to get good data before  
then too.

RjS

On May 25, 2007, at 1:28 PM, Paul Kyzivat wrote:

> The problem is: what should be done when it changes? If behaviors  
> are not all consistent in this case then we have not solved anything.
>
> Apparently there are at least two different behaviors that have  
> been observed in the wild.
>
> Some of the cases you describe below could result in a need to  
> change the mapping of payload type numbers. Given that 3264  
> explicitly states that these may not change, and that supporting  
> changes can be technically difficult, how many existing  
> implementations will support this?
>
> I do have an open mind on how this comes out. But if this can only  
> be solved by making a new extension, then I suspect that telling  
> people to use INVITE/Replaces would be simpler.
>
>> including the remote target. What I don't understand at all is WHY  
>> applications need to work around this?
>> It makes no sense to me. I personally know ONLY ONE implementation  
>> that actually enforces this
> I suspect we will find that many implementations just don't look at  
> the o-line at all, and act as if it is unchanged except for an  
> increment in the version number, applying all the restrictions of  
> 3264 regarding changes to the session.
>
> But that won't interoperate correctly with the implementation(s)  
> that expect a change in session id to mean that a new session (in  
> the 3264 sense) is to be started.
>
> 	Paul
>
>> From: Paul Kyzivat [mailto:[email-masked]] Sent: Friday, May  
>> 25, 2007 7:11 PM
>> To: sipping
>> 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.
>> An SDP session is defined (in RFC 4566) by the following  
>> identifiers from the o= line: <username>, <sess-id>, <nettype>,  
>> <addrtype>,
>> 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).
>> 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".
>> 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.

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 May 2007 15:12:55 -0400

Robert Sparks wrote:

> goes off into territory that not a lot of people have really looked hard 
> at. Jonathan, for one, has been

Robert - don't be so *negative*.

I've been down that road too. Weaving together SDP from two or more 
places is when it gets *interesting*. :-)

	Paul

---

From: Robert Sparks <[email-masked]>
Date: Fri, 25 May 2007 14:39:55 -0500

Hey - I love a challenge :)

On May 25, 2007, at 2:12 PM, Paul Kyzivat wrote:

>
>
> Robert Sparks wrote:
>
>> And the conversation so far is just clipping the top of the  
>> iceberg. When you add some of the more
>> gnarly 3pcc scenarios (where you want to build an SDP based on  
>> input from two different places) this
>> goes off into territory that not a lot of people have really  
>> looked hard at. Jonathan, for one, has been
>> down this road and you can see him cringe when you start asking  
>> about the things at the edges.
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 28 May 2007 00:58:00 -0500

On Fri, 25 May 2007 14:39:55 -0500

> Hey - I love a challenge :)

I really hate it when my dentist says that. 

But not as much as I hate it when trying to figure out a working O/A state machine.

--
Dean