- From: Harald Alvestrand <harald@alvestrand.no>
- Date: Fri, 19 Apr 2013 15:16:12 +0200
- To: José Luis Millán <jmillan@aliax.net>
- CC: public-webrtc@w3.org
- Message-ID: <5171439C.5080000@alvestrand.no>
On 04/19/2013 03:04 PM, José Luis Millán wrote: > Hi, > > > > Engineering-wise: > > 1) Do you have a definition of what "on hold" means that we can > refer to? The term does not occur in > draft-ietf-rtcweb-use-cases-and-requirements. > > 2) Do you know of a consistent specification for how SDP is used > to achieve "on hold" in other systems, for instance SIP? If so, > can you point us to that specification? > > At the moment, I'm not even sure what "on hold" means in terms of > what media flows cease; in a JS-centric world, another > implementation that somewhat matches what you describe might be: > > 1) Alice calls "disable" on her outgoing audio and video > MediaStreamTracks. > > 2) Alice sends a message to Bob informing him that he's on hold > (through signalling, which is not standardized in WebRTC or RTCWEB). > > 3) Bob calls "disable" on his outgoing audio and video > MediaStreamTracks. > > > > SDP needs to be mangled to do this AFAIK since not even the W3C > specification defines how this is done at RTCPeerConnection level. Well, the first thing to define is what needs to be done, and why. In the sentence above, it's not clear what "this" refers to, even though you use the word twice. A major reason RTCPeerConnection handles don't exist is because we don't have a clear specification of what we need handles for. So first: - What do you mean by "hold"? - Where is the specification of how other people are using SDP to achieve the thing you mean? It's the job of people who want to use SDP mechanisms to achieve "hold" to make these things clear.
Received on Friday, 19 April 2013 13:16:41 UTC