"Hold" unspecified

[dontcallmedom]

Originally reported on W3C Bugzilla ISSUE-20816 Tue, 29 Jan 2013 18:17:46 GMT
Reported by Matthew Kaufman
Assigned to

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.

[dontcallmedom]

Original comment by Iñaki Baz Castillo on W3C Bugzilla. Thu, 11 Apr 2013 11:25:26 GMT

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

[dontcallmedom]

Original comment by Harald Alvestrand on W3C Bugzilla. Fri, 19 Apr 2013 15:10:28 GMT

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.

[dontcallmedom]

Original comment by Iñaki Baz Castillo on W3C Bugzilla. Fri, 19 Apr 2013 15:59:27 GMT

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.

[dontcallmedom]

Original comment by Harald Alvestrand on W3C Bugzilla. Fri, 31 Oct 2014 16:07:04 GMT

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.

[fluffy]

Right now we have a way to tell the stream to only send "black" or "silence" via the mute, but we need a way to tell a stream to not send RTP packets (but keep doing keep alive , RTCP, etc) so that when the app wants to start sending packets again it can instantly start sending them with no signaling delay

[fluffy]

I don't think this is an enhancement - this was one of the reason we were going to do doohickeys and was discussed at the W3C meeting that was in China

[jan-ivar]

Isn't this an optimization? Is there a use-case for "I want to mute my video but waste my bandwidth"?

[fluffy]

Well if we had defined the baseline for mute to be not waste bandwidth, I'd be fine with it, but we seemed to make the default be wasted bandwidth with no way to not waste bandwidth.

[jan-ivar]

Doesn't the UA know that a stream is muted vs. black content? Is so, then can't it optimize it out? I know it can't today, but whatever we'd invent for hold couldn't we apply it to mute and fake the black on the receiving end?

[stefhak]

I think the "active" attribute on the RTPSender was supposed to do this (stop sending RTP, but keep RTCP going), see slide 11 https://www.w3.org/2011/04/webrtc/wiki/images/6/6c/WebRTC_RTCSender-Receiver%2C_TPAC_2014.pdf

I think there is no API to ask the other end to stop sending RTP to you, but I don't really see the need for it.

[fluffy]

Intersting - that version of active makes sense to me but I think @juberti might have been thinking of something different. Regardless of what we decide it means - we need to make the spec super clear on what it means.

[stefhak]

Agreed, the spec must be clear.

[alvestrand]

Bernard will query the list to see if this is OK.

[aboba]

The following PRs provide functionality relating to this issue:
Add activateReceiver() to RTCRtpTransceiver: #505
Add getParameters() to RTCRtpReceiver: #504
active for RTCRtpReceiver: #475

An example of "hold" usage is provided in RFC 4317 Section 3.1, where Alice sends an Offer to Bob who responds with a=sendonly (putting Alice on Hold). To resume, Bob sends an Offer to Alice and Alice Answers.

Here is how this can be implemented:

1. Alice (the Offerer) calls pc.addTransceiver() with init.send=true and init.receive=true (sendrecv)
2. Bob (the Answerer) calls pc.addTransceiver() with init.send=true and init.receive=false (sendonly).
3. After Alice calls setRemoteDescription(), sender.getParameters().encodings[0].active should be set to "false".
4. For Bob to resume receiving audio from Alice, Bob calls activateReceiver(), and then sends an Offer to Alice which should indicate sendrecv.
5. Once Alice calls setRemoteDescription(), sender.getParameters.encodings[0].active should then be set to "true".

[elagerway]

@aboba Can you please create a PR for this in the form of a sample in the examples section of the draft, if you think it's appropriate?

[aboba]

Will write a PR once we decide what to do with PR #466

[elagerway]

Now that #466 is near merged, Bernard will create PR

[aboba]

Assuming that setDirection() lands (see PR #620) we will have all the basics:

1. Mute (on a track level):

Solution:
var parameters = sender.getParameters();
parameters.encodings[0].active = "false";
sender.setParameters();

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

Solution: replaceTrack()

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

Solution: transceiver.setDirection(direction)

4. notification of directionality changes

Solution: signaling