1173348 - SDP offer adds a=sendrecv before first m= when all m= sections are a=recvonly, call fails

Status: RESOLVED WONTFIX

(Core :: WebRTC: Signaling, defect)

Description

[Roland Andriese]

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

Steps to reproduce:

Whenever I start a call to our MCU application and I initiate the call with recvonly, Firefox (starting from version 38) adds a=sendrecv to the SDP.

No local streams were added and offerToReceive{Audio/Video} were set to true.


Actual results:

Call gets terminated by Firefox with 'Answer tried to set recv when offer did not set send'.

This is the SDP generated by Firefox:

INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/WSS jvr62bt1um5r.invalid;branch=z9hG4bK2359581
Max-Forwards: 70
To: <sip:[e-mail]>
From: <sip:[e-mail]>;tag=jh4hpd9dmd
Call-ID: e1ssirqnkv5129b91quu
CSeq: 9051 INVITE
Proxy-Authorization: Digest algorithm=MD5, username="roland", Realm="redhosting.nl", nonce="VXg84lV4O7aPUP6WhWC5Z/Sut9BD9TY9", uri="sip:[e-mail]", response="310801209f82e038de8c345cb76a2718"
X-HASH: [e-mail];00a030edd8264b91eb0fd0d0a8dea700
Contact: <sip:[e-mail];transport=ws;ob>
Allow: ACK,CANCEL,BYE,OPTIONS,INFO,NOTIFY,INVITE
Content-Type: application/sdp
Supported: outbound
User-Agent: SIP.js/0.6.4
Content-Length: 2494

v=0
o=mozilla...THIS_IS_SDPARTA-41.0a1 4294967295 0 IN IP4 192.0.2.119
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 49:93:3A:F0:5E:90:AF:AF:73:7B:13:96:BB:0A:98:3B:34:3B:19:01:C3:A3:EC:6C:64:1C:09:3E:F8:48:31:9D
a=group:BUNDLE sdparta_0 sdparta_1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 20397 UDP/TLS/RTP/SAVPF 109 9 0 8
c=IN IP4 89.184.172.104
a=candidate:0 1 UDP 2128609535 10.0.1.99 52618 typ host
a=candidate:0 2 UDP 2128609534 10.0.1.99 52619 typ host
a=candidate:1 1 UDP 1692467199 89.184.168.160 52618 typ srflx raddr 10.0.1.99 rport 52618
a=candidate:3 1 UDP 98631679 89.184.172.104 20397 typ relay raddr 89.184.172.104 rport 20397
a=candidate:1 2 UDP 1692467198 89.184.168.160 52619 typ srflx raddr 10.0.1.99 rport 52619
a=candidate:3 2 UDP 98631678 89.184.172.104 23898 typ relay raddr 89.184.172.104 rport 23898
a=recvonly
a=end-of-candidates
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=ice-pwd:c65effffe03b678616719591996f4295
a=ice-ufrag:e436b881
a=mid:sdparta_0
a=rtcp:23898 IN IP4 89.184.172.104
a=rtcp-mux
a=rtpmap:109 opus/48000/2
a=rtpmap:9 G722/8000/1
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=setup:actpass
a=ssrc:2963842913 cname:{c1c54cb6-72f3-437e-a638-5eaa146e8afb}
m=video 32746 UDP/TLS/RTP/SAVPF 120 126 97
c=IN IP4 89.184.172.104
a=candidate:0 1 UDP 2128609535 10.0.1.99 52620 typ host
a=candidate:0 2 UDP 2128609534 10.0.1.99 52621 typ host
a=candidate:1 1 UDP 1692467199 89.184.168.160 52620 typ srflx raddr 10.0.1.99 rport 52620
a=candidate:3 1 UDP 98631679 89.184.172.104 32746 typ relay raddr 89.184.172.104 rport 32746
a=candidate:1 2 UDP 1692467198 89.184.168.160 52621 typ srflx raddr 10.0.1.99 rport 52621
a=candidate:3 2 UDP 98631678 89.184.172.104 21487 typ relay raddr 89.184.172.104 rport 21487
a=recvonly
a=end-of-candidates
a=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:126 profile-level-id=42e01f;level-asymmetry-allowed=1;packetization-mode=1
a=fmtp:97 profile-level-id=42e01f;level-asymmetry-allowed=1
a=ice-pwd:c65effffe03b678616719591996f4295
a=ice-ufrag:e436b881
a=mid:sdparta_1
a=rtcp:21487 IN IP4 89.184.172.104
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-mux
a=rtpmap:120 VP8/90000
a=rtpmap:126 H264/90000
a=rtpmap:97 H264/90000
a=setup:actpass
a=ssrc:4051235105 cname:{c1c54cb6-72f3-437e-a638-5eaa146e8afb}



Expected results:

Firefox should not add the first a=sendrecv to the generated SDP. This doesn't only happen with these specific calls, Firefox adds a=sendrecv to ALL calls made from the browser.

Comment 1

[:Gijs (he/him)]

Jesup, can you help triage this further?

Comment 2

[:Gijs (he/him)]

Actually, Roland, one thing I can already ask: do you see the same behaviour with Firefox Nightly ( https://nightly.mozilla.org/ ) ?

Comment 3

[Roland Andriese]

(In reply to :Gijs Kruitbosch from comment #2)
> Actually, Roland, one thing I can already ask: do you see the same behaviour
> with Firefox Nightly ( https://nightly.mozilla.org/ ) ?

Yep, same behavior in 41.0a1 (2015-06-10).

Comment 4

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

So a=sendrecv in the before-first-m-line section should end up being ignored, as each m= section has an a=recvonly. (a=sendrecv is effectively the default).

However, I don't see a=sendrecv in this simple test, so some additional API calls must be being done (or additional options):

var pc = new mozRTCPeerConnection();
var constraints = { mandatory: { OfferToReceiveVideo : true, OfferToReceiveAudio: true } };
function failed(){dump("failed\n");};
function step2(){dump("done\n");};
pc.createOffer(function(offer) {
                   dump(offer.sdp + "\n"); 
                   pc.setLocalDescription(offer, step2, failed);},
               failed,
               constraints);

This shows it's going through a JSEP->SIP conversion:
INVITE sip:[e-mail] SIP/2.0
Via: SIP/2.0/WSS jvr62bt1um5r.invalid;branch=z9hG4bK2359581
Max-Forwards: 70
To: <sip:[e-mail]>

Is it possible that the conversion is adding a blanket a=sendrecv to the SDP?  Can you dump the result of createOffer (offer.sdp) as I do above?  And what call is generating the error?  SetLocalDescription?  Last question: was offer (in particular offer.sdp) passed without modification to setLocalDescription()?

Comment 5

[Byron Campen [:bwc]]

Yes, the a=sendrecv at the session level is a default that only matters if there is no media-level direction attribute. I suspect that your MCU is not ignoring it, and replying with either sendrecv or recvonly at the media level.

Comment 6

[Byron Campen [:bwc]]

I should also note that if there is no direction attribute at all, the default is sendrecv. This is the reason we put a=sendrecv at the session-level; we're just making the default explicit:

From RFC 4566, Sec 6, page 26
"
    a=sendrecv

         This specifies that the tools should be started in send and
         receive mode.  This is necessary for interactive conferences
         with tools that default to receive-only mode.  It can be either
         a session or media-level attribute, and it is not dependent on
         charset.

         If none of the attributes "sendonly", "recvonly", "inactive",
         and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
         default for sessions that are not of the conference type
         "broadcast" or "H332" (see below).

"

Comment 7

[Roland Andriese]

(In reply to Byron Campen [:bwc] (PTO June 15-25) from comment #6)
> I should also note that if there is no direction attribute at all, the
> default is sendrecv. This is the reason we put a=sendrecv at the
> session-level; we're just making the default explicit:
> 
> From RFC 4566, Sec 6, page 26
> "
>     a=sendrecv
> 
>          This specifies that the tools should be started in send and
>          receive mode.  This is necessary for interactive conferences
>          with tools that default to receive-only mode.  It can be either
>          a session or media-level attribute, and it is not dependent on
>          charset.
> 
>          If none of the attributes "sendonly", "recvonly", "inactive",
>          and "sendrecv" is present, "sendrecv" SHOULD be assumed as the
>          default for sessions that are not of the conference type
>          "broadcast" or "H332" (see below).
> 
> "

But why does Firefox sends the attribute on both session-level and media-level? Additionally, the session-level is not adjustable by and the media-level is. So in this case, I think Firefox still contains a bug since the most specific setting for the attribute should count...

Comment 8

[Byron Campen [:bwc]]

Session level direction attributes are not the most specific. They only matter when there is no media level direction attribute. They are a fallback only, and if we removed it the semantics are exactly the same, since the default would still be sendrecv.

Comment 9

[Roland Andriese]

(In reply to Byron Campen [:bwc] (PTO June 15-25) from comment #8)
> Session level direction attributes are not the most specific. They only
> matter when there is no media level direction attribute. They are a fallback
> only, and if we removed it the semantics are exactly the same, since the
> default would still be sendrecv.

Actually I meant that the media-level are the most specific, and that I don't understand that FF adds the session-level attribute when it already specifies a=recvonly for the media-levels. In my opinion, FF should be consistent with the value of the attribute...

Comment 10

[Byron Campen [:bwc]]

(In reply to Roland Andriese from comment #9)
> (In reply to Byron Campen [:bwc] (PTO June 15-25) from comment #8)
> > Session level direction attributes are not the most specific. They only
> > matter when there is no media level direction attribute. They are a fallback
> > only, and if we removed it the semantics are exactly the same, since the
> > default would still be sendrecv.
> 
> Actually I meant that the media-level are the most specific, and that I
> don't understand that FF adds the session-level attribute when it already
> specifies a=recvonly for the media-levels. In my opinion, FF should be
> consistent with the value of the attribute...

   It adds it because not adding one is semantically equivalent to recvonly, but adding it is more explicit (which is good, considering we aren't interested in saving 16 bytes of bandwidth). I also see no value in writing code that checks all the m-sections, and if they are all the same, switches the session level to match.

Comment 11

[Roland Andriese]

(In reply to Byron Campen [:bwc] (PTO June 15-25) from comment #10)
> (In reply to Roland Andriese from comment #9)
> > (In reply to Byron Campen [:bwc] (PTO June 15-25) from comment #8)
> > > Session level direction attributes are not the most specific. They only
> > > matter when there is no media level direction attribute. They are a fallback
> > > only, and if we removed it the semantics are exactly the same, since the
> > > default would still be sendrecv.
> > 
> > Actually I meant that the media-level are the most specific, and that I
> > don't understand that FF adds the session-level attribute when it already
> > specifies a=recvonly for the media-levels. In my opinion, FF should be
> > consistent with the value of the attribute...
> 
>    It adds it because not adding one is semantically equivalent to recvonly,
> but adding it is more explicit (which is good, considering we aren't
> interested in saving 16 bytes of bandwidth). I also see no value in writing
> code that checks all the m-sections, and if they are all the same, switches
> the session level to match.

Of course it's good, if the attribute values are the same for media-level and session-level, but they are not... So now what happens is that the media-level values are recvonly and somehow the session-level gets set to sendrecv.

Comment 12

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

> >    It adds it because not adding one is semantically equivalent to recvonly,
> > but adding it is more explicit (which is good, considering we aren't
> > interested in saving 16 bytes of bandwidth). I also see no value in writing
> > code that checks all the m-sections, and if they are all the same, switches
> > the session level to match.
> 
> Of course it's good, if the attribute values are the same for media-level
> and session-level, but they are not... So now what happens is that the
> media-level values are recvonly and somehow the session-level gets set to
> sendrecv.

a=sendrecv in the session level is semantically noise - it merely makes explicit the default.  To a compliant implementation, it makes absolutely no difference at all.  It is not required, but any compliant implementation should handle it.

At most, it wastes a few characters. Now, there are more than a few SDP implementations that don't handle edge cases - or even reasonable cases they haven't seen.  And most implementations don't put a=sendrecv in the session level (most never put anything in the session level no matter what).  

I'd be fine with removing it - it may avoid a few odd cases where some SDP implementation chokes on session-level direction attributes.  But I wouldn't consider worrying about such broken implementations even mildly important.

If you want to put up a patch to remove it, I'm fine with that, and we can look at the patch.