Re: [Bug 20816] "Hold" unspecified

(Note: This is not an update of the bug. When we discuss items at a more 
generic level, I prefer to do that on the mailing list, not by leaving 
notes in the bug itself. Discussions are more flexible.)

On 04/11/2013 01:25 PM, bugzilla@jessica.w3.org wrote:
> https://www.w3.org/Bugs/Public/show_bug.cgi?id=20816
>
> Iñaki Baz Castillo <ibc@aliax.net> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                   CC|                            |ibc@aliax.net
>
> --- Comment #1 from Iñaki Baz Castillo <ibc@aliax.net> ---
> Something is needed, otherwise a simple hold/unhold process becomes really
> hard.
>
> Let's suppose an established audio/video session between Alice and Bob using
> SIP/XMPP over HTTP/WebSocket. Alice wants to put Bob on hold.
>
> 1) Alice mutes its local streams.
>
> 2) Alice gets the last SDP sent to Bob and *mangles* it by adding "a:sendonly"
> within the audio and video "m" sections.
>
> 3) Alice sends a re-INVITE with the modified SDP.
>
> 4) Bob receives it and updates its PeerConnection with it.
>
> 5) Bob (optionally) parses/searches in the SDP from Alice for "a=sendonly" to
> known whether Alice is putting him on hold and notify it in the web somehow.
>
> 6) If so, Bob retrieves his new SDP and manually adds "a=recvonly" or
> "a=inactive", and sends it to Alice.
>
> 7) Alice sets the received SDP as the remote SDP in the existing PC.
>
> This becomes really complex and manual, even more when we have to *manuall*
> mangle and parse an SDP.
>
> I strongly expect that, given that SDP is the "WebRTC information exchange
> unit" it should offer some kind of API to deal with hold/unhold SDP features.
> Otherwise the usage of SDP seems a bad choice (IMHO).

I'd dispute the idea that "SDP is the WebRTC information exchange unit". 
But that's a discussion about philosophy, more than what goes into 
engineering.

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.

No SDP was mangled in the imagining of this scenario.

Received on Friday, 19 April 2013 09:56:17 UTC