date:20171107

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

2017-11-07 Thread Daniel-Constantin Mierla

Hello,


On 08.11.17 07:23, David Escartín wrote:
> Hello Daniel
>
> sorry about that.
no worries, it was more for the future to keep a conversation in a
single place, if it is not some generic announcement or similar ...
>
> yes, if we make a restart, after a while (not fixed time some times
> minutes, some times 2 hours),  we start to see those types of messages

Do you know if all these dialogs were active at the last restart? Or new
dialogs after restart expose the same issue?

Cheers,
Daniel

>
> i attach you the sip messages of the call of the logs in the first mail
> the INVITE receiver is the Kamailio instance.
>
> thanks a lot and sorry again about the 2 email accounts
> david
>
>
> El 07/11/17 a las 18:40, Daniel-Constantin Mierla escribió:
>> Hello,
>>
>> first: no need to post on both sr-users and sr-dev, it makes it hard to
>> follow up if people answer on different lists.
>>
>> If it is about a stable release, you can use the sr-users, if it is
>> about devel version, you can use sr-dev. Of course, if it is a bug, you
>> can open an issue on:
>>
>>    - https://github.com/kamailio/kamailio/issues
>>
>> Now, back to the message itself -- have you done a recent restart before
>> this situation is exposed? Do you capture the traffic in your network?
>> If yes, can you extract the sip packets for one of these calls and send
>> them over to me?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 07.11.17 16:30, David Escartín wrote:
>>> hello all
>>>
>>> recently we are seeing some weird messages handling with dialogs in
>>> Kamailio version 5.0
>>> we sometimes are seeing messages like
>>> /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
>>> [dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old
>>> (0x7fa65445c850 ref 3)
>>> /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
>>> [dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old
>>> (0x7fa652d57110 ref 1)
>>>
>>> we increased the debug description adding some lines to the dialog
>>> module code so we could track the calls of the calls that these
>>> messages belong to, and we could see that those messages appeared in
>>> calls just released at that moment, for example:
>>>
>>> <134>Nov  4 11:21:38 localhost
>>> /usr/local/kamailio/sbin/kamailio[4108]: INFO: mad-localhost-1 Call
>>> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Creating dialog
>>> [8043:21772] with hash id 21772 and hash entry 8043
>>> <134>Nov  4 11:21:38 localhost
>>> /usr/local/kamailio/sbin/kamailio[4106]: INFO: mad-localhost-1 Call
>>> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 100, 6610
>>> <134>Nov  4 11:21:39 localhost
>>> /usr/local/kamailio/sbin/kamailio[4111]: INFO: mad-localhost-1 Call
>>> 97980 / Call-ID 1409565771_82382809@195.219.240.46: CANCEL received in
>>> A-Leg, relaying downstream
>>> <134>Nov  4 11:21:39 localhost
>>> /usr/local/kamailio/sbin/kamailio[4112]: INFO: mad-localhost-1 Call
>>> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 487, 6610
>>> <133>Nov  4 11:21:39 localhost
>>> /usr/local/kamailio/sbin/kamailio[4139]: NOTICE: dialog
>>> [dlg_hash.c:251]: dlg_clean_run(): dialog in delete state is too old
>>> (0x7fa0c02a6870 ref 3) with callid '1409565771_82382809@195.219.240.46'
>>> <129>Nov  4 11:21:39 mad-proxy-inout-1
>>> /usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog
>>> [dlg_handlers.c:1715]: dlg_run_event_route(): after event route -
>>> dialog not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid
>>> '1409565771_82382809@195.219.240.46'
>>>
>>> we printed the dialog id and entry hash values and we can see there
>>> are no other calls creating same values in the previous hours, or
>>> using same memory allocation, or same callid, so it seems like there
>>> was some kind of strange issue with the dialog timers¿?
>>> By the way, this is happening only few times (80-100 times) a day
>>> having many thousands of calls, so it's quite difficult for us to
>>> duplicate, we couldn't do it until now.
>>> We also tried to use the timer_procs 0 or 1 to use a different proc
>>> timer but seems the issue happens in both scenarios.
>>>
>>> The configuration change we made and seems it was done when these
>>> messages started to appear is to use dialog event_route when ended and
>>> failed to do some stuff there managing some dialog variables.
>>> Does ti make any sense that attempting to use those variables could
>>> cause these behaviour?
>>> Do you have any idea about it could be or how we can check it deeper?
>>>
>>> thanks a lot and regards
>>> david escartin
>>>
>>> ___
>>> Kamailio (SER) - Users Mailing List
>>> sr-users@lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

2017-11-07 Thread David Escartín


Hello Daniel

sorry about that.

yes, if we make a restart, after a while (not fixed time some times 
minutes, some times 2 hours),  we start to see those types of messages


i attach you the sip messages of the call of the logs in the first mail
the INVITE receiver is the Kamailio instance.

thanks a lot and sorry again about the 2 email accounts
david


El 07/11/17 a las 18:40, Daniel-Constantin Mierla escribió:

Hello,

first: no need to post on both sr-users and sr-dev, it makes it hard to
follow up if people answer on different lists.

If it is about a stable release, you can use the sr-users, if it is
about devel version, you can use sr-dev. Of course, if it is a bug, you
can open an issue on:

   - https://github.com/kamailio/kamailio/issues

Now, back to the message itself -- have you done a recent restart before
this situation is exposed? Do you capture the traffic in your network?
If yes, can you extract the sip packets for one of these calls and send
them over to me?

Cheers,
Daniel


On 07.11.17 16:30, David Escartín wrote:

hello all

recently we are seeing some weird messages handling with dialogs in
Kamailio version 5.0
we sometimes are seeing messages like
/usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
[dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old
(0x7fa65445c850 ref 3)
/usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
[dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old
(0x7fa652d57110 ref 1)

we increased the debug description adding some lines to the dialog
module code so we could track the calls of the calls that these
messages belong to, and we could see that those messages appeared in
calls just released at that moment, for example:

<134>Nov  4 11:21:38 localhost
/usr/local/kamailio/sbin/kamailio[4108]: INFO: mad-localhost-1 Call
97980 / Call-ID 1409565771_82382809@195.219.240.46: Creating dialog
[8043:21772] with hash id 21772 and hash entry 8043
<134>Nov  4 11:21:38 localhost
/usr/local/kamailio/sbin/kamailio[4106]: INFO: mad-localhost-1 Call
97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 100, 6610
<134>Nov  4 11:21:39 localhost
/usr/local/kamailio/sbin/kamailio[4111]: INFO: mad-localhost-1 Call
97980 / Call-ID 1409565771_82382809@195.219.240.46: CANCEL received in
A-Leg, relaying downstream
<134>Nov  4 11:21:39 localhost
/usr/local/kamailio/sbin/kamailio[4112]: INFO: mad-localhost-1 Call
97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 487, 6610
<133>Nov  4 11:21:39 localhost
/usr/local/kamailio/sbin/kamailio[4139]: NOTICE: dialog
[dlg_hash.c:251]: dlg_clean_run(): dialog in delete state is too old
(0x7fa0c02a6870 ref 3) with callid '1409565771_82382809@195.219.240.46'
<129>Nov  4 11:21:39 mad-proxy-inout-1
/usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog
[dlg_handlers.c:1715]: dlg_run_event_route(): after event route -
dialog not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid
'1409565771_82382809@195.219.240.46'

we printed the dialog id and entry hash values and we can see there
are no other calls creating same values in the previous hours, or
using same memory allocation, or same callid, so it seems like there
was some kind of strange issue with the dialog timers¿?
By the way, this is happening only few times (80-100 times) a day
having many thousands of calls, so it's quite difficult for us to
duplicate, we couldn't do it until now.
We also tried to use the timer_procs 0 or 1 to use a different proc
timer but seems the issue happens in both scenarios.

The configuration change we made and seems it was done when these
messages started to appear is to use dialog event_route when ended and
failed to do some stuff there managing some dialog variables.
Does ti make any sense that attempting to use those variables could
cause these behaviour?
Do you have any idea about it could be or how we can check it deeper?

thanks a lot and regards
david escartin

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




HOMER_CID_1409565771_82382809@195.219.240.46.pcap
Description: application/vnd.tcpdump.pcap
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

2017-11-07 Thread Daniel-Constantin Mierla

Hello,

first: no need to post on both sr-users and sr-dev, it makes it hard to
follow up if people answer on different lists.

If it is about a stable release, you can use the sr-users, if it is
about devel version, you can use sr-dev. Of course, if it is a bug, you
can open an issue on:

  - https://github.com/kamailio/kamailio/issues

Now, back to the message itself -- have you done a recent restart before
this situation is exposed? Do you capture the traffic in your network?
If yes, can you extract the sip packets for one of these calls and send
them over to me?

Cheers,
Daniel


On 07.11.17 16:30, David Escartín wrote:
> hello all
>
> recently we are seeing some weird messages handling with dialogs in
> Kamailio version 5.0
> we sometimes are seeing messages like
> /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
> [dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old
> (0x7fa65445c850 ref 3)
> /usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog
> [dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old
> (0x7fa652d57110 ref 1)
>
> we increased the debug description adding some lines to the dialog
> module code so we could track the calls of the calls that these
> messages belong to, and we could see that those messages appeared in
> calls just released at that moment, for example:
>
> <134>Nov  4 11:21:38 localhost
> /usr/local/kamailio/sbin/kamailio[4108]: INFO: mad-localhost-1 Call
> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Creating dialog
> [8043:21772] with hash id 21772 and hash entry 8043
> <134>Nov  4 11:21:38 localhost
> /usr/local/kamailio/sbin/kamailio[4106]: INFO: mad-localhost-1 Call
> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 100, 6610
> <134>Nov  4 11:21:39 localhost
> /usr/local/kamailio/sbin/kamailio[4111]: INFO: mad-localhost-1 Call
> 97980 / Call-ID 1409565771_82382809@195.219.240.46: CANCEL received in
> A-Leg, relaying downstream
> <134>Nov  4 11:21:39 localhost
> /usr/local/kamailio/sbin/kamailio[4112]: INFO: mad-localhost-1 Call
> 97980 / Call-ID 1409565771_82382809@195.219.240.46: Status 487, 6610
> <133>Nov  4 11:21:39 localhost
> /usr/local/kamailio/sbin/kamailio[4139]: NOTICE: dialog
> [dlg_hash.c:251]: dlg_clean_run(): dialog in delete state is too old
> (0x7fa0c02a6870 ref 3) with callid '1409565771_82382809@195.219.240.46'
> <129>Nov  4 11:21:39 mad-proxy-inout-1
> /usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog
> [dlg_handlers.c:1715]: dlg_run_event_route(): after event route -
> dialog not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid
> '1409565771_82382809@195.219.240.46'
>
> we printed the dialog id and entry hash values and we can see there
> are no other calls creating same values in the previous hours, or
> using same memory allocation, or same callid, so it seems like there
> was some kind of strange issue with the dialog timers¿?
> By the way, this is happening only few times (80-100 times) a day
> having many thousands of calls, so it's quite difficult for us to
> duplicate, we couldn't do it until now.
> We also tried to use the timer_procs 0 or 1 to use a different proc
> timer but seems the issue happens in both scenarios.
>
> The configuration change we made and seems it was done when these
> messages started to appear is to use dialog event_route when ended and
> failed to do some stuff there managing some dialog variables.
> Does ti make any sense that attempting to use those variables could
> cause these behaviour?
> Do you have any idea about it could be or how we can check it deeper?
>
> thanks a lot and regards
> david escartin
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


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

Re: [SR-Users] authenticating to mongodb fails

2017-11-07 Thread hdssdsdsdsfsdf hdssdsdsdsfsdf

Thanks for looking into this. I set debug=3 which gives the following debug 
messages. I included the mongod messages, which show a connection and end, but 
no succesful or failed authentication.

nov  7 15:45:21 kamailio: INFO:  [sctp_core.c:75]: 
sctp_core_check_support(): SCTP API not enabled - if you want to use it, load 
sctp module
Nov  7 15:45:22 kamailio: WARNING:  [socket_info.c:1303]: fix_hostname(): 
could not rev. resolve 
Nov  7 15:45:22 /opt/kamailio/sbin/kamailio[8905]: INFO: rr 
[../outbound/api.h:54]: ob_load_api(): unable to import bind_ob - maybe module 
is not loaded
Nov  7 15:45:22 /opt/kamailio/sbin/kamailio[8905]: INFO: rr [rr_mod.c:174]: 
mod_init(): outbound module not available
Nov  7 15:45:22 /opt/kamailio/sbin/kamailio[8905]: INFO: usrloc [hslot.c:51]: 
ul_init_locks(): locks array size 1024
Nov  7 15:45:22 /opt/kamailio/sbin/kamailio[8905]: INFO: auth [auth_mod.c:333]: 
mod_init(): auth: qop set, but nonce-count (nc_enabled) support disabled
Nov  7 15:45:22 mongod.27017[8038]: [thread1] connection accepted from 
127.0.0.1:40737 #20 (2 connections now open)
Nov  7 15:45:22 /opt/kamailio/sbin/kamailio[8905]: INFO:  
[sctp_core.c:53]: sctp_core_destroy(): SCTP API not initialized
Nov  7 15:45:22 mongod.27017[8038]: [conn20] end connection 127.0.0.1:40737 (2 
connections now open)

> Sent: Tuesday, November 07, 2017 at 3:38 PM
> From: "Daniel-Constantin Mierla" 
> To: "Kamailio (SER) - Users Mailing List" , 
> "hdssdsdsdsfsdf hdssdsdsdsfsdf" 
> Subject: Re: [SR-Users] authenticating to mongodb fails
>
> Can you set debug=3 in kamailio.cfg and then look at debug messages to
> see there is some hint about what happens?
> 
> Cheers,
> Daniel
> 
> 
> On 07.11.17 15:11, hdssdsdsdsfsdf hdssdsdsdsfsdf wrote:
> > When I connect using mongo, the credentials work:
> >
> > $ mongo kamailio -u "kam" -p "kam"
> > MongoDB shell version v3.4.9
> > connecting to: mongodb://127.0.0.1:27017/kamailio
> > MongoDB server version: 3.4.9
> >> db.subscriber.find()
> > { "_id" : ObjectI ...
> >
> > But when I use the following DBURL in kamailio.cfg, kamailio fails to even 
> > login to mongo:
> >
> > #!define DBURL "mongodb://kam:kam@localhost/kamailio"
> >
> > If I disable mongodb authentication, kamailio starts up just fine again. 
> > Any idea what's going wrong here?
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
> Kamailio World Conference - www.kamailioworld.com
> 
> 

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

[SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

2017-11-07 Thread David Escartín


hello all

recently we are seeing some weird messages handling with dialogs in 
Kamailio version 5.0

we sometimes are seeing messages like
/usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog 
[dlg_hash.c:249]: dlg_clean_run(): dialog in delete state is too old 
(0x7fa65445c850 ref 3)
/usr/local/kamailio/sbin/kamailio[15372]: NOTICE: dialog 
[dlg_hash.c:235]: dlg_clean_run(): dialog in early state is too old 
(0x7fa652d57110 ref 1)


we increased the debug description adding some lines to the dialog 
module code so we could track the calls of the calls that these messages 
belong to, and we could see that those messages appeared in calls just 
released at that moment, for example:


<134>Nov  4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4108]: 
INFO: mad-localhost-1 Call 97980 / Call-ID 
1409565771_82382809@195.219.240.46: Creating dialog [8043:21772] with 
hash id 21772 and hash entry 8043
<134>Nov  4 11:21:38 localhost /usr/local/kamailio/sbin/kamailio[4106]: 
INFO: mad-localhost-1 Call 97980 / Call-ID 
1409565771_82382809@195.219.240.46: Status 100, 6610
<134>Nov  4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4111]: 
INFO: mad-localhost-1 Call 97980 / Call-ID 
1409565771_82382809@195.219.240.46: CANCEL received in A-Leg, relaying 
downstream
<134>Nov  4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4112]: 
INFO: mad-localhost-1 Call 97980 / Call-ID 
1409565771_82382809@195.219.240.46: Status 487, 6610
<133>Nov  4 11:21:39 localhost /usr/local/kamailio/sbin/kamailio[4139]: 
NOTICE: dialog [dlg_hash.c:251]: dlg_clean_run(): dialog in delete state 
is too old (0x7fa0c02a6870 ref 3) with callid 
'1409565771_82382809@195.219.240.46'
<129>Nov  4 11:21:39 mad-proxy-inout-1 
/usr/local/kamailio/sbin/kamailio[4112]: ALERT: dialog 
[dlg_handlers.c:1715]: dlg_run_event_route(): after event route - dialog 
not found [8043:21772] (1/5) (0x7fa0c02a6870) with callid 
'1409565771_82382809@195.219.240.46'


we printed the dialog id and entry hash values and we can see there are 
no other calls creating same values in the previous hours, or using same 
memory allocation, or same callid, so it seems like there was some kind 
of strange issue with the dialog timers¿?
By the way, this is happening only few times (80-100 times) a day having 
many thousands of calls, so it's quite difficult for us to duplicate, we 
couldn't do it until now.
We also tried to use the timer_procs 0 or 1 to use a different proc 
timer but seems the issue happens in both scenarios.


The configuration change we made and seems it was done when these 
messages started to appear is to use dialog event_route when ended and 
failed to do some stuff there managing some dialog variables.
Does ti make any sense that attempting to use those variables could 
cause these behaviour?

Do you have any idea about it could be or how we can check it deeper?

thanks a lot and regards
david escartin

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

Re: [SR-Users] evapi_async_relay() failed

2017-11-07 Thread Daniel-Constantin Mierla

Hello,


On 07.11.17 15:51, Abdul Basit wrote:
> Hi list,
>
> I am configuring CGRateS with kamailio 4.4 using deb packages on debian 8.
>
> I am facing a issue while processing event_route[dialog:start] for
> answering call INVITE at
> evapi_async_relay("{\"event\":\"CGR_CALL_START\",
>
> with following error
>
> /usr/sbin/kamailio[13887]: ERROR: evapi [evapi_mod.c:288]:
> w_evapi_async_relay(): failed to suspend request processing
>
> However, after discussion with Dan on IRC i replaced function
> evapi_async_relay() with evapi_relay() resolved the issue.
>
> Whats causing this error?
> Can anyone suggest some way out for keep using evapi_async_relay?
event_route[dialog:start] is executed when 200ok response for INVITE is
received, so there is no SIP request to suspend at that time. Using
evapi_relay() should be fine in my opinion here.

There is support to suspend routing of sip responses as well, but not
sure if it is really useful in this case, you just need to notify
cgrates that the call has started, no reason to wait for a reply from
cgrates before forwarding the sip response.

Note that evapi_relay() is not blocking the sip routing, so it terms of
performances is in pair with async option.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com

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

Re: [SR-Users] http_async_client problem with tls_ca_path

2017-11-07 Thread gmele

Hello,

I reduced the number of kamailio children to 1 and found something that may
be interesting:

all requests are processed by 1 principal thread, but time to time, another
thread handle them (why, I don't know as children=1). When this occurs, the
https request ALWAYS fails with error 77. When the https requests are
handled by the main thread, all is ok.

Here are some traces (without curl verbose and debug). In the REGISTER, we
call the http_async_client module...

Nov  7 14:39:02 d-wn-sipregistrar-003 kamailio-registrar[*3325*]: msgType=1
cSeq=30 method=REGISTER callId=F0JIro3OZ3 | NOTICE: SIP Request from
sipSrc=sip:giovanni.m...@testrom2.com to
sipDst=sip:giovanni.m...@testrom2.com
Nov  7 14:39:02 d-wn-sipregistrar-003 kamailio-registrar[*3325*]: msgType=1
cSeq=30 method=REGISTER callId=F0JIro3OZ3 | NOTICE: Register device for user
sipSrc=giovanni.m...@testrom2.com
Nov  7 14:39:02 d-wn-sipregistrar-003 kamailio-registrar[*3332*]: ERROR:
http_async_client [http_multi.c:570]: check_multi_info(): handle 0x224edc0
returned error 77:
Nov  7 14:39:02 d-wn-sipregistrar-003 kamailio-registrar[*3332*]: ERROR:
Curl errorCode= when trying to register device
Nov  7 14:39:06 d-wn-sipregistrar-003 kamailio-registrar[*3325*]: msgType=1
cSeq=31 method=REGISTER callId=F0JIro3OZ3 | NOTICE: SIP Request from
sipSrc=sip:giovanni.m...@testrom2.com to
sipDst=sip:giovanni.m...@testrom2.com
Nov  7 14:39:08 d-wn-sipregistrar-003 kamailio-registrar[*3325*]: msgType=1
cSeq=31 method=REGISTER callId=F0JIro3OZ3 | NOTICE: Register device for user
sipSrc=giovanni.m...@testrom2.com


Hope it helps

Giovanni




--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

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

[SR-Users] evapi_async_relay() failed

2017-11-07 Thread Abdul Basit

Hi list,

I am configuring CGRateS with kamailio 4.4 using deb packages on debian 8.

I am facing a issue while processing event_route[dialog:start] for
answering call INVITE at
evapi_async_relay("{\"event\":\"CGR_CALL_START\",

with following error

/usr/sbin/kamailio[13887]: ERROR: evapi [evapi_mod.c:288]:
w_evapi_async_relay(): failed to suspend request processing

However, after discussion with Dan on IRC i replaced function
evapi_async_relay() with evapi_relay() resolved the issue.

Whats causing this error?
Can anyone suggest some way out for keep using evapi_async_relay?

--
regards,

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

Re: [SR-Users] authenticating to mongodb fails

2017-11-07 Thread Daniel-Constantin Mierla

Can you set debug=3 in kamailio.cfg and then look at debug messages to
see there is some hint about what happens?

Cheers,
Daniel


On 07.11.17 15:11, hdssdsdsdsfsdf hdssdsdsdsfsdf wrote:
> When I connect using mongo, the credentials work:
>
> $ mongo kamailio -u "kam" -p "kam"
> MongoDB shell version v3.4.9
> connecting to: mongodb://127.0.0.1:27017/kamailio
> MongoDB server version: 3.4.9
>> db.subscriber.find()
> { "_id" : ObjectI ...
>
> But when I use the following DBURL in kamailio.cfg, kamailio fails to even 
> login to mongo:
>
> #!define DBURL "mongodb://kam:kam@localhost/kamailio"
>
> If I disable mongodb authentication, kamailio starts up just fine again. Any 
> idea what's going wrong here?
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com
Kamailio World Conference - www.kamailioworld.com


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

Re: [SR-Users] http_async_client problem with tls_ca_path

2017-11-07 Thread gmele

Hello Giacomo,

here are the requested info:

1) unfortunately, I cannot give you this information as we copied the source
from git branch 5.0, August 18th and put it in our own source control
(Perforce)

2)1-2 requests per seconds seems ok, but as soon rate increases, problem
appears

3) I cannot give you the configuration file as we have some sensible
information in it. But we have the following configuration: SIP Proxy -> SIP
Registrar. The SIP registrar is using http_async_client when a REGISTER is
recieved (to register PUSH information from mobile app). Usually, this works
fine with 1-2 requests per seconds, but starts to fails as soon as rate
increases. When an INVITE is receivedm we also call http_async_client in
order to send a PUSH notification to the callee. I never saw this request
work as usually, there is a REGISTER  and right after an INVITE done, and it
seems that this cause http_async_client to fail.

I understand this information may not help you :-(

4) I configured 16 workers, but also tried with one. Kamailio is configured
with 8 childrens and SHM_MEMORY=2048. Maybe the problem is related to
kamailio childrens? I will try with only one children...

5) Upgrading to latest version 5.x will take me some time. I will try to do
this by the end of the week.

6) traces with debug level 3 and curl verbosity on are the same as the one I
sent you: when all is ok, the CApath is /etc/kamailio/ssl/ca/, and when it
doesn't work, it shows CApath: /etc/kamailio/ssl/ca/.


Let me try with children set to 1 to verify if it is a multi-thread problem
with the module. I will try to send you more logs.

Thx for your support

Giovanni



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

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

[SR-Users] authenticating to mongodb fails

2017-11-07 Thread hdssdsdsdsfsdf hdssdsdsdsfsdf

When I connect using mongo, the credentials work:

$ mongo kamailio -u "kam" -p "kam"
MongoDB shell version v3.4.9
connecting to: mongodb://127.0.0.1:27017/kamailio
MongoDB server version: 3.4.9
> db.subscriber.find()
{ "_id" : ObjectI ...

But when I use the following DBURL in kamailio.cfg, kamailio fails to even 
login to mongo:

#!define DBURL "mongodb://kam:kam@localhost/kamailio"

If I disable mongodb authentication, kamailio starts up just fine again. Any 
idea what's going wrong here?

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

Re: [SR-Users] Kamailio SIP-I

2017-11-07 Thread Sergey Basov

Hi.

You can look at modeule sipt documentation.
http://www.kamailio.org/docs/modules/devel/modules/sipt.html

Looking at source code you can extend this functionality, but you need some
C programming knowledge.


--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com

2017-11-03 20:37 GMT+02:00 Saleem Manasfi :

> Dears,
>
> Please if you can let us know how does Kamailio reads the SIP-I body
> (ISUP)?
>
> Is there any document or link that may help?
>
> ___
> 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] Topoh module configuration for SIP proxy and SIP registrar

2017-11-07 Thread Christian Conus

Hello Daniel, 

Do you have an idea why the SIP messages header are only partially encrypted
for the caller ?

Since both SIP clients connects to the same SIP proxy it means that SIP
messages go two times through the same proxy (client -> proxy -> registrar
-> proxy -> client), is it possible to configure topoh to encrypt headers
only for outgoing messages on a particular network interface ? 

It is not clear if partially encrypted messages means that the proxy has
decryted the already encrypted header parts and encrypted the parts in clear
?


Thanks
Christian



--
Sent from: http://sip-router.1086192.n5.nabble.com/Users-f3.html

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

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

Re: [SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

Re: [SR-Users] authenticating to mongodb fails

[SR-Users] strange --dialog in delete state is too old-- log line managing dialog hashes

Re: [SR-Users] evapi_async_relay() failed

Re: [SR-Users] http_async_client problem with tls_ca_path

[SR-Users] evapi_async_relay() failed

Re: [SR-Users] authenticating to mongodb fails

Re: [SR-Users] http_async_client problem with tls_ca_path

[SR-Users] authenticating to mongodb fails

Re: [SR-Users] Kamailio SIP-I

Re: [SR-Users] Topoh module configuration for SIP proxy and SIP registrar

13 matches

Site Navigation

Mail list logo

Footer information