Re: [EXTERNAL] rtpengine v4/v6 translation

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 <
[email protected]> 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 --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>


-- 
Best regards,
Ihor (Igor)

__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!