Return-Path: 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 58C3C11E817D for ; Fri, 27 Sep 2013 23:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: 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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3k80DBUSl-Y for ; Fri, 27 Sep 2013 23:52:35 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id AF8F711E8126 for ; Fri, 27 Sep 2013 23:52:33 -0700 (PDT) X-AuditID: c1b4fb30-b7f9a8e000005620-94-52467caf930b Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id A5.03.22048.FAC76425; Sat, 28 Sep 2013 08:52:32 +0200 (CEST) Received: from ESESSMB209.ericsson.se ([169.254.9.146]) by ESESSHC013.ericsson.se ([153.88.183.57]) 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: <7594FB04B1934943A5C02806D1A2204B1C4AE733@ESESSMB209.ericsson.se> References: <7594FB04B1934943A5C02806D1A2204B1C4A77DB@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C4AE0DB@ESESSMB209.ericsson.se>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] 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\)" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Sep 2013 06:52:41 -0000 --_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Hi, >>>>> Q_3: RTP >>>>> >>>>> The text says: >>>>> >>>>> =93The field MUST be set to "RTP/SAVPF". =93 >>>>> >>>>> But, that of course only applies to RTP based streams (not the data c= hannel). Also, in general, it needs to be clear what information >>>>> needs to be in every m- line, and what information is protocol specif= ic. I would suggest to have a =93General=94 sub-section, a =93RTP=94 sub-se= ction, etc. >>>>> >>>>> >>>> Yep - I think this should be offers are created with RTP/SAVPF for aud= io and video and system can reeve offers with SAVPF or SAVP >>> >>> Currently the document specifies what to do with media lines, with late= r discussion of handling the SCTP line. Do you think the current informatio= n is not sufficiently descriptive? >> >> My point was that we need to be more clear on what is generic, what is R= TP, 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 t= he SCTP specific stuff. >>>>> Q_6: BUNDLE >>>>> >>>>> We=92ll 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 crea= teAnswer treatment of BUNDLE is one clear thing that is currently missing. >> >> I want to have text covering both the 1st (unique address) and 2nd (shar= ed address) Offer. > Acknowledged. > >> And, when a PeerConnection is created due to forking (ie you use a separ= ate 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. Excellent. Regards, Christer --_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_ Content-Type: text/html; charset="Windows-1252" Content-ID: <430FD3D9713482449AA7CFFBB67BC001@ericsson.com> Content-Transfer-Encoding: quoted-printable

Hi,

 

>>>>> Q_3:      RTP
>>>>>
>>>>> The text says:
>>>>>
>>>>> =93The <proto> field MUST be set to "RTP/SA= VPF". =93
>>>>>
>>>>> But, that of course only applies to RTP based streams = (not the data channel). Also, in general, it needs to be clear what informa= tion
>>>>> needs to be in every m- line, and what infor= mation is protocol specific. I would suggest to have a =93General=94 sub-se= ction, a =93RTP=94 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 SAV= P
>>>
>>> Currently the document specifies what to do with media li= nes, with later discussion of handling the SCTP line. Do you think the curr= ent 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 a= dded, that clarification can be done when the SCTP text is added.

>Sorry I was unclear - there is SCTP-specific text in the current d= ocument. 
 
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=92ll 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 us= e 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 PeerConnectio= n to use a shared address on the initial offer, since it might have come fr= om such a fork. 
 
Excellent.
 
Regards,
 
Christer
 
--_000_7594FB04B1934943A5C02806D1A2204B1C4AE733ESESSMB209erics_--