[OpenSIPS-Users] Rtpengine configuration problem

[Robert Dyck]

Answering my own question, it appears that rtpengine reverses the logic of rtpproxy with regard 
to the media source address. It trusts the "c" ( connection ) address that the UA puts there. In 
this case the UA had learned what its public address was. Rtpengine trusts this instead using the 
source address. Now that the binding request is going to the UA I have to find where the binding 
response is going.

On Friday, July 3, 2020 8:06:16 P.M. PDT Robert Dyck wrote:


While configuring my script for rtpengine I got a rather confusing result. The test involved a UA 
tethered to a phone with only IPV4 availble. The test was a call to a UA registered with an IPV6 
address. The call was answered successfully but there was no media. A sniffer at the rtpengine 
host ( also opensips ) revealed the following --

continuous binding request, no media
wireless IPV4 -> rtpengine in port -> rtpengine out port -> IPV6 -> AB:CD::
The destination address was obviously bogus. Since the address was so short on a hunce I 
converted it to decimal. It turns out that the binding request was being sent to the NAT's public 
IPV4 address but as an IPV6 packet.

The signalling looked. Is this a misconfiguration? Rtpengine is configured in bridging mode with 
an IPV4 address and an IPV6 address.

INVTEe 






-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200704/164b34e1/attachment.html>