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

Re: [Bug 20816] "Hold" unspecified

From: José Luis Millán <jmillan@aliax.net>
Date: Fri, 19 Apr 2013 15:48:03 +0200
Message-ID: <CABw3bnNaGCZPgF060E1AZ=q+=P7pkW8sfKbOkRJZWFhOg9YMYw@mail.gmail.com>
To: Harald Alvestrand <harald@alvestrand.no>
Cc: public-webrtc@w3.org
2013/4/19 Harald Alvestrand <harald@alvestrand.no>

>  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.
>

With 'this' I meant the sentence above, the point 3 -> 'Bob calls "disable
on this outgoing..."'

How does Bob know that he needs to disable the Tracks?

- Mangling the SDP
- Detecting silence and blackness from the other end
- etc, etc

Such a mechanism is not defined in the specification and in fact, are
marked as "ISSUES" in [1], so unresolved.

>From my point of view, it should be handled by RTCPeerconnection at SDP
reception and it should be the standard way to do, since SDP was choosen as
the signaling mechanism.


>
> 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.
>
>
The problem is not with "hold" itself, it is just an application, but with
the RTCPeerconnection/Stream/Track unresponsiveness to some SDP stimulus.
Basically, I' m speaking about ISSUES 5 and 6 of the W3C RTCPeerconnection
especification.

In order to keep the focus: Are those specification issues being resolved
or will each implementation do it their way because of this lack of
decision?


[1]: http://dev.w3.org/2011/webrtc/editor/webrtc.html


-- 
José Luis Millán
Received on Friday, 19 April 2013 13:51:30 UTC

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