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

From: "Brian Stucker" <[email-masked]>
Date: Mon, 2 Jul 2007 13:43:09 -0500

Catching up on old threads...

Guys, without necessarily disagreeing with what folks have said here, I
think the disconnect or "creative interpretation" of RFC-3264 is
entirely focused upon what a session is with respect to RFC-3264.

I think there are two general interpretations that are running around
out there:

****

Case A:
----------
SDP session state is tied directly to the SIP session state. The session
id and version information in the SDP is vestigial as it is superceded
by the callid/tags/cseq present in the lower-layer SIP signaling. 

Case B:
----------
SDP session state is independent to the SIP session state. SIP is used
to tunnel SDP. The session id and version information in the SDP is
critical as otherwise SDP received by and endpoint simply describes
another destination for any media the endpoint wishes to send to it.

****

Case A seems to be what's being stated by some on this thread by some by
way of INVITE-replaces usage and ignoring the o-line, in that all SDP is
useful for is media description and SIP is where the real meat of
keeping SDP "sessions" in coherent order.

However, case B is what RFC-3264 appears to be written towards, and even
the change log in RFC-3261 outright states: "SDP processing has been
split off into a separate specification [RFC 3264], and more fully
specified as a formal offer/answer exchange process that is effectively
tunneled through SIP."

So, which is it? Seems to me that you can use SDP without using SIP to
carry it and that SDP has been specifically designed to stand on it's
own. However, if you read, very carefully (blink and you'll miss it) to
RFC-3261, section 14.1 you'll see the following:

	"The same offer-answer model that applies to session
descriptions in INVITEs [...] applies to re-INVITEs."

That's the only reference that I've been able to find that ties section
8 of RFC-3264 to Re-INVITEs. If you miss that, then a whole world of
possible interpretations opens up.

I think the text, as it stands, shows that the intent was to tie
RFC-3264 rules closely with RFC-3261 behavior, but that it's somewhat
difficult to figure out for someone not very familiar with the
documents, especially if you only read 3264.

Regards,
Brian

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:[email-masked]] 
> Sent: Friday, June 08, 2007 3:28 PM
> To: Jonathan Rosenberg; Darshan Bildikar
> Cc: Paul Kyzivat; [email-masked]
> Subject: RE: [Sipping] Relationship between SIP session and 
> SDP session
> 
> 
> Hi, 
> 
> >>I would think the problem here would be that there are some 
> >>implementations that are strict about receiving an offer with a 
> >>different o line. These implementations reject offers with 
> different o 
> >>lines.
> > 
> >I'd like to know if there are any that do that. If so, then 
> I think the 
> >rule would have to be that the o-line MUST remain the same, but a 
> >recipient MUST be prepared for it to be different and in that case 
> >pretend its the same.
> 
> Chapter 8 or RFC3264 says:
> 
> "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."
> 
> So, we should not say that the o-line MUST remain the same, 
> but the session id (and most other parameters, I assume) MUST 
> remain the same.
> 
> Regards,
> 
> Christer
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> > 
> > 
> > > Alternatively, I can think of adding an option tag that
> > will indicate
> > > what kind of o-a model the endpoint supports, but I suspect
> > this would
> > > be overkill.
> > 
> > Yes, its overkill. There isn't a 'feature' here at all.
> > 
> > -Jonathan R.
> > 
> > 
> > -- 
> > Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
> > Cisco Fellow                                   Parsippany, NJ 
> > 07054-2711
> > Cisco Systems
> > [email-masked]                              FAX:   (973) 952-5050
> > http://www.jdrosen.net                         PHONE: (973) 952-5000
> > http://www.cisco.com
> > 
> 
> 
> _______________________________________________
> 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: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Jul 2007 19:18:30 -0400

Brian,

I agree that there is no one place that hits you over the head with the 
relationship. But there is more than the one sentence in 3261. To that 
you add 3262, 3311 which all add other ways to weave the offer/answer 
excahnges of 3264 into a sip session. They really don't make a lot of 
sense except *for sip* except in the context of a sip session.

It would be entirely possible to use 3264 with some other protocol, in 
which case I think you would have to assume that what ever protocol that 
was would define the session context.

3264 is entirely silent on what to do if the session id in the o-line 
changes.

	Paul

---

From: "Brian Stucker" <[email-masked]>
Date: Mon, 2 Jul 2007 18:42:28 -0500

Agree in general, but was focusing solely on the modification aspect.
Obviously there's a considerable amount of text in 3261 that talks about
SDP.

I think you and I (and some others) emailed a bit before this chain
started. At the time I did look at RFC-3311 as well at the time, and
again, nothing bangs you over the head that relates to session
modification.

My overall point was, that it seems like folks are saying that *for SIP*
the o-line is irrelevant in SDP because nobody has clearly stated what
calamity will occur if you don't get it correct, that it's probably safe
to ignore (as long as the m-lines make sense) and that to change it you
have to change the SIP dialog as well (INVITE with replaces).

It seems like what we have is an agreement, by many but not all, that is
built on a few general assumptions, and not a complete specification. By
not covering the error cases explicitly it's not (at least very)
explicitly calling those cases out as errors other than, in general, if
you don't like the SDP you can always 488 it (i.e. call failure is
always an option).

I think the petina of completeness is being conferred upon the existing
text simply because it's taken awhile since it was written for people to
get into *interesting* uses for SDP as far as weaving is concerned.

It might be interesting to throw up two slides at the upcoming meeting,
one with case A, and another with case B and see how many people raise
their hands for each as the intended meaning of the existing text.

Regards,
Brian

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Monday, July 02, 2007 6:19 PM
> To: Stucker, Brian (RICH1:AR00)
> Cc: Christer Holmberg (JO/LMF); Jonathan Rosenberg; Darshan 
> Bildikar; [email-masked]
> Subject: Re: [Sipping] Relationship between SIP session and 
> SDP session
> 
> Brian,
> 
> I agree that there is no one place that hits you over the 
> head with the relationship. But there is more than the one 
> sentence in 3261. To that you add 3262, 3311 which all add 
> other ways to weave the offer/answer excahnges of 3264 into a 
> sip session. They really don't make a lot of sense except 
> *for sip* except in the context of a sip session.
> 
> It would be entirely possible to use 3264 with some other 
> protocol, in which case I think you would have to assume that 
> what ever protocol that was would define the session context.
> 
> 3264 is entirely silent on what to do if the session id in 
> the o-line changes.
> 
> 	Paul
> 
> Brian Stucker wrote:
> > Guys, without necessarily disagreeing with what folks have 
> said here, 
> > I think the disconnect or "creative interpretation" of RFC-3264 is 
> > SDP session state is tied directly to the SIP session state. The 
> > session id and version information in the SDP is vestigial as it is 
> > superceded by the callid/tags/cseq present in the 
> lower-layer SIP signaling.
> > 
> > Case B:
> > ----------
> > Case A seems to be what's being stated by some on this 
> thread by some 
> > by way of INVITE-replaces usage and ignoring the o-line, in 
> that all 
> > SDP is useful for is media description and SIP is where the 
> real meat 
> > of keeping SDP "sessions" in coherent order.
> > 
> > However, case B is what RFC-3264 appears to be written towards, and 
> > even the change log in RFC-3261 outright states: "SDP 
> processing has 
> > been split off into a separate specification [RFC 3264], and more 
> > fully specified as a formal offer/answer exchange process that is 
> > effectively tunneled through SIP."
> > 
> > own. However, if you read, very carefully (blink and you'll 
> miss it) 
> > to RFC-3261, section 14.1 you'll see the following:
> > 
> >> Subject: RE: [Sipping] Relationship between SIP session and SDP 
> >> session
> >>
> >>
> >> Hi,
> >>
> >> 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."
> >>
> >> So, we should not say that the o-line MUST remain the 
> same, but the 
> >> session id (and most other parameters, I assume) MUST remain the 
> >> same.
> >>
> >> Regards,
> >>
> >> Christer
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >> 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: Paul Kyzivat <[email-masked]>
Date: Mon, 02 Jul 2007 22:29:28 -0400

I don't disagree. As I've stated, since no guidance is given about what 
should/will happen if the session id changes, the only safe thing to do 
is ensure that you keep it constant when sending SDP within a sip 
session. We can get opinions about what should happen in other cases, 
but I doubt such opinions are normative.

	Paul

---

From: [email-masked]
Date: Tue, 3 Jul 2007 14:36:46 -0400

The problem, IMHO, is not what the specs say, or even what would be a
Good Idea.  (All of those militate toward the rule that you can't
change the SDP session ID.)  The problem is that people have
implemented the "music on hold" function by having the UA establish a
new SIP session with the music-on-hold source, and then copying the
SDP from the MOH source into a re-INVITE sent to the other UA.  This
has the tremendous advantage that the MOH goes directly from the MOH
source to the "held" UA, with savings in effort and direct codec
negotiation.  This technique was even shown in early versions of the
service-examples I-D.

It has the disadvantage that it violates the specifications.

I suspect that other audio processing activities use similar tricks.

If we're going to try to get people to return to strict adherence to
the rule, we need to have a plausible replacement for the current,
incorrect techniques.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 03 Jul 2007 20:36:43 +0100

Yes, and likewise for well-established techniques such as 3PCC transfer.

John 

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 03 July 2007 19:37
> To: [email-masked]

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 04 Jul 2007 17:47:44 -0400

In most cases that technique, with a minor tweak, can still work. The UA 
just needs to manipulate the SDP to make it compliant. In general it can 
keep the same IP addresses, ports, etc. - most of the SDP. The o-line 
needs to be rewritten, and m-lines may need to be rearranged if there 
was more than one in the original dialog.

There are limitations to this approach, but it is likely to be 
sufficient for this case.

	Paul