Hello,
It's more about rtpengine, than Kamailio, but as I'm using it via Kamailio, decided to ask here. I'm building IPv4/IPv6 dual-stack system and currently got stuck on rtpengine part.
Overall schema is like this
Client <---SRTP (v4/v6)---> Kamailio/rtpengine <----RTP(v4)----> Asterisk
When I'm using IPv4 on a client, audio is being transmitted ok, but if with the same parameters I'm using IPv6 on a client, despite all correct in SDP (means rtpengine detects IPv6 addresses), sees incoming traffic to IPv6 interface and sayng forwarding it to IPv4, there is no traffic on IPv4 going out, What I found puzzling, that when using IPv4-only, final statls looks like
Final packet stats: --- Tag 'bHWck2I1B' (label 'leg_A'), created 0:41 ago for branch '' --- subscribed to media with monologue tag '872ed199-e68c-41f3-928e-284a52c9da7f' (index: 1) --- subscription for media with monologue tag '872ed199-e68c-41f3-928e-284a52c9da7f' (index: 1) ------ Media #1 (audio over RTP/SAVPF) using PCMA/8000 --------- Port <server_ip_v4>:24530 <> <client_ip_v4>:7078 , SSRC e5809e3e, in 529 p, 90988 b, 0 e, 30 ts, out 459 p, 86292 b, 0 e --------- Port <server_ip_v4>:24531 <> <client_ip_v4>:7079 (RTCP), SSRC e5809e3e, in 9 p, 1776 b, 10 e, 30 ts, out 2 p, 240 b, 0 e --- SSRC e5809e3e ------ Average MOS 4.3, lowest MOS 4.3 (at 0:05), highest MOS 4.3 (at 0:05) lost:0 ------ respective (avg/min/max) jitter 0/0/0 ms, RTT-e2e 11.3/13.0/13.0 ms, RTT-dsct 10.5/12.1/12.1 ms, packet loss 0/0/0% --- Tag '872ed199-e68c-41f3-928e-284a52c9da7f' (label 'leg_B'), created 0:41 ago for branch 'cp-srtp' --- subscribed to media with monologue tag 'bHWck2I1B' (index: 1) --- subscription for media with monologue tag 'bHWck2I1B' (index: 1) ------ Media #1 (audio over RTP/AVP) using PCMA/8000 --------- Port <server_ip_v4>:27240 <> <asterisk_ip_v4>:12694, SSRC 13cdaf27, in 459 p, 78948 b, 0 e, 30 ts, out 529 p, 90988 b, 0 e --------- Port <server_ip_v4>:27241 <> <asterisk_ip_v4>:12695 (RTCP), SSRC 13cdaf27, in 2 p, 200 b, 0 e, 30 ts, out 9 p, 1776 b, 0 e
Note, for the both Media streams codec is shown, But on IPv6 I see
Final packet stats: --- Tag 'EDfwrVO8t' (label 'leg_A'), created 0:41 ago for branch '' --- subscribed to media with monologue tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (index: 1) --- subscription for media with monologue tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (index: 1) ------ Media #1 (audio over RTP/SAVPF) using PCMA/8000 --------- Port <server_ip_v6>:27264 <> <client_ip_v6>:7200 , SSRC 1d2284d4, in 562 p, 96664 b, 1 e, 30 ts, out 0 p, 0 b, 0 e --------- Port <server_ip_v6>:27265 <> <client_ip_v6>:7201 (RTCP), SSRC 1d2284d4, in 9 p, 1152 b, 23 e, 30 ts, out 0 p, 0 b, 0 e --- Tag 'eb643ca2-42c5-42ec-b55f-4b0ae15b5d8a' (label 'leg_B'), created 0:41 ago for branch 'cp-srtp' --- subscribed to media with monologue tag 'EDfwrVO8t' (index: 1) --- subscription for media with monologue tag 'EDfwrVO8t' (index: 1) ------ Media #1 (audio over RTP/AVP) *using unknown codec* --------- Port <server_ip_v6>:25990 <> <asterisk_ip_v4>:12226, SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 562 p, 96664 b, 0 e --------- Port <server_ip_v6>:25991 <> <asterisk_ip_v4>:12227 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 9 p, 1152 b, 0 e
Note the unknown codec in this case
Rtpeinge is started with /usr/bin/rtpengine --interface <server_ip_v4> --interface <server_ip_v6> --listen-ng 19999 -m 20000 -M 28000 --sip-source --log-level=6 --log-facility=local5 -o 43200 -s 43200 -a 43200 --offer-timeout=43200
Version: mr13.5.1.3
Invoked with
rtpengine_manage(replace-origin replace-session-connection SDES-pad label=leg_A rtcp-mux-demux ICE=remove RTP/AVP via-branch=extra)
I'm not using additional explicit bridging, as I've read, that this is outdated already and not used at all. Any hint would be helpful and thanks in advance!
On 22/01/2026 11.00, Ihor Olkhovskyi via sr-users wrote:
It's more about rtpengine, than Kamailio, but as I'm using it via Kamailio, decided to ask here. I'm building IPv4/IPv6 dual-stack system and currently got stuck on rtpengine part.
FTR, we have our own mailing list for questions like this one: https://rtpengine.com/mailing-list
When I'm using IPv4 on a client, audio is being transmitted ok, but if with the same parameters I'm using IPv6 on a client, despite all correct in SDP (means rtpengine detects IPv6 addresses), sees incoming traffic to IPv6 interface and sayng forwarding it to IPv4, there is no traffic on IPv4 going out,
Are you sure about "all correct in SDP?" Because:
------ Media #1 (audio over RTP/AVP) *using unknown codec* --------- Port*<server_ip_v6>:25990 <> <asterisk_ip_v4>:12226*, SSRC 0,*in 0 p,* 0 b, 0 e, 41 ts, out 562 p, 96664 b, 0 e --------- Port <server_ip_v6>:25991 <> <asterisk_ip_v4>:12227 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 9 p, 1152 b, 0 e
Note the unknown codec in this case
"Unknown codec" really is a symptom of not having received any RTP.
What's a lot more alarming is that, if your annotation is correct, you have rtpengine trying to use an IPv6 address/socket towards an IPv4 endpoint (Asterisk). This cannot possibly work, and would have been visible in the SDPs.
rtpengine_manage(replace-origin replace-session-connection SDES-pad label=leg_A rtcp-mux-demux ICE=remove RTP/AVP via-branch=extra)
I'm not using additional explicit bridging, as I've read, that this is outdated already and not used at all.
Don't know where you've read that, but this isn't really true. It is true for SDPs received by rtpengine, and it is true for cases involving ICE, and it is true for re-invites within established call flows, but it definitely isn't true for initial outgoing offer SDPs made towards non-ICE endpoints, as likely you have here.
Since rtpengine has no way of knowing which protocol the intended recipient (Asterisk) of an initial offer SDP is able to use, it's required that this information is given to rtpengine. The default is to use the same as was used in the received SDP (IPv6 in this case), but if the recipient is IPv4-only, then rtpengine must explicitly be told to use IPv4 for the outgoing SDP.
You should be able to deduce the appropriate protocol from the contact address or something similar.
Cheers
Richard,
Many thanks for your answer.
You are absolutely right, adding *address-family* option explicitly did the trick.
Many thanks again!
Le jeu. 22 janv. 2026 à 17:23, Richard Fuchs via sr-users < sr-users@lists.kamailio.org> a écrit :
On 22/01/2026 11.00, Ihor Olkhovskyi via sr-users wrote:
It's more about rtpengine, than Kamailio, but as I'm using it via Kamailio, decided to ask here. I'm building IPv4/IPv6 dual-stack system and currently got stuck on rtpengine part.
FTR, we have our own mailing list for questions like this one: https://rtpengine.com/mailing-list
When I'm using IPv4 on a client, audio is being transmitted ok, but if with the same parameters I'm using IPv6 on a client, despite all correct in SDP (means rtpengine detects IPv6 addresses), sees incoming traffic to IPv6 interface and sayng forwarding it to IPv4, there is no traffic on IPv4 going out,
Are you sure about "all correct in SDP?" Because:
------ Media #1 (audio over RTP/AVP) *using unknown codec* --------- Port* <server_ip_v6>:25990 <> <asterisk_ip_v4>:12226*, SSRC 0,* in 0 p,* 0 b, 0 e, 41 ts, out 562 p, 96664 b, 0 e --------- Port <server_ip_v6>:25991 <> <asterisk_ip_v4>:12227 (RTCP), SSRC 0, in 0 p, 0 b, 0 e, 41 ts, out 9 p, 1152 b, 0 e
Note the unknown codec in this case
"Unknown codec" really is a symptom of not having received any RTP.
What's a lot more alarming is that, if your annotation is correct, you have rtpengine trying to use an IPv6 address/socket towards an IPv4 endpoint (Asterisk). This cannot possibly work, and would have been visible in the SDPs.
rtpengine_manage(replace-origin replace-session-connection SDES-pad label=leg_A rtcp-mux-demux ICE=remove RTP/AVP via-branch=extra)
I'm not using additional explicit bridging, as I've read, that this is outdated already and not used at all.
Don't know where you've read that, but this isn't really true. It is true for SDPs received by rtpengine, and it is true for cases involving ICE, and it is true for re-invites within established call flows, but it definitely isn't true for initial outgoing offer SDPs made towards non-ICE endpoints, as likely you have here.
Since rtpengine has no way of knowing which protocol the intended recipient (Asterisk) of an initial offer SDP is able to use, it's required that this information is given to rtpengine. The default is to use the same as was used in the received SDP (IPv6 in this case), but if the recipient is IPv4-only, then rtpengine must explicitly be told to use IPv4 for the outgoing SDP.
You should be able to deduce the appropriate protocol from the contact address or something similar.
Cheers __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions -- sr-users@lists.kamailio.org To unsubscribe send an email to sr-users-leave@lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender!
-
Ihor Olkhovskyi -
Richard Fuchs