Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2)

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 20:15:36 +0100

Hi Cullen,

I am not sure I receied a reply from you (or anyone else) to the questions below.

Regards,

Christer 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 19. lokakuuta 2011 15:50
To: Cullen Jennings; [email-masked]; [email-masked]
Cc: Jonathan Rosenberg
Subject: Re: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling - seq/sessionId vs sess-version/sess-id (Section 5.2.1 and 5.2.2)

Hi,

What is the relation between the seq/sessionId values and the SDP sess-version/sess-id values (part of the SDP o= line), and why do we need seq/sessionId in the first place?

AFAIK, the only reason for having the seq/sessionId values is when sending an OK message, since there will be no SDP (and therefor no SDP sess-version/sessionId). Or, are there any other reasons?

I think the draft should say something about the correlation.

And, IF we need seq/sessionId, should we say that the SDP sess-version/sess-id values must be identical - or, at least saying that they must be set and incremented according to the SDP rules? I think that would help in SIP/SDP interworking cases. Otherwise the interworking gateway will have to check, keep track of, and possibly modify, the sess-version/sess-id values.

Regards,

Christer

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Cullen Jennings
> Sent: 15. lokakuuta 2011 6:09
> To: [email-masked]; [email-masked]
> Cc: Jonathan Rosenberg
> Subject: [rtcweb] SDP Offer/Answer draft-jennings-rtcweb-signaling
> 
> 
> Jonathan and I submitted a new draft on setting up media based on the 
> SDP Offer/Answer model. The ASCII flows are a bit hard to read so 
> until I update them, I recommend reading the PDF version at
> 
> http://tools.ietf.org/pdf/draft-jennings-rtcweb-signaling-00.pdf
> 
> Clearly the draft is an early stage but we plan to revise it before 
> the deadline for the IETF 82. Love to get input - particularly on if 
> this looks like generally the right direction to go.
> 
> 
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
_______________________________________________
rtcweb mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/rtcweb

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 3 Nov 2011 20:33:54 +0100

Hi, 

>> Q2. Are there restrictions when it comes to changing information in a non-final 
>> answer and a final answer? Or, can the final answer be completely different from 
>> previously sent non-final ANSWERS? In "legacy" O/A there are restrictions.
>
> Any answer has to be a valid answer for the offer but other than that, no restrictions, 
> so the final answer can change everything from an earlier one. 

Is there a reason/use-case/requirement why we need to allow that? As far as I know, the reason behind this is ICE.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 4 Nov 2011 08:43:58 -0700

> Is there a reason/use-case/requirement why we need to allow that? As far as I know, the reason behind this is ICE.

There a bunch of use cases but to mention two: In the browser to browser case, imagine that you start sending audio in the first answer but need to wait for user feedback to find out if video can be added or not in the final answer. In a browser to SIP use case, the early media for 1-800-go-fedex.

Cullen

PS - Sorry for slow replies but we had the week before the -00 drafts, then the week before the -01 drafts, now I am at the W3C TPAC meeting for a week, then reading drafts weeks, then IETF so I suspect a bunch of this I won't really get to till after IETF but ….

---

From: Harald Alvestrand <[email-masked]>
Date: Sun, 06 Nov 2011 17:35:10 +0100

> What is the relation between the seq/sessionId values and the SDP sess-version/sess-id values (part of the SDP o= line), and why do we need seq/sessionId in the first place?
My reading of the RFC is that the sess-id of an ANSWER is uncorrelated 
with the sess-id of an OFFER, and that in some cases, the sess-version is.

RFC 3264 section 6:

6 Generating the Answer

    The answer to an offered session description is based on the offered
    session description.  If the answer is different from the offer in
    any way (different IP addresses, ports, etc.), the origin line MUST
    be different in the answer, since the answer is generated by a
    different entity.  In that case, the version number in the "o=" line
    of the answer is unrelated to the version number in the o line of the
    offer.

Section 8:

    Nearly all aspects of the session can be modified.  New streams can
    be added, existing streams can be deleted, and parameters of existing
    streams can change.  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.

 From the first example in section 10.1:
Offer:

    o=alice 2890844526 2890844526 IN IP4 host.anywhere.com

Answer:

    o=bob 2890844730 2890844730 IN IP4 host.example.com

Note the non-match, for both the sess-id and the version.

I was hoping that someone with deeper SDP knowledge would answer, that's 
why I didn't reply before...

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 9 Nov 2011 10:14:21 +0100

Hi Cullen, 

>>>> Q2. Are there restrictions when it comes to changing 
>>>> information in a non-final answer and a final answer? Or, can the final 
>>>> answer be completely different from previously sent non-final 
>>>> ANSWERS? In "legacy" O/A there are restrictions.
>>>> 
>>> Any answer has to be a valid answer for the offer but other than 
>>> that, no restrictions, so the final answer can change 
>>> everything from an earlier one.
>> 
>> Is there a reason/use-case/requirement why we need to allow 
>> that? As far as I know, the reason behind this is ICE.
>> 
> There a bunch of use cases but to mention two: In the browser 
> to browser case, imagine that you start sending audio in the 
> first answer but need to wait for user feedback to find out 
> if video can be added or not in the final answer. In a 
> browser to SIP use case, the early media for 1-800-go-fedex.

I think that could cause interoperability issues.

For example, assume that a gateway would map a more-to-come answer to a SIP 18x response.

Then, if the no-more-to-come answer is different, the gateway can't map it to SIP 200 response - at least not without chaning the SIP dialog identifier.

Also, if you map a more-to-come answer to a SIP 18x answer, and then receives a new SIP offer, the gateway *cannot* map it to a ROAP offer, as it is still wating waiting for the no-more-to-come answer.

Regards,

Christer

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 9 Nov 2011 07:37:41 -0700

> Then, if the no-more-to-come answer is different, the gateway can't map it to SIP 200 response - at least not without chaning the SIP dialog identifier.

Seems like it should be able to do this. Lets talk about this in Taipei - I suspect we are just talking past each other and both mean about the same thing. I'm not proposing any change to 3264.