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!
