[SR-Users] NAT problem with recvonly calls

[David Cunningham]

Hi Daniel,

Removing the sendonly from the INVITE SDP sounds like the most workable
solution in our case. We'd only want to do it for a new INVITE though, not
a re-INVITE in a situation where a call is put on hold. Would you be able
to give an example of such a configuration?

Thanks very much for your help!


On Tue, 8 Dec 2020 at 21:56, Daniel-Constantin Mierla <miconda at gmail.com>
wrote:

> Hello,
>
> if the endpoint is not behind a port forwarding nat/firewall (when one can
> instruct the rtp relay to use signaling address), then probably you can try
> to remove the sendonly from the INVITE SDP. That will enable rtp from
> endpoint to doorbell, which may rise additional concerns (e.g., privacy) if
> its is explicitly not wanted to happen. But as Alex said in another
> response, the only way to get it work is to make the endpoint behind nat to
> send a RTP packet. Usually the doorbells I encountered so far were
> accepting incoming traffic as well, to discuss/interact with the person
> ringing on it.
>
> Cheers,
> Daniel
> On 08.12.20 05:01, David Cunningham 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 Listsr-users at lists.kamailio.orghttps://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
>

-- 
David Cunningham, Voisonics Limited
http://voisonics.com/
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20201209/54791a98/attachment.htm>