[SR-Users] kamailio realtime integration
vaad.fabi at gmail.com
vaad.fabi at gmail.com
Fri Jun 24 20:12:37 CEST 2011
Yes, NOTIFY was generated by ipphone.
Thx, again :)
On 06/24/2011 12:00 PM, Daniel-Constantin Mierla wrote:
> Hello,
>
> based on the logs, the authentication fails due to wrong password.
> Check that you have the right password on client side.
>
> Kamailio does not generate any NOTIFY unless the presence server
> modules are loaded. If not, then the notify comes from somewhere else
> and it is just looped back due to config file routing logic.
>
> Cheers,
> Daniel
>
> On 6/24/11 10:01 AM, vaad.fabi at gmail.com wrote:
>> Hi all,
>>
>> Still trying to run kamailio 3.1.x + asterisk 1.6.2.X realtime
>> architecture.
>> As i mentioned earlier, instead of asterisk i use another softswitch
>> with db, table "retailroute" with "login" and "password" fields as
>> user auth data.
>> Of course, troubles... user can't register to kamailio :(
>>
>> Logs( without users attempts to register, only kamailio internal logic:
>>
>>
>> Jun 24 11:23:26 sbc kamailio[17768]: INFO: <script>:
>> ------------------ SIP Request: method [NOTIFY] from
>> [sip:100 at 100.100.100.100] to [sip:100.100.100.100]
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [parser/msg_parser.c:167]: get_hdr_field: cseq <CSeq>: <811> <NOTIFY>
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: maxfwd [mf_funcs.c:85]:
>> value = 70
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [parser/msg_parser.c:201]: DEBUG: get_hdr_body : content_length=0
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [parser/msg_parser.c:103]: found end of header
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [msg_translator.c:204]: check_via_address(XX.116.255.XXX,
>> 192.168.0.180, 0)
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: siputils [checks.c:73]:
>> no totag
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: tm [t_lookup.c:1081]:
>> DEBUG: t_check_msg: msg id=39 global id=38 T start=(nil)
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: tm [t_lookup.c:528]:
>> t_lookup_request: start searching: hash=31430, isACK=0
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: tm [t_lookup.c:485]:
>> DEBUG: RFC3261 transaction matching failed
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: tm [t_lookup.c:711]:
>> DEBUG: t_lookup_request: no transaction found
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: tm [t_lookup.c:1150]:
>> DEBUG: t_check_msg: msg id=39 global id=39 T end=(nil)
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [select.c:424]:
>> Calling SELECT 0x832b7e4
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [socket_info.c:501]: grep_sock_info - checking if host==us: 13==13
>> && [100.100.100.100] == [100.100.100.100]
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [socket_info.c:504]: grep_sock_info - checking if port 5060 matches
>> port 5060
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth_db
>> [authorize.c:239]: realm value [100.100.100.100]
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth [api.c:95]: auth:
>> digest-algo: MD5 parsed value: 1
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:118]:
>> allocate 28 bytes for result set at 0x832c8cc
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: db_mysql [km_res.c:68]: 1
>> columns returned from the query
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:155]:
>> allocate 4 bytes for result names at 0x832ba40
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:165]:
>> allocate 4 bytes for result types at 0x832ba08
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: db_mysql [km_res.c:85]:
>> allocate 8 bytes for RES_NAMES[0] at 0x832c950
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: db_mysql [km_res.c:92]:
>> RES_NAMES(0x832c950)[0]=[password]
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: db_mysql [km_res.c:136]:
>> use DB1_STRING result type
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:184]:
>> allocate 8 bytes for rows at 0x832c918
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_row.c:119]:
>> allocate 20 bytes for row values at 0x832e75c
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_val.c:117]:
>> converting STRING [dav0011]
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth_db
>> [authorize.c:120]: HA1 string calculated:
>> a8fdf502e497ff8e9407ac2dc31540df
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth [api.c:205]:
>> check_response: Our result = 'fa83bf7c0a7af33cc500aa2b62758931'
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth [api.c:215]:
>> check_response: Authorization failed
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:81]:
>> freeing 1 columns
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:85]:
>> freeing RES_NAMES[0] at 0x832c950
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:94]:
>> freeing result names at 0x832ba40
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:99]:
>> freeing result types at 0x832ba08
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:54]:
>> freeing 1 rows
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_row.c:97]:
>> freeing row values at 0x832e75c
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:62]:
>> freeing rows at 0x832c918
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [db_res.c:136]:
>> freeing result set at 0x832c8cc
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth [challenge.c:102]:
>> build_challenge_hf: realm='100.100.100.100'
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: auth [challenge.c:236]:
>> auth: 'Proxy-Authenticate: Digest realm="100.100.100.100",
>> nonce="TgQ8mU4EO22Odd1W63tOO27IRrKX0kU '
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: sl [sl.c:278]: reply in
>> stateless mode (sl)
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core>
>> [msg_translator.c:204]: check_via_address(XX.116.255.XXX,
>> 192.168.0.180, 0)
>> Jun 24 11:23:26 sbc kamailio[17768]: DEBUG: <core> [usr_avp.c:646]:
>> DEBUG:destroy_avp_list: destroying list (nil)
>>
>>
>>
>> Such messages periodically sends kamailio. Why kamailio every time
>> sends yourself these NOTIFY messages, what it try to do ?
>> I see problem something around auth_db autorization and HA1, isn't it
>> ? How to fix it ?
>>
>>
>
--
vad fabi
More information about the sr-users
mailing list