20816 2013-01-29 18:17:46 +0000 "Hold" unspecified 2014-12-15 10:39:39 +0000 1 1 1 Unclassified WebRTC Working Group WebRTC API unspecified PC Windows NT RESOLVED LATER P2 normal --- 1 matthew.kaufman juberti harald ibc public-webrtc oldest_to_newest 82298 0 matthew.kaufman 2013-01-29 18:17:46 +0000 The WebRTC draft and its normative references do not define a mechanism for applications for placing a session on hold. Similarly, no mechanism is defined for receivers to use in requesting that a sender stop the transmission of a specific stream for the purposes of muting that stream. 85943 1 ibc 2013-04-11 11:25:26 +0000 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). 86391 2 harald 2013-04-19 15:10:28 +0000 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. ------------------------------------------- 86393 3 ibc 2013-04-19 15:59:27 +0000 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. 114335 4 harald 2014-10-31 16:07:04 +0000 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. 116327 5 dom 2014-12-15 10:39:39 +0000 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.