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

On 11/03/2011 08:15 PM, Christer Holmberg wrote:
> Hi Cullen,
>
> I am not sure I receied a reply from you (or anyone else) to the questions below.
>
> Regards,
>
> Christer
>
> -----Original Message-----
> From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Christer Holmberg
> Sent: 19. lokakuuta 2011 15:50
> To: Cullen Jennings; rtcweb@ietf.org; public-webrtc@w3.org
> 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?
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...
> 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: rtcweb-bounces@ietf.org
>> [mailto:rtcweb-bounces@ietf.org] On Behalf Of Cullen Jennings
>> Sent: 15. lokakuuta 2011 6:09
>> To: rtcweb@ietf.org; public-webrtc@w3.org
>> 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
>> rtcweb@ietf.org
>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>