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

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,

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

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

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

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 >

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

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

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

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

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

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

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

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 firewa

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

> 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

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

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

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

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: > > H

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

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., privac

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

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

[SR-Users] NAT problem with recvonly calls

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

Re: [SR-Users] NAT problem

Hello Arnout, don't worry, everybody started somewhere. Great that it works now. :-) About the changing the from and to header - there is indeed functionality in the uac module for that, look for the "replace" functions there. Cheers, Henning Am 17.09.19 um 13:35 schrieb Arnout Van Den Kieboo

Re: [SR-Users] NAT problem

Yes sorry, it is a typo. I meant public ip... But indeed, it does go once again through the firewall. I am thinking the problem is here: In the tcpdump (on kamailio) I see it says incoming call from: sip:number@IP OF CARRIER Ans it is forwarded this way to pbx I "think" that this way the PBX

Re: [SR-Users] NAT problem

Hi, In the meantime I think i figured it out, at least partly. As said I tried setting up outbound calls and learned a lot about the rest of the example config. Especially about how the natting rules are written and how a call follows certain "routes". In the beginning I had a lot of problems to

Re: [SR-Users] NAT problem

On Mon, Sep 16, 2019 at 02:06:43PM +0200, Arnout Van Den Kieboom wrote: > > If you need more info, feel free to ask! > Start looking at the SDP contents involved. What are the rtp endpoints in the them in the scenarios you are having problems with (the ipadress in the c= line and the ports in th

Re: [SR-Users] NAT problem

Hello, might be just a typing mistake, but: rtpproxy -A "private ip" -F -l "local ip" -m 1 -M 2 -s udp:*:7722 -d INFO says that -A is private ip, it should be public IP. Then, towards asterisk, is it everything on a private network, or does it go again through some FW with public ip an

Re: [SR-Users] NAT problem

Hi, Firewall (PFsense) does port forwarding: inbound publicIP:5060 --> private ip (192.168.150.119) inbound PublicIP:1 to 2 -> private ip (192.168.150.119) The public ip is set in the config file (kamailio.cfg) and RTP proxy is started with rtpproxy -A "private ip" -F -l "local ip" -

Re: [SR-Users] NAT problem

Hello, is Kamailio and RTPProxy (or Asterisk) using public IP addresses? Or they listen on a private address and the firewall does port forwarding of a public IP address? Cheers, Daniel On Mon, Sep 16, 2019 at 10:51 AM Arnout Van Den Kieboom < arnoutvdkieb...@gmail.com> wrote: > Hi, > > First o

[SR-Users] NAT problem

Hi, First of all, I'm really new to Kamailio. So sorry if I ask a stupid question, or perhaps a really weird one. I started using kamailio in a test environment about a week ago. for setup i have the situation for inbound calls: Carrier --> FW (NAT) --> Kamailio for outbound to an asterisk box i