Re: [Bug 20816] "Hold" unspecified

On 04/19/2013 04:05 PM, Iñaki Baz Castillo wrote:
> 2013/4/19 Harald Alvestrand <harald@alvestrand.no>:
>>>> - What do you mean by "hold"?
>>> "Putting a peer on hold" means:
>>>
>>> 1) Muting my local streams.
>>> 2) And tell the peer about it.
>>
>> That's funny, because it's exactly the opposite definition as the one Olle
>> dug up from RFC 5359 (where "hold" is Bob's demand that Alice cease
>> transmission).
>>
>> Can we use one term for one thing?
> Let me fix it:
>
>
> "Putting a peer on hold" means:
>
> 1) Muting my local streams.
> 2) And tell the peer about it.
> 3) And ask the remote not to send media to me.
>
> This is where "a=inactive" takes place.
>
>
> or:
>
> 1) Ask the remote not to send media to me (since I will stop rendering
> it right now).
> 2) but I could send media to the remote.
>
> This is where "a=sendonly" takes place.

OK, now you have 2 meanings of "on hold". Theÿ́re different, of course.

I added those to the bug description, with Inaki's name attached to it.

>
>
>
> Typically when a SIP PBX puts a SIP phone on hold, it sends
> "a=sendonly" to the phone, so the phone replies with "a=recvonly" and
> listens to the "musin on hold" provided by the PBX.
>
> But when a phone puts on hold the peer, it does it by sending
> "a=inactive" since it won't send media to the peer (no music on hold
> or whatever). Anyhow some phones use "a=sendonly" but that's not very
> important.
>
>
> Anyhow, this concept of "putting on hold" is just a "SIP application"
> (no idea whether Jingle also uses it), and it is irrelevant.

If "putting on hold" is irrelevant, should we close the bug as 
irrelevant, and instead ask for specific bugs that request specific 
behaviour?


>   What me
> and others are requesting is the posibility of implement such
> "applications" via WebRTC API and events.
>
> WebRTC uses SDP so it should play the rules of RFC 4566 and allow
> setting "a=" attributes via API and detect them via events or
> attributes.
>
>
> --
> Iñaki Baz Castillo
> <ibc@aliax.net>
>

Received on Friday, 19 April 2013 15:10:57 UTC