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

["Roni Even" <[e-mail]>]

Hi,

I think that plan B is the right direction. I am wondering if this should be discussed in RTCWEB or MMUSIC

 

I like the proposed solution for multicast support but there is also an individual draft in MMUSIC see http://tools.ietf.org/html/draft-westerlund-avtcore-rtp-simulcast-02 . I think that it will be good to have a separate document on simulcast support

 

Some comments

 

1.       In section 3.1 when talking about using more than one m-line for a media type I think that there are other cases when this may be required . for example, if an attribute is not specified at SSRC level or if the SDP will be simpler when using multiple m-line  )describing different codec combinations

2.       In section 3.2 the document says that collision will not happen if the answerer sees the SDP from the Offer. I am not sure it will work when joining a multipoint conference since the offer is joining an existing session and do not know what SSRC have been used. I think that the issue is handled in RFC5576 so you can point at it.

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.

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. I think that it will be needed since an offer may include more options than can be really sent by the offerer and the maxssrc can tell the answerer how many it can select. It can also tell the answerer how many simultaneous RTP streams the offerer can receive. Otherwise it may be better to have a specific identifier that will tell that multiple RTP streams in an m-line are supported.

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?

6.       Small nit on section 5.1.4, according to section 8 of the Lennox source selection draft, the third offer must have sending:on for the streams that are being sent so probably need a=ssrc:1 msid:left-mic sending:on

 

 

Roni Even

 

 

 

 

 

From: [e-mail] [mailto:[e-mail]] On Behalf Of Justin Uberti
Sent: 03 May, 2013 9:09 AM
To: [e-mail]; [e-mail]
Subject: [rtcweb] Fwd: New Version Notification for draft-uberti-rtcweb-plan-00.txt

 

Scribbled down the basic concepts of what I have been referring to as "Plan B" - a way to signal multiple MediaStreamTracks in SDP without needing a separate m= line for each.

 

Hopefully this will make discussion of this topic easier.

 

---------- Forwarded message ----------
From: <[e-mail]>
Date: Thu, May 2, 2013 at 10:46 PM
Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
To: Justin Uberti <[e-mail]>



A new version of I-D, draft-uberti-rtcweb-plan-00.txt
has been successfully submitted by Justin Uberti and posted to the
IETF repository.

Filename:        draft-uberti-rtcweb-plan
Revision:        00
Title:           Plan B: a proposal for signaling multiple media sources in WebRTC.
Creation date:   2013-05-03
Group:           Individual Submission
Number of pages: 15
URL:             http://www.ietf.org/internet-drafts/draft-uberti-rtcweb-plan-00.txt
Status:          http://datatracker.ietf.org/doc/draft-uberti-rtcweb-plan
Htmlized:        http://tools.ietf.org/html/draft-uberti-rtcweb-plan-00


Abstract:
   This document explains how multiple media sources can be signaled in
   WebRTC using SDP, in a fashion that avoids many common problems and
   provides a simple control surface to the receiver.




The IETF Secretariat

 

 

  _____