Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

Bernard Aboba <> Tue, 07 May 2013 21:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8B9BD21F8F2C; Tue, 7 May 2013 14:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.598
X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 15y4-BNv82iq; Tue, 7 May 2013 14:56:11 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3C5AD21F8F03; Tue, 7 May 2013 14:56:11 -0700 (PDT)
Received: from BLU169-W108 ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Tue, 7 May 2013 14:56:10 -0700
X-EIP: [izp0FB9rnfTVCJ71FBPs+TcF4RFmoqVd5NwWkxvuy8M=]
X-Originating-Email: []
Message-ID: <BLU169-W108D56DF61B85814543873C93BA0@phx.gbl>
Content-Type: multipart/alternative; boundary="_a6681fa6-d553-4a7a-9cfe-d3526eb65904_"
From: Bernard Aboba <>
To: Roni Even <>, 'Justin Uberti' <>, "" <>, "" <>
Date: Tue, 7 May 2013 14:56:10 -0700
Importance: Normal
In-Reply-To: <008701ce4b21$a0997aa0$e1cc6fe0$>
References: <> <>, <>, <008701ce4b21$a0997aa0$e1cc6fe0$>
MIME-Version: 1.0
X-OriginalArrivalTime: 07 May 2013 21:56:10.0889 (UTC) FILETIME=[AF89DF90:01CE4B6D]
Subject: Re: [MMUSIC] [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 07 May 2013 21:56:18 -0000

Roni said:  
3.       The draft, as far as I can tell, is discussing point to point calls and full meshed conferences. I think we need to look at other topologies including a centralized MCU doing video switch, for example.
[BA] There should be an evaluation against the RTP topology bis draft which would include assessment of compatibility.  In addition to "video switch" I would be interested in RTP translator compatibility as well. 

4.       In section 4.1 you suggest using the MSID as an indication for supporting plan B. I think that this may be RTCWEB specific and other usages like CLUE may use a different way to associate an SSRC to a Media Capture. My proposal is to use maxssrc. 

[BA] Among other things, putting maxssrc in the Offer partially addresses the issue of being able to receive streams before the Answer is received.  However, since the Offerer will not know the SSRCs that it is expected to receive there has got to be a way to map the incoming streams to WebRTC mediastreams.   

5.       I have a question about the last paragraph of section 4.2. Currently the answerer can start sending media immediately when getting the offer in parallel to sending the SDP answer since the offer includes receive capabilities and receive transport address. Are you suggesting that media will flow only after the 3 way handshake?
[BA] Yes, I think that is the implication, though it doesn't seem either necessary or desirable to me.  Actually, I don't think that "Peer B" will be able to send until it gets an Answer to its Offer (the second Offer/Answer exchange), because it won't know what streams "Peer A" is prepared to accept (assuming there is no maxssrc in the initial offer).