Re: [SR-Users] Authentication Feature Question

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 &lt;miconda(a)gmail.com&gt; 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 >> &lt;miconda(a)gmail.com&gt; 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:support1@register.domain.com>. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.3053. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.fce3. >>>> From: "Test Ast"<sip:support1@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 alijawad1(a)gmail.com&lt; >>>> 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:support1@register.domain.com>. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.6b98. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>. >>>> From: "Test Ast"<sip:support1@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:support1@register.domain.com>;tag=e597ca73bdb255490f0cefa03b2fda82.2f76. >>>> From: "Test Ast"<sip:support1@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 >>>> &lt;miconda(a)gmail.com&gt; 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 >>>>>> &lt;miconda(a)gmail.com&gt; 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 >>>>>>>> &lt;miconda(a)gmail.com&gt; 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 >>>>>>>>>> &lt;miconda(a)gmail.com&gt; 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&lt;ali.jawad(a)splendor.net&gt; >>>>>>>>>>>> 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