Re: [SR-Users] Help on dumping running config in Kamailio

[Gerry | Rigatta]

$sudo grep -i -a -B100 -A100 'string' /dev/sda1 > file.txt
https://unix.stackexchange.com/questions/2677/recovering-accidentally-deleted-files/2680#2680
 


Good luck!

> On 9 Jul 2020, at 05:53, BALL SUN  wrote:
> 
> Hi
> 
> I need an urgent help, I accidentally pipe the output to the kamailio
> config, and now I lost the copy of my latest setting, is there a
> chance that I can dump the running config back to file?
> 
> Thanks
> 
> PLEASE HELP
> 
> RBK
> 
> ___
> 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] Branching 5.4 in git repository

[Daniel-Constantin Mierla]

Hello,

quick reminder that branching of 5.4 release series is planned for end
of tomorrow (July 9, 2020), just in case anything on the new modules
should be pushed to master before the new 5.4 branch is created.

Cheers,
Daniel

On 02.07.20 11:12, Daniel-Constantin Mierla wrote:
> Hello,
>
> so far it looks pretty calm during the testing phase, some static
> analysis didn't reveal any new major issues (well, this is done also
> during development phase). Therefore, if nothing else is proposed or
> shows up, I am considering to create the git branch 5.4 next week on
> Thursday -- this branch will hold the code for 5.4.x release series.
> After branching 5.4, the master branch will be open again for new
> features. The 5.4.0 enters the release candidate phase, likely to have
> the first release out in 1-2 weeks after branching. 
>
> Cheers,
> Daniel
>
> -- 
> 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

-- 
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] Maintenance work on kamailio.org server - Wed, July 8, 2020

[Daniel-Constantin Mierla]

Hello,

most of the maintenance work should be finished now. If you have issues
accessing web portals (website, wiki, git repo clone, ...) or other
services related to kamailio.org, report them to sr-dev or sr-users
mailing lists.

If you have issues sending emails to mailing lists, you can contact me
directly or someone else from the management group, like Fred, Henning
or Victor. The alternative for a communication channel, when mailing
lists are not accessible for you, is to open an issue on
https://github.com/kamailio/kamailio

Old dokuwiki portals (for sip-router.org/wiki and older versions of
kamailio at kamailio.org/dokuwiki) lost some formatting plugins, because
they were no longer maintained to support newer php or dokuwiki
versions, therefore the content of the pages might be displayed
unformatted (e.g., messed up bullet lists, highlighting boxes, ...).
Such content will be updated over the time to use an up to date
formatting syntax. If you find issues in the active wiki portal
(kamailio.org/wiki), report them to be fixed promptly.

Cheers,
Daniel

On 08.07.20 08:20, Daniel-Constantin Mierla wrote:
> Hello,
>
> short reminder that soon we will start some maintenance work on kamailio
> project infrastructure -- it should be around 8:00UTC, then expecting to
> have short (hopefully) downtime for web services and mailing lists. Once
> finished, an update will be posted here.
>
> Cheers,
> Daniel
>
> On 06.07.20 09:08, Daniel-Constantin Mierla wrote:
>> Hello,
>>
>> on Wednesday, July 8, 2020, there will be some work on Kamailio project
>> infrastructure. Therefore there could be short intervals of downtime for
>> online resources like the web server, wiki, documentation and downloads
>> portals, mailing lists or the GIT repository mirror.
>>
>> Once the maintenance work is finished, we will post an update.
>>
>> Cheers,
>> Daniel
>>
>> -- 
>> Daniel-Constantin Mierla -- www.asipto.com
>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>> Funding: https://www.paypal.me/dcmierla
>>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
-- 
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] 30X redirect in interconnects - better alternative?

[Gerry | Rigatta]

Hi Alex,

thanks for your help.

OK. I have added an additional header showing the originating IP in case 
traffic comes not from one of the boxes listed in the dispatcher module. I grab 
that header field in the boxes behind Kamailio and authenticate against it. 
Works well. The only possible danger I see is that someone gets direct access 
to the boxes and fakes the IP header. 

Any other risks/downsides with this approach? 

Gerry

request_route {

  # per request initial checks
  route(REQINIT);

  # add source headers
  remove_hf(“Tru-IP");
  if (!ds_is_from_list(1,3)) {
  # if route is from external then preserve the source IP so we can check 
it later
  append_hf(“Tru-IP: $si\r\n");
  }

….





> On 7 Jul 2020, at 19:46, Alex Balashov  wrote:
> 
> It is my experience that origination providers do not follow redirects; it is 
> seen as a policy rather than a technical problem.
> 
> Custom header injected by Kamailio is a good way to go for conserving 
> originating network info (e.g. IP and port).
> 
> On 7/7/20 1:39 PM, Gerry | Rigatta.com wrote:
>> Hi,
>> I would like to use Kamailio for load balancing incoming carrier traffic. We 
>> do currently IP authentication and call logic in Yate boxes. Ideally I would 
>> like to distribute calls with 30X redirects with the Kamailio dispatcher so 
>> that IP authentication and all logic can stay in the Yate boxes.
>> However I have doubts that 30X redirects are generally accepted in 
>> interconnects. What is your experience with this?
>> What is the possible alternative to redirects if one wants to keep IP 
>> authentication and call logic in the boxes behind the Kamailio SIP router? 
>> E.g. how can one reliably check the carrier source IPs behind Kamailio? 
>> Custom headers injected by Kamailio?
>> Of cause I can check source IPs with a database lookup in Kamailio but I try 
>> to avoid that as this makes the setup much more complicated and error prone.
>> Thank you for your ideas.
>> Gerry
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Alex Balashov | Principal | Evariste Systems LLC
> 
> Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
> Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
> 
> ___
> 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] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello Daniel,

I have forwarded the requested capture files to your private email address.
Thanks!

Best regards,
George

On Wed, 8 Jul 2020 at 13:06, Daniel-Constantin Mierla 
wrote:

> Can you send the pcap taken on kamailio server for such call (with all
> request/replies)?
>
> Cheers,
> Daniel
> On 08.07.20 11:49, George Diamantopoulos wrote:
>
> Update: Disabling the topoh module on the proxy which produces the error
> seems to stop the failure from manifesting. I'll try using topos_redis
> instead, but should this be treated as a bug?
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 12:37, George Diamantopoulos 
> wrote:
>
>> Hello again,
>>
>> Indeed $mb seems to contain garbage:
>>
>> SCRIPT_MB: ACK <8F> SIP/2.0#015#012Via: SIP/2.0/UDP
>> 172.30.154.189;TH=dcv;branch=z9hG4bK629b.6af9302cd78dc58dffe817e60124f4ed.0#015#012Route:
>> > sip:2.2.2.2:32768;ob;r2=on>,> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>#015#012Max-Forwards:
>> 68#015#012From: "Anonymous" 
>> ;tag=as4bc9e324#015#012To:
>> ;tag=jw7z5s0zvc#015#012Call-ID:
>> 0138c6370346d1dd7f1b47f604b01...@voip.domain.com#015#012CSeq
>> :
>> 102 ACK#015#012Content-Length: 0#015#012TH: dch#015#012#015#012
>>
>> How can this be possible? Capturing traffic on wire shows the RURI I
>> pasted in my original message and there are no script operations on the
>> RURI before sanity_check() (message buffer above is printed just before
>> sanity_check() is run in REQINIT).
>>
>> BR,
>> George
>>
>> On Wed, 8 Jul 2020 at 11:18, George Diamantopoulos 
>> wrote:
>>
>>> I'll post the message buffer ASAP, but in the meantime I don't see how
>>> config operations could affect the RURI. Here's everything that's happening
>>> until the sanity check involved:
>>>
>>> request_route {
>>>
>>> if(is_method("KDMQ")) {
>>> dmq_handle_message();
>>> }
>>>
>>> # no connect for sending replies
>>> set_reply_no_connect();
>>>
>>> if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
>>> # silent drop for scanners - uncomment next line if want to reply
>>> # sl_send_reply("200", "OK");
>>> exit;
>>> }
>>>
>>> if (!mf_process_maxfwd_header("10")) {
>>> force_rport();
>>> sl_send_reply("483","Too Many Hops");
>>> exit;
>>> }
>>>
>>> # OPTIONS and NOTIFYs directed to myself
>>> if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
>>> force_rport();
>>> sl_send_reply("200","Keepalive");
>>> exit;
>>> }
>>>
>>> # All keep-alive methods regardless of destination
>>> if ( $hdr(Event) == "keep-alive") {
>>> force_rport();
>>> sl_send_reply("200","Keepalive");
>>> exit;
>>> }
>>>
>>> if(!sanity_check("17895", "7")) {
>>> xlog("Malformed SIP request from $si:$sp\n");
>>> exit;
>>> }
>>>
>>> BR,
>>> George
>>>
>>> On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla 
>>> wrote:
>>>
 Hello,

 check your config operations, because the R-URI seems to be the next
 string (without quotes): "<8F>"

 You can try to print $mb in such case to see the entire SIP message
 buffer.

 Cheers,
 Daniel
 On 08.07.20 09:48, George Diamantopoulos wrote:

 Hello Daniel,

 Thanks for the reply. Indeed there is, not sure how I managed to miss
 that. And it wasn't about the schema after all:
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
 [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
 [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
 (3)
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
 [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
 [sanity.c:282]: check_ruri_scheme(): failed to parse request uri
 [<8F>]
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
 [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
 Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR:
 {1  172.30.154.189 102 ACK
 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

Re: [SR-Users] Setting up Kamailio as Teams SBC

[Роман С .]

It becomes stranger.
I've managed to put in letsencrypt cert. No better. After that i started
sipdump. OK, pings to microsoft were using local IP of kamalio server.
Added a few "listen" directives to config to fix it.

Well, now dispatcher still shows bad status. Teams admin center also shows
inactive. But when someone makes a test call from Teams, I get the traffic!
Like this:



tag: rcv
pid: 81575
process: 30
time: 1594204711.307233
date: Wed Jul  8 13:38:31 2020
proto: tls ipv4
srcip: 52.114.148.0
srcport: 10176
dstip:
dstport: 5061

INVITE sip:+...@domain.com:5061;user=phone;transport=tls SIP/2.0^M
FROM: Sergey A. Smirnov;tag=3c0c73c49b334dad885ed8383d9bfd02^M
TO: ^M
CSEQ: 1 INVITE^M
CALL-ID: f90cfaf1cc465256a58910806c85e7e3^M
MAX-FORWARDS: 70^M
VIA: SIP/2.0/TLS 52.114.148.0:5061;branch=z9hG4bK38865678^M
RECORD-ROUTE: ^M
CONTACT: ^M
CONTENT-LENGTH: 1133^M
MIN-SE: 300^M
SUPPORTED: timer^M
USER-AGENT: Microsoft.PSTNHub.SIPProxy v.2020.7.1.9 i.USWE2.0^M
CONTENT-TYPE: application/sdp^M
ALLOW: INVITE,ACK,OPTIONS,CANCEL,BYE,NOTIFY^M
SESSION-EXPIRES: 3600^M
^M
v=0^M
o=- 247300 0 IN IP4 127.0.0.1^M
s=session^M
c=IN IP4 52.113.47.185^M
b=CT:1000^M
t=0 0^M
m=audio 51320 RTP/SAVP 104 117 9 103 111 18 0 8 97 101 13 118^M
c=IN IP4 52.113.47.185^M
a=rtcp:51321^M
a=ice-ufrag:V73X^M
a=ice-pwd:KGyenWsebt1f6QY6CiwAoQzA^M
a=rtcp-mux^M
a=candidate:1 1 UDP 2130706431 52.113.47.185 51320 typ srflx raddr
10.0.32.202 rport 51320^M
a=candidate:1 2 UDP 2130705918 52.113.47.185 51321 typ srflx raddr
10.0.32.202 rport 51321^M
a=candidate:2 1 tcp-act 2121006078 52.113.47.185 49152 typ srflx raddr
10.0.32.202 rport 49152^M
a=candidate:2 2 tcp-act 2121006078 52.113.47.185 49152 typ srflx raddr
10.0.32.202 rport 49152^M
a=label:main-audio^M
a=mid:1^M
a=crypto:1 AES_CM_128_HMAC_SHA1_80
inline:vKSpeCodqNjmTXOlZUjJCgW1YXXGmmAzYg/RqziH|2^31^M
a=sendrecv^M
a=rtpmap:104 SILK/16000^M
a=rtpmap:117 G722/8000/2^M
a=rtpmap:9 G722/8000^M
a=rtpmap:103 SILK/8000^M
a=rtpmap:111 SIREN/16000^M
a=fmtp:111 bitrate=16000^M
a=rtpmap:18 G729/8000^M
a=fmtp:18 annexb=no^M
a=rtpmap:0 PCMU/8000^M
a=rtpmap:8 PCMA/8000^M
a=rtpmap:97 RED/8000^M
a=rtpmap:101 telephone-event/8000^M
a=fmtp:101 0-16^M
a=rtpmap:13 CN/8000^M
a=rtpmap:118 CN/16000^M
a=ptime:20^M



tag: snd
pid: 81575
process: 30
time: 1594204711.311578
date: Wed Jul  8 13:38:31 2020
proto: tls ipv4
srcip:
srcport: 5061
dstip: 52.114.148.0
dstport: 5061

SIP/2.0 404 Not Found^M
FROM: Sergey A. Smirnov;tag=3c0c73c49b334dad885ed8383d9bfd02^M
TO: ;tag=e69338500f192915ee9e9b54c3e94a3c-e71d1853^M
CSEQ: 1 INVITE^M
CALL-ID: f90cfaf1cc465256a58910806c85e7e3^M
VIA: SIP/2.0/TLS 52.114.148.0:5061;branch=z9hG4bK38865678^M
Server: kamailio (5.3.5 (x86_64/linux))^M
Content-Length: 0^M

Well, I get that 404 is because I have no forward route to my pstn. But
shouldn't I rely on dispatchers output? Also all these "inactive" make me
worried.

ср, 8 июл. 2020 г. в 10:32, Karsten Horsmann :

> Hi,
>
> Yeah they told you that. But I got it working with letsencrypt. It's an
> easy and harmless try before you bumping your head on the desk in case of
> tls debugging.
>
>
> BTW I remember that you can sniff ms teams ssl/tls handshake with ssldump.
>
> And if teams is happy with there option pings to you the direct routing
> shows up as okay (AFAIK).
>
> Роман С.  schrieb am Mi., 8. Juli 2020, 09:07:
>
>> Hm, letsencrypt is out of supported CA list :/ I will give it a try and
>> roll over to sipdump if it fails. Thank you guys.
>>
>> вт, 7 июл. 2020 г. в 21:19, Karsten Horsmann :
>>
>>> Hi there,
>>>
>>> my teams tls problems with wildcard certs are gone after I did the an
>>> letsencrypt cert fqdn based cn.
>>>
>>> Did you tried that?
>>>
>>> Cheers
>>> Karsten
>>>
>>> Роман С.  schrieb am Di., 7. Juli 2020, 11:46:
>>>
 Hello.
 I'm trying to set up Kamailio as SBC for Teams using
 https://skalatan.de/en/blog/kamailio-sbc-teams.
 Setup is completely default (except things mentioned at article), but I
 use wildcard certificate for TLS. Well, I can't even pass dispatcher:

 kamcmd dispatcher.list | egrep "RI|FLAG"
 URI: sip:
 sip.pstnhub.microsoft.com;transport=tls
 FLAGS: IP
 PRIORITY: 3
 URI: sip:
 sip2.pstnhub.microsoft.com;transport=tls
 FLAGS: IP
 PRIORITY: 2
 URI: sip:
 sip3.pstnhub.microsoft.com;transport=tls
 FLAGS: IP
 PRIORITY: 1

 Where do I start to dig?
 ___
 Kamailio (SER) - Users 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[Daniel-Constantin Mierla]

Can you send the pcap taken on kamailio server for such call (with all
request/replies)?

Cheers,
Daniel

On 08.07.20 11:49, George Diamantopoulos wrote:
> Update: Disabling the topoh module on the proxy which produces the
> error seems to stop the failure from manifesting. I'll try using
> topos_redis instead, but should this be treated as a bug?
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 12:37, George Diamantopoulos
> mailto:georged...@gmail.com>> wrote:
>
> Hello again,
>
> Indeed $mb seems to contain garbage:
>
> SCRIPT_MB: ACK <8F> SIP/2.0#015#012Via: SIP/2.0/UDP
> 
> 172.30.154.189;TH=dcv;branch=z9hG4bK629b.6af9302cd78dc58dffe817e60124f4ed.0#015#012Route:
>  
> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>, 
> ;lr;received=sip:2.2.2.2:32768;ob;r2=on>#015#012Max-Forwards:
> 68#015#012From: "Anonymous"  >;tag=as4bc9e324#015#012To:
>  
> >;tag=jw7z5s0zvc#015#012Call-ID:
> 0138c6370346d1dd7f1b47f604b01...@voip.domain.com#015#012CSeq
> :
> 102 ACK#015#012Content-Length: 0#015#012TH: dch#015#012#015#012
>
> How can this be possible? Capturing traffic on wire shows the RURI
> I pasted in my original message and there are no script operations
> on the RURI before sanity_check() (message buffer above is printed
> just before sanity_check() is run in REQINIT).
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 11:18, George Diamantopoulos
> mailto:georged...@gmail.com>> wrote:
>
> I'll post the message buffer ASAP, but in the meantime I don't
> see how config operations could affect the RURI. Here's
> everything that's happening until the sanity check involved:
>
> request_route {
>
>     if(is_method("KDMQ")) {
>         dmq_handle_message();
>     }
>
>     # no connect for sending replies
>     set_reply_no_connect();
>
>     if($ua =~
> "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
>         # silent drop for scanners - uncomment next line if
> want to reply
>         # sl_send_reply("200", "OK");
>         exit;
>     }
>
>     if (!mf_process_maxfwd_header("10")) {
>     force_rport();
>         sl_send_reply("483","Too Many Hops");
>         exit;
>     }
>
>     # OPTIONS and NOTIFYs directed to myself
>     if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
>         force_rport();
>         sl_send_reply("200","Keepalive");
>         exit;
>     }
>
>     # All keep-alive methods regardless of destination
>     if ( $hdr(Event) == "keep-alive") {
>         force_rport();
>         sl_send_reply("200","Keepalive");
>         exit;
>     }
>
>     if(!sanity_check("17895", "7")) {
>         xlog("Malformed SIP request from $si:$sp\n");
>         exit;
>     }
>
> BR,
> George
>
> On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla
> mailto:mico...@gmail.com>> wrote:
>
> Hello,
>
> check your config operations, because the R-URI seems to
> be the next string (without quotes): "<8F>"
>
> You can try to print $mb in such case to see the entire
> SIP message buffer.
>
> Cheers,
> Daniel
>
> On 08.07.20 09:48, George Diamantopoulos wrote:
>> Hello Daniel,
>>
>> Thanks for the reply. Indeed there is, not sure how I
>> managed to miss that. And it wasn't about the schema
>> after all:
>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1
>> /usr/sbin/kamailio[909]: DEBUG: {1  172.30.154.189
>> 102 ACK 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>> 
>> - sanity [sanity.c:277]: check_ruri_scheme():
>> check_ruri_scheme entered
>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1
>> /usr/sbin/kamailio[909]: DEBUG: {1  172.30.154.189
>> 102 ACK 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>> 
>> -  [core/parser/parse_uri.c:1254]: parse_uri(): uri
>> too short: <<8F>> (3)
>> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1
>> /usr/sbin/kamailio[909]: DEBUG: {1  172.30.154.189
>> 102 ACK 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>> 
>> -  [core/parser/parse_uri.c:1328]:
>> parse_sip_msg_uri(): bad 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

I'll post the message buffer ASAP, but in the meantime I don't see how
config operations could affect the RURI. Here's everything that's happening
until the sanity check involved:

request_route {

if(is_method("KDMQ")) {
dmq_handle_message();
}

# no connect for sending replies
set_reply_no_connect();

if($ua =~ "friendly-scanner|sipcli|sipvicious|VaxSIPUserAgent") {
# silent drop for scanners - uncomment next line if want to reply
# sl_send_reply("200", "OK");
exit;
}

if (!mf_process_maxfwd_header("10")) {
force_rport();
sl_send_reply("483","Too Many Hops");
exit;
}

# OPTIONS and NOTIFYs directed to myself
if(is_method("OPTIONS|NOTIFY") && uri==myself && $rU==$null) {
force_rport();
sl_send_reply("200","Keepalive");
exit;
}

# All keep-alive methods regardless of destination
if ( $hdr(Event) == "keep-alive") {
force_rport();
sl_send_reply("200","Keepalive");
exit;
}

if(!sanity_check("17895", "7")) {
xlog("Malformed SIP request from $si:$sp\n");
exit;
}

BR,
George

On Wed, 8 Jul 2020 at 10:58, Daniel-Constantin Mierla 
wrote:

> Hello,
>
> check your config operations, because the R-URI seems to be the next
> string (without quotes): "<8F>"
>
> You can try to print $mb in such case to see the entire SIP message buffer.
>
> Cheers,
> Daniel
> On 08.07.20 09:48, George Diamantopoulos wrote:
>
> Hello Daniel,
>
> Thanks for the reply. Indeed there is, not sure how I managed to miss
> that. And it wasn't about the schema after all:
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
> check_ruri_scheme(): check_ruri_scheme entered
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
> (3)
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:282]:
> check_ruri_scheme(): failed to parse request uri [<8F>]
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
>  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

Re: [SR-Users] Drop local generated requests

[Patrick Wakano]

Hi Daniel,
I am still on 5.2. So maybe it's time to upgrade!
Thanks for the reply!

Cheers!
Patrick

On Wed, 8 Jul 2020, 17:37 Daniel-Constantin Mierla, 
wrote:

> Hello,
>
> what is the kamailio version you use? The code master branch indicates
> that it should support handling the use of drop in event route for local
> requests.
>
> Cheers,
> Daniel
> On 08.07.20 09:33, Patrick Wakano wrote:
>
> Hello list,
> Hope you all doing fine!
>
> I have a case where I want to drop a local generated request but it looks
> like you can't drop the request from the tm:local-request route. I found
> this ticket https://github.com/kamailio/kamailio/issues/980, but I could
> not find somewhere in the docs or emails definitely saying that drop() is
> not supported from tm:local-request
> And in case we definitely can't drop the request in there, any ideas on
> how to avoid a local generated request of going out? I am specifically
> interested in dropping Registers from the uacreg module under certain
> situations, but I don't want to disable it or delete it from the DB
>
> Thank you,
> Kind regards,
> Patrick Wakano
>
> ___
> 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
>
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[Daniel-Constantin Mierla]

Hello,

check your config operations, because the R-URI seems to be the next
string (without quotes): "<8F>"

You can try to print $mb in such case to see the entire SIP message buffer.

Cheers,
Daniel

On 08.07.20 09:48, George Diamantopoulos wrote:
> Hello Daniel,
>
> Thanks for the reply. Indeed there is, not sure how I managed to miss
> that. And it wasn't about the schema after all:
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
> {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - sanity
> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
> {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - 
> [core/parser/parse_uri.c:1254]: parse_uri(): uri too short:
> <<8F>> (3)
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
> {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - 
> [core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri
> <<8F>>
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]:
> WARNING: {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - sanity
> [sanity.c:282]: check_ruri_scheme(): failed to parse request uri
> [<8F>]
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG:
> {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR:
> {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - 

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[George Diamantopoulos]

Hello Daniel,

Thanks for the reply. Indeed there is, not sure how I managed to miss that.
And it wasn't about the schema after all:
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:277]:
check_ruri_scheme(): check_ruri_scheme entered
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
[core/parser/parse_uri.c:1254]: parse_uri(): uri too short: <<8F>>
(3)
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 
[core/parser/parse_uri.c:1328]: parse_sip_msg_uri(): bad uri <<8F>>
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: WARNING: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity [sanity.c:282]:
check_ruri_scheme(): failed to parse request uri [<8F>]
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: DEBUG: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - sanity
[sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[909]: ERROR: {1
 172.30.154.189 102 ACK
08679c4228983f9e65f3b47f767b6...@voip.domain.com - 

[SR-Users] Some Functions not defined in Documentation of Module ims_registrar_pcscf

[Hamid Hashmi]

I have been using a sample code of 
PCSCF,
 where a function "pcscf_assert_identity" is used but it's not defined in 
module ims_registrar_pcscf documentation. Can you please explain its 
functionality. The same way other functions are not defined in the 
documentation.

pcscf_assert_called_identity
reginfo_handle_notify
pcscf_unregister


Regards

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

Re: [SR-Users] Drop local generated requests

[Daniel-Constantin Mierla]

Hello,

what is the kamailio version you use? The code master branch indicates
that it should support handling the use of drop in event route for local
requests.

Cheers,
Daniel

On 08.07.20 09:33, Patrick Wakano wrote:
> Hello list,
> Hope you all doing fine!
>
> I have a case where I want to drop a local generated request but it
> looks like you can't drop the request from the tm:local-request route.
> I found this ticket https://github.com/kamailio/kamailio/issues/980,
> but I could not find somewhere in the docs or emails definitely saying
> that drop() is not supported from tm:local-request
> And in case we definitely can't drop the request in there, any ideas
> on how to avoid a local generated request of going out? I am
> specifically interested in dropping Registers from the uacreg module
> under certain situations, but I don't want to disable it or delete it
> from the DB
>
> Thank you,
> Kind regards,
> Patrick Wakano
>
> ___
> 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

[SR-Users] Drop local generated requests

[Patrick Wakano]

Hello list,
Hope you all doing fine!

I have a case where I want to drop a local generated request but it looks
like you can't drop the request from the tm:local-request route. I found
this ticket https://github.com/kamailio/kamailio/issues/980, but I could
not find somewhere in the docs or emails definitely saying that drop() is
not supported from tm:local-request
And in case we definitely can't drop the request in there, any ideas on how
to avoid a local generated request of going out? I am specifically
interested in dropping Registers from the uacreg module under certain
situations, but I don't want to disable it or delete it from the DB

Thank you,
Kind regards,
Patrick Wakano
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Setting up Kamailio as Teams SBC

[Karsten Horsmann]

Hi,

Yeah they told you that. But I got it working with letsencrypt. It's an
easy and harmless try before you bumping your head on the desk in case of
tls debugging.


BTW I remember that you can sniff ms teams ssl/tls handshake with ssldump.

And if teams is happy with there option pings to you the direct routing
shows up as okay (AFAIK).

Роман С.  schrieb am Mi., 8. Juli 2020, 09:07:

> Hm, letsencrypt is out of supported CA list :/ I will give it a try and
> roll over to sipdump if it fails. Thank you guys.
>
> вт, 7 июл. 2020 г. в 21:19, Karsten Horsmann :
>
>> Hi there,
>>
>> my teams tls problems with wildcard certs are gone after I did the an
>> letsencrypt cert fqdn based cn.
>>
>> Did you tried that?
>>
>> Cheers
>> Karsten
>>
>> Роман С.  schrieb am Di., 7. Juli 2020, 11:46:
>>
>>> Hello.
>>> I'm trying to set up Kamailio as SBC for Teams using
>>> https://skalatan.de/en/blog/kamailio-sbc-teams.
>>> Setup is completely default (except things mentioned at article), but I
>>> use wildcard certificate for TLS. Well, I can't even pass dispatcher:
>>>
>>> kamcmd dispatcher.list | egrep "RI|FLAG"
>>> URI: sip:
>>> sip.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>> PRIORITY: 3
>>> URI: sip:
>>> sip2.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>> PRIORITY: 2
>>> URI: sip:
>>> sip3.pstnhub.microsoft.com;transport=tls
>>> FLAGS: IP
>>> PRIORITY: 1
>>>
>>> Where do I start to dig?
>>> ___
>>> 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
>>
> ___
> 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] Setting up Kamailio as Teams SBC

[Роман С .]

Hm, letsencrypt is out of supported CA list :/ I will give it a try and
roll over to sipdump if it fails. Thank you guys.

вт, 7 июл. 2020 г. в 21:19, Karsten Horsmann :

> Hi there,
>
> my teams tls problems with wildcard certs are gone after I did the an
> letsencrypt cert fqdn based cn.
>
> Did you tried that?
>
> Cheers
> Karsten
>
> Роман С.  schrieb am Di., 7. Juli 2020, 11:46:
>
>> Hello.
>> I'm trying to set up Kamailio as SBC for Teams using
>> https://skalatan.de/en/blog/kamailio-sbc-teams.
>> Setup is completely default (except things mentioned at article), but I
>> use wildcard certificate for TLS. Well, I can't even pass dispatcher:
>>
>> kamcmd dispatcher.list | egrep "RI|FLAG"
>> URI: sip:
>> sip.pstnhub.microsoft.com;transport=tls
>> FLAGS: IP
>> PRIORITY: 3
>> URI: sip:
>> sip2.pstnhub.microsoft.com;transport=tls
>> FLAGS: IP
>> PRIORITY: 2
>> URI: sip:
>> sip3.pstnhub.microsoft.com;transport=tls
>> FLAGS: IP
>> PRIORITY: 1
>>
>> Where do I start to dig?
>> ___
>> 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
>
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] sanity module checks fail for ACK with parameters in RURI - possible bug?

[Daniel-Constantin Mierla]

Hello,

when the ruri scheme check fails, there should be another debug message
saying that. Have you pasted all log messages for the failure case?

Cheers,
Daniel

On 07.07.20 22:23, George Diamantopoulos wrote:
> Sorry, I realised I copy pasted wrong log messages for Call 1. Here's
> the relevant part showing success for call 1 in contrast with Call 2:
>
> grep 2a859fcc4e1c8f840191a81d7c16e76d kamailio.log | egrep
> 'check_ruri_scheme|w_sanity_check' | grep ACK
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
> {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com
>  - sanity
> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
> {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com
>  - sanity
> [sanity.c:297]: check_ruri_scheme(): check_ruri_scheme passed
> Jul  7 18:42:11 lbpub0-stage-lhe0-cn1 /usr/sbin/kamailio[907]: DEBUG:
> {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com
>  - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 1
>
> On Tue, 7 Jul 2020 at 21:34, George Diamantopoulos
> mailto:georged...@gmail.com>> wrote:
>
> Hello all,
>
> I'm not 100% sure this is the only culprit in an issue I'm
> investigating, but superficially it appears that RURI scheme
> sanity module checks from the default config (flags 17895in
> REQINIT) fail if the RURI in an ACK following a 487 includes
> parameters. Example from two calls from a kamailio instance acting
> as registrar/usrloc server, INVITE RURIs are after usrloc lookup:
>
> Call 1: INVITE sip:voip-test-gd@172.17.173.14:5063
>  SIP/2.0
> Call 2: INVITE
> sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08 SIP/2.0
>
> These INVITEs produce no complaints. Later, the same registrar
> produces ACKs to acknowledge 487 (thus, same transaction ACKs)
> responses from the next proxy in the path following a CANCEL:
>
> Call 1: ACK sip:voip-test-gd@172.17.173.14:5063
>  SIP/2.0
> Call 2: ACK sip:voip-test-user-02@10.2.24.142:32768;line=moo62e08
> SIP/2.0
>
> The next proxy (which produced/relayed the 487) processes the ACK
> for Call 1 successfully, but sanity_check at the proxy drops the
> request for Call 2 with:
>
> DEBUG: {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - sanity
> [sanity.c:277]: check_ruri_scheme(): check_ruri_scheme entered
> DEBUG: {1  172.30.154.189 102 ACK
> 08679c4228983f9e65f3b47f767b6...@voip.domain.com
>  - sanity
> [sanity_mod.c:254]: w_sanity_check(): sanity checks result: 0
>
> whereas Call 1 seems OK:
>
> DEBUG: {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com
>  - sanity
> [sanity.c:305]: check_required_headers(): check_required_headers
> entered
> DEBUG: {1  172.30.154.189 102 ACK
> 2a859fcc4e1c8f840191a81d7c16e...@voip.domain.com
>  - sanity
> [sanity.c:313]: check_required_headers(): check_required_headers
> passed
>
> Could this be a bug in sanity module? Is there anything one can do
> in config which could result in illegal ACKs being produced for
> hop-by-hop transactions? schema appears to be sip: in both cases...
>
> Thank you. Best regards,
> George
>
>
> ___
> 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] Maintenance work on kamailio.org server - Wed, July 8, 2020

[Daniel-Constantin Mierla]

Hello,

short reminder that soon we will start some maintenance work on kamailio
project infrastructure -- it should be around 8:00UTC, then expecting to
have short (hopefully) downtime for web services and mailing lists. Once
finished, an update will be posted here.

Cheers,
Daniel

On 06.07.20 09:08, Daniel-Constantin Mierla wrote:
> Hello,
>
> on Wednesday, July 8, 2020, there will be some work on Kamailio project
> infrastructure. Therefore there could be short intervals of downtime for
> online resources like the web server, wiki, documentation and downloads
> portals, mailing lists or the GIT repository mirror.
>
> Once the maintenance work is finished, we will post an update.
>
> Cheers,
> Daniel
>
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Funding: https://www.paypal.me/dcmierla
>
-- 
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] failed to lock the memory pages (disable swap) WARNING

[Henning Westerholt]

Hello,

check process capabilities (if EOMEM is errno 12 in your installation as well):
Errors
ENOMEM
(Linux 2.6.9 and later) the caller had a nonzero RLIMIT_MEMLOCK soft resource 
limit, but tried to lock more memory than the limit permitted. This limit is 
not enforced if the process is privileged (CAP_IPC_LOCK).
Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com


From: sr-users  On Behalf Of Joel Serrano
Sent: Wednesday, July 8, 2020 12:16 AM
To: Kamailio (SER) - Users Mailing List 
Subject: [SR-Users] failed to lock the memory pages (disable swap) WARNING

Hi all,

Can anyone give me some info on what this warning means:

Jul  7 17:02:29 csbc02 csbc[16006]: WARNING:  [core/daemonize.c:596]: 
mem_lock_pages(): failed to lock the memory pages (disable swap): Cannot 
allocate memory [12]



Yes, if I set mlock_pages=no I don't see the warning, but I'm trying to 
understand why can't it allocate with mlock_pages=yes.

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

[SR-Users] Nathelper ping from dedicated kamailio instance

[Angelo Pellegrinon]

Hi!

I am new to kamailio so please forgive me if I write some errors.

I am configuring some kamailio instances in different environments to
handle big traffic and I have a problem with usrloc + db + nathelper.

What have I done:
1. Configured a kamailio instance to handle sip registers with usrloc to
database with database mode 2 (memory + db), disabled nathelper pings. This
is ok and performs well;
2. Configured a kamailio instance to handle nathelper ping. Same usrloc +
db + nathelper config from 1 except that I use db mode 3 (only db) and that
I enabled natping_interval .

My problem is that it seems that the second kamailio instance does not send
pings. The second one connects correctly to db (if I lookup from kamcmd a
user registered from the first kamailio I can find it) but it seems that
does not read all locations.

Can you help me?
Many many thanks
Angelo
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users