W3C home > Mailing lists > Public > public-webrtc@w3.org > April 2013

Re: [Bug 20816] "Hold" unspecified

From: Iñaki Baz Castillo <ibc@aliax.net>
Date: Fri, 19 Apr 2013 16:05:14 +0200
Message-ID: <CALiegfn1YSg84ZsPBDt8uZaUxSF+1k2U_aDNdqM+MEaOMQdCTA@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: "public-webrtc@w3.org" <public-webrtc@w3.org>
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.



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. 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 14:06:00 UTC

This archive was generated by hypermail 2.3.1 : Monday, 23 October 2017 15:19:33 UTC