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

On 05/07/2013 02:51 PM, Roni Even wrote:
>
> Hi,
>
> I think that plan B is the right direction. I am wondering if this 
> should be discussed in RTCWEB or MMUSIC
>

Good question.

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

I'm not sure the multipoint conference scenario (using a mixer, 
transport relay or multicast) is in scope here. Those scenarios can't be 
done with offer/answer anyway.

With scenarios that do centralized call termination (and not using 
CSRC), doing per-leg SSRC allocation is reasonable.

> 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:*rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] *On 
> Behalf Of *Justin Uberti
> *Sent:* 03 May, 2013 9:09 AM
> *To:* rtcweb@ietf.org; mmusic@ietf.org
> *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: <internet-drafts@ietf.org <mailto:internet-drafts@ietf.org>>
> Date: Thu, May 2, 2013 at 10:46 PM
> Subject: New Version Notification for draft-uberti-rtcweb-plan-00.txt
> To: Justin Uberti <justin@uberti.name <mailto:justin@uberti.name>>
>
>
>
> 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
>
> ------------------------------------------------------------------------
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic