- From: Paul Kyzivat <pkyzivat@alum.mit.edu>
- Date: Fri, 26 Apr 2013 19:13:36 -0400
- To: public-webrtc@w3.org
On 4/19/13 11:13 AM, Randell Jesup wrote: > 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 You can argue whether it is a bad idea, but is is commonly expected and done. You can view it as an optimization - suppressing transmission of media that will be ignored. > 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). *signaling* that you *intend* to not transmit allows the other end to handle things differently. E.g. it can play local "music on hold" (or "video on hold") or the moral equivalent of audio/video white noise if that is what will make the user most comfortable. Thanks, Paul >>> - 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. >> > >
Received on Friday, 26 April 2013 23:14:04 UTC