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

From Inaki Baz Castillo, on the list:
-----------------------------------
"Putting a peer on hold" means:

1) Muting my local streams.
2) And tell the peer about it.
3) And ask the remote not to send media to me.

or:

1) Ask the remote not to send media to me (since I will stop rendering
it right now).
2) but I could send media to the remote.
-------------------------------------------

By Randell Jesus in public-webrtc maillist:

--------------------
Let's avoid the term "hold". We need:

1) Mute (on a track level)
(optionally) Mute on a stream level (Mute all tracks)
(where "Mute" means replace with silence/black)

2) Replace track with other media (muzak, slate, etc)

3) change directionality of a stream
     sendonly, sendrecv, recvonly, inactive

4) notification of directionality changes

From those, an application can compose whatever they want.
-------------------

IMHO notifications in 4) could be replaced with JS attributes in mediaStream instances (this is: instead of firing events let the developer inspect those mediaStream attributes when a new SDP is received and passed to the local PeerConnection.

Muting a track (ceasing to send data) is a local event, and will be covered by the RTPSender proposal.

Using SDP to cause the other party to cease sending data isn't clear about how it is done today, or should be done; this can likely be done in the RTPReceiver API, but this is a post-1.0 feature.

Bug will be marked as "later" once RTPSender muting lands.

WebRTC API bugs have been moved to github issues: https://github.com/w3c/webrtc-pc/issues

Please subscribe to the issues you want to keep watching.