subject:"\[SR\-Users\] NAT problem with recvonly calls"

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread David Cunningham

Thanks Alex!


On Thu, 10 Dec 2020 at 14:09, Alex Balashov 
wrote:

> if(has_body("application/sdp") && search("a=sendonly")) [1]
>
> It's what comes to mind off the top of my head, anyway.
>
> -- Alex
>
> [1] https://www.kamailio.org/docs/modules/stable/modules/textops.html
>
> On 12/9/20 7:43 PM, David Cunningham wrote:
> > 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  > > 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
> > mailto:mico...@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 List
> >  >> sr-users@lists.kamailio.org
> > 
> >  > >
> >  >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > 
> >  >

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread Alex Balashov


if(has_body("application/sdp") && search("a=sendonly")) [1]

It's what comes to mind off the top of my head, anyway.

-- Alex

[1] https://www.kamailio.org/docs/modules/stable/modules/textops.html

On 12/9/20 7:43 PM, David Cunningham wrote:

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 > 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
mailto:mico...@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 List
 >> sr-users@lists.kamailio.org
 
>
 >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
 
>
 >
 >     --
 >     Daniel-Constantin Mierla --www.asipto.com
  >
 > www.twitter.com/miconda  
> 
--www.linkedin.com/in/miconda  
>
 >

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread 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 
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  > > 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 List
> >> sr-users@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  
> > www.twitter.com/miconda    --
> www.linkedin.com/in/miconda  
> > Funding:https://www.paypal.me/dcmierla  <
> https://www.paypal.me/dcmierla>
> >
> >
> >
> > --
> > David Cunningham, Voisonics Limited
> > http://voisonics.com/ 
> > USA: +1 213 221 1092
> > New Zealand: +64 (0)28 2558 3782
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@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@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
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-09 Thread 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  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  >> > 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/ 
> >>> USA: +1 213 221 1092
> >>> New Zealand: +64 (0)28 2558 3782
> >>>
> >>> ___
> >>> Kamailio (SER) - Users Mailing List
> >>> sr-users@lists.kamailio.org
> >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >> ___
> >> Kamailio (SER) - Users Mailing List
> >> sr-users@lists.kamailio.org 
> >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> >
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@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@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



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

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread 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 > 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 List
sr-users@lists.kamailio.org  
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users  



-- 
Daniel-Constantin Mierla --www.asipto.com  

www.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

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

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread 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 
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@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
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread Alex Balashov

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 > 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/ 
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org 
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



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

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread Olle E. Johansson



> On 8 Dec 2020, at 18:55, Richard Fuchs  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/ 
>> USA: +1 213 221 1092
>> New Zealand: +64 (0)28 2558 3782
>> 
>> 
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org 
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users 
>> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread Richard Fuchs


Use IPv6 

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/ 
USA: +1 213 221 1092
New Zealand: +64 (0)28 2558 3782

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread Ovidiu Sas

Hello David,

If the receiving NATed device has support for ICE, you can enable ICE
support on the asterisk server and then the media should flow through
(NAT pinholes are opened during ICE candidates negotiation).

Regards,
Ovidiu Sas

On Mon, Dec 7, 2020 at 11:02 PM 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 List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users



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

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-08 Thread Daniel-Constantin Mierla

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 List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Funding: https://www.paypal.me/dcmierla

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

2020-12-07 Thread Alex Balashov

RTPEngine does the same kind of port latching that Asterisk would — that is, 
wait to receive an RTP frame in order to learn the external port that the NAT 
gateway has mapped the device’s (symmetric) RTP endpoint to. If it never gets 
one, it won’t learn. That’s the industry-standard solution.

No magic workarounds, alas.

—
Sent from mobile, with due apologies for brevity and errors.

> On Dec 7, 2020, at 11:02 PM, 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 List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] NAT problem with recvonly calls

2020-12-07 Thread David Cunningham

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 List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

Re: [SR-Users] NAT problem with recvonly calls

[SR-Users] NAT problem with recvonly calls

13 matches

Site Navigation

Mail list logo

Footer information