rtpengine not getting the packets(bytes) sent by firefox

33 views
Skip to first unread message

Julien Chavanton

unread,
May 31, 2024, 6:03:22 PMMay 31
to rtpe...@googlegroups.com


I wonder where these packets are lost, firefox is reporting 737171 bytes sent and 1334780 bytes received (This is matching rtpengine)

But rtpengine only saw 3252 bytes from firefox, any clue before I start to dig to find where they are lost/dropped

[core] --- Tag 'pkf2uc80a7', created 3:19 ago for branch '' [core] --- subscribed to 'btu97n61ds' [core] --- subscription for 'btu97n61ds' [core] ------ Media #1 (audio over UDP/TLS/RTP/SAVPF) using opus/48000/2 [core] --------- Port 10.125.25.146:10758 <> 24.122.50.10:47823, SSRC 9b771883, in 57 p, 3252 b, 6767 e, 60 ts, out 6772 p, 1334780 b, 0 e


image.png

Richard Fuchs

unread,
May 31, 2024, 7:23:10 PMMay 31
to rtpe...@googlegroups.com
With rx errors reported, my first guess would be a problem with SRTP, possibly DTLS-SRTP not established in time or incorrectly (or not at all) re-established. A common problem is when the two sides disagree on whether a new DTLS connection ought to be established, say after a re-invite, and rtpengine waits for a new DTLS connection but the peer wants to continue the previously established one.

Cheers
--
You received this message because you are subscribed to the Google Groups "Sipwise rtpengine" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rtpengine+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/rtpengine/CAKmcL2%3DjfBjnpGaTiTNSRReJr3-aTVS0%2BbmGbF6W4LrMLtbaZA%40mail.gmail.com.

Julien Chavanton

unread,
May 31, 2024, 11:37:32 PMMay 31
to rtpe...@googlegroups.com
Thanks for the hint, I can add that this is working with chrome, the problem is taking place with Firefox.



image.png

Julien Chavanton

unread,
Jun 3, 2024, 8:51:53 AMJun 3
to rtpe...@googlegroups.com
Thanks,  I was blind with "6767 e", I need to figure out what is going on with the simple offer answer scenario I am using.

Julien Chavanton

unread,
Jun 3, 2024, 9:11:14 AMJun 3
to rtpe...@googlegroups.com
[1717420106.601541] INFO: [8ieuckf0gs0n527alndf]: [control] Received command 'offer' from 10.125.25.146:55832
[1717420106.601672] NOTICE: [8ieuckf0gs0n527alndf]: [core] Creating new call
[1717420106.603851] INFO: [8ieuckf0gs0n527alndf]: [control] Replying to 'offer' from 10.125.25.146:55832 (elapsed time 0.002292 sec)
[1717420134.749247] INFO: [dvqegbav0r7cu6ps0no4]: [control] Received command 'offer' from 10.125.25.146:55832
[1717420134.749619] NOTICE: [dvqegbav0r7cu6ps0no4]: [core] Creating new call
[1717420134.760061] INFO: [dvqegbav0r7cu6ps0no4]: [control] Replying to 'offer' from 10.125.25.146:55832 (elapsed time 0.010787 sec)
[1717420141.298203] INFO: [dvqegbav0r7cu6ps0no4]: [control] Received command 'answer' from 10.125.25.146:55832
[1717420141.303267] INFO: [dvqegbav0r7cu6ps0no4]: [control] Replying to 'answer' from 10.125.25.146:55832 (elapsed time 0.005029 sec)
[1717420141.330910] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: new peer for component 1 is 24.122.50.10:50908
[1717420141.330930] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: local interface 10.125.25.146
[1717420141.330987] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: new peer for component 1 is 24.122.50.10:44376
[1717420141.330995] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: local interface 10.125.25.146
[1717420141.413894] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [ice] ICE negotiated: peer for component 1 is 24.122.50.10:53145
[1717420141.413914] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [ice] ICE negotiated: local interface 10.125.25.146
[1717420141.448532] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [crypto] DTLS: Peer certificate accepted
[1717420141.466892] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: peer for component 1 is 24.122.50.10:44376
[1717420141.467012] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [ice] ICE negotiated: local interface 10.125.25.146
[1717420141.477014] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80
[1717420141.477138] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [crypto] DTLS-SRTP successfully negotiated using AES_CM_128_HMAC_SHA1_80
[1717420141.503834] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [crypto] DTLS: Peer certificate accepted
[1717420141.504592] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [crypto] DTLS-SRTP successfully negotiated using AEAD_AES_256_GCM
[1717420141.504625] INFO: [dvqegbav0r7cu6ps0no4 port 11108]: [crypto] DTLS-SRTP successfully negotiated using AEAD_AES_256_GCM
[1717420141.557334] WARNING: [dvqegbav0r7cu6ps0no4 port 11108]: [core] Discarded SRTP packet: decryption failed
[1717420141.654699] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [ice] ICE negotiated: peer for component 1 is 24.122.50.10:53145
[1717420141.654714] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [ice] ICE negotiated: local interface 10.125.25.146
[1717420143.892583] WARNING: [dvqegbav0r7cu6ps0no4 port 11124]: [rtcp] Discarded invalid SRTCP packet: authentication failed
[1717420145.011622] INFO: [dvqegbav0r7cu6ps0no4 port 11124]: [core] Confirmed peer address as 24.122.50.10:53145

Julien Chavanton

unread,
Jun 3, 2024, 9:24:06 AMJun 3
to rtpe...@googlegroups.com
I am looking the the crypto cypher a=line, this seems to be the main difference in the SDP comparing with a working call
They seem to be optional, maybe I could remove them ?

a=crypto:1 AEAD_AES_256_GCM inline:tM8V4Hc7nP0ohiOvpiRSoXxYdPtYuGdkQH1npyFEsnOgSycryJIqUy+J6kU
a=crypto:2 AEAD_AES_128_GCM inline:9tn8fBKyzmE6f/eUXPsYDsZ4yasaccSt42MhFg
a=crypto:3 AES_256_CM_HMAC_SHA1_80 inline:GBmQLizOaP9AI+5cvPOK8GeLypLnIvxf/TU6Td/aVkvynGBXdJJnJY6zMb37HQ
a=crypto:4 AES_256_CM_HMAC_SHA1_32 inline:z1HJ6m8f/U78i/VrJbkIq6Q0ZPp90jlj4IG2ZkAQZnRaotfm35UKj56Ehroprw
a=crypto:5 AES_192_CM_HMAC_SHA1_80 inline:IPzCiHwqAw2TKIqKkBQ1XCuWnK5aUYU764IxBeD8dSlb6zjHTio
a=crypto:6 AES_192_CM_HMAC_SHA1_32 inline:TOI2HrhlVtOVz/kh6vtUv+yH0jGR+j8jmYVa5Kel2WF696ClTaE
a=crypto:7 AES_CM_128_HMAC_SHA1_80 inline:V1MK6gIaLcvM6q3SsyQkrXWyKoEyX6aVtEkI6CFr
a=crypto:8 AES_CM_128_HMAC_SHA1_32 inline:FmYFK4tMcK4M8BHKskga8wMmmrEic/Skeaai3RnX
a=crypto:9 F8_128_HMAC_SHA1_80 inline:9ha+OzpnQ1Mc4MUyCV3J3MKneYKFKXlz7vd+pZKa
a=crypto:10 F8_128_HMAC_SHA1_32 inline:2v60K7txfhkIyt0icbQxgXv5SZ7AE0QjkyZWU6z0
a=crypto:11 NULL_HMAC_SHA1_80 inline:cs465yNB54AXwWZSQkycEyUXScYe15RmxudKTb1Q
a=crypto:12 NULL_HMAC_SHA1_32 inline:cWCuQi0NQcSPFeg3H3e4GnMCYfigL0v2XhzFZzde

On Mon, Jun 3, 2024 at 8:51 AM Julien Chavanton <jchav...@gmail.com> wrote:

Richard Fuchs

unread,
Jun 3, 2024, 9:42:07 AMJun 3
to rtpe...@googlegroups.com
Not only are these optional, they are in fact forbidden in a WebRTC environment. You should use `SDES-off` when talking to a WebRTC client.

Cheers

Julien Chavanton

unread,
Jun 3, 2024, 10:54:22 AMJun 3
to rtpe...@googlegroups.com
Thanks, I removed SDED-off by mistake wile testing modifications.
(I did not know how these line were used, appreciated !)


I am guessing it must be something in the SDP offer , I am comparing the one SDP offer that is working with FS and the one I am making with rtp-engine, maybe there is something here ...


// firefox packets are dropped by rtpengine when decrypting
v=0
o=- 4943546551427777016 2 IN IP4 54.243.200.121
s=-
t=0 0
a=extmap-allow-mixed
a=msid-semantic: WMS 3a98007b-f965-458b-8d71-36f2d71ca901
a=rtpengine:2661dd46789c
m=audio 11403 UDP/TLS/RTP/SAVP 111 96 110
c=IN IP4 54.243.200.121
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=msid:3a98007b-f965-458b-8d71-36f2d71ca901 7ff1fa61-7f2b-49b8-97e2-45ba15e307f4
a=ssrc:3198589081 cname:K3J4UZgJ/IbQlPcc
a=ssrc:3198589081 msid:3a98007b-f965-458b-8d71-36f2d71ca901 7ff1fa61-7f2b-49b8-97e2-45ba15e307f4
a=mid:0
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtcp-fb:111 transport-cc
a=rtpmap:96 CN/48000
a=rtpmap:110 telephone-event/48000
a=sendrecv
a=rtcp:11403
a=rtcp-mux
a=setup:actpass
a=fingerprint:sha-256 9F:3C:56:78:53:7A:AF:22:8A:90:7D:BA:E1:F1:DE:BE:F1:67:23:70:EF:99:CE:07:9B:2F:6D:90:9B:7F:AC:80
a=tls-id:664ac6d64f253fc1d1f4613542a2866d
a=ice-ufrag:rispFBrB
a=ice-pwd:twvh46FpOjvwlqRZwmL7AmYyhD
a=candidate:JrKmj1opsRm9LG9r 1 UDP 2130706431 54.243.200.121 11403 typ host

// working firefox (sip.js) receiving an SDP offer from FS
v=0
o=FreeSWITCH 1717410868 1717410869 IN IP4 54.243.200.121
s=FreeSWITCH
c=IN IP4 54.243.200.121
t=0 0
a=msid-semantic: WMS SB9wcwqTfCyj4YaHiLdm8jQJZfP41L8K
m=audio 15130 RTP/SAVPF 102 101
a=rtpmap:102 opus/48000/2
a=fmtp:102 useinbandfec=1; maxaveragebitrate=30000; maxplaybackrate=8000; ptime=20; minptime=10; maxptime=40
a=rtpmap:101 telephone-event/48000
a=fingerprint:sha-256 77:D4:0D:A2:67:AA:9F:3B:DD:9C:B6:4A:CF:E7:8C:B1:64:59:DC:16:66:69:5B:93:0A:89:8E:CC:88:27:A0:03
a=setup:actpass
a=rtcp-mux
a=rtcp:15130 IN IP4 54.243.200.121
a=ssrc:1986839942 cname:d86fvmYAPnJKcKhk
a=ssrc:1986839942 msid:SB9wcwqTfCyj4YaHiLdm8jQJZfP41L8K a0
a=ssrc:1986839942 mslabel:SB9wcwqTfCyj4YaHiLdm8jQJZfP41L8K
a=ssrc:1986839942 label:SB9wcwqTfCyj4YaHiLdm8jQJZfP41L8Ka0
a=ice-ufrag:lkwjudTjize9bcJe
a=ice-pwd:bGjwT8Wylw9n6gyirVsLYcV7
a=candidate:2760183103 1 udp 2130706431 54.243.200.121 15130 typ host generation 0
a=candidate:2760183103 2 udp 2130706431 54.243.200.121 15130 typ host generation 0
a=ptime:20


Julien Chavanton

unread,
Jun 3, 2024, 11:45:20 AMJun 3
to rtpe...@googlegroups.com
I did rewrite the sdp to remove the extmap lines, not sure if anything else should be changed, I may have to push the investigation in rtpengine.

v=0
o=- 2151652086361155649 2 IN IP4 54.243.200.121
s=-
t=0 0
a=msid-semantic: WMS 6f395769-d9e4-4bb4-bc6f-c365384f5dcd
a=rtpengine:2661dd46789c
m=audio 11568 UDP/TLS/RTP/SAVP 111 96 110
c=IN IP4 54.243.200.121
a=msid:6f395769-d9e4-4bb4-bc6f-c365384f5dcd f8e01066-ca2e-4e37-b78a-c5739b231acb
a=ssrc:1733580988 cname:ClUhlHJiFtKLq/Qk
a=ssrc:1733580988 msid:6f395769-d9e4-4bb4-bc6f-c365384f5dcd f8e01066-ca2e-4e37-b78a-c5739b231acb

a=mid:0
a=rtpmap:111 opus/48000/2
a=fmtp:111 minptime=10;useinbandfec=1
a=rtcp-fb:111 transport-cc
a=rtpmap:96 CN/48000
a=rtpmap:110 telephone-event/48000
a=sendrecv
a=rtcp:11568

a=rtcp-mux
a=setup:actpass
a=fingerprint:sha-256 9F:3C:56:78:53:7A:AF:22:8A:90:7D:BA:E1:F1:DE:BE:F1:67:23:70:EF:99:CE:07:9B:2F:6D:90:9B:7F:AC:80
a=tls-id:87125822a4f24ee336794f90e564483b
a=ice-ufrag:AKQ0hrXO
a=ice-pwd:V7pcpcxfZUzjUk2Qc3eS5TtgEM
a=candidate:JrKmj1opsRm9LG9r 1 UDP 2130706431 54.243.200.121 11568 typ host

Richard Fuchs

unread,
Jun 3, 2024, 12:12:32 PMJun 3
to rtpe...@googlegroups.com
You should probably look at the actual media flow with Wireshark, including DTLS and ICE exchanges.

Julien Chavanton

unread,
Jun 25, 2024, 3:48:18 PMJun 25
to rtpe...@googlegroups.com
God, I feel sorry to have wasted your precious time,  was running an old version, I just tested master 236ca5 / 12.5.0 and the problem is gone !

Thank you for your help !


Reply all
Reply to author
Forward
0 new messages