Hi,
We are having an issue with a stasis app that has multiple mixing bridges with video and allows the caller to switch between them. Essentially joining different video ‘rooms’. Most of the time this works perfectly fine however, if you keep moving between bridges, eventually you will get an error.
Upon entering a bridge we are presented with the following error in the console and video streams for the other parties inside the bridge are not relayed to the client in the SDP.
[Sep 19 14:52:11] WARNING[9236]: res_pjsip_session.c:1103 handle_negotiated_sdp: PJSIP/dev-live-call-0000000f: Local SDP contains 17 media streams while we expected it to contain 16
This is the SDP sent from asterisk to the client:
v=0
o=- 2002303739 33 IN IP4 10.210.0.11
s=Asterisk
c=IN IP4 10.210.0.11
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1 video-2 video-3 video-4 video-5 video-6 video-7 video-8 video-9 video-10 video-11 video-12 video-13 video-14 video-15
m=audio 18322 UDP/TLS/RTP/SAVPF 111 8 0 126
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 D0:DB:24:94:16:E2:DE:55:44:11:FE:44:69:3E:E5:31:6F:3F:EC:B9:19:10:4B:DA:F6:73:40:C5:EB:C9:61:04
a=ice-ufrag:53ca6ff264ec37cc4a200fd207207ca1
a=ice-pwd:7280498149b7219129d01372731d5b35
a=candidate:Had2000b 1 UDP 2130706431 10.210.0.11 18322 typ host
a=candidate:Hac110001 1 UDP 2130706431 172.17.0.1 18322 typ host
a=candidate:S3fb311f 1 UDP 1694498815 3.251.49.31 18322 typ srflx raddr 10.210.0.11 rport 18322
a=rtpmap:111 opus/48000/2
a=fmtp:111 useinbandfec=1
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:758588480 cname:0cbd1471-7e1d-4d2f-946b-82f6f9427cce
a=msid:358eda66-46cd-47b7-8a24-626f971cb1df 40bcedf0-578c-42d6-8566-74788eccfb93
a=rtcp-fb:* transport-cc
a=mid:0
m=video 18322 UDP/TLS/RTP/SAVPF 98 96
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 D0:DB:24:94:16:E2:DE:55:44:11:FE:44:69:3E:E5:31:6F:3F:EC:B9:19:10:4B:DA:F6:73:40:C5:EB:C9:61:04
a=ice-ufrag:53ca6ff264ec37cc4a200fd207207ca1
a=ice-pwd:7280498149b7219129d01372731d5b35
a=rtpmap:98 VP9/90000
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:895565677 cname:67561ce0-909c-409c-968f-60a74877e5ec
a=msid:358eda66-46cd-47b7-8a24-626f971cb1df 182c2222-a12c-4f31-8bcb-525dc89023bd
a=rtcp-fb:* transport-cc
a=rtcp-fb:* ccm fir
a=rtcp-fb:* goog-remb
a=rtcp-fb:* nack
a=extmap:2 docs/native-code/rtp-hdrext/abs-send-time - src - Git at Google
a=extmap:3 http://www.ietf.org/id/draft-holmer-rmcat-transport-wide-cc-extensions-01
a=mid:1
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-2
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-3
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-4
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-5
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-6
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-7
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-8
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-9
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-10
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-11
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-12
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-13
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-14
m=video 0 UDP/TLS/RTP/SAVPF 0
a=mid:video-15
There is only one other participant in the bridge sending video. I believe all the ‘empty’ video streams are left behind from when the call has joined other bridges.
It seems pretty happen pretty randomly, some times it make take 20 bridge changes but other times it might only take 3. The only pattern I have notice is when I get the error it always seems to be expecting 16 streams, but it may have 17 or 18 in the local SDP.
I would have thought that when you change bridges and reinvite, these ‘old’ streams should not be included in the new SDP and only streams ‘live’ in the bridge should be included. Is this expected behaviour? It seems odd to me.