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

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 01 Jun 2007 11:23:08 -0400

Perhaps I am missing something, but I don't understand what *problem* we 
are trying to solve.

I think RFC 3264 is pretty clear that the o line ID remains fixed, and 
there is a 1-1 mapping of an SDP to a SIP session. Thus, an RFC 3264 
compliant endpoint would never change it.

As with anything else in SIP, we encourage folks to be strict on sending 
and lenient on receiving. So it is appropriate IMHO to not validate this 
on receipt, and to proceed anyway with a session as if the origin line 
had not changed. Of course, this is an implementation decision, as is 
any treatment of requests which are not compliant to the specs.

So, what more do we need to do here? Is someone saying that there is a 
REQUIREMENT here to be able to change SDP sessions and to define some 
kind of new semantic for it? If so, someone needs to clearly state it.

-Jonathan R.

Robert Sparks wrote:

> 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:
> 
>>
>>
>> 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
> 
> 
> 
> 
> _______________________________________________
> 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
> 

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

---

From: [email-masked]
Date: Sun, 3 Jun 2007 18:00:06 -0400

From: Jonathan Rosenberg <[email-masked]>

I fear that there is plenty of equipment out there that assumes that
changing the o line will work, e.g., for music-on-hold purposes.  I
expect that the devices use the same rules as for
INVITE-with-Replaces, as someone mentioned.

But this raises the question of why changing the o line was originally
forbidden -- I can see why the request SDP and response SDP must have
correlated m lines, etc., but what is gained by requiring each
revision of SDP to be in the same "series"?

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 03 Jun 2007 19:57:49 -0400

> INVITE-with-Replaces, as someone mentioned.

It had never dawned on me until this thread began that anybody would 
make such an interpretation. But obviously some do. I also expect that 
there is plenty of equipment out there that never looks at the o-line at 
all, and that assumes each subsequent offer/answer builds on the former 
as described in 3264.

Both behaviors are sometimes compatible with 3264, and are compatible 
with each other in that case. Both are extending behavior into areas not 
covered by 3264. We have three choices:
- leave things as they are
- state that the behavior for subsequent offers be the same if
   the session id in the o-line changes as it is when it stays the
   same and the version increments
- state that the behavior for subsequent offers where the session id
   in the o-line changes be the same as for a first offer.

Apparently all of these will probably break current practice for 
somebody.  We need to decide which leaves us in the best final position 
and which causes the least pain. If one answer causes least pain and a 
different answer leaves us in the best final position then we need to 
make a judgment call.

I don't have enough data to decide which will cause the least pain. I 
suspect that treating a new session id as an initial offer is probably 
the best final position, though I think it requires further 
consideration of the implications of that.

> revision of SDP to be in the same "series"?

I don't know.

	Paul

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 04 Jun 2007 11:16:37 -0700

Paul Kyzivat wrote:
>>    So, what more do we need to do here? Is someone saying that there 
>> is a    REQUIREMENT here to be able to change SDP sessions and to 
>> define some    kind of new semantic for it? If so, someone needs to 
>> clearly state it.
>>

What's the observable difference between the first and second choice?

> consideration of the implications of that.

I'm not sure what you mean by "treating a new session id as an initial 
offer". The new offer will have to obey the rules for how subsequent 
offers can differ from old ones, e.g. m= lines can be added and changed 
in certain ways but not removed.

Thanks,
Anders

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 13:29:06 -0500

On Jun 4, 2007, at 1:16 PM, Anders Kristensen wrote:

>>>    So, what more do we need to do here? Is someone saying that  
>>> there is a    REQUIREMENT here to be able to change SDP sessions  
>>> and to define some    kind of new semantic for it? If so, someone  
>>> needs to clearly state it.
>>>
>> It had never dawned on me until this thread began that anybody  
>> would make such an interpretation. But obviously some do. I also  
>> expect that there is plenty of equipment out there that never  
>> looks at the o-line at all, and that assumes each subsequent offer/ 
>> answer builds on the former as described in 3264.
>> Both behaviors are sometimes compatible with 3264, and are  
>> compatible with each other in that case. Both are extending  
>> behavior into areas not covered by 3264. We have three choices:
see below.
>> somebody.  We need to decide which leaves us in the best final  
>> position and which causes the least pain. If one answer causes  
>> least pain and a different answer leaves us in the best final  
>> position then we need to make a judgment call.
>> I don't have enough data to decide which will cause the least  
>> pain. I suspect that treating a new session id as an initial offer  
>> is probably the best final position, though I think it requires  
>> further consideration of the implications of that.
>
> I'm not sure what you mean by "treating a new session id as an  
> initial offer". The new offer will have to obey the rules for how  
> subsequent offers can differ from old ones, e.g. m= lines can be  
> added and changed in certain ways but not removed.

There's the disconnect. What I think Paul means (and I agree is a  
useful way to cast the question) is that you basically
_reset_ the SDP if you change the session-id - all state about any  
previous SDP is gone - you don't _need_ to keep
track of previous m-lines anymore.

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 04 Jun 2007 15:03:35 -0500

> track of previous m-lines anymore.

Yes, precisely.  That was the expected behavior that has driven
the motivation for the private email between Paul, Gonzalo and
myself, and subsequently this thread.  Some implemenations
simply assumed that changing the session-id will have the
effect of removing all previous SDP state and starting anew.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 22:39:06 +0200

Hi,

Is this something we should add to the offer-answer draft?

Regards,

Christer

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: 4. kesäkuuta 2007 2:58
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Sipping] Relationship between SIP session and 
> SDP session
> 
> 
> 
> It had never dawned on me until this thread began that 
> anybody would make such an interpretation. But obviously some 
> do. I also expect that there is plenty of equipment out there 
> that never looks at the o-line at all, and that assumes each 
> subsequent offer/answer builds on the former as described in 3264.
> 
> Apparently all of these will probably break current practice 
> for somebody.  We need to decide which leaves us in the best 
> final position and which causes the least pain. If one answer 
> causes least pain and a different answer leaves us in the 
> best final position then we need to make a judgment call.
> 
> pain. I suspect that treating a new session id as an initial 
> offer is probably the best final position, though I think it 
> requires further consideration of the implications of that.
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2007 16:50:54 -0400

It can be added *if* we can agree on *what* to add before the draft is done.

	Paul

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Mon, 4 Jun 2007 23:05:08 +0200

Hi,

If the changing of the session-id is allowed in SIP, I guess we should start by adding the different alternatives you listed how it could be intepreted.

If the changing of the session-id is not allowed in SIP, I guess we should say that the SDP shall be rejected.

If we don't know whether changing of the session-id is allowed or not in SIP, we should describe both cases above.

It's similar to the how-to-reject-an-offer-in-PRACK issue: we may not have an answer yet, but at least we document the issue, and potential solutions.

Regards,

Christer 

> Sent: 4. kesäkuuta 2007 23:51
> To: Christer Holmberg (JO/LMF)
> Cc: [email-masked]; [email-masked]
> >> Subject: Re: [Sipping] Relationship between SIP session and SDP 
> >> session
> >>
> >>
> >>
> anybody would 
> >> make such an interpretation. But obviously some do. I also expect 
> >> that there is plenty of equipment out there that never 
> looks at the 
> >> o-line at all, and that assumes each subsequent 
> offer/answer builds 
> >> on the former as described in 3264.
> >>
> compatible 
> >> with each other in that case. Both are extending behavior 
> into areas 
> >> not covered by 3264. We have three choices:
> >> position and which causes the least pain. If one answer 
> causes least 
> >> pain and a different answer leaves us in the best final 
> position then 
> >> suspect that treating a new session id as an initial offer is 
> >> probably the best final position, though I think it 
> requires further 
> >> 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: Anders Kristensen <[email-masked]>
Date: Mon, 04 Jun 2007 14:14:51 -0700

I am surprised that anyone would interpret the specs in a way that 
allows multiple SDP session for a single SIP dialog. There may not be 
any text that unambiguously says that there's a one-to-one relationship 
between SIP dialogs and SDP sessions but I think it's pretty clearly 
implicit throughout. For example, there are sections on establishing, 
modifying and terminating sessions but nowhere does it talk about 
creating a new session within the context of an existing dialog. In 
fact, to my knowledge, no RFC even hints at this so I'm wondering how 
many people have taken the view that this is legal.

I'd guess a lot more implementations ignore the session-id field 
altogether or else reject offers that change it or fail in various ways. 
As such I'd prefer the option that says that an SDP with a changed 
session-id should be treated same as if the session-id was the same but 
the version was incremented. Or else just clearly outlaw a change in 
session-id and leave the consequences unspecified.

Anders

---

From: Anders Kristensen <[email-masked]>
Date: Mon, 04 Jun 2007 14:30:48 -0700

Anders Kristensen wrote:
> implicit throughout.

Throughout 3261 and 3264, that is. Sorry.

Anders

  For example, there are sections on establishing,

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 04 Jun 2007 18:49:33 -0400

Christer Holmberg (JO/LMF) wrote:
> If the changing of the session-id is not allowed in SIP,
> I guess we should say that the SDP shall be rejected.

I think it is pretty clearly *not* allowed now by 3264.
But 3264 doesn't say what to do if you receive something which does it.

Since we are going for a BCP here, I don't think we can say to violate 
the requirement. But we could say what to do it is violated, assuming we 
can agree to that. We could also reiterate that you must not violate 
this requirement.

Going further, and making a change to allow the session id to be 
changed, regardless of what meaning we assign to that, seems to be out 
of scope for this document, though some people are asking for that.

If implementations are currently violating this, and there is any 
possibility that an extension here will make their behavior legal, then 
its unlikely they will change as a result of what we write. But perhaps 
this would be of help to new implementations that haven't thought about 
this.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 07 Jun 2007 15:28:07 -0400

I still don't see why this topic is confusing.

RFC3264 is clear that the session ID stays the same. Implementations, 
have, over time, simply ignored it. So, some folks started sending 
offers and answers with different session IDs, but they were treated as 
if they were the same. This is a natural consequence of the 
strict-on-send and liberal-on-receive behavior.

An interpretation that says that a change in sessionID causes an O/A 
restart is totally new functionality and not supported by any text 
anywhere. If you want to do such a restart, try INVITE+Replaces. Why do 
we need a new mechanism?

Thus I think its appropriate to clarify this in the offer-answer draft 
to say that there is only ever one session, and that you SHOULD have the 
o-line sessionID be the same, but changes in it are treated as if the 
sessionID weren't changed anyway, so it doesn't really matter.

-Jonathan R.

Paul Kyzivat wrote:

>> If the changing of the session-id is allowed in SIP, I guess we should 
>> start by adding the different alternatives you listed how it could be 
>> intepreted.
>>
>> If we don't know whether changing of the session-id is allowed or not 
>> in SIP, we should describe both cases above.
>>
>> It's similar to the how-to-reject-an-offer-in-PRACK issue: we may not 
>> have an answer yet, but at least we document the issue, and potential 
>> solutions.
>>
>> Regards,
>>
>> Christer
>>
>>> From: Paul Kyzivat [mailto:[email-masked]] Sent: 4. kesäkuuta 
>>> 2007 23:51
>>> Subject: Re: [Sipping] Relationship between SIP session and SDP session
>>>
>>>>>>    So, what more do we need to do here? Is someone saying
>>>>>
>>>>> that there is a
>>>>>
>>>>>>    REQUIREMENT here to be able to change SDP sessions and
>>>>>
>>>>> to define some
>>>>>
>>>>>>    kind of new semantic for it? If so, someone needs to
>>>>>
>>>>> clearly state it.
>>>>>
>>>>>> I fear that there is plenty of equipment out there that
>>>>>
>>>>> assumes that
>>>>>
>>>>>> changing the o line will work, e.g., for music-on-hold 
>>>
>>> purposes.  I
>>>
>>>>> - state that the behavior for subsequent offers where the 
>>>
>>> session id
>>>
>>> position then
>>>>> we need to make a judgment call.
>>>>>
>>>>> I don't have enough data to decide which will cause the 
>>>
>>> least pain. I
>>>
>>>>>> But this raises the question of why changing the o line was
>>>>>
>>>>> originally
>>>>>
>>>>>> forbidden -- I can see why the request SDP and response SDP
>>>>>
>>>>> must have
>>>>>

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 07:30:20 +0200

Hi,

Just to be clear, I assume we are not talking about the whole "o line".

Because, it also contains sess-version, which I think people SHALL change when they update the SDP within a session. 

If NOT updated, the receiver of the re-INVITE/UPDATE should be able to assume that the SDP has not changed, and that the request was sent for some other purpose (e.g. to update the remote target). 

Regards,

Christe

> From: Darshan Bildikar [mailto:[email-masked]] 
> Sent: 8. kesäkuuta 2007 7:25
> To: 'Jonathan Rosenberg'; 'Paul Kyzivat'
> Cc: [email-masked]; Christer Holmberg (JO/LMF)
> Subject: RE: [Sipping] Relationship between SIP session and 
> SDP session
> 
> 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.
> 
> Hence, if you say in the offer answer draft that the "o line" 
> really doesn't matter i.e. a SHOULD strength, inter 
> operability will break with implementations that implement 
> this exactly as per 3264.
> 
> I support normatively changing it i.e. remove this 
> restriction. Don't know however whether this can be done in 
> the offer-answer draft. 
> 
> We have certain hacks built into our AS, that involve 
> manually changing SDP when we really don't HAVE to. If this 
> restriction is relaxed, it would make our code a lot cleaner.
> 
> 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.
> 
> Darshan
> 
> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, June 08, 2007 12:58 AM
> To: Paul Kyzivat
> Cc: [email-masked]; Christer Holmberg (JO/LMF)
> RFC3264 is clear that the session ID stays the same. 
> Implementations, have, over time, simply ignored it. So, some 
> folks started sending offers and answers with different 
> session IDs, but they were treated as if they were the same. 
> This is a natural consequence of the strict-on-send and 
> liberal-on-receive behavior.
> 
> An interpretation that says that a change in sessionID causes 
> an O/A restart is totally new functionality and not supported 
> by any text anywhere. If you want to do such a restart, try 
> INVITE+Replaces. Why do we need a new mechanism?
> 
> Thus I think its appropriate to clarify this in the 
> offer-answer draft to say that there is only ever one 
> session, and that you SHOULD have the o-line sessionID be the 
> same, but changes in it are treated as if the sessionID 
> weren't changed anyway, so it doesn't really matter.
> 
> -Jonathan R.
> 
> Paul Kyzivat wrote:
> 
> > 
> > 
> >> If the changing of the session-id is allowed in SIP, I guess we 
> >> should start by adding the different alternatives you 
> listed how it 
> >> could be intepreted.
> >>
> >> If the changing of the session-id is not allowed in SIP, I 
> guess we 
> >> should say that the SDP shall be rejected.
> > 
> > 
> > the requirement. But we could say what to do it is 
> violated, assuming 
> > we can agree to that. We could also reiterate that you must not 
> > violate this requirement.
> > 
> > possibility that an extension here will make their behavior legal, 
> > then its unlikely they will change as a result of what we 
> write. But 
> > perhaps this would be of help to new implementations that haven't 
> > thought about this.
> > 
> >     Paul
> > 
> >>> It can be added *if* we can agree on *what* to add before 
> the draft 
> >>> is done.
> >>>
> >>>     Paul
> >>>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 08 Jun 2007 08:19:32 -0400

Darshan Bildikar wrote:

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

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

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Fri, 8 Jun 2007 22:27:46 +0200

Hi, 

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