[SR-Users] NAT problem with recvonly calls

Alex Balashov abalashov at evaristesys.com
Wed Dec 9 08:40:14 CET 2020


ICE support just doesn't seem to me to be something a SIP doorbell would 
have.

On 12/9/20 2:39 AM, Olle E. Johansson wrote:
> 
> 
>> On 8 Dec 2020, at 18:55, Richard Fuchs <rfuchs at sipwise.com 
>> <mailto:rfuchs at sipwise.com>> wrote:
>>
>> Use IPv6 😃
> 
> While I like that proposal, assuming that IPv6 will not have a stateful 
> firewall is propably not a good assumption.
> So I suspect that an IPv6 firewall would not let the packets in if there 
> is not outbound traffic first. I do like Ovidius
> ICE-based solution and would like to add RTCP - if muxed it would open 
> the port, but the likelyhood that it’s
> implemented is propably low.
> 
> IPv6 greetings!
> /O :-)
>>
>> Cheers
>>
>> On 07/12/2020 23.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
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> 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/



More information about the sr-users mailing list