WebRTC Renegotiation with ConfBridge not working

Hello!

I am using Asterisk 18.8.0 and PJSIP. The softphones used in the calls are JsSIP/WebRTC.

I have two (or more) participants in a conference (ConfBridge) which are both using WebRTC. I need to be able to add streams/tracks during the call and then renegotiate the connection.

In a normal call with two WebRTC clients, asterisk forwards the INVITE with the new offer SDP to the other part as expected, but in a ConfBridge-conference the INVITE is not forwarded. The offerer sends the INVITE to asterisk, asterisk responds 200 OK and then nothing else happens.

The SDP’s are pretty much identical for the normal call and the conference call in the “re-INVITE”.

Is there any obvious reason for this behavior? Let me know if I need to add any more information.

Thanks in advance!

Asterisk is a back to back user agent; it never forwards INVITEs.

It might get close to forwarding the SDP if it is native bridging, but conference bridges are never native, at leat not where SIP is involved.

Also you didn’t say which channel driver you are using. chan_sip definitely cannot add streams that weren’t in the original offer.

Alright, my understanding is probably a bit flawed.

The behavior i’m seeing is probably as expected, in the normal call the destination of the “reinvite” is the other extension hence why it is “forwarded” (in lack of a better word). But in the conference the destination is the conference, which is some temporary entity within asterisk.

The channel driver i’m using is chan_pjsip.

Even though adding a new stream in the regular call seems to be working, maybe it is not intended the way im doing it? or at all? For example it seems to only work properly from the callers side and not the callee.

Is there a proper way to handle WebRTC renegotiating new streams during a call using chan_pjsip? If so, should it also work in the case of ConfBridge?

Using what video mode for the conference bridge?

Im using video mode sfu.

Provided you’re allowing multiple video streams it should work. You’d need to provide an actual debug log with SIP trace in it.

If video_mode=sfu is the only config needed for multiple streams I should be good.

SIP trace from renegotiation: (case*563 is the conference number) (Also note how the INVITE content i s cut off, maybe just a visual thing or could this be an issue?)

<--- Received SIP request (10045 bytes) from WSS:<ip-1>:64126 --->
INVITE sip:192.168.1.210:4062;transport=ws SIP/2.0
Via: SIP/2.0/WSS mi2coo7g1488.invalid;branch=z9hG4bK8825663
Max-Forwards: 69
To: <sip:case*563@ip-1-domain>;tag=d9f770f0-9a63-417c-88b3-7ecd70665319
From: <sip:o_webrtc@ip-1-domain>;tag=hdnetlclot
Call-ID: uhbr79gsl59bj5m6merf
CSeq: 537 INVITE
Contact: <sip:d4db4liu@mi2coo7g1488.invalid;transport=ws;ob>
Content-Type: application/sdp
Session-Expires: 1800;refresher=uac
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: timer,ice,replaces,outbound
User-Agent: JsSIP 3.9.0
Content-Length: 9445

v=0
o=- 462343703604638188 5 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 video-2
a=extmap-allow-mixed
a=msid-semantic: WMS DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW
m=audio 53533 UDP/TLS/RTP/SAVPF 111 9 8 0 126 63 103 104 106 105 13 110 112 113
c=IN IP4 <ip-1>
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1466007278 1 udp 2122260223 <ip-2> 53531 typ host generation 0 network-id 1
a=candidate:49843329 1 udp 2122194687 172.24.64.1 53532 typ host generation 0 network-id 2
a=candidate:2894319779 1 udp 2122129151 192.168.1.52 53533 typ host generation 0 network-id 3
a=candidate:3374666510 1 udp 2122063615 192.168.244.1 53534 typ host generation 0 network-id 4
a=candidate:111037495 1 udp 2121998079 192.168.187.1 53535 typ host generation 0 network-id 5
a=candidate:1519626615 1 udp 1685921535 <ip-1> 53533 typ srflx raddr 192.168.1.52 rport 53533 generation 0 network-id 3
a=candidate:434274846 1 tcp 1518280447 <ip-2> 9 typ host tcptype active generation 0 network-id 1
a=candidate:1283158129 1 tcp 1518214911 172.24.64.1 9 typ host tcptype active generation 0 network-id 2
a=candidate:3791662163 1 tcp 1518149375 192.168.1.52 9 typ host tcptype active generation 0 network-id 3
a=candidate:2275848190 1 tcp 1518083839 192.168.244.1 9 typ host tcptype active generation 0 network-id 4
a=candidate:1209905351 1 tcp 1518018303 192.168.187.1 9 typ host tcptype active generation 0 network-id 5
a=ice-ufrag:1emn
a=ice-pwd:Wm54KA46hmya9IXMi3qq0qJ4
a=ice-options:trickle
a=fingerprint:sha-256 90:F3:2B:17:41:9E:EE:77:62:CF:E3:08:C9:27:F7:36:C2:C9:90:6A:56:69:45:6C:0F:36:A0:8C:74:FA:06:11
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=sendrecv
a=msid:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW 0a240a6d-4ee5-4395-96d8-b7f85667ac3a
a=rtcp-mux
a=rtpmap:111 opus/48000/2
a=rtcp-fb:111 transport-cc
a=fmtp:111 minptime=10;useinbandfec=1
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=rtpmap:63 red/48000/2
a=fmtp:63 111/111
a=rtpmap:103 ISAC/16000
a=rtpmap:104 ISAC/32000
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=ssrc:4278102898 cname:hy7kke18IlczsmWZ
a=ssrc:4278102898 msid:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW 0a240a6d-4ee5-4395-96d8-b7f85667ac3a
a=ssrc:4278102898 mslabel:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW
a=ssrc:4278102898 label:0a240a6d-4ee5-4395-96d8-b7f85667ac3a
m=video 53538 UDP/TLS/RTP/SAVPF 98 96 97 99 100 101 121 107 109 120 119 36 41 42 115 116 117 118
c=IN IP4 <ip-1>
b=AS:1000
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:1466007278 1 udp 2122260223 <ip-2> 53536 typ host generation 0 network-id 1
a=candidate:49843329 1 udp 2122194687 172.24.64.1 53537 typ host generation 0 network-id 2
a=candidate:2894319779 1 udp 2122129151 192.168.1.52 53538 typ host generation 0 network-id 3
a=candidate:3374666510 1 udp 2122063615 192.168.244.1 53539 typ host generation 0 network-id 4
a=candidate:111037495 1 udp 2121998079 192.168.187.1 53540 typ host generation 0 network-id 5
a=candidate:1519626615 1 udp 1685921535 <ip-1> 53538 typ srflx raddr 192.168.1.52 rport 53538 generation 0 network-id 3
a=candidate:434274846 1 tcp 1518280447 <ip-2> 9 typ host tcptype active generation 0 network-id 1
a=candidate:1283158129 1 tcp 1518214911 172.24.64.1 9 typ host tcptype active generation 0 network-id 2
a=candidate:3791662163 1 tcp 1518149375 192.168.1.52 9 typ host tcptype active generation 0 network-id 3
a=candidate:2275848190 1 tcp 1518083839 192.168.244.1 9 typ host tcptype active generation 0 network-id 4
a=candidate:1209905351 1 tcp 1518018303 192.168.187.1 9 typ host tcptype active generation 0 network-id 5
a=ice-ufrag:1emn
a=ice-pwd:Wm54KA46hmya9IXMi3qq0qJ4
a=ice-options:trickle
a=fingerprint:sha-256 90:F3:2B:17:41:9E:EE:77:62:CF:E3:08:C9:27:F7:36:C2:C9:90:6A:56:69:45:6C:0F:36:A0:8C:74:FA:06:11
a=setup:actpass
a=mid:1
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:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 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:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW d70e2733-bf87-4409-a11e-510f634273d0
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=fmtp:98 profile-id=0
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: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:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:41 AV1/90000
a=rtcp-fb:41 goog-remb
a=rtcp-fb:41 transport-cc
a=rtcp-fb:41 ccm fir
a=rtcp-fb:41 nack
a=rtcp-fb:41 nack pli
a=rtpmap:42 rtx/90000
a=fmtp:42 apt=41
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 red/90000
a=rtpmap:117 rtx/90000
a=fmtp:117 apt=116
a=rtpmap:118 ulpfec/90000
a=ssrc-group:FID 4137190936 3773942999
a=ssrc:4137190936 cname:hy7kke18IlczsmWZ
a=ssrc:4137190936 msid:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW d70e2733-bf87-4409-a11e-510f634273d0
a=ssrc:4137190936 mslabel:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW
a=ssrc:4137190936 label:d70e2733-bf87-4409-a11e-510f634273d0
a=ssrc:3773942999 cname:hy7kke18IlczsmWZ
a=ssrc:3773942999 msid:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW d70e2733-bf87-4409-a11e-510f634273d0
a=ssrc:3773942999 mslabel:DMONl2dRdqbHFdUOHuKfWGC07hlKwemUoDsW
a=ssrc:3773942999 label:d70e2733-bf87-4409-a11e-510f634273d0
m=video 9 UDP/TLS/RTP/SAVPF 98 96 97 99 100 101 121 107 109 120 119 36 41 42 115 116 117 118
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:1emn
a=ice-pwd:Wm54KA46hmya9IXMi3qq0qJ4
a=ice-options:trickle
a=fingerprint:sha-256 90:F3:2B:17:41:9E:EE:77:62:CF:E3:08:C9:27:F7:36:C2:C9:90:6A:56:69:45:6C:0F:36:A0:8C:74:FA:06:11
a=setup:actpass
a=mid:video-2
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:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 http://www.webr<--- Transmitting SIP response (3068 bytes) to WSS:<ip-1>:64126 --->          <NOTE! Cut off due to length?>
SIP/2.0 200 OK
Via: SIP/2.0/WSS mi2coo7g1488.invalid;rport=64126;received=<ip-1>;branch=z9hG4bK8825663
Call-ID: uhbr79gsl59bj5m6merf
From: <sip:o_webrtc@ip-1-domain>;tag=hdnetlclot
To: <sip:case*563@ip-1-domain>;tag=d9f770f0-9a63-417c-88b3-7ecd70665319
CSeq: 537 INVITE
Session-Expires: 1800;refresher=uac
Require: timer
Contact: <sip:192.168.1.210:4062;transport=ws>
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, MESSAGE, REFER
Supported: 100rel, timer, replaces, norefersub
Server: domain.com pbx
Content-Type: application/sdp
Content-Length:  2441

v=0
o=- 427700716 7 IN IP4 192.168.1.210
s=domain.com pbx
c=IN IP4 192.168.1.210
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1 video-2
m=audio 4154 UDP/TLS/RTP/SAVPF 111 9 8 0 126
a=connection:existing
a=setup:active
a=fingerprint:SHA-256 A9:33:FB:CE:1C:15:4D:90:B1:85:92:8C:66:5B:6B:BA:86:30:45:79:56:01:6A:60:A1:92:41:ED:26:C9:AE:E5
a=ice-ufrag:3eef1e686e8b0d7318c4a73b680bc9e1
a=ice-pwd:63efb1d11a1840ae0afaeb792e524e69
a=candidate:Hc0a801d2 1 UDP 2130706431 192.168.1.210 4154 typ host
a=candidate:Sd4f70495 1 UDP 1694498815 <ip-1> 4154 typ srflx raddr 192.168.1.210 rport 4154
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
a=rtpmap:9 G722/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:126 telephone-event/8000
a=fmtp:126 0-16
a=ptime:20
a=maxptime:20
a=sendrecv
a=rtcp-mux
a=ssrc:1363526631 cname:2fb75399-6441-4c55-b9d3-f2fb8a2a0e62
a=msid:ffa83386-639f-4dc8-ac7b-485ef13c0719 be48067c-e724-4ac6-88aa-80316ec7258e
a=rtcp-fb:* transport-cc
a=mid:0
m=video 4154 UDP/TLS/RTP/SAVPF 98
a=connection:existing
a=setup:active
a=fingerprint:SHA-256 A9:33:FB:CE:1C:15:4D:90:B1:85:92:8C:66:5B:6B:BA:86:30:45:79:56:01:6A:60:A1:92:41:ED:26:C9:AE:E5
a=ice-ufrag:3eef1e686e8b0d7318c4a73b680bc9e1
a=ice-pwd:63efb1d11a1840ae0afaeb792e524e69
a=rtpmap:98 VP9/90000
a=sendrecv
a=rtcp-mux
a=ssrc:1333153738 cname:f3ac07d9-43f0-41f9-a607-d0e02c6a7fb4
a=msid:ffa83386-639f-4dc8-ac7b-485ef13c0719 930ca227-3612-48d5-a8af-ed712fb0e8fe
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
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 4154 UDP/TLS/RTP/SAVPF 98
a=connection:existing
a=setup:active
a=fingerprint:SHA-256 A9:33:FB:CE:1C:15:4D:90:B1:85:92:8C:66:5B:6B:BA:86:30:45:79:56:01:6A:60:A1:92:41:ED:26:C9:AE:E5
a=ice-ufrag:3eef1e686e8b0d7318c4a73b680bc9e1
a=ice-pwd:63efb1d11a1840ae0afaeb792e524e69
a=rtpmap:98 VP9/90000
a=sendrecv
a=rtcp-mux
a=ssrc:862269189 cname:ab685344-755f-4f2f-ba2a-3a9625bfa8c4
a=msid:5c948aa6-89d9-46bc-957c-829ad724274b f9948d38-9f4c-463a-9f31-d48412144b26
a=label:1652675716.23
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
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

<--- Received SIP request (442 bytes) from WSS:<ip-1>:64126 --->
ACK sip:192.168.1.210:4062;transport=ws SIP/2.0
Via: SIP/2.0/WSS mi2coo7g1488.invalid;branch=z9hG4bK1282764
Max-Forwards: 69
To: <sip:case*563@ip-1-domain>;tag=d9f770f0-9a63-417c-88b3-7ecd70665319
From: <sip:o_webrtc@ip-1-domain>;tag=hdnetlclot
Call-ID: uhbr79gsl59bj5m6merf
CSeq: 537 ACK
Allow: INVITE,ACK,CANCEL,BYE,UPDATE,MESSAGE,OPTIONS,REFER,INFO,NOTIFY
Supported: outbound
User-Agent: JsSIP 3.9.0
Content-Length: 0

It’s generally cosmetic, but this is only a SIP trace. I also wanted debug[1] because the bridge_softmix module has debug for its handling of this.

[1] Collecting Debug Information - Asterisk Project - Asterisk Project Wiki

Oh sorry, forgot about debug logging.

Here is the debug log with SIP trace:
debug_log_confbridge.txt (60.5 KB)

In the provided log I see 3 streams. 1 audio, 1 video from the client, 1 video from Asterisk to the client. Should there be more? If so, it’s not in this SDP from the client.

There should be 2 video streams from the client. But for some reason the added stream seems to be merged with or added to the recvonly m=video section (incoming video from Asterisk I assume), see the code snippets below. It is also changed from recvonly to sendrecv and has msid and ssrc attributes.

I guess this is why Asterisk doesn’t recognize it as a new stream.

I’m not sure if this is a WebRTC or Asterisk issue though.

Here is the m=video section before adding a new stream and track:

m=video 9 UDP/TLS/RTP/SAVPF 98 96 97 99 100 101 102 122 121 107 109 120 119 36 38 40 41 42 115 116 117 118 43
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:L3fq
a=ice-pwd:qdobEN+Ftfm9oW5fxpyZJP9Z
a=ice-options:trickle
a=fingerprint:sha-256 25:0B:6F:27:23:13:E5:FA:80:E6:FB:53:94:E6:FD:C8:16:9F:07:5F:D2:F7:9E:9B:69:47:FB:2A:96:CF:07:AB
a=setup:actpass
a=mid:video-2
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:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 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:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=recvonly
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=fmtp:98 profile-id=0
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: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 VP9/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 profile-id=1
a=rtpmap:122 rtx/90000
a=fmtp:122 apt=102
a=rtpmap:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:38 rtx/90000
a=fmtp:38 apt=37
a=rtpmap:40 rtx/90000
a=fmtp:40 apt=39
a=rtpmap:41 AV1/90000
a=rtcp-fb:41 goog-remb
a=rtcp-fb:41 transport-cc
a=rtcp-fb:41 ccm fir
a=rtcp-fb:41 nack
a=rtcp-fb:41 nack pli
a=rtpmap:42 rtx/90000
a=fmtp:42 apt=41
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 red/90000
a=rtpmap:117 rtx/90000
a=fmtp:117 apt=116
a=rtpmap:118 ulpfec/90000
a=rtpmap:43 flexfec-03/90000
a=rtcp-fb:43 goog-remb
a=rtcp-fb:43 transport-cc
a=fmtp:43 repair-window=10000000

And this is after:

m=video 9 UDP/TLS/RTP/SAVPF 98 96 97 99 100 101 121 107 109 120 119 36 41 42 115 116 117 118
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:fjCc
a=ice-pwd:QV0X0mXTQOjTxrDabRiPG8lF
a=ice-options:trickle
a=fingerprint:sha-256 0E:60:23:F6:B6:CB:08:DD:B5:17:21:BE:47:31:77:60:C3:2E:23:34:09:75:B5:F2:59:0B:73:67:AE:D5:4E:14
a=setup:actpass
a=mid:video-2
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:14 urn:ietf:params:rtp-hdrext:toffset
a=extmap:13 urn:3gpp:video-orientation
a=extmap:5 http://www.webrtc.org/experiments/rtp-hdrext/playout-delay
a=extmap:6 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:10 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=extmap:11 urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-stream-id
a=sendrecv
a=msid:64506b4b-98eb-4da9-ba7c-bc20a8f71511 8ca65335-6f4c-4b91-aa6d-e93d3ab3210c
a=rtcp-mux
a=rtcp-rsize
a=rtpmap:98 VP9/90000
a=rtcp-fb:98 transport-cc
a=rtcp-fb:98 ccm fir
a=rtcp-fb:98 nack
a=fmtp:98 profile-id=0
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: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:121 rtx/90000
a=fmtp:121 apt=127
a=rtpmap:107 rtx/90000
a=fmtp:107 apt=125
a=rtpmap:109 rtx/90000
a=fmtp:109 apt=108
a=rtpmap:120 rtx/90000
a=fmtp:120 apt=124
a=rtpmap:119 rtx/90000
a=fmtp:119 apt=123
a=rtpmap:36 rtx/90000
a=fmtp:36 apt=35
a=rtpmap:41 AV1/90000
a=rtcp-fb:41 goog-remb
a=rtcp-fb:41 transport-cc
a=rtcp-fb:41 ccm fir
a=rtcp-fb:41 nack
a=rtcp-fb:41 nack pli
a=rtpmap:42 rtx/90000
a=fmtp:42 apt=41
a=rtpmap:115 rtx/90000
a=fmtp:115 apt=114
a=rtpmap:116 red/90000
a=rtpmap:117 rtx/90000
a=fmtp:117 apt=116
a=rtpmap:118 ulpfec/90000
a=ssrc-group:FID 1191896351 2967228407
a=ssrc:1191896351 cname:07uLPbdfo9fstnJg
a=ssrc:1191896351 msid:64506b4b-98eb-4da9-ba7c-bc20a8f71511 8ca65335-6f4c-4b91-aa6d-e93d3ab3210c
a=ssrc:1191896351 mslabel:64506b4b-98eb-4da9-ba7c-bc20a8f71511
a=ssrc:1191896351 label:8ca65335-6f4c-4b91-aa6d-e93d3ab3210c
a=ssrc:2967228407 cname:07uLPbdfo9fstnJg
a=ssrc:2967228407 msid:64506b4b-98eb-4da9-ba7c-bc20a8f71511 8ca65335-6f4c-4b91-aa6d-e93d3ab3210c
a=ssrc:2967228407 mslabel:64506b4b-98eb-4da9-ba7c-bc20a8f71511
a=ssrc:2967228407 label:8ca65335-6f4c-4b91-aa6d-e93d3ab3210c

Asterisk doesn’t support “merging” or “adding”. It expects an additional stream to be added, the stream from Asterisk to the client can’t be used for two purposes.

Yeah, that makes sense.

I’m not sure why there is not a new m-line instead of this strange merge-behavior. I have tried to change around my JavaScript code a bit but I get the same result.
I will have to do some research and see if I can make this make sense.

I don’t see anything I would interpret as merging. I see a single stream that was originally on hold which is being taken out of hold.

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