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

Re: [Bug 20816] "Hold" unspecified

From: Harald Alvestrand <harald@alvestrand.no>
Date: Fri, 19 Apr 2013 15:16:12 +0200
Message-ID: <5171439C.5080000@alvestrand.no>
To: José Luis Millán <jmillan@aliax.net>
CC: public-webrtc@w3.org
On 04/19/2013 03:04 PM, José Luis Millán wrote:
> Hi,
>     Engineering-wise:
>     1) Do you have a definition of what "on hold" means that we can
>     refer to? The term does not occur in
>     draft-ietf-rtcweb-use-cases-and-requirements.
>     2) Do you know of a consistent specification for how SDP is used
>     to achieve "on hold" in other systems, for instance SIP? If so,
>     can you point us to that specification?
>     At the moment, I'm not even sure what "on hold" means in terms of
>     what media flows cease; in a JS-centric world, another
>     implementation that somewhat matches what you describe might be:
>     1) Alice calls "disable" on her outgoing audio and video
>     MediaStreamTracks.
>     2) Alice sends a message to Bob informing him that he's on hold
>     (through signalling, which is not standardized in WebRTC or RTCWEB).
>     3) Bob calls "disable" on his outgoing audio and video
>     MediaStreamTracks.
> SDP needs to be mangled to do this AFAIK since not even the W3C 
> specification defines how this is done at RTCPeerConnection level.

Well, the first thing to define is what needs to be done, and why. In 
the sentence above, it's not clear what "this" refers to, even though 
you use the word twice.

A major reason RTCPeerConnection handles don't exist is because we don't 
have a clear specification of what we need handles for.

So first:

- What do you mean by "hold"?
- Where is the specification of how other people are using SDP to 
achieve the thing you mean?

It's the job of people who want to use SDP mechanisms to achieve "hold" 
to make these things clear.
Received on Friday, 19 April 2013 13:16:41 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:17:42 UTC