Hello Everyone,
I am trying start kamailio 4.2 with remote mysql server and on debug I see
DEBUG: db_mysql [km_my_con.c:94]: db_mysql_new_connection(): opening connection: mysql://xxxx:xxxx@localhost/kamailio
but in cfg defined actual mysql server ip and not localhost
0(28885) DEBUG: <core> [sr_module.c:695]: find_mod_export_record(): find_export_record: found <db_bind_api> in module db_mysql [/usr/lib64/kamailio/modules/db_mysql.so]
0(28885) DEBUG: <core> [db.c:213]: db_bind_mod(): using db bind api for db_mysql
0(28885) DEBUG: <core> [db.c:318]: db_do_init2(): connection 0x7faca59eced8 not found in pool
0(28885) DEBUG: db_mysql [km_my_con.c:94]: db_mysql_new_connection(): opening connection: mysql://xxxx:xxxx@localhost/kamailio
0(28885) ERROR: db_mysql [km_my_con.c:109]: db_mysql_new_connection(): driver error: Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2 "No such file or directory")
0(28885) ERROR: <core> [db.c:322]: db_do_init2(): could not add connection to the pool 0(28885) ERROR: dialog [dlg_db_handler.c:147]: init_dlg_db(): unable to connect to the database
Slava.
Hello Daniel,
Today I installed kamailio from GIT last devel 4.3.0-dev3.
*The problem is solved!*
Thank you so much for your help !
Julia
On Mon, Jan 26, 2015 at 8:38 PM, Julia Boudniatsky <juliabo(a)gmail.com>
wrote:
> Yes it /usr/local/sbin/kamailio,
> I haven't internet in the test server.
> I get git from another server and copy received directory kamailio to test
> server, then make cfg/all/install.
>
> BR,
> Julia
>
> On Mon, Jan 26, 2015 at 8:10 PM, Daniel-Constantin Mierla <
> miconda(a)gmail.com> wrote:
>
>> I did the same right now and I get:
>>
>> version: kamailio 4.3.0-dev3 (x86_64/darwin) 1b334f
>>
>> Can you check if you have another instance installed on a different path
>> that takes precendence?
>>
>> Do:
>>
>> which kamailio
>>
>> When installed from sources, it should be:
>>
>> /usr/local/sbin/kamailio
>>
>> Cheers,
>> Daniel
>>
>>
>>
>> On 26/01/15 18:55, Julia Boudniatsky wrote:
>>
>> I used from your link * http://www.kamailio.org/wiki/#installation
>>
>>
>> - Install Kamailio Devel Version From GIT
>> <http://www.kamailio.org/wiki/install/devel/git>
>>
>> #mkdir -p /usr/local/src/kamailio-devel
>> #cd /usr/local/src/kamailio-devel
>> #git clone --depth 1 --no-single-branch git://git.kamailio.org/kamailio
>> kamailio
>> #cd kamailio
>>
>> BR,
>>
>> Julia
>>
>> On Mon, Jan 26, 2015 at 7:04 PM, Daniel-Constantin Mierla <
>> miconda(a)gmail.com> wrote:
>>
>>> Hello,
>>>
>>> that is not the last devel version, it should be with -dev3. How did you
>>> get the sources?
>>>
>>> I get:
>>>
>>> version: kamailio 4.3.0-dev3 (x86_64/darwin) 1b334f
>>>
>>> And yes, if you still get the error, send the logs with the description.
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 26/01/15 17:16, Julia Boudniatsky wrote:
>>>
>>> Hello Daniel,
>>> In devel installed, I received the same problem.
>>>
>>> kamailio -V
>>> version: kamailio 4.3.0-dev2 (x86_64/linux) ecd5c5
>>> flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>>> F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>> id: ecd5c5
>>> compiled on 18:02:05 Jan 26 2015 with gcc 4.4.6
>>>
>>> Do you want a log files?
>>>
>>> Thank you,
>>>
>>> Julia
>>>
>>> On Mon, Jan 26, 2015 at 12:47 PM, Daniel-Constantin Mierla <
>>> miconda(a)gmail.com> wrote:
>>>
>>>> Hello,
>>>>
>>>> none of existing releases are good because the patches are only in git
>>>> branches, added after the last relesea (I added it iver this weekend). You
>>>> must install from git, as pointed by one of the tutorials at:
>>>>
>>>> * http://www.kamailio.org/wiki/#installation
>>>>
>>>> You must use devel (master), 4.2 (v4.2.x) or 4.1 (v4.1.x) branches.
>>>>
>>>> We will have new releases in the near future, like 1-2 weeks from now,
>>>> but by then I hope to get this bug sorted out.
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 26/01/15 11:42, Julia Boudniatsky wrote:
>>>>
>>>> Hello Daniel,
>>>> I installed last 4.2
>>>>
>>>> version: kamailio 4.2.1 (x86_64/linux) d80dfc
>>>> flags: STATS: Off, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
>>>> DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC,
>>>> F_MALLOC, DBG_F_MALLOC, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE,
>>>> USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
>>>> ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16,
>>>> MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
>>>> poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
>>>> id: d80dfc
>>>> compiled on 10:06:01 Jan 26 2015 with gcc 4.4.6
>>>>
>>>>
>>>> *Problem in call with Call-ID : 5-5028(a)10.25.153.150
>>>> <5-5028(a)10.25.153.150> *
>>>>
>>>> *Short log*
>>>>
>>>> *dialog [3748:5628]*
>>>>
>>>> *100 trying*
>>>>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]:
>>>> DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:637]: parse_msg(): status: <100>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Trying>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param:
>>>> tag=9313591363960470767
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header
>>>> reached, state=29
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG: get_hdr_field:
>>>> <To> [71]; uri=[sip:039951004@10.25.153.149:5060;user=phone]
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [
>>>> <sip:039951004@10.25.153.149:5060;user=phone>]
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field: cseq
>>>> <CSeq>: <1> <INVITE>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 234,
>>>> <received> = <10.25.153.149>; state=6
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232,
>>>> <branch> = <z9hG4bKbde6.9c95fbe06c33a54c13ef2ebc4b519dcc.0>; state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232,
>>>> <branch> = <z9hG4bKbde6.785d27b1.0>; state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232,
>>>> <branch> = <z9hG4bKbde6.5be423cd6c755cf13d68e74be1f301a1.0>; state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:1284]: parse_via_param(): Found param type 232,
>>>> <branch> = <z9hG4bK-5028-5-0>; state=16
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_via.c:2672]: parse_via(): end of header reached,
>>>> state=5
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers: Via
>>>> found, flags=2
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers: this is
>>>> the first via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [receive.c:154]: receive_msg(): After parse_msg...
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=132 global
>>>> id=131 T start=0xffffffffffffffff
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching: hash
>>>> 28379 label 0 branch 0
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching: reply
>>>> matched (T=0x7f3ec89a3e68)!
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=132 global
>>>> id=132 T end=0x7f3ec89a3e68
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> tm [t_reply.c:2200]: reply_received(): DEBUG: reply_received: org. status
>>>> uas=100, uac[0]=0 local=0 is_invite=1)
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG: add_param:
>>>> tag=5028SIPpTAG005
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of header
>>>> reached, state=29
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG: get_hdr_body :
>>>> content_length=0
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of header
>>>> *Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]:
>>>> ERROR: KAMnet: processing INVITE
>>>> (5-5028(a)10.25.153.150/5028SIPpTAG005/9313591363960470767/SIP/2.0/UDP
>>>> <http://5-5028@10.25.153.150/5028SIPpTAG005/9313591363960470767/SIP/2.0/UDP>
>>>> 10.25.153.149:5060;received=10.25.153.149;branch=z9hG4bKbde6.9c95fbe06c33a54c13ef2ebc4b519dcc.0,SIP/2.0/UDP
>>>> 10.25.154.104;branch=z9hG4bKbde6.785d27b1.0,SIP/2.0/UDP
>>>> 10.25.153.149:5060;branch=z9hG4bKbde6.5be423cd6c755cf13d68e74be1f301a1.0,SIP/2.0/UDP
>>>> 10.25.153.150:5062;branch=z9hG4bK-5028-5-0)[sip:39988004@10.25.153.150
>>>> <sip%3A39988004(a)10.25.153.150>;user=phone=>sip:039951004@10.25.153.149:5060;user=phone]*
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> dialog [dlg_hash.c:711]: internal_get_dlg(): ref dlg 0x7f3ec89b6d28 with 1
>>>> -> 2
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> dialog [dlg_hash.c:714]: internal_get_dlg(): *dialog
>>>> callid='5-5028(a)10.25.153.150 <5-5028(a)10.25.153.150>' found*
>>>> * on entry 3748, dir=1*
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20649]: DEBUG:
>>>> dialog [dlg_var.c:243]: print_lists(): Internal var-list ((nil)):
>>>>
>>>>
>>>> *301 Moved Permanently*
>>>>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:633]: parse_msg(): SIP Reply (status):
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:635]: parse_msg(): version: <SIP/2.0>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:637]: parse_msg(): status: <301>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:639]: parse_msg(): reason: <Moved
>>>> Permanently>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG:
>>>> add_param: tag=9313591363960470767
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of
>>>> header reached, state=29
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:190]: get_hdr_field(): DEBUG:
>>>> get_hdr_field: <To> [71]; uri=[
>>>> sip:039951004@10.25.153.149:5060;user=phone]
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:192]: get_hdr_field(): DEBUG: to body [
>>>> <sip:039951004@10.25.153.149:5060;user=phone>]
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:170]: get_hdr_field(): get_hdr_field:
>>>> cseq <CSeq>: <1> <INVITE>
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
>>>> type 234, <received> = <10.25.153.149>; state=6
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
>>>> type 232, <branch> = <z9hG4bKbde6.9c95fbe06c33a54c13ef2ebc4b519dcc.0>;
>>>> state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
>>>> type 232, <branch> = <z9hG4bKbde6.785d27b1.0>; state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
>>>> type 232, <branch> = <z9hG4bKbde6.5be423cd6c755cf13d68e74be1f301a1.0>;
>>>> state=9
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:2715]: parse_via(): parse_via: next_via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:1284]: parse_via_param(): Found param
>>>> type 232, <branch> = <z9hG4bK-5028-5-0>; state=16
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_via.c:2672]: parse_via(): end of header
>>>> reached, state=5
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:513]: parse_headers(): parse_headers:
>>>> Via found, flags=2
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:515]: parse_headers(): parse_headers:
>>>> this is the first via
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [receive.c:154]: receive_msg(): After parse_msg...
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=136
>>>> global id=135 T start=0xffffffffffffffff
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: tm [t_lookup.c:949]: t_reply_matching(): DEBUG: t_reply_matching:
>>>> hash 28379 label 0 branch 0
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: tm [t_lookup.c:1004]: t_reply_matching(): DEBUG: t_reply_matching:
>>>> reply matched (T=0x7f3ec89a3e68)!
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: tm [t_lookup.c:1141]: t_check_msg(): DEBUG: t_check_msg: msg id=136
>>>> global id=136 T end=0x7f3ec89a3e68
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: tm [t_reply.c:2200]: reply_received(): DEBUG: reply_received: org.
>>>> status uas=100, uac[0]=100 local=0 is_invite=1)
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_addr_spec.c:176]: parse_to_param(): DEBUG:
>>>> add_param: tag=5028SIPpTAG005
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/parse_addr_spec.c:898]: parse_addr_spec(): end of
>>>> header reached, state=29
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:204]: get_hdr_field(): DEBUG:
>>>> get_hdr_body : content_length=0
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: <core> [parser/msg_parser.c:106]: get_hdr_field(): found end of
>>>> header
>>>> *Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[20653]:
>>>> ERROR: KAMnet: processing INVITE
>>>> (5-5028(a)10.25.153.150/5028SIPpTAG005/9313591363960470767/SIP/2.0/UDP
>>>> <http://5-5028@10.25.153.150/5028SIPpTAG005/9313591363960470767/SIP/2.0/UDP>
>>>> 10.25.153.149:5060;received=10.25.153.149;branch=z9hG4bKbde6.9c95fbe06c33a54c13ef2ebc4b519dcc.0,SIP/2.0/UDP
>>>> 10.25.154.104;branch=z9hG4bKbde6.785d27b1.0,SIP/2.0/UDP
>>>> 10.25.153.149:5060;branch=z9hG4bKbde6.5be423cd6c755cf13d68e74be1f301a1.0,SIP/2.0/UDP
>>>> 10.25.153.150:5062;branch=z9hG4bK-5028-5-0)[sip:39988004@10.25.153.150
>>>> <sip%3A39988004(a)10.25.153.150>;user=phone=>sip:039951004@10.25.153.149:5060;user=phone]*
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: dialog [dlg_hash.c:654]: dlg_lookup(): ref dlg 0x7f3ec895f650 with 1
>>>> -> 2
>>>> Jan 26 10:20:49 vm-KAMnet-dev01 /usr/local/sbin/kamailio[*20653*]:
>>>> DEBUG: dialog [dlg_hash.c:656]: dlg_lookup(): *dialog id=2299 found on
>>>> entry 422*
>>>>
>>>>
>>>>
>>>> Thank you,
>>>> Julia
>>>>
>>>>
>>>>
>>>> On Sun, Jan 25, 2015 at 7:47 PM, Daniel-Constantin Mierla <
>>>> miconda(a)gmail.com> wrote:
>>>>
>>>>> I looked at the logs, but I don't see any log messages like:
>>>>>
>>>>> ... resetting the local dialog shortcuts ...
>>>>>
>>>>> I did some tests locally and it is printed even after processing 100
>>>>> Trying. The log message appears after 301 or 200ok as well. Are you sure
>>>>> you run the latest version from the git branch (4.1, 4.2, or master) or all
>>>>> log messages were sent over?
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 25/01/15 12:27, Julia Boudniatsky wrote:
>>>>>
>>>>>
>>>>> *dialog [3692:448]*
>>>>>
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]:
>>>>> ERROR: KAMnet: processing INVITE (
>>>>> 2-17858(a)10.25.153.150/17858SIPpTAG002/9313591363960453592/SIP/2.0/UDP
>>>>> 10.25.153.149:5060;received=10.25.153.149;branch=z9hG4bK3ae5.3e00b5a33eaac375191362e27e930fba.0,SIP/2.0/UDP
>>>>> 10.25.154.104;branch=z9hG4bK3ae5.89c39796.0,SIP/2.0/UDP 10.25.153.149:5060;branch=z9hG4bK3ae5.42e72ca36c3875261747250c959a8d70.0,SIP/2.0/UDP
>>>>> 10.25.153.150:5062;branch=z9hG4bK-17858-2-0)[
>>>>> sip:39988001@10.25.153.150;user=phone=>
>>>>> sip:039951001@10.25.153.149:5060;user=phone]
>>>>>
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]: DEBUG:
>>>>> dialog [dlg_hash.c:872]: dlg_unref(): unref dlg 0x7faf1c35fa48 with 1 -> 1
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]:
>>>>> NOTICE: KAMnet: REPLY_TO_SOURCE: 301 Q.850[410] [1 INVITE] from C5tst to
>>>>> IVRcustomer
>>>>> ru=<null>
>>>>> fu=sip:39988001@10.25.153.150;user=phone
>>>>> tu=sip:039951001@10.25.153.149:5060;user=phone
>>>>> ai=<null>
>>>>> ci=2-17858(a)10.25.153.150
>>>>> ct=sip:D39739951001@10.25.153.150
>>>>> cl=0
>>>>> branch[1]
>>>>>
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]:
>>>>> DEBUG: tm [t_lookup.c:1072]: t_check_msg(): DEBUG: t_check_msg: msg id=8
>>>>> global id=8 T start=0x7faf1c372048
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]: DEBUG:
>>>>> tm [t_lookup.c:1144]: t_check_msg(): DEBUG: t_check_msg: T already found!
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]: DEBUG:
>>>>> tm [tm.c:1035]: t_check_status(): DEBUG:t_check_status: checked status is
>>>>> <301>
>>>>> Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]: DEBUG:
>>>>> dialog [dlg_hash.c:654]: dlg_lookup(): ref dlg 0x7faf1c35fa48 with 1 -> 2
>>>>> *Jan 25 11:41:31 vm-KAMnet-dev01 /usr/local/sbin/kamailio[2588]:
>>>>> DEBUG: dialog [dlg_hash.c:656]: dlg_lookup(): dialog id=9780 found on entry
>>>>> 1905*
>>>>>
>>>>> *Thank you,*
>>>>>
>>>>> *Julia*
>>>>>
>>>>> On Sun, Jan 25, 2015 at 12:48 PM, Daniel-Constantin Mierla <
>>>>> miconda(a)gmail.com> wrote:
>>>>>
>>>>>> Can you point shortly again the lines where the wrong matching
>>>>>> happens? Like last time -- it helped to spot in the file faster and analyze
>>>>>> from there.
>>>>>>
>>>>>> Cheers,
>>>>>> Daniel
>>>>>>
>>>>>>
>>>>>> On 25/01/15 11:44, Julia Boudniatsky wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sun, Jan 25, 2015 at 12:03 AM, Daniel-Constantin Mierla <
>>>>>> miconda(a)gmail.com> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> got the time to analyze your last logs and I discovered that the
>>>>>>> previous patch was not resetting properly the dialog shortcuts. I pushed a
>>>>>>> fix, can you try again with the latest version from one of the branches:
>>>>>>> master, 4.2 or 4.1?Let me know the results.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>> On 15/01/15 23:42, Daniel-Constantin Mierla wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I looked at the logs, but I cannot see the log message I added with
>>>>>>> the patch for reseting local dialog shortcuts after onreply and failure
>>>>>>> route. It shuld be something like:
>>>>>>>
>>>>>>> "... resetting the local dialog shortcuts"
>>>>>>>
>>>>>>> Are you sure you are running the latest branch 4.1? You can send the
>>>>>>> output of kamailio -v to double check here.
>>>>>>>
>>>>>>> I separated the logs per process and looked when a 301 was received,
>>>>>>> apparently the ones for Call-ID: 4-21712 are matching the same dialog. I
>>>>>>> found something not printing the same kind of logs like for other 301 for
>>>>>>> Call-ID: 2-21712. If you can point the line in the logs where you think it
>>>>>>> was the wrong dialog match, I can investigate from there, but now I
>>>>>>> couldn't find any lead.
>>>>>>>
>>>>>>> Anyhow, if it is the latest branch 4.1 and the problem still
>>>>>>> persists, can you add the following xlog at the beginning of main
>>>>>>> request_route (or the route {...} ), plus in each reply_route,
>>>>>>> onreply_route and failure_route:
>>>>>>>
>>>>>>> xlog("processing $rm ( $ci / %ft / $tt / $hdr(Via) ) [$fu =>
>>>>>>> $tu]\n");
>>>>>>>
>>>>>>> Then redo the tests to catch the issue and send me the new logs.
>>>>>>> Because you use sipp with tags like '4', it is hard to search on a single
>>>>>>> tocken and I want to have the all message attribute when a relevant route
>>>>>>> block is executed.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>> On 14/01/15 15:07, Daniel-Constantin Mierla wrote:
>>>>>>>
>>>>>>> Hello Julia,
>>>>>>>
>>>>>>> ok, I will look over the logs very soon.
>>>>>>>
>>>>>>> As a short note for the future, make the archives zip or tgz, being
>>>>>>> more common formats that can be unarchived everywhere without installing
>>>>>>> additional app, being handy to open even on small devices. Now it is ok
>>>>>>> with rar, being at the desk.
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>> On 14/01/15 14:43, Julia Boudniatsky wrote:
>>>>>>>
>>>>>>> Hello Daniel,
>>>>>>>
>>>>>>> Please find in attached file the debug 3 log.
>>>>>>> Failed call with Call-ID: 4-21712(a)10.25.153.150.
>>>>>>> The problem occurred with all modes of "dlg_match_mode "
>>>>>>> The same load test in 3.3 executed without failures.
>>>>>>>
>>>>>>> Thank you,
>>>>>>>
>>>>>>> Julia.
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>>
>>>>>
>>>>
>>>> --
>>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>>
>>>>
>>>
>>> --
>>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>>
>>>
>>
>> --
>> Daniel-Constantin Mierlahttp://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
>>
>>
>
Hi!
Please help me to figure out how to use "@select" or "$sel" in routes.
For example: there is a sip message at the entrance of kamailo. This
message contains an authorization header.
Authorization: Digest username="oleg.pershin", realm="178.62.221.112",
nonce="VMT1cVTE9EVT/6/MLuDZR8dA4g1Mfir4", uri="sip:178.62.221.112",
response="6eb5427433ef0b51832829f9fd4340ea", algorithm=MD5
Authentication Scheme: Digest
username="oleg.pershin"
realm="178.62.220.111"
nonce="VMT1cVTE9EVT/6/MLuDZR7dA4g1Mfir4"
uri="sip:178.62.220.111"
response="6eb5327433ef0b51832829f9fd4340ea"
algorithm=MD5
So I want to get a value from the "nonce" with "@select" or "$sel"
functions .
How will it look like?
Best regards, Oleg Pershin.
Hey gents,
In relation to my attempts to get transaction logging successful, I'm
curious to know when transaction logging triggers.
My current theory is that something I'm doing in my SIPp uac test messages
(what's being sent to Kamailio) is preventing the transaction from fully
completing and thus preventing logging.
I'm currently setting up an Asterisk box to test this theory, but I'd still
like to know more about this and see if I can understand more of what's
going on under the hood.
Thanks in advance,
Ryan Brindley
Hello. I need parallel forking calls with the same username. (Call to all
contacts with name for example User123), my endpoints may be WebSocket
based and standart UDP endpoints. And I use rtpengine_manage for nmanaging
calls wor webphones and standart softh/hard phones.
I get all contacts manually and than at the branch route set
rtpengine_manage settings for every call.
It works fine but it works for one kamailio server.
When I use 2 kamailio servers as load balansers Server that handle call get
all endpoints from location but call to only one, that registred only at
ths server
for example I call user123
I have 3 contacts
user123(a)1.2.3.4 - was registered at kamailio 1
user123(a)3.2.1.4 - was registered at kamailio 2
user123(a)4.3.2.1 - was registered at kamailio 1
So if call goes through kamailio 1 it call only to user123(a)1.2.3.4 and
user123(a)4.3.2.1
I use this settings for usrloc at 2 kamailios to share all table between 2
servers
modparam("usrloc", "db_url", DBURL)
modparam("usrloc", "db_mode", 3)
modparam("usrloc", "user_column", "username")
modparam("usrloc", "contact_column", "contact")
modparam("usrloc", "expires_column", "expires")
modparam("usrloc", "q_column", "q")
modparam("usrloc", "callid_column", "callid")
modparam("usrloc", "cseq_column", "cseq")
modparam("usrloc", "methods_column", "methods")
modparam("usrloc", "cflags_column", "cflags")
modparam("usrloc", "user_agent_column", "user_agent")
modparam("usrloc", "received_column", "received")
modparam("usrloc", "socket_column", "socket")
modparam("usrloc", "path_column", "path")
modparam("usrloc", "ruid_column", "ruid")
modparam("usrloc", "instance_column", "instance")
modparam("usrloc", "use_domain", 1)
and this code for calling them
[GET_CONTACTS]
{
sql_query("ca", "select contact from location where username='$tU'", "ra");
xlog("rows: $dbr(ra=>rows) cols: $dbr(ra=>cols)\n");
if($dbr(ra=>rows)>0){
$var(i)=0;
while($var(i)<$dbr(ra=>rows)){
xlog("L_INFO","SQL query return contact {$dbr(ra=>[$var(i),0])} for {$tU}
at step {$var(i)}\n");
if ($dbr(ra=>[$var(i),0])=~"transport=ws"){
xlog("L_INFO", "This is a Websocket call to endpoint");
sql_pvquery("ca", "select received from location where
contact='$dbr(ra=>[$var(i),0])'","$var(recieved)");
$du=$var(recieved);
xlog("L_INFO","SQL query return recieved {$var(recieved)} for {$tU}.
Destination is {$du}\n");
append_branch("sip:$tU@$(du{s.select,1,:})");
}
else
{
xlog("L_INFO", "This is a classic UDP call to endpoint");
$var(recieved)='';
sql_pvquery("ca", "select received from location where
contact='$dbr(ra=>[$var(i),0])'","$var(recieved)");
xlog("L_INFO", "SQL query return RECIEVED {$var(recieved)}");
if ($var(recieved)==0){
xlog("L_INFO", "Recieved string is EMPTY");
$du="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@});
}
else {
xlog("L_INFO", "Recieved string is {$var(recieved)}");
$du=$var(recieved);
}
$var(UDP_contact)="sip:"+$(dbr(ra=>[$var(i),0]){s.select,1,@});
append_branch("sip:$tU@$(du{s.select,1,:})");
xlog("L_INFO","Classic Destination URI is {$dbr(ra=>[$var(i),0])} for
{$tU}}. Destination is {$du}\n");
}
$var(i) = $var(i) + 1;
}
}
t_on_branch("1");
return;
}
}
}
branch_route[1]{
if($du=~"transport=ws"){
xlog("L_INFO","Websocket Branch is {$du} for {$tU}\n");
rtpengine_manage("internal extenal force trust-address replace-origin
replace-session-connection ICE=force RTP/SAVPF");
t_on_reply("REPLY_FROM_WS");
}
else{
xlog("L_INFO","UDP Branch is {$du)} for {$tU}\n");
rtpengine_manage("replace-origin replace-session-connection ICE=remove
RTP/AVP");
t_on_reply("MANAGE_CLASSIC_REPLY");
}
}
When it try to branch endpoint without registration at server that handle
call I get errors that tm module can not build Via header
**via_builder(): TCP/TLS connection (id: 0) for WebSocket could not be
found*
*ERROR: <core> [msg_translator.c:1725]: build_req_buf_from_sip_req():
could not create Via header*
*ERROR: <core> [forward.c:607]: forward_request(): ERROR:
forward_request: building failed*
*
UDP calls get errors something like above (sorry than can not share
error code, This situation not often).
So I think I have this trouble because I use manually handling call
and tried to substitute to lookup_branches function. but I have no
Idea how to set rtpengine_manage paraments for each endpoint depending
this is websocket or standart call.
IF there is write problem for callings thhrough 2 kamailios as
loadbalansers pleas let me know about how to set rtpengine_manage
parametrs wor endpoints for every fork. If not- can you tell me how I
can call to all endpoints endepending of registration server (kamailio
1 or 2).
Thanks.
I've been working to try to get kamailio (4.1) to log every transaction to
file, but can't seem to do it -- or even get it to reliably log. What the
heck am i missing?
It seems Kamailio logs the first time i try it on a day, but then won't do
it again no matter what variation of configs I try.
Is it something wrongly configured with flatstore? Permission issues? Any
help/leads/hunches are greatly appreciated.
The following is my truncated test config
#!KAMAILIO
#!define DBURL "flatstore:/var/log/kamailio-acc"
#!define FLT_ACC 1
#!define FLT_ACCMISSED 2
#!define FLT_ACCFAILED 3
(the config and load mod stuff)
modparam("acc", "log_level", 1)
modparam("acc", "log_flag", FLT_ACC)
modparam("acc", "log_missed_flag", FLT_ACCMISSED)
modparam("acc", "log_facility", "LOG_LOCAL2") #confirmed in Ubuntu rsyslog
LOG_LOCAL2 is configured
modparam("acc", "failed_transaction_flag", FLT_ACCFAILED)
modparam("acc", "db_url", DBURL)
modparam("acc", "db_flag", FLT_ACC)
modparam("acc", "db_missed_flag", FLT_ACCMISSED)
request_route {
(non-invite request stuff)
setflag(FLT_ACC);
setflag(FLT_ACCMISSED);
setflag(FLT_ACCFAILED);
send_reply("420", "Test");
exit;
}
Ryan Brindley
Hello,
I am totally struck at a point while implementing Kamailio as proxy for
WebRTC enabled UAC (Jssip). I am using Google's TURN server
(rfc5766-turn-server for ICE/STUN). I am able to get to the point where the
SIP server sends 183 session in progress to kamailio but after that I can
only see -
"STUN: using this candidate"
"Successful STUN binding request from .."
"SRTP output wanted, but no crypto suite was negotiated"
a) What should I do to resolve this issue ?
b) Why is that I never get 200 OK for the INVITE ?
I am attaching the logfile & configs herewith.
Can somebody please help me out here...
--
Warm Regds.
MathuRahul
Hi ,
I've updated kamailio from 4.1.4 to 4.1.7 and some times dialog variables
are not writed on the db by the ACC module.
The variable that is not writed ,is setted in the on reply route ,when it
receive the 200ok and method is invite.
If i come back to the 4.1.4 all is ok.
If i patch kamailio 4.1.4 with the code "dialog: Set the dialog context on
incoming replies" (commit:b12a01e553699786953ec601197669314bf414c7)
sometime the variable are not writed.
Any ideas?
Thanks
Hi All,
I'm running into a issue with the dialog module since the upgrade from
4.2.1 to 4.2.2. I use the dialog module to add extra vars to the cdr's
generated by the ACC module.
I use the following config:
# ----- dialog params -----
modparam("dialog", "enable_stats", 1)
modparam("dialog", "dlg_match_mode", 1)
modparam("dialog", "dlg_flag", FLT_DLG)
modparam("dialog", "rr_param", "did")
modparam("dialog", "wait_ack", 1)
# Create dialog
if (method=="INVITE") {
# Create Dialog
dlg_manage();
# Add test dialog var
$dlg_var(src_ua) = $hdr(User-Agent);
}
This seems to work fine on kamailio 4.2.1 but after the upgrade i see
the following errors in the logs:
Jan 22 13:16:57 sip /usr/sbin/kamailio[2773]: CRITICAL: dialog
[dlg_hash.c:901]: log_next_state_dlg(): bogus event 6 in state 1 for dlg
0x7f2f0332ed40 [3693:11222] with clid
'9192c5fc24627a14c2ec42f084a96587(a)192.168.149.126' and tags '4017642921'
''
Jan 22 13:17:01 sip /usr/sbin/kamailio[2770]: CRITICAL: dialog
[dlg_hash.c:901]: log_next_state_dlg(): bogus event 7 in state 1 for dlg
0x7f2f0332ed40 [3693:11222] with clid
'9192c5fc24627a14c2ec42f084a96587(a)192.168.149.126' and tags '4017642921'
''
If i'm correct "bogus event 6 in state 1" indicates that a ACK whas
received while the dialog still was in unconfirmed state. Should i catch
the 200 OK on the INVITE to update the dialog?
Thanks,
Jan Hazenberg