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!
-- Best regards, Ihor (Igor)