[SR-Users] NAT problem with recvonly calls

[Alex Balashov]

The salient quality of a reinvite is that has_totag() == true; it is 
handled in the loose_route() section of your config. You want to do the 
SDP manipulation in the part below that, where initial INVITEs are handled.

On 12/9/20 2:47 AM, David Cunningham wrote:
> 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 
> <mailto: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/ <http://voisonics.com/>
>>     USA: +1 213 221 1092
>>     New Zealand: +64 (0)28 2558 3782
>>
>>     _______________________________________________
>>     Kamailio (SER) - Users Mailing List
>>     sr-users at lists.kamailio.org  <mailto:sr-users at lists.kamailio.org>
>>     https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  <https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>
> 
>     -- 
>     Daniel-Constantin Mierla --www.asipto.com  <http://www.asipto.com>
>     www.twitter.com/miconda  <http://www.twitter.com/miconda>  --www.linkedin.com/in/miconda  <http://www.linkedin.com/in/miconda>
>     Funding:https://www.paypal.me/dcmierla  <https://www.paypal.me/dcmierla>
> 
> 
> 
> -- 
> David Cunningham, Voisonics Limited
> http://voisonics.com/ <http://voisonics.com/>
> USA: +1 213 221 1092
> New Zealand: +64 (0)28 2558 3782
> 
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 

-- 
Alex Balashov | Principal | Evariste Systems LLC

Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/