[rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)

Christer Holmberg <christer.holmberg@ericsson.com> Thu, 19 September 2013 10:08 UTC

Return-Path: <christer.holmberg@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 6A71D21F8517 for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 03:08:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.78
X-Spam-Status: No, score=-5.78 tagged_above=-999 required=5 tests=[AWL=0.468, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id N4aX4R1rnn1i for <rtcweb@ietfa.amsl.com>; Thu, 19 Sep 2013 03:08:21 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se []) by ietfa.amsl.com (Postfix) with ESMTP id B9F5921F8CB4 for <rtcweb@ietf.org>; Thu, 19 Sep 2013 03:08:19 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-a1-523acd128747
Received: from ESESSHC011.ericsson.se (Unknown_Domain []) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D3.16.03802.21DCA325; Thu, 19 Sep 2013 12:08:18 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([]) by ESESSHC011.ericsson.se ([]) with mapi id 14.02.0328.009; Thu, 19 Sep 2013 12:08:17 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Thread-Topic: JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: Ac61H8SXeXXAffdpQLKis+JdCZjjDA==
Date: Thu, 19 Sep 2013 10:08:16 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4A77DBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrALMWRmVeSWpSXmKPExsUyM+Jvja7QWasgg2VXJSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXRm/HA6aCp8EV2//dZm5gnOLR xcjJISFgInH36id2CFtM4sK99WxdjFwcQgKHGSWWX5zECOEsYZTYtf4uUxcjBwebgIVE9z9t kAYRAXWJyw8vgDUzC1RIrPm4GswWFvCRWHLtOBtETbDEoj1XGCFsPYm2O59YQWwWAVWJyau2 gdXwCvhKPJ61BCzOCHTE91NrmCBmikvcejKfCeI4AYkle84zQ9iiEi8f/2MFOUdCQFFieb8c iMkskC+xYIk0xERBiZMzn7BMYBSehWTQLISqWUiqIEp0JBbs/sQGYWtLLFv4mhnGPnPgMROy +AJG9lWM7LmJmTnp5UabGIGxcnDLb9UdjHfOiRxilOZgURLn3ax3JlBIID2xJDU7NbUgtSi+ qDQntfgQIxMHp1QD4w6+Gzs9BQ6YK8spznpYyznnQkvCriUy7uLS+yqS7hy45j59V2/T3XVJ 2ekZK58dUHn98MnM3I9S13S/MEqn2UQe9p20j5/vzJz7e15oMAkzlC+Yf+f12Wmtnt27lspm sfWfXjK18+SNW5xZPLax15e1qTv33W+w+zTpWfm5zSnxhw5ZPMl+X6LEUpyRaKjFXFScCADH HZfnYwIAAA==
Cc: "Cullen Jennings (fluffy@cisco.com)" <fluffy@cisco.com>
Subject: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
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: Thu, 19 Sep 2013 10:08:34 -0000


Section 5.2.1:

Q_1:      o- line <sess-version> initial value - deviation

What is the reason for recommending a <sess-version> zero value in the initial Offer, when the RFC says SHOULD use an NTP format timestamp?

I don't have any strong feelings, but in general: whenever we deviate from the "base" SDP procedures I think we should justify why.

Q_2:      o- line <sess-version> initial value - forking

When a new PeerConnection is created due to forking, the <sess-version> value must be based (incremented) on the value associated with the "mother" PeerConnection, for which the initial Offer of the whole communication session was created.

Q_3:      RTP

The text says:

"The <proto> field MUST be set to "RTP/SAVPF". "

But, that of course only applies to RTP based streams (not the data channel). Also, in general, it needs to be clear what information needs to be in every m- line, and what information is protocol specific. I would suggest to have a "General" sub-section, a "RTP" sub-section, etc.

Q_4:      BUNDLE

The text says:

"If a m= section is not being bundled into another m= section, it MUST
                generate a unique set of ICE credentials and gather its own set of
                candidates.  Otherwise, it MUST use the same ICE credentials and
                candidates that were used in the m= section that it is being bundled

As, when BUNDLE is used, the initial Offer will contain identical ICE candidates, does that mean that we will also include identical address information in the initial Offer?

I don't object to that - I just want to clarify, as it has impacts on the text in the BUNDLE spec :)

Section 5.2.2:

Q_5:      Offer when in "local-offer"

The text says:

"If the initial offer was applied using setLocalDescription, but an
                answer from the remote side has not yet been applied, meaning the
                PeerConnection is still in the "local-offer" state, the steps for
                generating an initial offer should be followed,"

I don't understand this. Why would you create a new Offer while you are waiting for an Answer to the previously sent Offer?

Also, when setRemote() is called, to which Offer does it apply?

Q_6:      BUNDLE

We'll probably also need some text about BUNDLE.