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!
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 dcunningham@voisonics.com 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
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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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 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
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@gmail.com mailto:miconda@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@lists.kamailio.org <mailto: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 <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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
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@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@gmail.com mailto:miconda@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@lists.kamailio.org <mailto: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%3E
-- 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%3E
-- 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@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
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 <abalashov@evaristesys.com mailto:abalashov@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@gmail.com <mailto:miconda@gmail.com> > <mailto:miconda@gmail.com <mailto:miconda@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/> <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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org <mailto: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> <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> <http://www.asipto.com <http://www.asipto.com>> > www.twitter.com/miconda <http://www.twitter.com/miconda> <http://www.twitter.com/miconda <http://www.twitter.com/miconda>> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> <http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>> > Funding:https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla> <https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>> > > > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ <http://voisonics.com/> <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@lists.kamailio.org <mailto: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> > -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto: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>-- 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@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Thanks Alex!
On Thu, 10 Dec 2020 at 14:09, Alex Balashov abalashov@evaristesys.com 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 <abalashov@evaristesys.com mailto:abalashov@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 dothe
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@gmail.com <mailto:miconda@gmail.com> > <mailto:miconda@gmail.com <mailto:miconda@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 INVITESDP.
> 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 RTPpacket.
> 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 theSDP.
>> The problem is that the destination is behind NAT, and itsreply
>> 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 receivesaudio
>> from, however because this device is recvonly Asterisk never >> receives audio from it. This means Asterisk keeps trying tosend
>> the doorbell's RTP to the private network IP which of course >> fails, and the destination never gets the RTP from thedoorbell.
>> >> 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 anyrecommended
>> solutions? >> >> Thank you in advance! >> >> -- >> David Cunningham, Voisonics Limited >> http://voisonics.com/ <http://voisonics.com/> <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@lists.kamailio.org <mailto:sr-users@lists.kamailio.org> <mailto:sr-users@lists.kamailio.org <mailto: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> <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> <http://www.asipto.com <> www.twitter.com/miconda <http://www.twitter.com/miconda> <http://www.twitter.com/miconda <http://www.twitter.com/miconda>> --www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda> <http://www.linkedin.com/in/miconda <http://www.linkedin.com/in/miconda>> > Funding:https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla> <https://www.paypal.me/dcmierla <https://www.paypal.me/dcmierla>> > > > > -- > David Cunningham, Voisonics Limited > http://voisonics.com/ <http://voisonics.com/> <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@lists.kamailio.org <mailto: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> > -- Alex Balashov | Principal | Evariste Systems LLC Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free) Web: http://www.evaristesys.com/ <http://www.evaristesys.com/>, http://www.csrpswitch.com/ <http://www.csrpswitch.com/> _______________________________________________ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org <mailto: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>-- 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@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
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 dcunningham@voisonics.com 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
-
Alex Balashov -
Daniel-Constantin Mierla -
David Cunningham -
Ovidiu Sas