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

[Bernard Aboba <[e-mail]>]

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