- From: cowwoc <cowwoc@bbs.darktech.org>
- Date: Thu, 20 Feb 2014 12:12:08 -0500
- To: public-webrtc@w3.org
On 20/02/2014 12:07 PM, Tim Panton new wrote: > On 20 Feb 2014, at 09:44, piranna@gmail.com wrote: > >>> I'm not sure that's a compelling reason to separate the two, but it's a >>> possible reason, even in the absence of SDP modification. >>> >> I'm not saying to remove setLocalDescription(), I'm only saying that >> for most use cases is redundant to call to >> createOffer()/createAnswer() and inmediately to setLocalDescription(), >> so I'll change the spec to do the call implicitly and if some changes >> are required, let the user to do the call explicitly, overwritting >> this way the content of the local description with its custom one. >> This will make easier to new comers what's the call flow: >> >> createOffer() -> send() >> onmessage -> setRemoteDescription() >> createAnswer() -> send() >> onmessage -> setRemoteDescription() >> >> Honestly, if you need to call to setLocalDescription() with a modified >> SDP, you are not in "WebRTC 101" anymore... Why complicate it? > Except that WebRTC 101 - the example apprtc app does munge the SDP before calling > setLocal. > > function setLocalAndSendMessage(sessionDescription) { > sessionDescription.sdp = maybePreferAudioReceiveCodec(sessionDescription.sdp); > pc.setLocalDescription(sessionDescription, > onSetSessionDescriptionSuccess, onSetSessionDescriptionError); > sendMessage(sessionDescription); > } > > So even in the simplest cases you end up needing to intercept. > > T. Then my point applies even more strongly. We shouldn't be saying one thing ("SDP is not part of the API surface") but doing something else (doing SDP munging in reference implementation). Gili
Received on Thursday, 20 February 2014 17:13:05 UTC