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

Christer Holmberg <> Sat, 28 September 2013 06:52 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 58C3C11E817D for <>; Fri, 27 Sep 2013 23:52:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.677
X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.571, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id N3k80DBUSl-Y for <>; Fri, 27 Sep 2013 23:52:35 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AF8F711E8126 for <>; Fri, 27 Sep 2013 23:52:33 -0700 (PDT)
X-AuditID: c1b4fb30-b7f9a8e000005620-94-52467caf930b
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A5.03.22048.FAC76425; Sat, 28 Sep 2013 08:52:32 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.02.0328.009; Sat, 28 Sep 2013 08:52:31 +0200
From: Christer Holmberg <>
To: Justin Uberti <>
Thread-Topic: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
Thread-Index: AQHOti5khdNmMeesKEOgz91K2tbZBJnZyWEAgAAwyzyAAAVFB4AACS8AgAC38feAAAGv7Q==
Date: Sat, 28 Sep 2013 06:52:30 +0000
Message-ID: <>
References: <> <> <> <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrGLMWRmVeSWpSXmKPExsUyM+Jvre6GGrcgg+7jLBYdk9kstk4Vslj7 r53dgdljyu+NrB4LNpV6LFnykymAOYrLJiU1J7MstUjfLoErY3frVcaCrdYV81/MY2pg3GbY xcjJISFgIvF021p2CFtM4sK99WxdjFwcQgKHGSXWLp3KBOEsYZS49vIjUIaDg03AQqL7nzZI g4iAmsTDWbtYQWxmgQiJI6d62UBsYYFoiUcrJrJB1MRI7Dr/hQXCDpM4cXIhWJxFQFXi9rxP YDavgK/E+7UnoHY9YJJ40bqWEWQXp0CgRMsaDpAaRqDjvp9awwSxS1zi1pP5TBBHC0gs2XOe GcIWlXj5+B8rSKuEgKLE8n45iPJ8ibdTHzFDrBKUODnzCcsERtFZSCbNQlI2C0kZRNxA4v25 +cwQtrbEsoWvoWx9iY1fzjJC2NYSf05eYEVWs4CRYxUje25iZk56ufkmRmDcHdzy22AH46b7 YocYpTlYlMR5P7x1DhISSE8sSc1OTS1ILYovKs1JLT7EyMTBKdXAaH0gbd6m2c1v3VY5vr53 fKX6S5+3TxS3XzT+IKCpcUVsQf07a7U9Tk/Y3m++8K5OZaH3t5+cb2t/rHHp5Hl9NsPTblPU 5aj/0pPZQ0TN/h07KPXwjofd5F3vnBbueOrx9j1jj++xn4JbuPwaj22rWey3wPf4zUV1Xhse xp2rVdtls+s6d5MQR6oSS3FGoqEWc1FxIgBdtFfriQIAAA==
Cc: "Cullen Jennings (fluffy)" <>, "" <>
Subject: Re: [rtcweb] JSEP-04: Some comments on Section 5.2.1. and 5.2.2 (19th september)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 28 Sep 2013 06:52:41 -0000


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

>Sorry I was unclear - there is SCTP-specific text in the current document.

Ok, so while the content itself might be ok, at some point I'd like to have separate sub-sections for the generic stuff, the RTP specicif stuff, and the SCTP specific stuff.

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

> Acknowledged.


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


> Yes. Which may indicate the need for a setting on a PeerConnection to use a shared address on the initial offer, since it might have come from such a fork.