Subject: [Sip] New SDP session within old SIP session?

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 18 May 2005 07:05:06 +0200

Hi,

Chapter 8 (Modifying the session) in RFC3264 says the following:
 
"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.  However, the answerer MUST generate a valid answer (which MAY be the same as the previous SDP from the answerer, or MAY be different), according to the procedures defined in Section 6."

My questions are:

1. The text says that when the session (I assume the text talks about an SDP session, not a SIP session) is modified, the o= line must be identical, except for the version part. But, is it allowed, within the SAME SIP session, to offer a NEW SDP session, ie change the session-id part of the o= line? The RFC doesn't describe it, but it doesn't seem to forbid it either...

2. If the answer to the first question is "yes", how does it affect the rules about matching m= lines etc? If I offer a new SDP session, does the offer still have to contain the same number (or more) of m= lines as the previous offer, which was for the old SDP session?

Regards,

Christer Holmberg
LM Ericsson

_______________________________________________
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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2005 08:55:42 -0400

> 1. The text says that when the session (I assume the text talks about an SDP session, not a SIP session) is modified, the o= line must be identical, except for the version part. But, is it allowed,…

I have always assumed that you may only modify the existing session.
(If you want to establish a new one you can use INVITE/Replaces.)

It might be interesting to consider relaxing this, but I think it would 
open Pandora's Box.

Note that it is the *offerer* that modifies an existing session. The 
answerer isn't constrained this way. It is only constrained by 
offer/answer to provide an answer consistent with the offer. Without 
this it would be more difficult to make 3pcc work. So, by sending offers 
in opposite directions it is possible to fully change the O-lines on 
both ends.

	Paul

---

From: "Dale Worley" <[email-masked]>
Date: Wed, 18 May 2005 10:03:46 -0400

> From: Christer Holmberg (JO/LMF)
>
> My questions are:
>
> 1. The text says that when the session (I assume the text
> talks about an SDP session, not a SIP session) is modified,
> the o= line must be identical, except for the version part.
> But, is it allowed, within the SAME SIP session, to offer a
> NEW SDP session, ie change the session-id part of the o=
> line? The RFC doesn't describe it, but it doesn't seem to
> forbid it either...

I've been assuming that the section in question would be better phrased:

"When issuing an offer that modifies the SDP of the SIP 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.  Alternatively, the version
in the origin line is not incremented and the SDP MUST be
identical to the SDP with that version number.  ..."

So I would say that it is assumed that you cannot start a different SDP
session within the SIP session.

Dale

---

From: "JOHN J. BARTON" <[email-masked]>
Date: Wed, 18 May 2005 09:44:06 -0700

Is there really two different things, one a "SIP-session" and the other 
an "SDP-session"?  I thought not: there is just a session, initiated by 
SIP and described by SDP.  So my version would be:

"When issuing an offer that modifies the SDP of 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.  Alternatively, the version
in the origin line is not incremented and the SDP MUST be
identical to the SDP with that version number. "

Then I would say that the concept of "a different SDP session" is 
meaningless.  There is only a session.  An offer that modifies the SDP 
offers a modification of that session.  The purpose of incrementing the 
version is to signal the modification.  No increment means no modification.

Are there really two different sessions, an inner and outer kind?

John.

-- 
John J. Barton              IBM Almaden Research Center
http://www.almaden.ibm.com/cs/people/bartonjj/index.htm

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2005 13:39:14 -0400

> Are there really two different sessions, an inner and outer kind?

I think there is a difference here, although we may not have the 
terminology to discuss it concisely. As with most things having to do 
with offer/answer, 3pcc brings out the corner cases. Consider:

	             |---------------C
	             |
	A------------B
	             |
	             |---------------D

where A,C,D are UAs and B is a B2BUA 3pcc controller.

Initially B sets up a call between A and C. From a SIP signaling 
perspective there are two sessions: A-B and B-C. But if B did the 3pcc 
in the conventional way, relaying offers and answers, then there is a 
single media session A-C.

Now consider what happens when B decides to transfer the call. It first 
sends an offerless reinvite to A, causing A to return an offer. A may 
choose to return an offer unchanged from before, or it may choose to 
include a change in the offer. B then decides not to relay that on to C, 
but instead to initiate a new session with D and send the offer there.

Note that in this case the *answer* will have an o-line unrelated to the 
prior one. We end up with a different media session A-D. We continue to 
have the sip session A-B and a new one B-D. The old sip session B-C and 
media session A-C go away.

	Paul

---

From: "JOHN J. BARTON" <[email-masked]>
Date: Wed, 18 May 2005 11:08:54 -0700

reply inline below...

Paul Kyzivat wrote:
> 
> 
> JOHN J. BARTON wrote:
> 
>> Is there really two different things, one a "SIP-session" and the 
>> other an "SDP-session"?  I thought not: there is just a session, 
>> initiated by SIP and described by SDP.  So my version would be:
>>
>>
>> offers a modification of that session.  The purpose of incrementing 
>> the version is to signal the modification.  No increment means no 
>> modification.
>>

I notice that you didn't need to say "SDP session" in your explanation. 
I see three sessions, AB BC and BD.  During the transfer, the 
description of the AB session changes from the one BC negotiated to the 
one BD negotiated.  So I believe that B is obligated by the standard to 
answer A's offer with an SDP containing A's o= line with an incremented 
version. This is B's answer to A's offer.  It happens that B computed 
its answer by offering to D, but that does not matter to A.  For A it's 
an AB session, not a BD or AD session.

The AC and AD media sessions are no more of an issue than media sessions 
in conventional SIP.  Whether RTP packets flow to C or B or D doesn't 
matter to SIP.

Doesn't that sound right?

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 May 2005 15:42:39 -0400

JOHN J. BARTON wrote:
>>> meaningless.  There is only a session.  An offer that modifies the 
>>> SDP offers a modification of that session.  The purpose of 
>>> incrementing the version is to signal the modification.  No increment 
>>> means no modification.
>>>
>> Now consider what happens when B decides to transfer the call. It 
>> first sends an offerless reinvite to A, causing A to return an offer. 
>> A may choose to return an offer unchanged from before, or it may 
>> choose to include a change in the offer. B then decides not to relay 
>> that on to C, but instead to initiate a new session with D and send 
>> the offer there.
>>
>> Note that in this case the *answer* will have an o-line unrelated to 
>> the prior one. We end up with a different media session A-D. We 
>> continue to have the sip session A-B and a new one B-D. The old sip 
>> session B-C and media session A-C go away.
> 
> 
> I see three sessions, AB BC and BD. 

Maybe I didn't say it, but I meant it. AB, BC, and BD are sip sessions. 
Those pairs have sip signaling relationships with one another. But there 
is no sip signaling relationship between AC or AD.

However I can, arguably, make the case that there are SDP sessions AC 
and AD, and none involving B. This is because B is simply acting as a 
signaling relay. While A is aware of B and not C or D from a sip 
perspective, A is aware first of C and later of D from a media 
perspective, and is never involved with B for media.

> During the transfer, the 

I will disagree with you there. That is certainly not the way 3pcc is 
usually implemented (though it could be), and it is not required by 
3264. While there is a requirement on the offerer to use the old o-line, 
and increment the version if it changes, there is no corresponding 
requirement on the answerer. The answer can have any o-line as long as 
the answer is consistent with the offer.

I agree there are some interesting applications where B manipulates the 
SDP, but there are many common cases where that is not required and the 
B2BUA can be simpler.

> Doesn't that sound right?

I agree that you can choose to view it that way. But viewing B as 
uninvolved in the offer/answer is also a useful viewpoint.

	Paul