[SR-Users] Kamailio dump configuration and exit?

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

  -?,-h : this help

  -v: show version and exit

  -V: show version and configure options then exit

  -t: test configuration and exit

  -T: test configuration, dump it and exit

  -q: suppress non-error messages during configuration testing

  -s signal : send signal to a master process: stop, quit, reopen,
reload

  -p prefix : set prefix path (default: /usr/share/nginx/)

  -c filename   : set configuration file (default: /etc/nginx/nginx.conf)

  -g directives : set global directives out of configuration file



Thanks for your time in advance!
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

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

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

[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 that wants to see the in-dialog messages needs to add itself to
the record route list when receiving the initial INVITE for example. If a
server is not in the list of record routes, then in-dialog requests will
not be sent to the server. Headers that are most important in terms of
routing are R-URI, Route, Record-Route, Contact, Via.

Via header is for routing responses, while Record-Route is for in-dialog
requests.

I've put a few tips and some resources here about starting with Kamailio,
which hopefully may help you a bit:
http://tao-communications-ltd.simplesite.com/447576389

Cheers,
Yufei

>* Message: 7
*>* Date: Thu, 5 Nov 2020 12:26:16 +0200
*>* From: "Adrian Tabacioiu" https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users>>
*>* To: sr-users at lists.kamailio.org

*>* Subject: [SR-Users] Proxy configuration that exit dialog afer INVITE
*>* -> OK
*>* Message-ID: <7449102a9f3dbe38b6dba753d1cffcd8.squirrel at
mail.c-s.ro >
*>* Content-Type: text/plain;charset=iso-8859-1
*>>>* Hello all,
*>>* Am I new in the usage of kamailio, sorry if I ask somehow something simple
*>* or terribly wrong .
*>>* I need to test a configuration of Kamailio which exit the dialog between
*>* UA after the first OK (that means it will not receive the following ACK,
*>* BYE).
*>>* I understand that in theory this is possible in two configuration types:
*>* - no Record Route header
*>* - or stateless proxy
*>>* First question:
*>* Am I correct with the choices above?
*>* Can I find example configuration for this two modes ?
*>>* Question 2:
*>* two or more proxy should be inter-connected, removing the Record Route
*>* header would interfere with proxy routing ? (should not the "Via"
*>* information be sufficient?)
*>>* Thank you in advance for help.
*>>* Best regards,
*>* Adrian Tabacioiu
*>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

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

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

Re: [SR-Users] BYE and TCP

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

-- Juha

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

Re: [SR-Users] BYE and TCP

[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 for the remaining
requests.

-- Juha

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

Re: [SR-Users] BYE and TCP

[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
the traffic, you have to capture both directions on your kamailio server
to see what happens on each side.

Cheers,
Daniel


On 06.11.20 10:35, Kjeld Flarup wrote:
> 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 the advertised 5071
>
> Regards Kjeld
>
> Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla
> mailto:mico...@gmail.com>>:
>
> 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 to use another connection. Of
> course, if follows the same path as INVITE, if the connection is
> still open, it should be reused. But is a matter of matching, it
> can be that the INVITE uses different destination identifiers or
> the connection gets cut from different reasons. But the point is
> that even if there is a different connection, it should work.
>
> So, I actually looked at the pcap capture you sent in one of your
> previous emails and the BYE is sent out, but gets back:
>
> SIP/2.0 481 Unknown Dialog.
>
> Therefore it gets to the end point, which doesn't match it with
> any of its active calls. Looking at the headers, the 200ok/INVITE has:
>
> From: "Front Door"
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To: ;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> And the BYE:
>
> From: "Front Door"
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To:
> 
> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> While the dialog should be matched on call-id, from/to-tags, the
> From/To URI should be the same to be strict conformant with
> RFC3261 (that mandates unchanged From/To for backward
> compatibility with RFC2543). Likely you do some From/To header
> changes that are not done correctly to update/restore the values
> for traffic within dialog.
>
> Cheers,
> Daniel
>
> On 06.11.20 09:31, Kjeld Flarup wrote:
>> 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 an ACK. 
>>
>> However two seconds before receiving the 200 OK, there are some
>> spurious retransmissions and out of order on 37148. Perhaps this
>> has caused Kamailio to deem the connection bad, but it still
>> receives data on it.
>> Now I assume that the providers server (Which also is flying
>> Kamailio) should detect the new port, and continue using that. I
>> got a trace from the provider, where there is no disturbance.
>> Thus the server thinks that the connection is OK. 
>>
>> Now my next question is, what makes a Kamailio detect this change?
>> Is it a problem that I only rewrite To and From in the INVITE,
>> thus the ACK contains some other values. 
>>
>>
>> It is also a bit strange that I get this error exactly, the same
>> place in the conversation every time I make a call. Somehow I
>> suspect some NAT timeout in the router. (it is not carrier grade
>> NAT).
>> Can I do anything to prevent a NAT timeout from the client side?
>>
>>
>> Another thing. I assume that sending my internal port in the From
>> field, or any kind of advertising, should be ignored by the server.
>>
>> Regards Kjeld
>>
>>
>>
>> Den fre. 6. nov. 2020 kl. 07.45 skrev Juha Heinanen
>> mailto:j...@tutpro.com>>:
>>
>> 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 for the remaining
>> requests.
>>
>> -- Juha
>>
>> ___

Re: [SR-Users] BYE and TCP

[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 the advertised 5071

Regards Kjeld

Den fre. 6. nov. 2020 kl. 10.18 skrev Daniel-Constantin Mierla <
mico...@gmail.com>:

> 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 to
> use another connection. Of course, if follows the same path as INVITE, if
> the connection is still open, it should be reused. But is a matter of
> matching, it can be that the INVITE uses different destination identifiers
> or the connection gets cut from different reasons. But the point is that
> even if there is a different connection, it should work.
>
> So, I actually looked at the pcap capture you sent in one of your previous
> emails and the BYE is sent out, but gets back:
>
> SIP/2.0 481 Unknown Dialog.
>
> Therefore it gets to the end point, which doesn't match it with any of its
> active calls. Looking at the headers, the 200ok/INVITE has:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To: ;tag=12003375157297.
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> And the BYE:
>
> From: "Front Door" 
> ;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
> To:
> sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297
> .
> Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.
>
> While the dialog should be matched on call-id, from/to-tags, the From/To
> URI should be the same to be strict conformant with RFC3261 (that mandates
> unchanged From/To for backward compatibility with RFC2543). Likely you do
> some From/To header changes that are not done correctly to update/restore
> the values for traffic within dialog.
>
> Cheers,
> Daniel
> On 06.11.20 09:31, Kjeld Flarup wrote:
>
> 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 an ACK.
>
> However two seconds before receiving the 200 OK, there are some spurious
> retransmissions and out of order on 37148. Perhaps this has caused Kamailio
> to deem the connection bad, but it still receives data on it.
> Now I assume that the providers server (Which also is flying Kamailio)
> should detect the new port, and continue using that. I got a trace from the
> provider, where there is no disturbance. Thus the server thinks that the
> connection is OK.
>
> Now my next question is, what makes a Kamailio detect this change?
> Is it a problem that I only rewrite To and From in the INVITE, thus the
> ACK contains some other values.
>
>
> It is also a bit strange that I get this error exactly, the same place in
> the conversation every time I make a call. Somehow I suspect some NAT
> timeout in the router. (it is not carrier grade NAT).
> Can I do anything to prevent a NAT timeout from the client side?
>
>
> Another thing. I assume that sending my internal port in the From field,
> or any kind of advertising, should be ignored by the server.
>
> Regards Kjeld
>
>
>
> Den fre. 6. nov. 2020 kl. 07.45 skrev 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 for the remaining
>> requests.
>>
>> -- Juha
>>
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>
>
> --
>
> - Med Liberalistiske Hilsner --
>
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
>
>
> ___
> 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
>
>

-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere

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

[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 set_reply_close()+send_reply(), but have a
>> "mode" parameter to control what other operations should be done before
>> sending the reply out.
> That is how I understood it too.  For me a new function with mode param
> would be fine.
>
> -- Juha

-- 
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] BYE and TCP

[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 to use another connection. Of course, if follows the same path as
INVITE, if the connection is still open, it should be reused. But is a
matter of matching, it can be that the INVITE uses different destination
identifiers or the connection gets cut from different reasons. But the
point is that even if there is a different connection, it should work.

So, I actually looked at the pcap capture you sent in one of your
previous emails and the BYE is sent out, but gets back:

SIP/2.0 481 Unknown Dialog.

Therefore it gets to the end point, which doesn't match it with any of
its active calls. Looking at the headers, the 200ok/INVITE has:

From: "Front Door"
;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To: ;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.

And the BYE:

From: "Front Door"
;tag=thm9OFNQemH0IsqgRR1jDGF4rjVivTOK.
To:
sip:195.249.145.198:5060;transport=udp;line=sr-z-yMngm27FwI73qx0CQo6gm2n3ao03LMn5UILt2NziWIO3ooTDc*;tag=12003375157297.
Call-ID: ***FgXBdt966gypC5V1T5VGUtLILtzxsJJ57NRSL5UMUiq*.

While the dialog should be matched on call-id, from/to-tags, the From/To
URI should be the same to be strict conformant with RFC3261 (that
mandates unchanged From/To for backward compatibility with RFC2543).
Likely you do some From/To header changes that are not done correctly to
update/restore the values for traffic within dialog.

Cheers,
Daniel

On 06.11.20 09:31, Kjeld Flarup wrote:
> 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 an ACK. 
>
> However two seconds before receiving the 200 OK, there are some
> spurious retransmissions and out of order on 37148. Perhaps this has
> caused Kamailio to deem the connection bad, but it still receives data
> on it.
> Now I assume that the providers server (Which also is flying Kamailio)
> should detect the new port, and continue using that. I got a trace
> from the provider, where there is no disturbance. Thus the server
> thinks that the connection is OK. 
>
> Now my next question is, what makes a Kamailio detect this change?
> Is it a problem that I only rewrite To and From in the INVITE, thus
> the ACK contains some other values. 
>
>
> It is also a bit strange that I get this error exactly, the same place
> in the conversation every time I make a call. Somehow I suspect some
> NAT timeout in the router. (it is not carrier grade NAT).
> Can I do anything to prevent a NAT timeout from the client side?
>
>
> Another thing. I assume that sending my internal port in the From
> field, or any kind of advertising, should be ignored by the server.
>
> Regards Kjeld
>
>
>
> Den fre. 6. nov. 2020 kl. 07.45 skrev 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 for the remaining
> requests.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org 
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
>
>
>
> -- 
>
> - Med Liberalistiske Hilsner --
>
>Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
>Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
>Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk 
> 
>
>
> ___
> 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] BYE and TCP

[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 an ACK.

However two seconds before receiving the 200 OK, there are some spurious
retransmissions and out of order on 37148. Perhaps this has caused Kamailio
to deem the connection bad, but it still receives data on it.
Now I assume that the providers server (Which also is flying Kamailio)
should detect the new port, and continue using that. I got a trace from the
provider, where there is no disturbance. Thus the server thinks that the
connection is OK.

Now my next question is, what makes a Kamailio detect this change?
Is it a problem that I only rewrite To and From in the INVITE, thus the ACK
contains some other values.


It is also a bit strange that I get this error exactly, the same place in
the conversation every time I make a call. Somehow I suspect some NAT
timeout in the router. (it is not carrier grade NAT).
Can I do anything to prevent a NAT timeout from the client side?


Another thing. I assume that sending my internal port in the From field, or
any kind of advertising, should be ignored by the server.

Regards Kjeld



Den fre. 6. nov. 2020 kl. 07.45 skrev 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 for the remaining
> requests.
>
> -- Juha
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>


-- 

- Med Liberalistiske Hilsner --

   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users