1015052 - setLocalDescription with modified SDP doesn't work for Hold

Status: RESOLVED INVALID

(Core :: WebRTC, defect)

Description

[rajkumaradass]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/34.0.1847.137 Safari/537.36

Steps to reproduce:

1. Make webRTC - webRTC audio call only.
2. Call connected and speech path is successful
3. If user tries hold, the initial generated offer SDP is modified to have "a=inactive" for audio type and applies with setLocalDescription.





Actual results:

Although setLocalDescription gives a successful callback - audio streaming is still happening.


Expected results:

Should stop sending audio packets.

Below is the SDP contents:

Initial Offer SDP: 
v=0
o=Mozilla-SIPUA-29.0.1 20846 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:ad054603
a=ice-pwd:8e8453ab526854036b60501fd2545963
a=fingerprint:sha-256 A4:36:93:6B:3D:27:70:AF:72:16:6D:A9:88:70:F2:09:42:19:34:88:BF:29:44:48:42:F9:FB:5E:E3:D5:E7:F6
m=audio 62996 RTP/SAVPF 109 0 8 101
c=IN IP4 135.27.117.198
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=setup:actpass
a=candidate:0 1 UDP 2128609535 135.27.117.198 62996 typ host
a=candidate:0 2 UDP 2128609534 135.27.117.198 62997 typ host
a=rtcp-mux

Modified initial offer SDP(for HOLD):
v=0
o=Mozilla-SIPUA-29.0.1 20846 0 IN IP4 0.0.0.0
s=SIP Call
t=0 0
a=ice-ufrag:ad054603
a=ice-pwd:8e8453ab526854036b60501fd2545963
a=fingerprint:sha-256 A4:36:93:6B:3D:27:70:AF:72:16:6D:A9:88:70:F2:09:42:19:34:88:BF:29:44:48:42:F9:FB:5E:E3:D5:E7:F6
m=audio 62996 RTP/SAVPF 109 0 8 101
c=IN IP4 135.27.117.198
a=rtpmap:109 opus/48000/2
a=ptime:20
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=inactive
a=setup:actpass
a=candidate:0 1 UDP 2128609535 135.27.117.198 62996 typ host
a=candidate:0 2 UDP 2128609534 135.27.117.198 62997 typ host
a=rtcp-mux

Comment 1

[Eric Rescorla (:ekr)]

The precise details of which SDP modifications browsers must respect are
still pending: https://github.com/rtcweb-wg/jsep/issues/8

However, currently a=inactive is not required.

Needinfo to :abr, but this is most likely a WONTFIX.

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Currently Firefox doesn't yet support renegotiation, which would be required to change sendrecv values during a call (see working-group discussion references).  

You can implement immediate Hold by muting audio and video on the mediastream/tracks (something like this would be needed anyways as reneogiation can be slow or rejected - you need to mute and then renegotiate).  Actually changing the stream directionality mostly just saves some bits, though some active B2BUA's you attach to might care.

Comment 3

[Adam Roach [:abr]]

There are really two parts to this.

The first is that we don't handle modification of a session once it has been established; see Bug 875115. So, I'm depending this on that bug, although that's kind of a moot point, because of the second part.

The second part, as EKR points out, is whether these kinds of SDP manipulations (media directionality) are allowed by the JSEP spec. Unless the RTCWEB working group decides that this is one of the things that is mutable in the SDP -- and, as EKR points out, it currently is not -- then the suggested behavior is not technically allowed. Not seeing a strong reason to implement in contravention of the specs, I'm going to mark this as INVALID.

As Randell points out, there are other, more javascripty ways of dealing with these features at the moment by manipulating the stream objects. Longer term, once the WebRTC working group has specified the RTCRtpSender objects and we've implemented them, they should provide an even more elegant way of handling audio and video muting.

Comment 4

[ushunmugan]

From section 5.1.1 of draft-ietf-rtcweb-jsep-11:
   R-9   The SDP attributes of "sendonly", "recvonly", "inactive", and
         "sendrecv" from [RFC4566] MUST be implemented to signal
         information about media direction.

Doesn't this mean taht this issue should be reopened?

Comment 5

[ushunmugan]

BTW, the renegotiation bug mentioned in Comment #3 should be 857115 (not 875115), which is resolved now.

Comment 6

[ushunmugan]

Just to reiterate the main issue, setLocalDescription succeeds with a=inactive, and SDP negotiation completes successfully; however, Firefox (version 41 and 42) keeps sending RTP for both audio and video (which is ignored/dropped by the gateway, in our case).

Comment 7

[Adam Roach [:abr]]

(In reply to ushunmugan from comment #4)
> From section 5.1.1 of draft-ietf-rtcweb-jsep-11:
>    R-9   The SDP attributes of "sendonly", "recvonly", "inactive", and
>          "sendrecv" from [RFC4566] MUST be implemented to signal
>          information about media direction.
> 
> Doesn't this mean taht this issue should be reopened?

You're confusing two things with each other.

One is the signaling sent between two peers. That signaling needs to generate and correctly process the direction attributes. That's what this requirement is talking about: the SDP generated by createOffer and createAnswer is required to contain these attributes; the values generated by createAnswer need to be consistent with those that were in the offer; and the resulting track configuration is required to match the negotiated directions.

But you're talking about something completely different here, which is (a) createOffer; (b) twiddle things in the SDP in an attempt to change the browser's behavior; and (c) setLocalDescription with this munged SDP.

The part of JSEP that talks about this kind of behavior is section 6 (https://tools.ietf.org/html/draft-ietf-rtcweb-jsep-12#section-6). The only thing it talks about being mandatory to honor is removing or reordering codecs in the SDP. (We're actually adding a section to the WebRTC spec that lets you do this via an API, so this requirement might not be in the final version of JSEP).

That said, there *is* a problem here in that you're getting a silent failure. JSEP requires that changes to the SDP that won't be acted on need to make setLocalDescription fail. I'm tagging Maire here to open a bug on that, if we don't already have one.

[As an aside: SDP modification is intended to be a tool of last resort. If there's any other way to do something, I guarantee that it will be more interoperable, better tested, and easier to use. The rule of thumb when it comes to modifying SDP is: don't.]

Comment 8

[Maire Reavy [:mreavy]]

Yes, that will be covered by a bug breakdown of bug 1095226, which will include a bug fix for making setLocalDescription fail if we see changes to the SDP that we choose not to act on.

Comment 9

[ushunmugan]

Thanks, Adam, for pointing it out.  The same section-6 in the spec states:
   The application can also modify the SDP to reduce the capabilities in
   the offer it sends to the far side or the offer that it installs from
   the far side in any way the application sees fit, as long as it is a
   valid SDP offer and specifies a subset of what was in the original
   offer.
Perhaps, it's somewhat vague, and may or may not apply to this.  Regardless, supporting modification of the media direction, especially to a=inactive in the offer SDP, may be useful to implement mute functionality (Chrome does) effectively.  You could use the "enabled" attribute in MediaStreamTracks for muting, given RTCP would continue to be sent, though some endpoints may have issues if you simply stop sending media without signalling it.  Signalling could also be useful for a recording application, which would want to stop recording during the muted period.

BTW, the same spec states that the browser MUST NOT honor an attempt to change "The number, type and port number of m= lines".  I hope it does not apply to changing the port to '0' to disable a media track (in which case, the spec should be made clear), since it is used by many, and supported currently by Chrome and Firefox.

Comment 10

[ushunmugan]

I just found this issue https://bugzilla.mozilla.org/show_bug.cgi?id=1213773, which is more applicable, if not the same. So, in this case, the SDP answer has a=inactive too, but Firefox doesn't respect it.  So, if you are going to fix this issue (in setRemoteDescription), you might as well support changing direction to a=inactive in setLocalDescription.

Also, you couldn't use "enabled" attribute in the tracks, if you are sending the same track to multiple endpoints, and you don't want stop sending media to all of them.

Comment 11

[Adam Roach [:abr]]

(In reply to ushunmugan from comment #10)
> Also, you couldn't use "enabled" attribute in the tracks, if you are sending
> the same track to multiple endpoints, and you don't want stop sending media
> to all of them.

In that case, you'd use RTCRtpSender (the object returned from addTrack) to set "active" to "false." The track remains enabled, but it's not sent for that specific media line.