Incorrect SDP a=sendrecv in firefox

[Karakoukie]

Hi Using Firefox 122.0

When putting caller on hold using the hold method of rtcsession (using reinvite), the SDP sent by JsSIP is incorrect: there is a "a=sendrecv" out of the media attributes in the first few lines of the SDP. The caller is on hold but asterisk does not send any music on hold.

Using Chrome, this attribute is not present, and asterisk correctly send moh to the caller.

Incorrect SDP sent by Firefox:

**INVITE sip:305@192.168.11.100:5060;transport=ws SIP/2.0
Via: SIP/2.0/WSS 192.168.11.100;branch=z9hG4bK5054457
Max-Forwards: 69
To: <sip:305@192.168.11.100>;tag=as10e1f83e
From: <sip:tristanWeb@192.168.11.100:8089>;tag=9snuogj20c
Call-ID: 24c85fef0facc43066fa40e32096bb3e@192.168.11.100:5060
CSeq: 1129 INVITE
Contact: <sip:tristanWeb@192.168.11.100:8089>
Content-Type: application/sdp
Session-Expires: 90;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,ice,replaces,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 1411

v=0
o=mozilla...THIS_IS_SDPARTA-99.0 2829398717788774288 1 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 C8:48:A8:2A:6D:84:91:92:68:1E:A6:27:D2:92:E1:4F:72:A7:4B:4A:C4:A7:14:51:AE:6D:2E:DF:43:22:86:3E
a=ice-options:trickle
a=msid-semantic: WMS *
a=group:BUNDLE 0
m=audio 55376 UDP/TLS/RTP/SAVPF 8 9 107 101 0
c=IN IP4 172.28.80.1
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000/1
a=rtpmap:107 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=rtpmap:0 PCMU/8000
a=fmtp:107 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2/recvonly urn:ietf:params:rtp-hdrext:csrc-audio-level
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:actpass
a=mid:0
a=msid:{1926e2fc-0061-4abb-adeb-e75b32938b28} {26e9a9f4-8efe-46b5-98f8-c362d97444ac}
a=sendonly
a=ice-ufrag:1fedc680
a=ice-pwd:788a2d0bfcd1903d14965b56604de06f
a=candidate:0 1 UDP 2122121471 192.168.5.155 55374 typ host
a=candidate:1 1 UDP 2122187007 192.168.11.168 55375 typ host
a=candidate:2 1 UDP 2122252543 172.28.80.1 55376 typ host
a=candidate:3 1 TCP 2105393407 192.168.5.155 9 typ host tcptype active
a=candidate:4 1 TCP 2105458943 192.168.11.168 9 typ host tcptype active
a=candidate:5 1 TCP 2105524479 172.28.80.1 9 typ host tcptype active
a=end-of-candidates
a=ssrc:1341419783 cname:{dd70acb7-4d05-4387-8865-76598e66f7e6}
a=rtcp-mux

Correct SDP sent by Chrome

INVITE sip:305@192.168.11.100:5060;transport=ws SIP/2.0
Via: SIP/2.0/WSS 192.168.11.100;branch=z9hG4bK8143446
Max-Forwards: 69
To: <sip:305@192.168.11.100>;tag=as6e043600
From: <sip:tristanWeb@192.168.11.100:8089>;tag=he6reilfb7
Call-ID: 194c8912328290ff0ade30b643241797@192.168.11.100:5060
CSeq: 8407 INVITE
Contact: <sip:tristanWeb@192.168.11.100:8089>
Content-Type: application/sdp
Session-Expires: 90;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,ice,replaces,outbound
User-Agent: JsSIP 3.10.1
Content-Length: 1577

v=0
o=- 3601013793651234952 3 IN IP4 127.0.0.1
s=-
t=0 0
a=extmap-allow-mixed
a=msid-semantic: WMS c81a7c81-e085-4ee2-895b-6f3df8a43c20
a=group:BUNDLE 0
m=audio 56783 UDP/TLS/RTP/SAVPF 8 9 107 101 63 0 13 110
c=IN IP4 172.28.80.1
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:107 opus/48000/2
a=rtpmap:101 telephone-event/8000
a=rtpmap:63 red/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=fmtp:107 minptime=10;useinbandfec=1
a=fmtp:63 107/107
a=rtcp:9 IN IP4 0.0.0.0
a=extmap:1 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=setup:actpass
a=mid:0
a=msid:c81a7c81-e085-4ee2-895b-6f3df8a43c20 ba94b010-4be8-4dea-a772-f3af0b025cb6
a=sendonly
a=ice-ufrag:99YG
a=ice-pwd:UwyabPrgsqixOswnPPaHn1Mg
a=fingerprint:sha-256 28:3F:C2:F9:B2:E8:ED:9C:D1:C5:F1:6C:C1:C2:54:A3:2D:F1:31:2B:33:BD:47:BE:A4:EA:50:C7:F8:5C:42:7A
a=candidate:903878827 1 udp 2122260223 172.28.80.1 56783 typ host generation 0 network-id 1
a=candidate:173741700 1 udp 2122194687 192.168.11.168 56784 typ host generation 0 network-id 2 network-cost 10
a=candidate:864067708 1 udp 2122129151 192.168.5.155 56785 typ host generation 0 network-id 3 network-cost 10
a=ice-options:trickle
a=ssrc:1926735718 cname:4S+LpcKZNVNhDBpp
a=ssrc:1926735718 msid:c81a7c81-e085-4ee2-895b-6f3df8a43c20 ba94b010-4be8-4dea-a772-f3af0b025cb6
a=rtcp-mux

[ibc]

What is the "caller" here? To hard to figure out. I assume JsSTIP is not the "caller" in your scenario, but those things must be properly explained when reporting a bug.

So the fact that Firefox adds a a=sendrecv attribute at global SDP level is irrelevant. In the m=audio section there is a proper a=sendonly attribute that overrides the global one. If Asterisk doesn't understand it that's a bug in Asterisk side.

[warenbe]

Hi

reproduced here also. Asterisk 18.14

The issue exists in any call direction: either if it's incoming (session invte created by pbx) or outgoing (session invite created by jssip)

the SDP rfc say:

a=sendonly This specifies that the tools should be started in send-only mode. An example may be where a different unicast address is to be used for a traffic destination than for a traffic source. In such a case, two media descriptions may be used, one sendonly and one recvonly. It can be either a session- or media-level attribute, but would normally only be used as a media attribute. It is not dependent on charset. Note that sendonly applies only to the media, and any associated control protocol (e.g., RTCP) SHOULD still be received and processed as normal.

if i get it right, while its not invalid to put this in sesion level, it's preferable to put it in media level only. we'll check what can be done in asterisk side but i thinks it's really better to be clean and put this attribute only in media level instead of both session and media.

[ibc]

but i thinks it's really better to be clean and put this attribute only in media level instead of both session and media.

This is not JsSIP decision. It's Firefox the one that generates its SDP with that attribute at session and media level. This is WebRTC. Browsers generate their SDPs, not us.

[warenbe]

but i thinks it's really better to be clean and put this attribute only in media level instead of both session and media.

This is not JsSIP decision. It's Firefox the one that generates its SDP with that attribute at session and media level. This is WebRTC. Browsers generate their SDPs, not us.

interesting, i thought it was set by jssip.

[ibc]

JsSIP doesn't create SDP. It rewrites it a bit to change the sendrecv attribute at media level when calling hold() and unhold(), nothing else.

[warenbe]

Noted. i'll check if this bug (but is it ?) is reported on mozilla bugreport, and i'll check if we can do something on asterisk level. i agree that asterisk should play MOH in any case.

[ibc]

Firefox could omit the session level attribute but that's not a bug. Asterisk is the problem since if should check the media level attribute if present and override the session level one.