[SR-Users] Kamailio dump configuration and exit?

2020-11-06 Thread Brandon Armstead
Is there a similar hook to make kamailio dump its current configuration it is reading including ... included files, i.e. similar to nginx -T root@main:/home/brandon# nginx -h nginx version: nginx/1.14.2 Usage: nginx [-?hvVtTq] [-s signal] [-c filename] [-p prefix] [-g directives] Options:

Re: [SR-Users] send_reply() related feature request

2020-11-06 Thread Juha Heinanen
Daniel-Constantin Mierla writes: > New function added, but no testing done -- if there are issues, open a > bug report. Works as expected, thanks, Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org

Re: [SR-Users] Proxy configuration that exit dialog afer INVITE -> OK

2020-11-06 Thread Yufei Tao
Hi, Here's an example kamailio.cfg that uses record_route so in-dialog requests will go through the Kamailio proxy: https://github.com/kamailio/kamailio/blob/master/etc/kamailio.cfg There are many other example cfg files: https://github.com/kamailio/kamailio/tree/master/misc/examples Any server

Re: [SR-Users] send_reply() related feature request

2020-11-06 Thread Juha Heinanen
Daniel-Constantin Mierla writes: > New function added, but no testing done -- if there are issues, open a > bug report. Thanks, will test later today, -- Juha ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Juha Heinanen
Kjeld Flarup writes: > My question is still, which port is the BYE from the server supposed to be > sent to? If client is behind NAT, the server must use the connection that the client opened to it to send the request to client. There is no way the server opens the connection and uses it. --

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Juha Heinanen
Kjeld Flarup writes: > How is TCP SIP actually supposed to handle a BYE, when the client is > behind NAT. Client behind NAT is supposed to keep its TCP connection to SIP Proxy alive and use it for all requests of the call. If the connection breaks for some reason, the client sets up a new one

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Daniel-Constantin Mierla
Hello, from SIP specs point of view, can be any port -- ACK and BYE do not have to follow same path as INVITE, so they can even come from a different IP. Then, the call can be closed after 30secs because also the ACK has the same problems with the header as the BYE. Your pcap didn't include all

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Kjeld Flarup
Hi Daniel The Unknown Dialog comes because the server hang up the call 30 seconds earlier. We never gets these BYE messages, thus the door phone hangs times out and hangs up. My question is still, which port is the BYE from the server supposed to be sent to? The original 37148 The new 37150 or

Re: [SR-Users] send_reply() related feature request

2020-11-06 Thread Daniel-Constantin Mierla
New function added, but no testing done -- if there are issues, open a bug report. Cheers, Daniel On 04.11.20 13:48, Juha Heinanen wrote: > Daniel-Constantin Mierla writes: > >> I wanted to say that the new function to be added should be a bit more >> generic, not targeting only

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Daniel-Constantin Mierla
Hello, I think you hunt a mirage problem here by looking at the ports of tcp connections, if you think that being different ports is the cause of BYE failure. The ACK fpr 200ok is independent of the INVITE transaction and can have a completely different path than INVITE, thus is completely valid

Re: [SR-Users] BYE and TCP

2020-11-06 Thread Kjeld Flarup
Thanks Juha That makes it somehow easier to understand my capture. My Kamailio must then have detected a broken TCP connection, though I cannot see why in the capture, neither in the log, but I only run on debug level 2. It receives a 200 OK on port 37148, and then establishes 37150 to reply with