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

Christer Holmberg <christer.holmberg@ericsson.com> Fri, 27 September 2013 19:15 UTC

Return-Path: <christer.holmberg@ericsson.com>
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 7CD4921F9E68 for <rtcweb@ietfa.amsl.com>; Fri, 27 Sep 2013 12:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.685
X-Spam-Level:
X-Spam-Status: No, score=-5.685 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 lan5Y2qaZxt4 for <rtcweb@ietfa.amsl.com>; Fri, 27 Sep 2013 12:15:26 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CD6DD21F9E26 for <rtcweb@ietf.org>; Fri, 27 Sep 2013 12:15:18 -0700 (PDT)
X-AuditID: c1b4fb25-b7eff8e000000eda-04-5245d9450897
Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2C.28.03802.549D5425; Fri, 27 Sep 2013 21:15:17 +0200 (CEST)
Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0328.009; Fri, 27 Sep 2013 21:15:17 +0200
From: Christer Holmberg <christer.holmberg@ericsson.com>
To: Justin Uberti <juberti@google.com>, "Cullen Jennings (fluffy)" <fluffy@cisco.com>
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnZyWEAgAAwyzyAAAVFBw==
Date: Fri, 27 Sep 2013 19:15:16 +0000
Message-ID: <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>
References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1166BED56@xmb-aln-x02.cisco.com>, <CAOJ7v-35pjc-w_vgNCxE8dwfp9jh_cyGHR6_Cun8WAX4iCFNMQ@mail.gmail.com>
In-Reply-To: <CAOJ7v-35pjc-w_vgNCxE8dwfp9jh_cyGHR6_Cun8WAX4iCFNMQ@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.20]
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE0DBESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrOLMWRmVeSWpSXmKPExsUyM+Jvra7rTdcgg087TSw6JrNZbJ0qZLH2 Xzu7A7PHlN8bWT0WbCr1WLLkJ1MAcxSXTUpqTmZZapG+XQJXxozpN1kKTntUTPr5kK2B8a5V FyMnh4SAicSjC9MYIWwxiQv31rN1MXJxCAkcZpRoWX6fCcJZwijxsHs5cxcjBwebgIVE9z9t EFNEIFxi2kYVkF5mAXWJO4vPsYPYwgLREo9WTGQDsUUEYiR2nf/CAmE7SfTNu8wEYrMIqEr0 /r0NVs8r4Cux5v0cqFVXGSWWHL0PluAUCJRofjwbbBAj0HHfT61hglgmLnHryXwmiKMFJJbs Oc8MYYtKvHz8jxXCVpS4On05VH2+xP9DvWwQywQlTs58wjKBUXQWklGzkJTNQlIGETeQeH9u PjOErS2xbOFrKFtfYuOXs4wQtrXEoZ4vrMhqFjByrGJkz03MzEkvN9rECIy8g1t+q+5gvHNO 5BCjNAeLkjjvh7fOQUIC6YklqdmpqQWpRfFFpTmpxYcYmTg4pRoYNfLul+hHS4c35cQu2Kks I7KC6+YB5k9PPswqX781XuWtjOn2VQbnxD6F+8w0Dvz+7JFc6GHO6ClW8gnqpoZrUhVWMpiV PWlT0fv041tI1fpODxOpukqznLv6G0+Ha+a2Lf9T5jX7EOeEBtXLCzaskPZqjrXkavzb3hPa bDbHfZH5JJWzktxKLMUZiYZazEXFiQCArwlyigIAAA==
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [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: Fri, 27 Sep 2013 19:15:32 -0000

Hi,



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

>> Lets use NTP
>

> It's not necessary to use NTP, since the session-id is already random. Starting the session id at zero makes it easier for developers see the changes to the session id. I can spell this out in the next version of the document.

I assume you mean the session version, because that is what is currently zero.

But, I am sure there is a reason why SDP recommends NTP. So, again, if we want to change that, we shall discuss it in MMUSIC.

And, if we agree to change it, clearly document and justify it.



>>> 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.
>>>
>>>
>> Yep - I think this should be offers are created with RTP/SAVPF for audio and video and system can reeve offers with SAVPF or SAVP
>
> Currently the document specifies what to do with media lines, with later discussion of handling the SCTP line. Do you think the current information is not sufficiently descriptive?

My point was that we need to be more clear on what is generic, what is RTP, and what is SCTP. But, as you say SCTP text is still to be added, that clarification can be done when the SCTP text is added.



>> 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
>>                into.”
>>
>> 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?
>
>
> no the initial offer will not have identical stuff other than on lines that "bundle-only"

Assuming you by identical mean port zero, we'll still have to agree on that. But, that discussion belongs to MMUSIC.







>>> Q_6:      BUNDLE
>>>
>>> We’ll probably also need some text about BUNDLE.
>>>
>>

>> yep - but plan is to match up with unified plan
>>
>Can you be specific about what more you think needs to be said? The createAnswer treatment of BUNDLE is one clear thing that is currently missing.



I want to have text covering both the 1st (unique address) and 2nd (shared address) Offer.



And, when a PeerConnection is created due to forking (ie you use a separate PeerConnection for each forked leg of a session), I assume already the 1st Offer for that PeerConnection can have a shared address (as the remote entity has indicated support for BUNDLE). That also needs to be covered.





Regards,



Christer