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