Re: [SR-Users] set_advertised_address

[Daniel-Constantin Mierla]

Hello,

it is not clear what exactly you want to achieve...

Is it that for connected phones from local network to use the local IP
and for sip messages with devices outside to use external ip?

Cheers,
Daniel

On 04.12.18 23:33, Kjeld Flarup wrote:
> Hello
>
> I have a PBX behind NAT.
> Thus I advertise the public IP, and forwards the port to my PBX.
>
> listen=LOCALIP:5070 advertise EXTERNALIP:5070
>
> Now clients can connect to the PBX from the Internet. And also inside
> the LAN, because I have enabled NAT loopback.
>
> However some customers sysadmins complains that NAT loopback is a
> security risk. I have not been able to find any exploits of this, but
> the sales and support people asks if it is possible to remove this NAT
> loopback requirement.
>
> I could look at $rd and if it is local, then I could  advertise LOCALIP.
> I found set_advertised_address("LOCALIP");
>
> set_advertised_address however only seems to modify the latest Via
> header, not the Record-route, and audio neither works.
>
> Could I do something to make this work, or is it a dead end?
>
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


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

Re: [SR-Users] is_e164 logic to detect valid number

[Joel Serrano]

You might also want to have a look at the “phonenum” module...

https://www.kamailio.org/docs/modules/5.2.x/modules/phonenum.html


On Tue, Dec 4, 2018 at 19:12 Patrick Wakano  wrote:

> Thanks for the replies guys!
> I will probably add a length test to invalidate too short numbers!
> By the way, I had a quick look in the ITU recommendation (
> https://www.itu.int/rec/T-REC-E.164/en) and looks like the short numbers
> are for local purposes only being part of the "Non-ITU-T E.164 numbers"
> section, so I guess the function should return false in this case. Also it
> seems the + sign is recommended but not mandatory for a E.164 number, which
> is quite confusing.
>
> Kind regards,
> Patrick Wakano
>
>
> On Tue, 4 Dec 2018 at 08:57, Henning Westerholt  wrote:
>
>> Am Montag, 3. Dezember 2018, 06:08:27 CET schrieb Patrick Wakano:
>> > I am using the is_e164() function to validate the number we receive,
>> and I
>> > come to see that the number +555 was accepted
>> > After some googling it looks like(it is not very clear though) that 7
>> > digits are the minimum we could have for e164 numbers but after checking
>> > the source code, I saw it accepts anything starting with + and having
>> > between 2 and 16 numbers. So is it really valid to have a number with
>> just
>> > 2 digits? What is the case?
>>
>> Hello Patrick,
>>
>> I think the implementation was done with a pragmatic approach, to make
>> sure
>> that we don't reject numbers that are used in the field. The ITU standard
>> Amendment A mentions the possibility to use national short numbers, for
>> example. The standard mentions that the maximal length should be 15, but
>> I
>> think in this case this was also implemented a bit more relaxed.
>>
>> The original implementation from the enum module allows even longer
>> numbers, I
>> will check if this should be synchronized.
>>
>> Best regards,
>>
>> Henning
>>
>>
>> --
>> Henning Westerholt - https://skalatan.de/blog/
>> Kamailio services - https://skalatan.de/services
>> Kamailio security assessment - https://skalatan.de/de/assessment
>>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] is_e164 logic to detect valid number

[Patrick Wakano]

Thanks for the replies guys!
I will probably add a length test to invalidate too short numbers!
By the way, I had a quick look in the ITU recommendation (
https://www.itu.int/rec/T-REC-E.164/en) and looks like the short numbers
are for local purposes only being part of the "Non-ITU-T E.164 numbers"
section, so I guess the function should return false in this case. Also it
seems the + sign is recommended but not mandatory for a E.164 number, which
is quite confusing.

Kind regards,
Patrick Wakano


On Tue, 4 Dec 2018 at 08:57, Henning Westerholt  wrote:

> Am Montag, 3. Dezember 2018, 06:08:27 CET schrieb Patrick Wakano:
> > I am using the is_e164() function to validate the number we receive, and
> I
> > come to see that the number +555 was accepted
> > After some googling it looks like(it is not very clear though) that 7
> > digits are the minimum we could have for e164 numbers but after checking
> > the source code, I saw it accepts anything starting with + and having
> > between 2 and 16 numbers. So is it really valid to have a number with
> just
> > 2 digits? What is the case?
>
> Hello Patrick,
>
> I think the implementation was done with a pragmatic approach, to make
> sure
> that we don't reject numbers that are used in the field. The ITU standard
> Amendment A mentions the possibility to use national short numbers, for
> example. The standard mentions that the maximal length should be 15, but I
> think in this case this was also implemented a bit more relaxed.
>
> The original implementation from the enum module allows even longer
> numbers, I
> will check if this should be synchronized.
>
> Best regards,
>
> Henning
>
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] set_advertised_address

[Sergiu Pojoga]

Sure, eliminate NAT altogether? Haha

Don't see how else.

On Tue, Dec 4, 2018, 5:34 PM Kjeld Flarup  Hello
>
> I have a PBX behind NAT.
> Thus I advertise the public IP, and forwards the port to my PBX.
>
> listen=LOCALIP:5070 advertise EXTERNALIP:5070
>
> Now clients can connect to the PBX from the Internet. And also inside
> the LAN, because I have enabled NAT loopback.
>
> However some customers sysadmins complains that NAT loopback is a
> security risk. I have not been able to find any exploits of this, but
> the sales and support people asks if it is possible to remove this NAT
> loopback requirement.
>
> I could look at $rd and if it is local, then I could  advertise LOCALIP.
> I found set_advertised_address("LOCALIP");
>
> set_advertised_address however only seems to modify the latest Via
> header, not the Record-route, and audio neither works.
>
> Could I do something to make this work, or is it a dead end?
>
>
> --
>  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
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] set_advertised_address

[Kjeld Flarup]

Hello

I have a PBX behind NAT.
Thus I advertise the public IP, and forwards the port to my PBX.

listen=LOCALIP:5070 advertise EXTERNALIP:5070

Now clients can connect to the PBX from the Internet. And also inside 
the LAN, because I have enabled NAT loopback.


However some customers sysadmins complains that NAT loopback is a 
security risk. I have not been able to find any exploits of this, but 
the sales and support people asks if it is possible to remove this NAT 
loopback requirement.


I could look at $rd and if it is local, then I could  advertise LOCALIP.
I found set_advertised_address("LOCALIP");

set_advertised_address however only seems to modify the latest Via 
header, not the Record-route, and audio neither works.


Could I do something to make this work, or is it a dead end?


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

Re: [SR-Users] Dispatcher clear dst_avp

[Grant Bagdasarian]

To answer my own question regarding the reset of the avp variable: 
avp_delete(name) did the trick.

Grant Bagdasarian

Senior Developer

+31765727054

cm.com

[cid:image002.png@01D48BF4.08AB4470]


From: sr-users  On Behalf Of Grant 
Bagdasarian
Sent: dinsdag 4 december 2018 15:33
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] Dispatcher clear dst_avp

Hello,

I'm trying to use multiple destination sets which may include the same 
destination.
For instance:
SET ID: 1
sip:10.0.0.1:5060
sip:10.0.0.2:5060

SET ID: 2
sip:10.0.0.1:5060

Whenever a new SIP INVITE is sent to the Kamailio instance it will use SET ID 
1. If then for some reason this call attempt fails, failure_route will trigger 
and SET ID 2 will be used.  At first glance this might not make any sense, but 
there is some business logic behind this, but it's not relevant for this case.

For some reason, the dst_avp variable still contains the destinations of SET ID 
1 in failure_route.
Is there a built-in way to reset this variable for every call to 
ds_select_domain(), such that only the destinations of passed SET ID will be 
loaded into the avp?
I tried setting the avp to $null before calling ds_select_domain, but that had 
some undesirable effects.

The reason I'm asking this is the destinations the call is being sent to are 
Freeswitch instances, which will return a 482 Request Merged when the same 
INVITE is sent to the same Freeswitch within 4 seconds (default T4 timer).
I'm trying to match the previously selected destination in failure_route with 
the next destination and skip if they're the same, or stop processing when they 
are the same and no more destinations are available.
I know I can mess with the T4 timer in Freeswitch and perhaps even sleep in 
failure route to deal with the 482 failure, but I rather fix this in a normal 
way.

Regards,

Grant Bagdasarian

Senior Developer


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

[SR-Users] Dispatcher clear dst_avp

[Grant Bagdasarian]

Hello,

I'm trying to use multiple destination sets which may include the same 
destination.
For instance:
SET ID: 1
sip:10.0.0.1:5060
sip:10.0.0.2:5060

SET ID: 2
sip:10.0.0.1:5060

Whenever a new SIP INVITE is sent to the Kamailio instance it will use SET ID 
1. If then for some reason this call attempt fails, failure_route will trigger 
and SET ID 2 will be used.  At first glance this might not make any sense, but 
there is some business logic behind this, but it's not relevant for this case.

For some reason, the dst_avp variable still contains the destinations of SET ID 
1 in failure_route.
Is there a built-in way to reset this variable for every call to 
ds_select_domain(), such that only the destinations of passed SET ID will be 
loaded into the avp?
I tried setting the avp to $null before calling ds_select_domain, but that had 
some undesirable effects.

The reason I'm asking this is the destinations the call is being sent to are 
Freeswitch instances, which will return a 482 Request Merged when the same 
INVITE is sent to the same Freeswitch within 4 seconds (default T4 timer).
I'm trying to match the previously selected destination in failure_route with 
the next destination and skip if they're the same, or stop processing when they 
are the same and no more destinations are available.
I know I can mess with the T4 timer in Freeswitch and perhaps even sleep in 
failure route to deal with the 482 failure, but I rather fix this in a normal 
way.

Regards,

Grant Bagdasarian

Senior Developer


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

Re: [SR-Users] Auth_xkeys module - freeing already freed pointer

[Daniel-Constantin Mierla]

Hello,

can you try with master branch or with the patch from the next commit?

  -
https://github.com/kamailio/kamailio/commit/01f5ecbc45c236daea62d6638a02c168720c8479

If all is ok, I will backport.

Cheers,
Daniel

On 04.12.18 10:12, José Seabra wrote:
> Hello Henning,
>
> The function that seems to be causing this is "auth_xkeys_add".
>
> Let me know if do you need something else.
>
> Thank you for the support
> José
>
> Henning Westerholt mailto:h...@kamailio.org>> escreveu
> no dia segunda, 3/12/2018 à(s) 21:59:
>
> Am Montag, 3. Dezember 2018, 19:03:36 CET schrieb José Seabra:
> > I'm constantly getting the following message when i'm using module
> > auth_xkeys.
> >
> >  CRITICAL:  [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing
> > already freed pointer (0x7f6310987400), called from core:
> core/data_lump.c:
> > free_lump(466), first free core: core/data_lump.c:
> free_lump(466) - ignoring
> >
> >
> > Apparently kamailio only throw this message but i would like to
> know if its
> > a normal protection from kamailio or it should be fixed?
>
> Hello Jose,
>
> this is not a normal error, it shows a redundant (double) free
> which is
> detected from the internal Kamailio memory manager. This should be
> fixed.
>
> Can you investigate at which function call from the auth_xkeys
> module in the
> kamailio cfg this error is printed?
>
> Best regards,
>
> Henning
>
> -- 
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
>
>
>
> -- 
> Cumprimentos
> José Seabra
>
> ___
> 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
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

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

Re: [SR-Users] xlog issue

[Daniel-Constantin Mierla]

Hello,

typically syslog has some rate limiting, and with centos, you get extra
limits with selinux. You have to dive into rsyslog, system config and
selinux.

What you can do is to start with log_stderror=yes (or -E command line
option) and see if it is printing the messages you are looking for to
the terminal. You can eventually direct sderror to a file to be easier
to search/match...

Cheers,
Daniel

On 04.12.18 10:40, Soltanici Ilie wrote:
> Hello,
>
> Actually, async Syslog option was the initial option which I tried -
> it wasn't working properly so I changed to a synchronous mode in the
> hope that it will work better, but unfortunately it didn't.
>
> Daniel-Constantin Mierla :
>
> Hello,
>
> try with async syslogging option in rsyslog config: add a - in
> front of the file name, like:
>
> local0.*             -/var/log/kamailio/kamailio.log
>
> See if the results are better.
>
> Cheers,
> Daniel
>
> On 02.12.18 16:14, Soltanici Ilie wrote:
>>
>> Hello,
>>
>> I have a strange situation by using xlog module. I don't know for
>> what reason I'm not receiving all logs generated by kamailio.
>>
>> This is the configuration which I'm using in kamailio.cfg:
>>
>> log_facility=LOG_LOCAL0
>> log_name="kamailio"
>> log_prefix="{$rm ($mt) | Seq=$cs | Source IP=$si ($proto) | Call
>> ID=$ci} "
>>
>> # - xlog -
>> modparam("xlog", "buf_size", 8192)
>> modparam("xlog", "long_format", 0)
>> modparam("xlog", "force_color", 1)
>> modparam("xlog", "log_colors", "L_ERR=cr;L_WARN=px,L_INFO=px")
>>
>> This is rsyslog configuration file:
>> local0.*             /var/log/kamailio/kamailio.log
>>
>> Kamailio is running under kamailio user, permission for the log
>> file are as shown below:
>> -rwxrwxr-x 1 kamailio kamailio 252885132 Dec  2 14:51
>> /var/log/kamailio/kamailio.log
>>
>> In request_route block this is the first line:
>>
>> xlog("L_INFO","[START ROUTING]-(Source IP=$si:$sp/Destination
>> IP=$Ri:$Rp)\n");
>>
>> The problem is that not every request is logged in the log-file.
>> For example, some "INVITES" requests I can find in the log file,
>> but some of them - I cannot, even that in sngrep I see the
>> request and the call is successfully processed by kamailio. Also,
>> for some requests i can see only partial data, not full call-flow
>> as it supposed to be (for ex. i see only BYE requests, or ACK
>> response instead of full call flow).
>>
>> Does someone have the same issue? If you don't - how are you
>> dealing with kamailio log files? I'm thinking to send them to the
>> central ELK stack, but if I have such problems by saving them
>> locally - I don't see any reason to send them elsewhere.
>> I may think that the problem could be in rsyslog itself, but how
>> can I troubleshoot that?
>>
>> The traffic on the server is not very high - 30-50 concurrent
>> calls. As a storage i'm using an SSD disk and xfs filesystem.
>> Load on the disk - according to iostat/iotop - is minimum. 
>>
>> OS: CentOS Linux 7 (Core), Kamailio: 5.2.0 (x86_64/linux) 535e13
>> Thank You.
>>
>>
>> ___
>> 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
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>
-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

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

Re: [SR-Users] xlog issue

[Soltanici Ilie]

Hello,

Actually, async Syslog option was the initial option which I tried - it wasn't 
working properly so I changed to a synchronous mode in the hope that it will 
work better, but unfortunately it didn't.

>Daniel-Constantin Mierla :
>
>Hello,
>
>try with async syslogging option in
>  rsyslog config: add a - in front of the file name, like:
>
>local0.*            
>  -/var/log/kamailio/kamailio.log
>
>See if the results are better.
>
>Cheers,
>Daniel
>
>On 02.12.18 16:14, Soltanici Ilie
>  wrote:
>>Hello,
>>
>>I have a strange situation by using xlog module. I don't know
>>for what reason I'm not receiving all logs generated by
>>kamailio.
>>
>>This is the configuration which I'm using in kamailio.cfg:
>>
>>log_facility=LOG_LOCAL0
>>log_name="kamailio"
>>log_prefix="{$rm ($mt) | Seq=$cs | Source IP=$si ($proto) | Call
>>ID=$ci} "
>># - xlog -
>>modparam("xlog", "buf_size", 8192)
>>modparam("xlog", "long_format", 0)
>>modparam("xlog", "force_color", 1)
>>modparam("xlog", "log_colors", "L_ERR=cr;L_WARN=px,L_INFO=px")
>>
>>This is rsyslog configuration file:
>>local0.*             /var/log/kamailio/kamailio.log
>>
>>Kamailio is running under kamailio user, permission for the log
>>file are as shown below:
>>-rwxrwxr-x 1 kamailio kamailio 252885132 Dec  2 14:51
>>/var/log/kamailio/kamailio.log
>>
>>In request_route block this is the first line:
>>
>>xlog("L_INFO","[START ROUTING]-(Source IP=$si:$sp/Destination
>>IP=$Ri:$Rp)\n");
>>
>>The problem is that not every request is logged in the log-file.
>>For example, some "INVITES" requests I can find in the log file,
>>but some of them - I cannot, even that in sngrep I see the
>>request and the call is successfully processed by kamailio.
>>Also, for some requests i can see only partial data, not full
>>call-flow as it supposed to be (for ex. i see only BYE requests,
>>or ACK response instead of full call flow). 
>>
>>Does someone have the same issue? If you don't - how are you
>>dealing with kamailio log files? I'm thinking to send them to
>>the central ELK stack, but if I have such problems by saving
>>them locally - I don't see any reason to send them elsewhere.
>>I may think that the problem could be in rsyslog itself, but how
>>can I troubleshoot that?
>>
>>The traffic on the server is not very high - 30-50 concurrent
>>calls. As a storage i'm using an SSD disk and xfs filesystem.
>>Load on the disk - according to iostat/iotop - is minimum. 
>>
>>OS: CentOS Linux 7 (Core), Kamailio: 5.2.0 (x86_64/linux) 535e13
>>Thank You.
>>___
>>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
>Kamailio World Conference -- www.kamailioworld.com
>Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Auth_xkeys module - freeing already freed pointer

[José Seabra]

Hello Henning,

The function that seems to be causing this is "auth_xkeys_add".

Let me know if do you need something else.

Thank you for the support
José

Henning Westerholt  escreveu no dia segunda, 3/12/2018
à(s) 21:59:

> Am Montag, 3. Dezember 2018, 19:03:36 CET schrieb José Seabra:
> > I'm constantly getting the following message when i'm using module
> > auth_xkeys.
> >
> >  CRITICAL:  [core/mem/q_malloc.c:514]: qm_free(): BUG: freeing
> > already freed pointer (0x7f6310987400), called from core:
> core/data_lump.c:
> > free_lump(466), first free core: core/data_lump.c: free_lump(466) -
> ignoring
> >
> >
> > Apparently kamailio only throw this message but i would like to know if
> its
> > a normal protection from kamailio or it should be fixed?
>
> Hello Jose,
>
> this is not a normal error, it shows a redundant (double) free which is
> detected from the internal Kamailio memory manager. This should be fixed.
>
> Can you investigate at which function call from the auth_xkeys module in
> the
> kamailio cfg this error is printed?
>
> Best regards,
>
> Henning
>
> --
> Henning Westerholt - https://skalatan.de/blog/
> Kamailio services - https://skalatan.de/services
> Kamailio security assessment - https://skalatan.de/de/assessment
>


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

Re: [SR-Users] xlog issue

[Daniel-Constantin Mierla]

Hello,

try with async syslogging option in rsyslog config: add a - in front of
the file name, like:

local0.*             -/var/log/kamailio/kamailio.log

See if the results are better.

Cheers,
Daniel

On 02.12.18 16:14, Soltanici Ilie wrote:
>
> Hello,
>
> I have a strange situation by using xlog module. I don't know for what
> reason I'm not receiving all logs generated by kamailio.
>
> This is the configuration which I'm using in kamailio.cfg:
>
> log_facility=LOG_LOCAL0
> log_name="kamailio"
> log_prefix="{$rm ($mt) | Seq=$cs | Source IP=$si ($proto) | Call ID=$ci} "
>
> # - xlog -
> modparam("xlog", "buf_size", 8192)
> modparam("xlog", "long_format", 0)
> modparam("xlog", "force_color", 1)
> modparam("xlog", "log_colors", "L_ERR=cr;L_WARN=px,L_INFO=px")
>
> This is rsyslog configuration file:
> local0.*             /var/log/kamailio/kamailio.log
>
> Kamailio is running under kamailio user, permission for the log file
> are as shown below:
> -rwxrwxr-x 1 kamailio kamailio 252885132 Dec  2 14:51
> /var/log/kamailio/kamailio.log
>
> In request_route block this is the first line:
>
> xlog("L_INFO","[START ROUTING]-(Source IP=$si:$sp/Destination
> IP=$Ri:$Rp)\n");
>
> The problem is that not every request is logged in the log-file. For
> example, some "INVITES" requests I can find in the log file, but some
> of them - I cannot, even that in sngrep I see the request and the call
> is successfully processed by kamailio. Also, for some requests i can
> see only partial data, not full call-flow as it supposed to be (for
> ex. i see only BYE requests, or ACK response instead of full call flow).
>
> Does someone have the same issue? If you don't - how are you dealing
> with kamailio log files? I'm thinking to send them to the central ELK
> stack, but if I have such problems by saving them locally - I don't
> see any reason to send them elsewhere.
> I may think that the problem could be in rsyslog itself, but how can I
> troubleshoot that?
>
> The traffic on the server is not very high - 30-50 concurrent calls.
> As a storage i'm using an SSD disk and xfs filesystem. Load on the
> disk - according to iostat/iotop - is minimum. 
>
> OS: CentOS Linux 7 (Core), Kamailio: 5.2.0 (x86_64/linux) 535e13
> Thank You.
>
>
> ___
> 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
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

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

Re: [SR-Users] presence/mwi issue

[Daniel-Constantin Mierla]

For the records, the commit was just backported to branch 5.1.

Cheers,
Daniel

On 28.11.18 17:29, Daniel-Constantin Mierla wrote:
> Hello,
>
> what I actually said it was that if you backport to your local git clone
> and testing was ok, then you can push it to 5.1 branch by yourself, no
> need to wait for me or others to push it. But I can also do it tomorrow.
>
> Cheers,
> Daniel
>
> On 28.11.18 15:10, Andreas Granig wrote:
>> Hi Daniel,
>>
>> This commit indeed fixed the issue, thanks for pointing it out! From my 
>> point of view, it’s fine backporting it to 5.1 to fix it there as well.
>>
>> Best,
>> Andreas
>>
>>> On 28.11.2018, at 13:45, Daniel-Constantin Mierla  wrote:
>>>
>>> Hello,
>>>
>>> ohh, I was looking at master and the commit I did seemed to be for the
>>> place without a guard on dialog event type.
>>>
>>> The master branch has the one you point to already guarded, done with:
>>>
>>>   -
>>> https://github.com/kamailio/kamailio/commit/6d0f8994611b50faa7ef7d1299acf0c390a2eed1
>>>   - https://github.com/kamailio/kamailio/pull/1453
>>>
>>> So apparently it was overlooked when backporting to release versions of
>>> 5.1.x.
>>>
>>> Can you cherry pick that commit and test? If all ok, you can push the
>>> backport to 5.1 branch. The master and 5.2 should be fine.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 28.11.18 13:36, Andreas Granig wrote:
 Hi Daniel,

 Unfortunately that doesn’t help. Digging a bit further, it seems that the 
 error comes from calling check_if_dialog() around line 715 in 
 update_presentity(), so actually before entering the 
 delete_presentity_if_dialog_id_exists() function.

 Andreas

> On 28.11.2018, at 12:51, Daniel-Constantin Mierla  
> wrote:
>
> Hello,
>
> can you try with the patch from next commit:
>
>  -
> https://github.com/kamailio/kamailio/commit/55c7f781be7cc40d0cd161640a47244aad60c0e7
>
> Cheers,
> Daniel
>
> On 28.11.18 12:34, Andreas Granig wrote:
>> Hi Daniel,
>>
>> I started fresh (never tried this module before), but after googling for 
>> the error, I came across Juha’s post, which sounds quite familiar.
>>
>> So I’m having a phone subscribing to message-summary of 
>> us...@example.org, and I have a script sending a PUBLISH in behalf of 
>> us...@example.org. This PUBLISH goes right into handle_publish in my 
>> config (with presence_mwi loaded), so nothing really special here, I 
>> believe.
>>
>> Andreas
>>
>>> On 28.11.2018, at 12:23, Daniel-Constantin Mierla  
>>> wrote:
>>>
>>> Hello,
>>>
>>> some clarifications in order to see where to look: you just started to
>>> play fresh with it and get this error? Or an old configuration that used
>>> to work in the past is now throwing the error?
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 28.11.18 12:13, Andreas Granig wrote:
 Hi,

 Currently playing with presence_mwi in kamailio 5.1, and it appears 
 the issue reported by Juha two years ago at 
 https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html
  seems to have appeared again somewhere along the way.

 I’m sending a PUBLISH with message-summary event type, however I’m 
 getting this error:

 ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse 
 xml document

 As said in the old thread, it’s not an XML document, so it shouldn’t 
 try to treat it as such. Any ideas?

 Best,
 Andreas
 ___
 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
>>> Kamailio World Conference -- www.kamailioworld.com
>>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>>>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>
>>> -- 
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio World Conference -- www.kamailioworld.com
>>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org

Re: [SR-Users] Dispatcher with a naptr address as destination

[Daniel-Constantin Mierla]

I just did it, if you use git, you can pull and have it. Nightly built
Debian packages will make it available tomorrow if you use
deb.kamailio.org apt repository with nightly builds.


Cheers,
Daniel


On 03.12.18 11:37, Patrick Murphy wrote:
> Thanks for the fix Daniel,
>
> Any ETA on when this will be backported to 5.2?
> 
> *From:* Daniel-Constantin Mierla 
> *Sent:* Thursday, November 29, 2018 10:54 AM
> *To:* Patrick Murphy; Henning Westerholt; sr-users@lists.kamailio.org
> *Cc:* José Seabra
> *Subject:* Re: [SR-Users] Dispatcher with a naptr address as destination
>  
>
> Hello,
>
>
> a solution for the moment would be to add a new flag to mark the
> destination for no-keepalive, so it is considered to be active always.
>
>
> Right now the issue is created by the fact that keepalive is enabled
> and the implementation needs the IP at start up.
>
>
> However, for NAPTR/SRV records, there can be a different IP returned
> for each query, so it might not bring much benefits to do keepalives
> in such cases. This can be added if someone wants to develop it.
>
>
> Then, just to refresh, you can do SRV based load balancing without
> dispatcher, it is done by tm and core automatically.
>
>
> Cheers,
> Daniel
>
>
> On 29.11.18 11:32, Patrick Murphy wrote:
>> Here you go: https://github.com/kamailio/kamailio/issues/1743
>>
>> The reason I posted here first was that I wanted to rule out any
>> obvious thing I was missing here since there already was a thread
>> open on it. 
>>
>> Cheers,
>> Pat
>> 
>> *From:* Henning Westerholt  
>> *Sent:* Wednesday, November 28, 2018 9:06 PM
>> *To:* sr-users@lists.kamailio.org 
>> *Cc:* Patrick Murphy; José Seabra; mico...@gmail.com
>> 
>> *Subject:* Re: [SR-Users] Dispatcher with a naptr address as destination
>>  
>> Am Mittwoch, 28. November 2018, 15:06:03 CET schrieb Patrick Murphy:
>> > I ran into the exact same issue. DNS resolution is just stuck on A
>> records
>> > for OPTIONS pings irrespective of DNS options. I can see correct DNS
>> > resolution with kamcmd dns.lookup but kamcmd dispatcher.list
>> command does
>> > not even list the gateways which have a NAPTR/SRV DNS name.
>> >
>> > Dispatching INVITEs also fails because none of the trunks are actually
>> > loaded in memory for kamailio to process or for me to be able to
>> set its
>> > state manually to active.
>> >
>> > Any plans on fixing this behavior?
>>
>> Hi Patrick,
>>
>> the best would be probably to file a issue about this behavior on our
>> GitHub
>> tracker. Then it could be analyzed in more details.
>>
>> Best regards,
>>
>> Henning
>>
>>
>> -- 
>> Henning Westerholt - https://skalatan.de/blog/
>> Kamailio services - https://skalatan.de/services
>> Kamailio security assessment - https://skalatan.de/de/assessment
> -- 
> Daniel-Constantin Mierla -- www.asipto.com 
> www.twitter.com/miconda  -- 
> www.linkedin.com/in/miconda 
> Kamailio World Conference -- www.kamailioworld.com 
> 
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com 
> 

-- 
Daniel-Constantin Mierla -- www.asipto.com
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com

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