- From: Randell Jesup <randell-ietf@jesup.org>
- Date: Fri, 19 Apr 2013 11:13:50 -0400
- To: public-webrtc@w3.org
On 4/19/2013 9:47 AM, Iñaki Baz Castillo wrote: > 2013/4/19 Harald Alvestrand <harald@alvestrand.no>: >> So first: >> >> - What do you mean by "hold"? > "Putting a peer on hold" means: > > 1) Muting my local streams. > 2) And tell the peer about it. > > Step 2 in SDP is achieved by re-sending my local SDP to the peer with > "a=sendonly" or "a=inactive" (better) within each "m" section. > The peer accepts it by sending its remote SDP with "a=recvonly" or "a=inactive". Well, that's *one* definition of Hold. Another (perhaps more common) one is: 1) changing my local streams to muzak/video-slate 2) stop local playback of incoming audio/video 3) optionally renegotiating as sendonly, but for Hold this is generally a Bad Idea, as it mean un-hold requires renegotiation, which is not expected by most people Black/silence is also confusing to the other user (especially the black video) - we had a lot of experience with this and non-techy users at WorldGate. For some reason with video people assume something has failed, while with audio they're a little more forgiving (in a situation where someone might put them on Hold). >> - Where is the specification of how other people are using SDP to achieve >> the thing you mean? > RFC 4566 "SDP": > > http://tools.ietf.org/html/rfc4566#section-6 > > > > Of course anyone can notify the peer about "hold" in tons of ways, bu > when dealing with SIP and SDP (and WebRTC deals with SDP) IMHO it > should be possible to reuse the SDP itself for those kind of common > features. > -- Randell Jesup randell-ietf@jesup.org
Received on Friday, 19 April 2013 15:16:30 UTC