Re: [Bug 20816] "Hold" unspecified

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