[asterisk-bugs] [JIRA] (ASTERISK-29963) res_rtp_asterisk: ssrc_invalid on unidirectional videostream after confbridge reinvite
Joshua C. Colp (JIRA)
noreply at issues.asterisk.org
Thu Mar 10 04:42:06 CST 2022
[ https://issues.asterisk.org/jira/browse/ASTERISK-29963?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Joshua C. Colp updated ASTERISK-29963:
--------------------------------------
Description:
When a client joins a Confbridge and get an INVITE from asterisk looing like this
Asterisk will send the other participants video stream on the second video with ssrc=12683906 and everything is working as it should.
The problem is when the client loses a packet and sends a NACK request to Asterisk, then asterisk is unable to map that rtcp instance to the sendonly stream since the mapping is marked as ssrc_invalid=0. Asterisk will then fail to map to the correct instance and try to act on the voice instance instead and write res_rtp_asterisk.c:6551 ast_rtcp_interpret: (0x7ff0c8083bc0) RTCP before handle NACK request, retransmissions are not enabled ignore this message!
I can see by adding some extra logging in asterisk that the function ast_rtp_bundle sets the mapping.ssrc_valid=child_rtp->themssrc_valid wich in this case is 0 right after asterisk processes the sdp.
Is't possible to get retransmissions to work by changing this line in __rtp_find_instance_by_ssrc
if (mapping->ssrc_valid && mapping_ssrc == ssrc) {
to
if (mapping_ssrc == ssrc) {
was:
When a client joins a Confbridge and get an INVITE from asterisk looing like this
INVITE sip:14hjh1lr at 192.168.1.64:61731;transport=ws;ob SIP/2.0
Via: SIP/2.0/WSS 192.168.1.231:9062;rport;branch=z9hG4bKPjafc6d2ba-2841-43e9-9184-92fb5d27f465;alias
From: <sip:9988 at 192.168.1.231>;tag=f044d3f5-97b1-4305-86e8-d7f6d6f57feb
To: <sip:1_webrtc at 192.168.1.231>;tag=27mgt9i7b4
Contact: <sip:192.168.1.231:9062;transport=ws>
Call-ID: vralkvok6h1vp2r8ab6c
CSeq: 14043 INVITE
Allow: OPTIONS, REGISTER, SUBSCRIBE, NOTIFY, PUBLISH, INVITE, ACK, BYE, CANCEL, UPDATE, PRACK, REFER, MESSAGE
Supported: 100rel, timer, replaces, norefersub, histinfo
Session-Expires: 1800;refresher=uas
Min-SE: 90
Max-Forwards: 70
User-Agent: wx3.se pbx
Content-Type: application/sdp
Content-Length: 2599
v=0
o=- 1395058744 5 IN IP4 192.168.1.231
s=Asterisk
c=IN IP4 192.168.1.231
t=0 0
a=msid-semantic:WMS *
a=group:BUNDLE 0 1 video-2
m=audio 14264 UDP/TLS/RTP/SAVPF 111 9 8 0 126
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 49:A0:82:79:46:CC:46:F0:92:57:E9:15:5D:B6:11:A1:4E:C4:31:8E:4B:C9:1C:B9:1C:72:DA:23:FD:9E:49:BE
a=ice-ufrag:4c67f5b33099618527fbe21c2244c63a
a=ice-pwd:34a17def72e1fcc62c4a9c990cc02295
a=candidate:Hc0a801e7 1 UDP 2130706431 192.168.1.231 14264 typ host
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:767905177 cname:0e429237-8399-4f4c-ab63-ed627706fffd
a=msid:46167cbd-25d9-46c1-a6d5-80d3cf7cb7a2 70a3431c-0a02-45ac-8890-59adaaa1095a
a=rtcp-fb:* transport-cc
a=mid:0
m=video 14264 UDP/TLS/RTP/SAVPF 98 102 96
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 49:A0:82:79:46:CC:46:F0:92:57:E9:15:5D:B6:11:A1:4E:C4:31:8E:4B:C9:1C:B9:1C:72:DA:23:FD:9E:49:BE
a=ice-ufrag:4c67f5b33099618527fbe21c2244c63a
a=ice-pwd:34a17def72e1fcc62c4a9c990cc02295
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=rtpmap:96 VP8/90000
a=sendrecv
a=rtcp-mux
a=ssrc:1528787399 cname:939a44f3-407e-4b38-a965-8f06ab7fe96c
a=msid:46167cbd-25d9-46c1-a6d5-80d3cf7cb7a2 57cf4b7a-ef1b-4088-88e3-e41ba3cd6034
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 14264 UDP/TLS/RTP/SAVPF 98 102 96
a=connection:existing
a=setup:actpass
a=fingerprint:SHA-256 49:A0:82:79:46:CC:46:F0:92:57:E9:15:5D:B6:11:A1:4E:C4:31:8E:4B:C9:1C:B9:1C:72:DA:23:FD:9E:49:BE
a=ice-ufrag:4c67f5b33099618527fbe21c2244c63a
a=ice-pwd:34a17def72e1fcc62c4a9c990cc02295
a=rtpmap:98 VP9/90000
a=rtpmap:102 H264/90000
a=fmtp:102 packetization-mode=1;level-asymmetry-allowed=1;profile-level-id=42001F
a=rtpmap:96 VP8/90000
a=sendonly
a=rtcp-mux
a=ssrc:733408114 cname:15205e51-0bd9-4d35-a90f-59614506084a
a=msid:dcd91543-5b85-4550-8047-4a585743e859 16b8b8c5-1661-4a1a-8f5d-39f566c1d834
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
SIP/2.0 200 OK
Via: SIP/2.0/WSS 192.168.1.231:9062;rport;branch=z9hG4bKPjafc6d2ba-2841-43e9-9184-92fb5d27f465;alias
To: <sip:1_webrtc at 192.168.1.231>;tag=27mgt9i7b4
From: <sip:9988 at 192.168.1.231>;tag=f044d3f5-97b1-4305-86e8-d7f6d6f57feb
Call-ID: vralkvok6h1vp2r8ab6c
CSeq: 14043 INVITE
Contact: <sip:14hjh1lr at gn423gqo2vbs.invalid;transport=ws;ob>
Session-Expires: 1800;refresher=uas
Supported: timer,ice,replaces,outbound
Content-Type: application/sdp
Content-Length: 3426
v=0
o=- 849152999030188088 3 IN IP4 127.0.0.1
s=-
t=0 0
a=group:BUNDLE 0 1 video-2
a=msid-semantic: WMS u6tstBvLcUbxW0IEheMslXD1t1b6fIKF4cVM
m=audio 60600 UDP/TLS/RTP/SAVPF 111 9 8 0 126
c=IN IP4 212.247.4.149
a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3460887983 1 udp 2122260223 192.168.1.64 60600 typ host generation 0 network-id 1
a=candidate:945327227 1 udp 1686052607 212.247.4.149 60600 typ srflx raddr 192.168.1.64 rport 60600 generation 0 network-id 1
a=candidate:2160789855 1 tcp 1518280447 192.168.1.64 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:Nk03
a=ice-pwd:wkJ1TKIZ6kf3QyBGgL6QYZXz
a=ice-options:trickle
a=fingerprint:sha-256 5A:29:86:1F:EE:42:53:0F:14:2C:90:9A:02:19:C3:0E:DE:78:74:D6:2E:15:DD:47:F5:CE:4D:03:72:45:7D:2B
a=setup:passive
a=mid:0
a=sendrecv
a=msid:u6tstBvLcUbxW0IEheMslXD1t1b6fIKF4cVM b8a51bfa-2ff0-4c5a-8b5e-0f3374fa0c66
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=ssrc:1854519133 cname:LDd7LE4FD0g2MJyG
m=video 63435 UDP/TLS/RTP/SAVPF 98 102 96
c=IN IP4 212.247.4.149
b=AS:1000a=rtcp:9 IN IP4 0.0.0.0
a=candidate:3460887983 1 udp 2122260223 192.168.1.64 63435 typ host generation 0 network-id 1
a=candidate:945327227 1 udp 1686052607 212.247.4.149 63435 typ srflx raddr 192.168.1.64 rport 63435 generation 0 network-id 1
a=candidate:2160789855 1 tcp 1518280447 192.168.1.64 9 typ host tcptype active generation 0 network-id 1
a=ice-ufrag:Nk03
a=ice-pwd:wkJ1TKIZ6kf3QyBGgL6QYZXz
a=ice-options:trickle
a=fingerprint:sha-256 5A:29:86:1F:EE:42:53:0F:14:2C:90:9A:02:19:C3:0E:DE:78:74:D6:2E:15:DD:47:F5:CE:4D:03:72:45:7D:2B
a=setup:passive
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=sendrecv
a=msid:u6tstBvLcUbxW0IEheMslXD1t1b6fIKF4cVM d1f0a022-7164-49a7-acb9-74e9ef8bbee6
a=rtcp-mux
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:102 H264/90000
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
a=ssrc-group:FID 12683906 4121512
a=ssrc:12683906 cname:LDd7LE4FD0g2MJyG
a=ssrc:4121512 cname:LDd7LE4FD0g2MJyG
m=video 9 UDP/TLS/RTP/SAVPF 98 102 96
c=IN IP4 0.0.0.0
a=rtcp:9 IN IP4 0.0.0.0
a=ice-ufrag:Nk03
a=ice-pwd:wkJ1TKIZ6kf3QyBGgL6QYZXz
a=ice-options:trickle
a=fingerprint:sha-256 5A:29:86:1F:EE:42:53:0F:14:2C:90:9A:02:19:C3:0E:DE:78:74:D6:2E:15:DD:47:F5:CE:4D:03:72:45:7D:2B
a=setup:passive
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=recvonly
a=rtcp-mux
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:102 H264/90000
a=rtcp-fb:102 transport-cc
a=rtcp-fb:102 ccm fir
a=rtcp-fb:102 nack
a=fmtp:102 level-asymmetry-allowed=1;packetization-mode=1;profile-level-id=42001f
a=rtpmap:96 VP8/90000
a=rtcp-fb:96 transport-cc
a=rtcp-fb:96 ccm fir
a=rtcp-fb:96 nack
Asterisk will send the other participants video stream on the second video with ssrc=12683906 and everything is working as it should.
The problem is when the client loses a packet and sends a NACK request to Asterisk, then asterisk is unable to map that rtcp instance to the sendonly stream since the mapping is marked as ssrc_invalid=0. Asterisk will then fail to map to the correct instance and try to act on the voice instance instead and write res_rtp_asterisk.c:6551 ast_rtcp_interpret: (0x7ff0c8083bc0) RTCP before handle NACK request, retransmissions are not enabled ignore this message!
I can see by adding some extra logging in asterisk that the function ast_rtp_bundle sets the mapping.ssrc_valid=child_rtp->themssrc_valid wich in this case is 0 right after asterisk processes the sdp.
Is't possible to get retransmissions to work by changing this line in __rtp_find_instance_by_ssrc
if (mapping->ssrc_valid && mapping_ssrc == ssrc) {
to
if (mapping_ssrc == ssrc) {
> res_rtp_asterisk: ssrc_invalid on unidirectional videostream after confbridge reinvite
> --------------------------------------------------------------------------------------
>
> Key: ASTERISK-29963
> URL: https://issues.asterisk.org/jira/browse/ASTERISK-29963
> Project: Asterisk
> Issue Type: Bug
> Security Level: None
> Components: Resources/res_rtp_asterisk
> Affects Versions: 18.8.0
> Environment: Alma Linux 8, Chrome WebRTC with JsSIP
> Reporter: Erik Bergschöld
> Labels: webrtc
> Attachments: sip.txt
>
>
> When a client joins a Confbridge and get an INVITE from asterisk looing like this
> Asterisk will send the other participants video stream on the second video with ssrc=12683906 and everything is working as it should.
> The problem is when the client loses a packet and sends a NACK request to Asterisk, then asterisk is unable to map that rtcp instance to the sendonly stream since the mapping is marked as ssrc_invalid=0. Asterisk will then fail to map to the correct instance and try to act on the voice instance instead and write res_rtp_asterisk.c:6551 ast_rtcp_interpret: (0x7ff0c8083bc0) RTCP before handle NACK request, retransmissions are not enabled ignore this message!
> I can see by adding some extra logging in asterisk that the function ast_rtp_bundle sets the mapping.ssrc_valid=child_rtp->themssrc_valid wich in this case is 0 right after asterisk processes the sdp.
> Is't possible to get retransmissions to work by changing this line in __rtp_find_instance_by_ssrc
> if (mapping->ssrc_valid && mapping_ssrc == ssrc) {
> to
> if (mapping_ssrc == ssrc) {
--
This message was sent by Atlassian JIRA
(v6.2#6252)
More information about the asterisk-bugs
mailing list