Re: [Bug 20816] "Hold" unspecified

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.

Here a couple of snippets from [1]:

```
When a track belongs to a MediaStream that comes from a remote peer and the
remote peer has permanently stopped sending data the ended event must be
fired on the track, as specified in [GETUSERMEDIA].

ISSUE 5
ISSUE: How do you know when it has stopped? This seems like an SDP
question, not a media-level question.

```

```
In addition, a MediaStreamTrack has its readyState set to muted on the
remote peer if the local user agent disables the corresponding
MediaStreamTrack in the MediaStream that is being sent. When the addstream
event triggers on an RTCPeerConnection, all MediaStreamTrack objects in the
resulting MediaStream are muted until media data can be read from the RTP
source.

ISSUE 6

ISSUE: How do you know when it has been disabled? This seems like an SDP
question, not a media-level question.

```



> No SDP was mangled in the imagining of this scenario.
>
>
>
As said above, it must be mangled. Please correct me if I' m wrong.

Even if this could be achieved in other ways like those discussed in [2],
considering that we are using SDP as the signaling mechanism, we should
cover such mentioned cases and make RTCPeerconnection
react consequently upon SDP reception. Even if the covered cases are
limited, they should be defined in the specification.

>From my point of view, this should be implemented at least for SDP as the
standard way.

[1]: http://dev.w3.org/2011/webrtc/editor/webrtc.html
[2]: http://www.ietf.org/mail-archive/web/rtcweb/current/msg04624.html



-- 
José Luis Millán