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

Harald Alvestrand <harald@alvestrand.no> Sun, 06 November 2011 16:35 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A959721F8495 for <rtcweb@ietfa.amsl.com>; Sun, 6 Nov 2011 08:35:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.999
X-Spam-Level:
X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_13=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id taYCs8LRYzGZ for <rtcweb@ietfa.amsl.com>; Sun, 6 Nov 2011 08:34:59 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 86A0E21F8491 for <rtcweb@ietf.org>; Sun, 6 Nov 2011 08:34:59 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C4DE39E0A3 for <rtcweb@ietf.org>; Sun, 6 Nov 2011 17:34:58 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u8ZGE1kMCS6t for <rtcweb@ietf.org>; Sun, 6 Nov 2011 17:34:57 +0100 (CET)
Received: from [10.154.240.196] (unknown [62.206.113.61]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 2838139E074 for <rtcweb@ietf.org>; Sun, 6 Nov 2011 17:34:57 +0100 (CET)
Message-ID: <4EB6B73E.6010501@alvestrand.no>
Date: Sun, 06 Nov 2011 17:35:10 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <15B0E3AD-3086-499A-8E79-7AE58B3376C4@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058522341F4A8B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A05852235789601@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05852235789601@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
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)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Nov 2011 16:35:00 -0000

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
>