Hi
It fetches one value from the database to compare it against a second
value that has to be computed right, in the computation of the second
hash where is the domain part fetched from ?
Regards
On Wed, Jan 4, 2012 at 12:26 AM, Daniel-Constantin Mierla
<mico...@gmail.com> wrote:
> Hello,
>
>
> On 1/3/12 10:08 PM, Ali Jawad wrote:
>>
>> Hi
>>
>> In Xlite/eyebeam I put in the username and one of my 3 kamailio
>> servers respectively as the sip registrar, I.e. register1.domain.com,
>> register2.domain.com and register3.domain.com, that is why I was
>> saying that hashing will create different hashes based on the register
>> domain. With reference to my first related post, one kamailio server
>> is for softphones, one for sip devices and one for mobile phones with
>> SIP software. Each server has a slightly different NAT and Call
>> routing structure.
>
> but your service domain is 'domain.com', specific server addresses (domains)
> per UA type should be set as outbound proxy on the UA devices.
>
>> This is why I wanted to eliminate the domain factor from the hashing
>> procedure, I am sure it chooses the right value from the DB value
>> because it is the same value shown in the log of kamailio against
>> which a comparison is being done and because it works if I put
>> register.domain.com in the domain column rehash the HA! value of the
>> db.
>
>
> When auth_db module is configured to take the hashed value from database
> (calculate_ha1 parameter is 0), there is no more computation of it in
> kamailio -- it is just fetched from database and used -- so it does not
> matter anymore the domains in the sip message.
>
> Check to see if the xlite does not have a realm field that has to be set
> properly.
>
>
>
>>>>>>> values at 0xb7b78dac
>>>>>>>>
>>>>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING
>>>>>>>> [6f966cd9c628f14cdc20172f96a4d065]<====##### This is the value in
>>>>>>>> the DB based on domain.com
>>>>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result =
>>>>>>>> '6f95e6235edca0b7765042ef119fd83b'<====##### This value appears to
>>>>>>>> be the value generated register.domain.com
>>>>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
>>
>> How can I enable the SQL query log ?
>
>
> I don't know by hart, googling should help you.
>
> Cheers,
> Daniel
>
>
>>
>> On Tue, Jan 3, 2012 at 8:12 PM, Daniel-Constantin Mierla
>> <mico...@gmail.com> wrote:
>>>
>>> Hello,
>>>
>>> why are you using register.domain.com as domain for registration? Isn't
>>> domain.com the right one?
>>>
>>> Can you enable the sql query log for mysql server and double check if the
>>> right value (column) is selected from the database table?
>>>
>>> Cheers,
>>> Daniel
>>>
>>>
>>> On 1/3/12 5:13 PM, Ali Jawad wrote:
>>>>
>>>> Hi
>>>> Please see the below, thanks !
>>>>
>>>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>>>> match: support1
>>>>
>>>> U +6.698682 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060
>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport.
>>>> Max-Forwards: 70.
>>>>
>>>>
>>>> Contact:<sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>>>> To: "Test Ast"<sip:suppo...@register.domain.com>.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=f710b930.
>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>> CSeq: 1 REGISTER.
>>>> Expires: 3600.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>> SUBSCRIBE, INFO.
>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.005245 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832
>>>> SIP/2.0 401 Unauthorized.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-05164a466600837d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>>>> To: "Test
>>>>
>>>> Ast"<sip:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=f710b930.
>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>> CSeq: 1 REGISTER.
>>>> WWW-Authenticate: Digest realm="domain.com",
>>>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.428042 yy.yy.yy.146:18832 -> xx.xx.xx.51:5060
>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport.
>>>> Max-Forwards: 70.
>>>>
>>>>
>>>> Contact:<sip:support1@192.168.0.191:18832;rinstance=f8e37e314657e0d7;transport=udp>.
>>>> To: "Test Ast"<sip:suppo...@register.domain.com>.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=f710b930.
>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>> CSeq: 2 REGISTER.
>>>> Expires: 3600.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>> SUBSCRIBE, INFO.
>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>> Authorization: Digest
>>>>
>>>>
>>>> username="support1",realm="domain.com",nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl",uri="sip:register.domain.com",response="6122245b77e2df0b90179304464341e7",algorithm=MD5.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.005146 xx.xx.xx.51:5060 -> yy.yy.yy.146:18832
>>>> SIP/2.0 401 Unauthorized.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:18832;branch=z9hG4bK-d8754z-fc633b21627dca6d-1---d8754z-;rport=18832;received=yy.yy.yy.146.
>>>> To: "Test
>>>>
>>>> Ast"<sip:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=f710b930.
>>>> Call-ID: Y2RmNmFhZWM2MzM5OWQ5ODEwNjc0NzJiNGE2MmQzYjY..
>>>> CSeq: 2 REGISTER.
>>>> WWW-Authenticate: Digest realm="domain.com",
>>>> nonce="TwMpUE8DKCSt/IP7jcNRMbCT4TnbqlHl".
>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> [root@kam-rtp-100-51 mysql]# mail alijaw...@gmail.com< output.txt
>>>> [root@kam-rtp-100-51 mysql]# ngrep -W byline -T support1 -q -d eth1
>>>> interface: eth1 (xx.xx.xx.0/255.255.255.0)
>>>> match: support1
>>>>
>>>>
>>>>
>>>>
>>>> U +5.321505 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060
>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport.
>>>> Max-Forwards: 70.
>>>>
>>>>
>>>> Contact:<sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>>>> To: "Test Ast"<sip:suppo...@register.domain.com>.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=ba705453.
>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>> CSeq: 1 REGISTER.
>>>> Expires: 3600.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>> SUBSCRIBE, INFO.
>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.004782 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610
>>>> SIP/2.0 401 Unauthorized.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-fb28723daa3f772d-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>>>> To: "Test
>>>>
>>>> Ast"<sip:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=ba705453.
>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>> CSeq: 1 REGISTER.
>>>> WWW-Authenticate: Digest realm="domain.com",
>>>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.400706 yy.yy.yy.146:63610 -> xx.xx.xx.51:5060
>>>> REGISTER sip:register.domain.com SIP/2.0.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport.
>>>> Max-Forwards: 70.
>>>>
>>>>
>>>> Contact:<sip:support1@192.168.0.191:63610;rinstance=782b19a2fccc665f;transport=udp>.
>>>> To: "Test Ast"<sip:suppo...@register.domain.com>.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=ba705453.
>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>> CSeq: 2 REGISTER.
>>>> Expires: 3600.
>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>> SUBSCRIBE, INFO.
>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>> Authorization: Digest
>>>>
>>>>
>>>> username="support1",realm="domain.com",nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk",uri="sip:register.domain.com",response="4bfd80b0b836c20b748ee19a1c886284",algorithm=MD5.
>>>> Content-Length: 0.
>>>> .
>>>>
>>>>
>>>> U +0.005302 xx.xx.xx.51:5060 -> yy.yy.yy.146:63610
>>>> SIP/2.0 401 Unauthorized.
>>>> Via: SIP/2.0/UDP
>>>>
>>>>
>>>> 192.168.0.191:63610;branch=z9hG4bK-d8754z-81517d296225234f-1---d8754z-;rport=63610;received=yy.yy.yy.146.
>>>> To: "Test
>>>>
>>>> Ast"<sip:suppo...@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76.
>>>> From: "Test Ast"<sip:suppo...@register.domain.com>;tag=ba705453.
>>>> Call-ID: MzM4Y2IwNzQzZGYwOGI3ZTY1YzYxZjcyZGJjMTMwODI..
>>>> CSeq: 2 REGISTER.
>>>> WWW-Authenticate: Digest realm="domain.com",
>>>> nonce="TwMpsU8DKIX4lvWDwPsV4iUhCl+iOAdk".
>>>> Server: kamailio (3.2.1 (i386/linux)).
>>>> Content-Length: 0.
>>>> .
>>>>
>>>> On Tue, Jan 3, 2012 at 6:08 PM, Daniel-Constantin Mierla
>>>> <mico...@gmail.com> wrote:
>>>>>
>>>>> Hello,
>>>>>
>>>>> I need the entire flow for registration, including the 401 reply and
>>>>> the
>>>>> following REGISTER request.
>>>>>
>>>>> Cheers,
>>>>> Daniel
>>>>>
>>>>>
>>>>> On 1/3/12 5:02 PM, Ali Jawad wrote:
>>>>>>
>>>>>> Hi
>>>>>> Please see the ngrep below, please note that if I use in the db
>>>>>> register.domain.com and generate a hash against it for HA1 it
>>>>>> works,but then the user cant logon to register2.domain.com
>>>>>>
>>>>>>
>>>>>> U +10.630576 xx.yy.yy.yy:20020 -> xx.xx.xx.xx:5060
>>>>>> REGISTER sip:register.domain SIP/2.0.
>>>>>> Via: SIP/2.0/UDP
>>>>>>
>>>>>>
>>>>>>
>>>>>> 192.168.0.191:20020;branch=z9hG4bK-d8754z-af65a442980c375f-1---d8754z-;rport.
>>>>>> Max-Forwards: 70.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Contact:<sip:support1@192.168.0.191:20020;rinstance=4009190a4e109ac6;transport=udp>.
>>>>>> To: "Test Ast"<sip:support1@register.domain>.
>>>>>> From: "Test Ast"<sip:support1@register.domain>;tag=976bb004.
>>>>>> Call-ID: MDFmZDU2ZTI2YjJjMGNlMGFmOTIzMWFmZGQ1ZTNjMDE..
>>>>>> CSeq: 1 REGISTER.
>>>>>> Expires: 3600.
>>>>>> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE,
>>>>>> SUBSCRIBE, INFO.
>>>>>> User-Agent: eyeBeam release 1102q stamp 51814.
>>>>>> Content-Length: 0.
>>>>>>
>>>>>> On Tue, Jan 3, 2012 at 5:58 PM, Daniel-Constantin Mierla
>>>>>> <mico...@gmail.com> wrote:
>>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>>
>>>>>>> On 1/3/12 4:48 PM, Ali Jawad wrote:
>>>>>>>>
>>>>>>>> Hi Daniel
>>>>>>>>
>>>>>>>> Please see
>>>>>>>>
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:184]: allocate 8 bytes for
>>>>>>>> rows
>>>>>>>> at
>>>>>>>> 0xb7b78d74
>>>>>>>> 5(18649) DEBUG:<core> [db_row.c:119]: allocate 20 bytes for
>>>>>>>> row
>>>>>>>> values at 0xb7b78dac
>>>>>>>> 5(18649) DEBUG:<core> [db_val.c:117]: converting STRING
>>>>>>>> [6f966cd9c628f14cdc20172f96a4d065]
>>>>>>>> 5(18649) DEBUG: auth [api.c:210]: check_response: Our result =
>>>>>>>> '6f95e6235edca0b7765042ef119fd83b'
>>>>>>>> 5(18649) DEBUG: auth [api.c:220]: check_response: Authorization
>>>>>>>> failed
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:81]: freeing 1 columns
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:85]: freeing RES_NAMES[0] at
>>>>>>>> 0xb7b78d3c
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:94]: freeing result names at
>>>>>>>> 0xb7b78bfc
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:99]: freeing result types at
>>>>>>>> 0xb7b78c64
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:54]: freeing 1 rows
>>>>>>>> 5(18649) DEBUG:<core> [db_row.c:97]: freeing row values at
>>>>>>>> 0xb7b78dac
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:62]: freeing rows at
>>>>>>>> 0xb7b78d74
>>>>>>>> 5(18649) DEBUG:<core> [db_res.c:136]: freeing result set at
>>>>>>>> 0xb7b78bb0
>>>>>>>> 5(18649) DEBUG: auth [challenge.c:102]: build_challenge_hf:
>>>>>>>> realm='nymgo.com'
>>>>>>>> 5(18649) DEBUG: auth [challenge.c:244]: auth: 'WWW-Authenticate:
>>>>>>>> Digest realm="domain.com", nonce="TwMcuk8DG47SLxatlNdZfyfR8p3OiyAE"
>>>>>>>> '
>>>>>>>>
>>>>>>>> I rebuilt the hashes against domain.com and then tried to connect to
>>>>>>>> sip1.domain.com and sip2.domain.com and sip3.domain.com with all of
>>>>>>>> the having
>>>>>>>>
>>>>>>>>
>>>>>>>> # ----- auth_db params -----
>>>>>>>> #!ifdef WITH_AUTH
>>>>>>>> modparam("auth_db", "db_url", DBURL)
>>>>>>>> modparam("auth_db", "calculate_ha1", 0 )
>>>>>>>> modparam("auth_db", "password_column", "ha1")
>>>>>>>> modparam("auth_db", "load_credentials", "")
>>>>>>>> modparam("auth_db", "use_domain", MULTIDOMAIN)
>>>>>>>>
>>>>>>>> And in the routing process :
>>>>>>>>
>>>>>>>> if (!www_authorize("domain.com", "subscriber"))
>>>>>>>> {
>>>>>>>>
>>>>>>>> www_challenge("domain.com", "0");
>>>>>>>> exit;
>>>>>>>> }
>>>>>>>>
>>>>>>>>
>>>>>>>> +++++++++++++
>>>>>>>>
>>>>>>>> My point is that the hashes are caculated from user:doman:pwd which
>>>>>>>> are extracted from the SIP packet and in this case the domains are
>>>>>>>> sip1,sip2,sip3 while the hashes stored in the database are generated
>>>>>>>> against domain.com
>>>>>>>>
>>>>>>>> If " ha1 is actually hash over 'user:realm:pwd' " shouldn't I have
>>>>>>>> to
>>>>>>>> set the domain/realm in the config file ?
>>>>>>>
>>>>>>>
>>>>>>> the first parameter in www_authorize and www_challenge functions is
>>>>>>> the
>>>>>>> realm and it is used to build the digest response.
>>>>>>>
>>>>>>> Is your phone putting user@domain in authorization header? Can you
>>>>>>> paste
>>>>>>> here the ngrep of registration?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Daniel
>>>>>>>
>>>>>>>
>>>>>>>> I might be wrong....thanks for the help so far.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> On Tue, Jan 3, 2012 at 5:15 PM, Daniel-Constantin Mierla
>>>>>>>> <mico...@gmail.com> wrote:
>>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 1/3/12 4:12 PM, Ali Jawad wrote:
>>>>>>>>>>
>>>>>>>>>> Hi Daniel
>>>>>>>>>> This certainly makes sense, I will try it in a few mins, but what
>>>>>>>>>> I
>>>>>>>>>> observed at Debug Level 3 is that Hash is calculated before
>>>>>>>>>> www_authenticate is executed and it shows HA comparison failed, if
>>>>>>>>>> I
>>>>>>>>>> do use domain.com instead of $fd and use $domain.com in db domain
>>>>>>>>>> field and build HA1 filed based on that, wont Kamailio still try
>>>>>>>>>> to
>>>>>>>>>> build the HA1 hash which it will compare form user:domain:pwd
>>>>>>>>>> where
>>>>>>>>>> domain is fed in to the hash function from the header of the SIP
>>>>>>>>>> packet ?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> the ha1 is actually hash over 'user:realm:pwd' -- it is just common
>>>>>>>>> practice
>>>>>>>>> to use the domain as realm, since realm should be a unique token to
>>>>>>>>> identify
>>>>>>>>> the service, but it can be any random string. realm is given as
>>>>>>>>> parameter
>>>>>>>>> to auth functions in kamailio.cfg
>>>>>>>>>
>>>>>>>>> Cheers,
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>>
>>>>>>>>>> On Tue, Jan 3, 2012 at 5:07 PM, Daniel-Constantin Mierla
>>>>>>>>>> <mico...@gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hello,
>>>>>>>>>>>
>>>>>>>>>>> you can simply use 'domain.com' as realm parameter to
>>>>>>>>>>> authentication
>>>>>>>>>>> function instead of $fd. Also build ha1 and ha1b with domain.com
>>>>>>>>>>> and
>>>>>>>>>>> then
>>>>>>>>>>> you are safe no matter which sip server is used.
>>>>>>>>>>>
>>>>>>>>>>> Of course you can build the realm by striping first token before
>>>>>>>>>>> '.'
>>>>>>>>>>> in
>>>>>>>>>>> $fd
>>>>>>>>>>> and pass it to authentication functions, but not sure if makes
>>>>>>>>>>> sense
>>>>>>>>>>> since
>>>>>>>>>>> it should be always domain.com
>>>>>>>>>>>
>>>>>>>>>>> Cheers,
>>>>>>>>>>> Daniel
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 1/3/12 3:15 PM, Ali Jawad wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi
>>>>>>>>>>>> After some research it seems to me that the only way to achieve
>>>>>>>>>>>> this
>>>>>>>>>>>> is to "try" and change how hashing is done in the source code, a
>>>>>>>>>>>> little bit too ambitious for me, and it means I will have loads
>>>>>>>>>>>> of
>>>>>>>>>>>> problems each time an upgrade is released.
>>>>>>>>>>>>
>>>>>>>>>>>> Or
>>>>>>>>>>>>
>>>>>>>>>>>> Use pseudovariables to fix the value of the $fd value to
>>>>>>>>>>>> something
>>>>>>>>>>>> constant, while this worked for values like $var(y) I was not
>>>>>>>>>>>> able
>>>>>>>>>>>> to
>>>>>>>>>>>> assign/strip $fd to remove the subdomain part.
>>>>>>>>>>>>
>>>>>>>>>>>> Any input please ?
>>>>>>>>>>>>
>>>>>>>>>>>> Regards
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, Jan 3, 2012 at 2:06 PM, Ali
>>>>>>>>>>>> Jawad<ali.ja...@splendor.net>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi
>>>>>>>>>>>>> I do have 3 Kamailio servers, one for mobile phone
>>>>>>>>>>>>> registrations,
>>>>>>>>>>>>> one
>>>>>>>>>>>>> for softphone registrations and one for SIP device
>>>>>>>>>>>>> registrations.
>>>>>>>>>>>>> Each
>>>>>>>>>>>>> of those devices connects to it's perspective kamailio server
>>>>>>>>>>>>>
>>>>>>>>>>>>> sip1.domain.com
>>>>>>>>>>>>> sip2.domain.com
>>>>>>>>>>>>> sip3.domain.com
>>>>>>>>>>>>>
>>>>>>>>>>>>> All 3 Kamailio servers share the same database, and users can
>>>>>>>>>>>>> use
>>>>>>>>>>>>> their kamailio user/pwd on any of the devices, now I want to
>>>>>>>>>>>>> use
>>>>>>>>>>>>> encrypted passwords and remove clear text passwords from the
>>>>>>>>>>>>> database.
>>>>>>>>>>>>> I did test with one server and all is fine,however if a user
>>>>>>>>>>>>> want
>>>>>>>>>>>>> to
>>>>>>>>>>>>> register from the second kamailio server it does not work,
>>>>>>>>>>>>> basically
>>>>>>>>>>>>> because the db domain entry from which the hash is created is
>>>>>>>>>>>>> sip1.domain.com and stored in the db, while the user connects
>>>>>>>>>>>>> from
>>>>>>>>>>>>> to
>>>>>>>>>>>>> sip2.domain.com this eventually generates a different hash.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Is there anyway to overcome this ? Can I exclude Domain from
>>>>>>>>>>>>> Hash
>>>>>>>>>>>>> generation ? Any other option that allows me to do the above ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>> --
>>>>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>>>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>>>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>> --
>>>>>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>>>>>
>>>>> --
>>>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>>>
>>>>
>>> --
>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>
>>
>>
>
> --
> Daniel-Constantin Mierla -- http://www.asipto.com
> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>
--
Ali Jawad
Information Systems Manager
Splendor Telecom (www.splendor.net)
Beirut, Lebanon
Phone: +9611373725/ext 116
FAX: +9611375554
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users@lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
