[SR-Users] NAT problem with recvonly calls

[David Cunningham]

Hi Alex,

Thank you for that. Do you offhand know of an easy way to test if the
sendonly attribute is set? Presumably we can use
sdp_remove_line_by_prefix() to remove it.,


On Wed, 9 Dec 2020 at 20:52, Alex Balashov <abalashov at evaristesys.com>
wrote:

> 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/
>
> _______________________________________________
> Kamailio (SER) - Users Mailing List
> sr-users at lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 
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/20201210/c6fa8a4f/attachment.htm>