Re: [EXTERNAL] rtpengine v4/v6 translation

Richard Fuchs via sr-users <[email protected]>
Newsgroups gmane.comp.voip.ser
Organization Sipwise GmbH
Message-ID <[email protected]>
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!
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.