- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Sun, 19 Aug 2012 21:29:15 +0200
- To: public-webrtc@w3.org
On 08/19/2012 05:46 PM, Eric Rescorla wrote: > The current RTCIceCandidate type has two ways of identifying the m-line, > an m-line index (sdpMLineIndex) and an sdpMid, corresponding > to the RFC 3388 media stream identification value. The reason for the index is that we can't guarantee that a remote offer will have unique labels on all its M-lines. For offers produced by WebRTC, we can choose to make them all have mid values (and they have to, if we use BUNDLE). > > http://dev.w3.org/2011/webrtc/editor/webrtc.html#rtcicecandidate-type > > [Constructor (optional RTCIceCandidateInit candidateInitDict)] > interface RTCIceCandidate { > attribute DOMString? candidate; > attribute DOMString? sdpMid; > attribute unsigned short? sdpMLineIndex; > stringifier DOMString (); > }; > dictionary RTCIceCandidateInit { > DOMString candidate; > DOMString sdpMid; > unsigned short sdpMLineIndex; > }; > > Is there a reason why it makes sense to have two of these? Since the > receiver of the candidate has no way of indicating which versions > they support, that means you need to support both, and translating > between them in the JS is going to be a pain in the ass. Also, it's > just another way for there to be disagreement (what happens if they > don't refer to the same m-line.) > > ISTM to me that it would make more sense to pick just one > of these (probably sdpMLineIndex) and stick with it. > > -Ekr >
Received on Sunday, 19 August 2012 19:29:32 UTC