Hi
When I did set modparam("auth_db", "calculate_ha1", 0 )
Kamailio is crashing see
http://pastebin.com/anaKan0Y
Regards
On Tue, Jan 3, 2012 at 11:54 PM, Ali Jawad <ali.ja...@splendor.net> wrote:
> 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
--
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
