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

[Bug 20816] "Hold" unspecified

From: <bugzilla@jessica.w3.org>
Date: Thu, 11 Apr 2013 11:25:26 +0000
To: public-webrtc@w3.org
Message-ID: <bug-20816-4991-2eFx3Fr67M@http.www.w3.org/Bugs/Public/>
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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
Received on Thursday, 11 April 2013 11:25:28 UTC

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