Problem with SDP in ARI video bridge

Hi,
I have latest 18.0.1 asterisk and following ari app.

WebRTC client1 calls asterisk (using sip.js library)
Call is received, new bridge is created and incoming channel is added to bridge with video_sfu.
New channel is originated to webrtc client2, after success this channel is added to bridge.

This is SIP trace from asterisk:

00000 1605689340 * <== 127.0.0.1:36858          INVITE sip:1*3001*5af93731-0000-011f-cc6d-953f3bd57437@example.com SIP/2.0
00001 1605689340 * ==> 127.0.0.1:36858          SIP/2.0 401 Unauthorized
00002 1605689340 * <== 127.0.0.1:36858          ACK sip:1*3001*5af93731-0000-011f-cc6d-953f3bd57437@example.com SIP/2.0
00003 1605689340 * <== 127.0.0.1:36858          INVITE sip:1*3001*5af93731-0000-011f-cc6d-953f3bd57437@example.com SIP/2.0
00004 1605689340 * ==> 127.0.0.1:36858          SIP/2.0 100 Trying
00005 1605689340 * ==> 127.0.0.1:36858          SIP/2.0 200 OK
00006 1605689340 * <== 127.0.0.1:36858          ACK sip:127.0.1.1:8089;transport=ws SIP/2.0
00007 1605689340 * ==> 127.0.0.1:36850          INVITE sip:kaqqgrd3@127.0.0.1:36850;transport=ws SIP/2.0
00008 1605689340 * <== 127.0.0.1:36850          SIP/2.0 100 Trying
00009 1605689340 * <== 127.0.0.1:36850          SIP/2.0 180 Ringing
00010 1605689344 * <== 127.0.0.1:36850          SIP/2.0 200 OK
00011 1605689344 * ==> 127.0.0.1:36850          ACK sip:kaqqgrd3@127.0.0.1:36850;transport=ws SIP/2.0
00012 1605689344 * ==> 127.0.0.1:36858          INVITE sip:g2t9g9hl@127.0.0.1:36858;transport=ws;ob SIP/2.0
00013 1605689344 * ==> 127.0.0.1:36850          INVITE sip:kaqqgrd3@127.0.0.1:36850;transport=ws SIP/2.0
00014 1605689344 * <== 127.0.0.1:36850          SIP/2.0 200 OK
00015 1605689344 * ==> 127.0.0.1:36850          ACK sip:kaqqgrd3@127.0.0.1:36850;transport=ws SIP/2.0
00016 1605689344 * <== 127.0.0.1:36858          SIP/2.0 200 OK
00017 1605689344 * ==> 127.0.0.1:36858          ACK sip:g2t9g9hl@127.0.0.1:36858;transport=ws;ob SIP/2.0

Problem is that SDP generated in #00012 and #00013 is probably not correct.

SDP #00012:

v=0
o=- 2698389917 5 IN IP4 10.1.2.106
s=Asterisk
c=IN IP4 10.1.2.106
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1 video-2
m=audio 10000 UDP/TLS/RTP/SAVPF 8 126
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 01:D2:D8:52:9B:6B:77:A2:0F:E5:DD:88:BE:14:EF:06:31:74:E9:41:45:DF:B9:1A:4A:62:65:FC:53:96:67:D5
a=ice-ufrag:654fa44e13a291d009acbf306eb571d0
a=ice-pwd:716b24e94bd5a0d63e4de2a62706f327
a=candidate:Ha01026a 1 UDP 2130706431 10.1.2.106 10000 typ host
a=candidate:Hac130001 1 UDP 2130706431 172.19.0.1 10000 typ host
a=candidate:Hac120001 1 UDP 2130706431 172.18.0.1 10000 typ host
a=candidate:Hac140001 1 UDP 2130706431 172.20.0.1 10000 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 10000 typ host
a=candidate:S598f0dee 1 UDP 1694498815 89.143.13.238 10000 typ srflx raddr 10.1.2.106 rport 10000
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:1111618130 cname:5dcafc8d-c956-4865-bad2-706cb6d6dc21
a=msid:0243a8e1-03cc-4187-aa55-efc4fe650497 dbe1a156-99fb-48c0-a350-dafbd179a760
a=rtcp-fb:* transport-cc
a=mid:0
m=video 10000 UDP/TLS/RTP/SAVPF 96
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 01:D2:D8:52:9B:6B:77:A2:0F:E5:DD:88:BE:14:EF:06:31:74:E9:41:45:DF:B9:1A:4A:62:65:FC:53:96:67:D5
a=ice-ufrag:654fa44e13a291d009acbf306eb571d0
a=ice-pwd:716b24e94bd5a0d63e4de2a62706f327
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:1114895987 cname:024477cb-c989-412a-ac81-3f851722690b
a=msid:0243a8e1-03cc-4187-aa55-efc4fe650497 342617e1-57bb-4c09-a2c3-f3b5680caaa6
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
m=video 10000 UDP/TLS/RTP/SAVPF 96
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 01:D2:D8:52:9B:6B:77:A2:0F:E5:DD:88:BE:14:EF:06:31:74:E9:41:45:DF:B9:1A:4A:62:65:FC:53:96:67:D5
a=ice-ufrag:654fa44e13a291d009acbf306eb571d0
a=ice-pwd:716b24e94bd5a0d63e4de2a62706f327
a=rtpmap:96 VP8/90000
a=sendonly
a=rtcp-mux
a=ssrc:668544066 cname:82b76b4c-6199-49c3-bf86-87a42afc88f2
a=msid:4d9f567b-b8aa-4c80-adce-84d3c657656b 06c4981b-e142-4df8-b659-c456fd06b0f9
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:video-2

As you can see it has one m=audio line and two m=video lines. Audio line is a=sendrecv, first video is sendrecv and second is sendonly. This gives total 5 audio/video track: 2 for audio and 3 for video. Because you have only two participants, there should be only 2 audio and 2 video tracks.
This can be confirmed in chrome webrtc-internals where I can see 5 video tracks. One is inactive (no traffic on it). Inactive receiving video track is from first m=video line (one that has sendrecv).

Application still works but it requires more client side handling and also I found some problems latter when I try to implement additional features like holding.

So what should be correct behavior for 2 participants?
a.) m=audio sendrecv, m=video recvonly, m=video sendonly,
b.) m=audio sendrecv, m=video sendrecv

I would prefer b, because this is the same as you get when you have direct peer connection with two participants. For third, fourth … participant there is just additional m=video, sendonly.

Is this bug or I’m missing something.

thanks in advance
edvin

This is the way that the SFU support works. You only ever have 1 audio stream as it is mixed. You have 1 stream which is for video coming from a client (the code could likely be changed to make it recvonly within SDP but hasn’t) and then ‘n’ streams for video coming from other participants.

ok,
thanks.

This is what I wrote as a.) previously (m=audio sendrecv, m=video recvonly, m=video sendonly). But currently first m=video is sendrecv. Should I fill bug issue?

br

You can, I have no timeframe on when it will get looked into though.