[SR-Users] NAT problem with recvonly calls

[Ovidiu Sas]

The doorbell is the caller. ICE support would be required on the
callee side (between NATed callee and asterisk).
There's no need for ICE support on the doorbell/caller side.

-ovidiu

On Wed, Dec 9, 2020 at 2:42 AM Alex Balashov <abalashov at evaristesys.com> wrote:
>
> 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/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



-- 
VoIP Embedded, Inc.
http://www.voipembedded.com