Empty m=video in astersik answer for firefox

Hi,
it looks like that SDP response for firefox connecting to endpoint with vp8 codec is not correct.

1.) When I use chrome it works OK.
1a) This is SDP from chrome INVITE

v=0
o=- 7747810820772849228 2 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1
a=msid-semantic: WMS 78740cb8-93f5-4ef1-be92-dba39ee7311d
m=audio 42962 UDP/TLS/RTP/SAVPF 111 103 104 9 0 8 106 105 13 110 112 113 126
c=IN IP4 89.143.13.238
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1051995033 1 udp 2122260223 172.18.0.1 42962 typ host generation 0 network-id 1 network-cost 50
a=candidate:1401363944 1 udp 2122194687 10.1.2.106 55028 typ host generation 0 network-id 2
a=candidate:1882707817 1 tcp 1518280447 172.18.0.1 9 typ host tcptype active generation 0 network-id 1 network-cost 50
a=candidate:486859032 1 tcp 1518214911 10.1.2.106 9 typ host tcptype active generation 0 network-id 2
a=candidate:3717574005 1 udp 1686052607 89.143.13.238 42962 typ srflx raddr 172.18.0.1 rport 42962 generation 0 network-id 1 network-cost 50
a=candidate:2963708676 1 udp 1685987071 89.143.13.238 55028 typ srflx raddr 10.1.2.106 rport 55028 generation 0 network-id 2
a=ice-ufrag:iHSD
a=ice-pwd:s3w9LUaW63IfLigR0gmMwLRx
a=ice-options:trickle
a=fingerprint:sha-256 56:03:4E:7C:2F:3C:6F:71:AD:0F:02:DE:61:21:52:42:97:8F:5F:FC:EE:26:BD:9F:7E:E1:3B:D9:11:99:8D:D3
a=setup:actpass
a=mid: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=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:78740cb8-93f5-4ef1-be92-dba39ee7311d 507e1394-0710-4ec1-97c1-269994bb1040
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
a=rtpmap:9 G722/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:106 CN/32000
a=rtpmap:105 CN/16000
a=rtpmap:13 CN/8000
a=rtpmap:110 telephone-event/48000
a=rtpmap:112 telephone-event/32000
a=rtpmap:113 telephone-event/16000
a=rtpmap:126 telephone-event/8000
a=ssrc:291263388 cname:yuyk3dkmTmvtfGgD
a=ssrc:291263388 msid:78740cb8-93f5-4ef1-be92-dba39ee7311d 507e1394-0710-4ec1-97c1-269994bb1040
a=ssrc:291263388 mslabel:78740cb8-93f5-4ef1-be92-dba39ee7311d
a=ssrc:291263388 label:507e1394-0710-4ec1-97c1-269994bb1040
m=video 9 UDP/TLS/RTP/SAVPF 96 97 98 99 100 101 102 121 127 120 125 107 108 109 124 119 123
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:iHSD
a=ice-pwd:s3w9LUaW63IfLigR0gmMwLRx
a=ice-options:trickle
a=fingerprint:sha-256 56:03:4E:7C:2F:3C:6F:71:AD:0F:02:DE:61:21:52:42:97:8F:5F:FC:EE:26:BD:9F:7E:E1:3B:D9:11:99:8D:D3
a=setup:actpass
a=mid:1
a=extmap:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:2 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:13 urn:3gpp:video-orientation
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=extmap:12 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:11 http://www.webrtc.org/experiments/rtp-hdrext/video-content-type
a=extmap:7 http://www.webrtc.org/experiments/rtp-hdrext/video-timing
a=extmap:8 http://www.webrtc.org/experiments/rtp-hdrext/color-space
a=extmap:4 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:5 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:6 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:78740cb8-93f5-4ef1-be92-dba39ee7311d 2b5f4776-f90a-4e6b-9cc5-c1ef646b807b
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 goog-remb
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=rtcp-fb:96 nack pli
a=rtpmap:97 rtx/90000
a=fmtp:97 apt=96
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 goog-remb
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=rtcp-fb:98 nack pli
a=fmtp:98 profile-id=0
a=rtpmap:99 rtx/90000
a=fmtp:99 apt=98
a=rtpmap:100 VP9/90000
a=rtcp-fb:100 goog-remb
a=rtcp-fb:100 transport-cc
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=fmtp:100 profile-id=2
a=rtpmap:101 rtx/90000
a=fmtp:101 apt=100
a=rtpmap:102 H264/90000
a=rtcp-fb:102 goog-remb
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=rtcp-fb:102 nack pli
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=102
a=rtpmap:127 H264/90000
a=rtcp-fb:127 goog-remb
a=rtcp-fb:127 transport-cc
a=rtcp-fb:127 ccm fir
a=rtcp-fb:127 nack
a=rtcp-fb:127 nack pli
a=fmtp:127 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42001f
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=127
a=rtpmap:125 H264/90000
a=rtcp-fb:125 goog-remb
a=rtcp-fb:125 transport-cc
a=rtcp-fb:125 ccm fir
a=rtcp-fb:125 nack
a=rtcp-fb:125 nack pli
a=fmtp:125 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42e01f
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:108 H264/90000
a=rtcp-fb:108 goog-remb
a=rtcp-fb:108 transport-cc
a=rtcp-fb:108 ccm fir
a=rtcp-fb:108 nack
a=rtcp-fb:108 nack pli
a=fmtp:108 level-asymmetry-allowed=1;packetization-mode=0;profile-level-id=42e01f
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:124 red/90000
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=124
a=rtpmap:123 ulpfec/90000
a=ssrc-group:FID 3664594598 258422007
a=ssrc:3664594598 cname:yuyk3dkmTmvtfGgD
a=ssrc:3664594598 msid:78740cb8-93f5-4ef1-be92-dba39ee7311d 2b5f4776-f90a-4e6b-9cc5-c1ef646b807b
a=ssrc:3664594598 mslabel:78740cb8-93f5-4ef1-be92-dba39ee7311d
a=ssrc:3664594598 label:2b5f4776-f90a-4e6b-9cc5-c1ef646b807b
a=ssrc:258422007 cname:yuyk3dkmTmvtfGgD
a=ssrc:258422007 msid:78740cb8-93f5-4ef1-be92-dba39ee7311d 2b5f4776-f90a-4e6b-9cc5-c1ef646b807b
a=ssrc:258422007 mslabel:78740cb8-93f5-4ef1-be92-dba39ee7311d
a=ssrc:258422007 label:2b5f4776-f90a-4e6b-9cc5-c1ef646b807b

1b) SDP Asterisk->chrome SIP OK

v=0
o=- 1326966348 4 IN IP4 10.1.1.5
s=Asterisk
c=IN IP4 10.1.1.5
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1
m=audio 15910 UDP/TLS/RTP/SAVPF 8 126
a=connection:new
a=setup:active
a=fingerprint:SHA-256 2A:2C:12:0C:9C:B8:7C:A5:75:C4:2A:E1:E8:10:09:5F:52:14:5C:3D:86:C2:50:01:FF:20:59:CA:C5:5D:AC:95
a=ice-ufrag:1c3335af0e8bc1414cc18c616c952bf1
a=ice-pwd:1f302514694f5df06c28bcb136c82f6a
a=candidate:Ha010105 1 UDP 2130706431 10.1.1.5 15910 typ host
a=candidate:Hac122572 1 UDP 2130706431 172.18.37.114 15910 typ host
a=candidate:Sc14da065 1 UDP 1694498815 193.77.160.101 15910 typ srflx raddr 10.1.1.5 rport 15910
a=rtpmap:8 PCMA/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:1972734060 cname:78923781-866d-42f7-8c4b-f91647fa1bc2
a=msid:891c1f28-b07b-4263-add7-541f2ccd1c25 eb8dc61f-e178-4595-a132-73535739b53d
a=rtcp-fb:* transport-cc
a=mid:0
m=video 15910 UDP/TLS/RTP/SAVPF 96
a=connection:new
a=setup:active
a=fingerprint:SHA-256 2A:2C:12:0C:9C:B8:7C:A5:75:C4:2A:E1:E8:10:09:5F:52:14:5C:3D:86:C2:50:01:FF:20:59:CA:C5:5D:AC:95
a=ice-ufrag:1c3335af0e8bc1414cc18c616c952bf1
a=ice-pwd:1f302514694f5df06c28bcb136c82f6a
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:1030952402 cname:1fb04e2d-9cf7-4e07-8951-752177d0700c
a=msid:891c1f28-b07b-4263-add7-541f2ccd1c25 7d55c7da-f157-4570-ace1-6507f3537923
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
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=mid:1

2.) But response from firefox does’t provide any video codec.
2a) This is SDP from firefox INVITE

v=0
o=mozilla...THIS_IS_SDPARTA-83.0 4302482666796200692 0 IN IP4 0.0.0.0
s=-
t=0 0
a=sendrecv
a=fingerprint:sha-256 43:80:C0:B3:4C:15:85:B5:89:25:57:A1:DC:DA:72:E3:93:87:F0:D0:0E:5C:66:34:C8:27:C6:90:E7:D4:62:69
a=group:BUNDLE 0 1
a=ice-options:trickle
a=msid-semantic:WMS *
m=audio 38768 UDP/TLS/RTP/SAVPF 109 9 0 8 101
c=IN IP4 89.143.13.238
a=candidate:0 1 UDP 2122252543 10.1.2.106 38768 typ host
a=candidate:2 1 UDP 2121990399 172.17.0.1 60177 typ host
a=candidate:4 1 UDP 2122187007 172.19.0.1 37615 typ host
a=candidate:6 1 UDP 2122121471 172.18.0.1 40485 typ host
a=candidate:8 1 UDP 2122055935 172.20.0.1 44273 typ host
a=candidate:10 1 TCP 2105524479 10.1.2.106 9 typ host tcptype active
a=candidate:11 1 TCP 2105262335 172.17.0.1 9 typ host tcptype active
a=candidate:12 1 TCP 2105458943 172.19.0.1 9 typ host tcptype active
a=candidate:13 1 TCP 2105393407 172.18.0.1 9 typ host tcptype active
a=candidate:14 1 TCP 2105327871 172.20.0.1 9 typ host tcptype active
a=candidate:0 2 UDP 2122252542 10.1.2.106 56855 typ host
a=candidate:2 2 UDP 2121990398 172.17.0.1 49417 typ host
a=candidate:4 2 UDP 2122187006 172.19.0.1 59021 typ host
a=candidate:6 2 UDP 2122121470 172.18.0.1 41581 typ host
a=candidate:8 2 UDP 2122055934 172.20.0.1 53200 typ host
a=candidate:10 2 TCP 2105524478 10.1.2.106 9 typ host tcptype active
a=candidate:11 2 TCP 2105262334 172.17.0.1 9 typ host tcptype active
a=candidate:12 2 TCP 2105458942 172.19.0.1 9 typ host tcptype active
a=candidate:13 2 TCP 2105393406 172.18.0.1 9 typ host tcptype active
a=candidate:14 2 TCP 2105327870 172.20.0.1 9 typ host tcptype active
a=candidate:1 1 UDP 1686052863 89.143.13.238 38768 typ srflx raddr 10.1.2.106 rport 38768
a=candidate:3 1 UDP 1685790719 89.143.13.238 60177 typ srflx raddr 172.17.0.1 rport 60177
a=candidate:5 1 UDP 1685987327 89.143.13.238 37615 typ srflx raddr 172.19.0.1 rport 37615
a=candidate:7 1 UDP 1685921791 89.143.13.238 40485 typ srflx raddr 172.18.0.1 rport 40485
a=candidate:9 1 UDP 1685856255 89.143.13.238 44273 typ srflx raddr 172.20.0.1 rport 44273
a=candidate:1 2 UDP 1686052862 89.143.13.238 56855 typ srflx raddr 10.1.2.106 rport 56855
a=candidate:3 2 UDP 1685790718 89.143.13.238 49417 typ srflx raddr 172.17.0.1 rport 49417
a=candidate:5 2 UDP 1685987326 89.143.13.238 59021 typ srflx raddr 172.19.0.1 rport 59021
a=candidate:7 2 UDP 1685921790 89.143.13.238 41581 typ srflx raddr 172.18.0.1 rport 41581
a=candidate:9 2 UDP 1685856254 89.143.13.238 53200 typ srflx raddr 172.20.0.1 rport 53200
a=sendrecv
a=end-of-candidates
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=fmtp:109 maxplaybackrate=48000;stereo=1;useinbandfec=1
a=fmtp:101 0-15
a=ice-pwd:ad32a27167bffe910202ac906c5b1c7d
a=ice-ufrag:eb6816e9
a=mid:0
a=msid:{dd750deb-80bb-4a82-bbf0-83f24ce292b3} {1cf4f97e-1968-4761-a77e-974702acf3f5}
a=rtcp:56855 IN IP4 89.143.13.238
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=rtpmap:101 telephone-event/8000
a=setup:actpass
a=ssrc:2507656454 cname:{23cfefa6-0564-4933-a926-c09f2bae0684}
m=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0
a=bundle-only
a=sendrecv
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:4 http://www.webrtc.org/experiments/rtp-hdrext/abs-send-time
a=extmap:5 urn:ietf:params:rtp-hdrext:toffset
a=extmap:6/recvonly http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:7 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
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=fmtp:120 max-fs=12288;max-fr=60
a=fmtp:124 apt=120
a=fmtp:121 max-fs=12288;max-fr=60
a=fmtp:125 apt=121
a=fmtp:127 apt=126
a=fmtp:98 apt=97
a=ice-pwd:ad32a27167bffe910202ac906c5b1c7d
a=ice-ufrag:eb6816e9
a=mid:1
a=msid:{dd750deb-80bb-4a82-bbf0-83f24ce292b3} {bcb0e3d3-29f3-4667-b6ec-9423e2f46ebd}
a=rtcp-fb:120 nack
a=rtcp-fb:120 nack pli
a=rtcp-fb:120 ccm fir
a=rtcp-fb:120 goog-remb
a=rtcp-fb:120 transport-cc
a=rtcp-fb:121 nack
a=rtcp-fb:121 nack pli
a=rtcp-fb:121 ccm fir
a=rtcp-fb:121 goog-remb
a=rtcp-fb:121 transport-cc
a=rtcp-fb:126 nack
a=rtcp-fb:126 nack pli
a=rtcp-fb:126 ccm fir
a=rtcp-fb:126 goog-remb
a=rtcp-fb:126 transport-cc
a=rtcp-fb:97 nack
a=rtcp-fb:97 nack pli
a=rtcp-fb:97 ccm fir
a=rtcp-fb:97 goog-remb
a=rtcp-fb:97 transport-cc
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:120 VP8/90000
a=rtpmap:124 rtx/90000
a=rtpmap:121 VP9/90000
a=rtpmap:125 rtx/90000
a=rtpmap:126 H264/90000
a=rtpmap:127 rtx/90000
a=rtpmap:97 H264/90000
a=rtpmap:98 rtx/90000
a=setup:actpass
a=ssrc:4257958389 cname:{23cfefa6-0564-4933-a926-c09f2bae0684}
a=ssrc:3288311794 cname:{23cfefa6-0564-4933-a926-c09f2bae0684}
a=ssrc-group:FID 4257958389 3288311794

2b) SDP Asterisk->firefox SIP OK

v=0
o=- 2661921524 2 IN IP4 10.1.1.5
s=Asterisk
c=IN IP4 10.1.1.5
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0
m=audio 16504 UDP/TLS/RTP/SAVPF 8 101
a=connection:new
a=setup:active
a=fingerprint:SHA-256 2A:2C:12:0C:9C:B8:7C:A5:75:C4:2A:E1:E8:10:09:5F:52:14:5C:3D:86:C2:50:01:FF:20:59:CA:C5:5D:AC:95
a=ice-ufrag:533ec0943b70551a6c5512520114ca28
a=ice-pwd:6f5472bc2e90b0de7e72d7050836f669
a=candidate:Ha010105 1 UDP 2130706431 10.1.1.5 16504 typ host
a=candidate:Hac122572 1 UDP 2130706431 172.18.37.114 16504 typ host
a=candidate:Sc14da065 1 UDP 1694498815 193.77.160.101 16504 typ srflx raddr 10.1.1.5 rport 16504
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=maxptime:150
a=sendrecv
a=rtcp-mux
a=ssrc:1682061302 cname:b855d086-26b0-4bfb-a320-3538119af50d
a=msid:4956878a-0e65-41ba-92d9-5f5804b7c4c4 a7f2d6c9-294e-425c-b87d-54548b60c9e1
a=rtcp-fb:* transport-cc
a=mid:0
m=video 0 UDP/TLS/RTP/SAVPF 120 124 121 125 126 127 97 98
c=IN IP4 0.0.0.0

As you can see in asterisk response for firefox, SDP for m=video is empty providing no video codec/connection info.

In both case I use same asterisk endpoint which supports only vp8.

Any clue why codec a=rtpmap:120 VP8/90000 was not accepted by asterisk from firefox offer?

best regard
edvin

You’d need to describe the full scenario and provide configuration.

Hi,
scenario is very simple.

I have asterisk ARI application and client (browser using sip.js) makes a call to asterisk endpoint. This is dynamic endpoint created using asterisk ari. Inbound channel is added to bridge with (video_sfu). Then another channel is originated and added to bridge. This all works fine on chrome, but problem is when inbound call is created from firefox. In this situation the first INVITE from firefox gets SDP with empty video as you can see in 2b of previous post. This all happens before second channel is originated and added to bridge.

Here is SIP history:

Here is SIP history:
00000 1606381674 * <== 127.0.0.1:33568          INVITE sip:1*3000*5537a56e-0002-0000-e56e-338a2cf071f4@example.com SIP/2.0
00001 1606381674 * ==> 127.0.0.1:33568          SIP/2.0 401 Unauthorized
00002 1606381674 * <== 127.0.0.1:33568          ACK sip:1*3000*5537a56e-0002-0000-e56e-338a2cf071f4@example.com SIP/2.0
00003 1606381674 * <== 127.0.0.1:33568          INVITE sip:1*3000*5537a56e-0002-0000-e56e-338a2cf071f4@example.com SIP/2.0
00004 1606381674 * ==> 127.0.0.1:33568          SIP/2.0 100 Trying
00005 1606381674 * ==> 127.0.0.1:33568          SIP/2.0 200 OK
00006 1606381674 * <== 127.0.0.1:33568          ACK sip:127.0.1.1:8089;transport=ws SIP/2.0
00007 1606381674 * ==> 127.0.0.1:33480          INVITE sip:i5khl523@127.0.0.1:33480;transport=ws SIP/2.0
00008 1606381674 * <== 127.0.0.1:33480          SIP/2.0 100 Trying
00009 1606381674 * <== 127.0.0.1:33480          SIP/2.0 180 Ringing
00010 1606381675 * <== 127.0.0.1:33568          REGISTER sip:navaya.12media.si SIP/2.0
00011 1606381675 * ==> 127.0.0.1:33568          SIP/2.0 401 Unauthorized
00012 1606381675 * <== 127.0.0.1:33568          REGISTER sip:navaya.12media.si SIP/2.0
00013 1606381675 * ==> 127.0.0.1:33568          SIP/2.0 200 OK
00014 1606381676 * <== 127.0.0.1:33480          SIP/2.0 200 OK
00015 1606381676 * ==> 127.0.0.1:33480          ACK sip:i5khl523@127.0.0.1:33480;transport=ws SIP/2.0
00016 1606381676 * ==> 127.0.0.1:33568          INVITE sip:hm6gn4ik@127.0.0.1:33568;transport=ws;ob SIP/2.0
00017 1606381676 * <== 127.0.0.1:33568          SIP/2.0 200 OK
00018 1606381676 * ==> 127.0.0.1:33568          ACK sip:hm6gn4ik@127.0.0.1:33568;transport=ws;ob SIP/2.0

Here #3 is offer from firefox and #5 is problematic SDP output from asterisk. All offer and answer SDP for chrome and firefox are in first mail. The problem is that first asterisk answer from firefox is completely different from one of chrome.

Also when second channel is added to bridge in case of chrome there are two INVITEs sended, with information of new video track. But in case of firefox only one INVITE is sended from asterisk! The end result is that one client is missing video from other!

So what confuse astersik that when he receives offer 2a) it gives answer 2b) without video but works with offer 1a) from chrome.

The response isn’t empty. m and c are sufficient.

I would say the problem was that firefox never offered the stream, as it sent a port number of 0 in the initial SDP. At least in a response, a port number of zero constitutes a rejection.

Hi,
I find a problem, it has to do how bundlePolicy works. I set bundle policy to “max-bundle” because the other peer is always asterisk and asterisk supports bundle policy. Firefox correctly implements this policy by setting m=video 0 and also adding a=bundle-only attribute.

From draft-ietf-mmusic-sdp-bundle-negotiation-48.txt:

This specification updates RFC 3264, to allow assigning a zero port value to a “m=” section without meaning that the media described by the “m=” section is disabled or rejected.

For “max-bundle” specification:

The ICE agent initially creates only a single RTCDtlsTransport to carry all of the RTCPeerConnection’s data. If the remote endpoint is not BUNDLE-aware, then only a single track will be negotiated and the rest ignored.

So assigning zero doesn’t means that this section is rejected it only means that single track will be used in case that remote peer doesn’t support bundling. So in this case asterisk works like it doesn’t support bundling. Because chrome implementation is not strict with specefication it also works with max-bundle.

Setting bundle policy to balanced works until asterisk supports a=bundle-only atribute.

I made mistake in previous mail when saying “Setting bundle policy to balanced works until asterisk supports a=bundle-only atribute”. You should use “max-compat” to ensure working with asterisk.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.