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

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

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

[SR-Users] Releasing Kamailio v5.4.3

Hello, I am considering to release Kamailio v5.4.3 sometime next week, likely on Monday, December 14, 2020. This is the usual heads up notification to see if anyone is aware of issues not yet reported to bug tracker and if yes, do it as soon as possible to give them a chance to be fixed. Cheers,

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

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

Re: [SR-Users] sngrep TLS connection

There are two options 1- use SIMPDUMP module to dup all SIP packets in Log file SIPDUMP Module | | | | SIPDUMP Module | | |   2- use SIPTRACE module and broadcast SIP traffic from kamailio to any local port and then capture through sngrep -p BROACST_PORT SipTrace Module | | |

Re: [SR-Users] Kamailio as an LCR based on prices but also signaling quality indicators

There’s a fork with a new module for just this... On Tue, 8 Dec 2020 at 04:46, Arsen Semenov wrote: > Hi, > > You can try CGRateS. It could be easily integrated with kamailio and it > has LCR and QoS based routing as I remember.. > > Regards, > > On Mon, Dec 7, 2020 at 6:31 PM Abdoul Osséni >

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

Re: [SR-Users] sngrep TLS connection

Hello, there were some limitations in sngrep for capturing tls traffic:   * https://github.com/irontec/sngrep/issues/112 Not sure if there was any work afterwards to improve. The best place to ask in on sngrep project. Anyhow, I want to add that if you use Kamailio, then you can load sipdump