RTPEngine does the same kind of port latching that Asterisk would — that is, wait to
receive an RTP frame in order to learn the external port that the NAT gateway has mapped
the device’s (symmetric) RTP endpoint to. If it never gets one, it won’t learn. That’s the
industry-standard solution.
No magic workarounds, alas.
—
Sent from mobile, with due apologies for brevity and errors.
On Dec 7, 2020, at 11:02 PM, David Cunningham
<dcunningham(a)voisonics.com> wrote:
Hello,
We have a problem with a SIP doorbell device which sends media one way only, and NAT at
the receiving device.
When the doorbell button is pressed it makes a call to a configured destination. Since
the doorbell only sends and doesn't receive it sends the INVITE with sendonly in the
SDP, and the destination then replies with a 200 OK with recvonly in the SDP. The problem
is that the destination is behind NAT, and its reply contains a private network IP in the
SDP.
Normally Asterisk when nat=yes works around that by adjusting the destination for RTP to
be the address it actually receives audio from, however because this device is recvonly
Asterisk never receives audio from it. This means Asterisk keeps trying to send the
doorbell's RTP to the private network IP which of course fails, and the destination
never gets the RTP from the doorbell.
We haven't found a solution in Asterisk to this, so are now looking to Kamailio which
acts as a load-balancing proxy in front of Asterisk for one. For example, maybe we could
use fix_nated_sdp, but only on 200 OK's with recvonly.
Has anyone else encountered this, and are there any recommended solutions?
Thank you in advance!
--
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
_______________________________________________
Kamailio (SER) - Users Mailing List
sr-users(a)lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users