Re: [Serusers] lookup_contacts() error after sd_lookup() from the speeddial module- latest cvs ottendorf
On Fri, 2007-02-23 at 01:39 +0100, TZieleniewski wrote:
Hi Michal
Michal Matyska napisał(a):
Hi,
so I've finally found some time and checked the code and from that point of view:
sd_lookup rewrites request-uri, so basically you should call t_relay if it was successful. (as the target of the speeddial might be different domain you should relay it).
I did like you wrote and called t_relay() after positive result of the sd_lookup() unfortunatelly the result was the same as in the previously tried scenarios when I tried to forward the sip message again to ser. The URI as you said was rewritten and again received and processed through the logic, but the invocation of
OK, so sd_lookup solved.
the lookup_user("$t.uid","@ruri") in the 'second round' didn't cause the 'second round' lookup_contacts() to return the positive result.
lookup_contacts searches in the TO / USER avp list only for avp with uid name. If such avp is not found the TO header uri is parsed and user uid looked in the db and new avp stored. (This is correct for REGISTER (but you won't use lookup_contacts within register :), for other request methods it should use the request-uri).
Which makes me crazy related to your observations, it is supposed to be working this way (but you reported it as failing): ... lookup_user("$tu.uid", "@ruri"); if (lookup_contacts("location")) { t_relay(); drop; }
lookup_contacts() works but only in the 'first round' with the lookup_user("$t.uid","@ruri").
It works by accident, if you don't set user/to avp uid, then the TO header is used for the AOR building (I've already created SER-234 bug report). So in the first loop, the To and request uri are the same and the user is found correctly. The second round (e.g. due to sd_lookup) is not working, as the To header is the original one.
I tried to invoke lookup_user("$tu.uid","@ruri") after the positive invocation of lookup_user("$t.uid","@ruri") to have the uid in the to / user track but even with the uid avp present the result of the second lookup_contacts() was negative (user was registered and available - direct call worked without any problems).
That's strange as we use it everywhere and it works.... Check uid of the registered contact (location table) against the uid found by lookup_user before the lookup_contacts call (dump_attrs).
Michal
Michal we have the source if the problem,finally!!!
On Fri, 2007-02-23 at 01:39 +0100, TZieleniewski wrote:
Hi Michal
Michal Matyska napisał(a):
Hi,
so I've finally found some time and checked the code and from that point of view:
sd_lookup rewrites request-uri, so basically you should call t_relay if it was successful. (as the target of the speeddial might be different domain you should relay it).
I did like you wrote and called t_relay() after positive result of the sd_lookup() unfortunatelly the result was the same as in the previously tried scenarios when I tried to forward the sip message again to ser. The URI as you said was rewritten and again received and processed through the logic, but the invocation of
OK, so sd_lookup solved.
the lookup_user("$t.uid","@ruri") in the 'second round' didn't cause the 'second round' lookup_contacts() to return the positive result.
lookup_contacts searches in the TO / USER avp list only for avp with uid name. If such avp is not found the TO header uri is parsed and user uid looked in the db and new avp stored. (This is correct for REGISTER (but you won't use lookup_contacts within register :), for other request methods it should use the request-uri).
Which makes me crazy related to your observations, it is supposed to be working this way (but you reported it as failing): ... lookup_user("$tu.uid", "@ruri"); if (lookup_contacts("location")) { t_relay(); drop; }
lookup_contacts() works but only in the 'first round' with the lookup_user("$t.uid","@ruri").
It works by accident, if you don't set user/to avp uid, then the TO header is used for the AOR building (I've already created SER-234 bug report). So in the first loop, the To and request uri are the same and the user is found correctly. The second round (e.g. due to sd_lookup) is not working, as the To header is the original one.
I tried to invoke lookup_user("$tu.uid","@ruri") after the positive invocation of lookup_user("$t.uid","@ruri") to have the uid in the to / user track but even with the uid avp present the result of the second lookup_contacts() was negative (user was registered and available - direct call worked without any problems).
That's strange as we use it everywhere and it works.... Check uid of the registered contact (location table) against the uid found by lookup_user before the lookup_contacts call (dump_attrs).
Ok I checked it and I think here is the problem!!:) The registration procedure and the invocation of the save_contacts("location") gives probably improper record because the uid column contains only the user name part of the sip uri without the '@domain' part. So this is probably a bug in the save_contacts() function. That is why lookup_contacts didn't find the user. When I changed it manually by adding the domain part to the value in the uid column it worked (with lookup_user("$tu.uid",""@ruri") as well as speeddial stuff) !! Strange that it somehow worked with "$t.uid".
What do you suggest to do to make it work??
contents of the location table:
mysql> select uid,aor,contact from location; +-------+---------------------------+--------------------------------------------------------+ | uid | aor | contact | +-------+---------------------------+--------------------------------------------------------+ | tomix | sip:tomix@tezet.no-ip.org | sip:tomix@192.168.1.2:7060 | | misia | sip:misia@tezet.no-ip.org | sip:misia@192.168.1.10:4532;rinstance=87be1b88955eac60 | +-------+---------------------------+--------------------------------------------------------+
dialog between ser and uac:
SEND TIME: 4013450560
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450588
RECEIVE << 192.168.1.2:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.1ef1
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
WWW-Authenticate: Digest realm="tezet.no-ip.org", nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6", qop="auth"
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3880 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
SEND TIME: 4013450589
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Expires: 1800
Authorization: Digest username="tomix",realm="tezet.no-ip.org",nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6",response="53452762af6fa51b21d4d40bd47cc991",uri="sip:tezet.no-ip.org",qop=auth,cnonce="08371BFB0A5C8A394D9ED6BB98BAC70F",nc=00000001
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450645
RECEIVE << 192.168.1.2:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.890b
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Contact: sip:tomix@192.168.1.2:7060;expires=1800
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3883 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
Cheers Tomasz
Michal
Michal we have the source if the problem,finally!!!
On Fri, 2007-02-23 at 01:39 +0100, TZieleniewski wrote:
Hi Michal
Michal Matyska napisał(a):
Hi,
so I've finally found some time and checked the code and from that point of view:
sd_lookup rewrites request-uri, so basically you should call t_relay if it was successful. (as the target of the speeddial might be different domain you should relay it).
I did like you wrote and called t_relay() after positive result of the sd_lookup() unfortunatelly the result was the same as in the previously tried scenarios when I tried to forward the sip message again to ser. The URI as you said was rewritten and again received and processed through the logic, but the invocation of
OK, so sd_lookup solved.
the lookup_user("$t.uid","@ruri") in the 'second round' didn't cause the 'second round' lookup_contacts() to return the positive result.
lookup_contacts searches in the TO / USER avp list only for avp with uid name. If such avp is not found the TO header uri is parsed and user uid looked in the db and new avp stored. (This is correct for REGISTER (but you won't use lookup_contacts within register :), for other request methods it should use the request-uri).
Which makes me crazy related to your observations, it is supposed to be working this way (but you reported it as failing): ... lookup_user("$tu.uid", "@ruri"); if (lookup_contacts("location")) { t_relay(); drop; }
lookup_contacts() works but only in the 'first round' with the lookup_user("$t.uid","@ruri").
It works by accident, if you don't set user/to avp uid, then the TO header is used for the AOR building (I've already created SER-234 bug report). So in the first loop, the To and request uri are the same and the user is found correctly. The second round (e.g. due to sd_lookup) is not working, as the To header is the original one.
I tried to invoke lookup_user("$tu.uid","@ruri") after the positive invocation of lookup_user("$t.uid","@ruri") to have the uid in the to / user track but even with the uid avp present the result of the second lookup_contacts() was negative (user was registered and available - direct call worked without any problems).
That's strange as we use it everywhere and it works.... Check uid of the registered contact (location table) against the uid found by lookup_user before the lookup_contacts call (dump_attrs).
Ok I checked it and I think here is the problem!!:) The registration procedure and the invocation of the save_contacts("location") gives probably improper record because the uid column contains only the user name part of the sip uri without the '@domain' part. So this is probably a bug in the save_contacts() function. That is why lookup_contacts didn't find the user. When I changed it manually by adding the domain part to the value in the uid column it worked (with lookup_user("$tu.uid",""@ruri") as well as speeddial stuff) !! Strange that it somehow worked with "$t.uid".
What do you suggest to do to make it work??
contents of the location table:
mysql> select uid,aor,contact from location; +-------+---------------------------+--------------------------------------------------------+ | uid | aor | contact | +-------+---------------------------+--------------------------------------------------------+ | tomix | sip:tomix@tezet.no-ip.org | sip:tomix@192.168.1.2:7060 | | misia | sip:misia@tezet.no-ip.org | sip:misia@192.168.1.10:4532;rinstance=87be1b88955eac60 | +-------+---------------------------+--------------------------------------------------------+
One more remark. The credentials table contains the correct value of the uid: mysql> select auth_username,did,uid,realm from credentials; +---------------+-----------------+-------------------------+-----------------+ | auth_username | did | uid | realm | +---------------+-----------------+-------------------------+-----------------+ | tomix | tezet.no-ip.org | tomix@tezet.no-ip.org | tezet.no-ip.org | | hellboy | tezet.no-ip.org | hellboy@tezet.no-ip.org | tezet.no-ip.org | | admin | tezet.no-ip.org | admin@tezet.no-ip.org | tezet.no-ip.org | | misia | tezet.no-ip.org | misia@tezet.no-ip.org | tezet.no-ip.org | | testser | tezet.no-ip.org | testser@tezet.no-ip.org | tezet.no-ip.org | +---------------+-----------------+-------------------------+-----------------+
Perhaps the save contacts insert the auth_username value instead of uid into the location table??
dialog between ser and uac:
SEND TIME: 4013450560
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450588
RECEIVE << 192.168.1.2:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.1ef1
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
WWW-Authenticate: Digest realm="tezet.no-ip.org", nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6", qop="auth"
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3880 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
SEND TIME: 4013450589
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Expires: 1800
Authorization: Digest username="tomix",realm="tezet.no-ip.org",nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6",response="53452762af6fa51b21d4d40bd47cc991",uri="sip:tezet.no-ip.org",qop=auth,cnonce="08371BFB0A5C8A394D9ED6BB98BAC70F",nc=00000001
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450645
RECEIVE << 192.168.1.2:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.890b
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Contact: sip:tomix@192.168.1.2:7060;expires=1800
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3883 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
Cheers Tomasz
Michal
Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Ok I checked it and I think here is the problem!!:) The registration procedure and the invocation of the save_contacts("location") gives probably improper record because the uid column contains only the user name part of the sip uri without the '@domain' part. So this is probably a bug in the save_contacts() function. That is why lookup_contacts didn't find the user. When I changed it manually by adding the domain part to the value in the uid column it worked (with lookup_user("$tu.uid",""@ruri") as well as speeddial stuff) !! Strange that it somehow worked with "$t.uid".
What do you suggest to do to make it work??
contents of the location table:
mysql> select uid,aor,contact from location; +-------+---------------------------+--------------------------------------------------------+ | uid | aor | contact | +-------+---------------------------+--------------------------------------------------------+ | tomix | sip:tomix@tezet.no-ip.org | sip:tomix@192.168.1.2:7060 | | misia | sip:misia@tezet.no-ip.org | sip:misia@192.168.1.10:4532;rinstance=87be1b88955eac60 | +-------+---------------------------+--------------------------------------------------------+
One more remark. The credentials table contains the correct value of the uid: mysql> select auth_username,did,uid,realm from credentials; +---------------+-----------------+-------------------------+-----------------+ | auth_username | did | uid | realm | +---------------+-----------------+-------------------------+-----------------+ | tomix | tezet.no-ip.org | tomix@tezet.no-ip.org | tezet.no-ip.org | | hellboy | tezet.no-ip.org | hellboy@tezet.no-ip.org | tezet.no-ip.org | | admin | tezet.no-ip.org | admin@tezet.no-ip.org | tezet.no-ip.org | | misia | tezet.no-ip.org | misia@tezet.no-ip.org | tezet.no-ip.org | | testser | tezet.no-ip.org | testser@tezet.no-ip.org | tezet.no-ip.org | +---------------+-----------------+-------------------------+-----------------+
Perhaps the save contacts insert the auth_username value instead of uid into the location table??
The authorization code loads extra attributes from the database (using authdb module it is just uid). Please, set debug=4 and check the output... it should contain line containing auth_db:generate_avps: set string AVP 'uid=....'
Michal
Hi,
now it's a lot easier to explain :-)
If you use authentization of requests (and you do), then the username from the auth header is put into the from/user uid avp and used in save_contacts.
You can either change username in your client to tomix@<whatever.domain> and try again (should work) or change your ser.cfg to contain:
if (method==REGISTER) { ... delete_attr("$fu.uid"); lookup_user("From"); #or lookup_user("$fu.uid","@from"); #or lookup_user("$fu.uid","@msg["your-header-name"]");
if (!save_contacts()) { ... } }
(I did not check by ser, should be ok ;-)
Michal
On Fri, 2007-02-23 at 16:37 +0100, tzieleniewski wrote:
Michal we have the source if the problem,finally!!!
On Fri, 2007-02-23 at 01:39 +0100, TZieleniewski wrote:
Hi Michal
Michal Matyska napisał(a):
Hi,
so I've finally found some time and checked the code and from that point of view:
sd_lookup rewrites request-uri, so basically you should call t_relay if it was successful. (as the target of the speeddial might be different domain you should relay it).
I did like you wrote and called t_relay() after positive result of the sd_lookup() unfortunatelly the result was the same as in the previously tried scenarios when I tried to forward the sip message again to ser. The URI as you said was rewritten and again received and processed through the logic, but the invocation of
OK, so sd_lookup solved.
the lookup_user("$t.uid","@ruri") in the 'second round' didn't cause the 'second round' lookup_contacts() to return the positive result.
lookup_contacts searches in the TO / USER avp list only for avp with uid name. If such avp is not found the TO header uri is parsed and user uid looked in the db and new avp stored. (This is correct for REGISTER (but you won't use lookup_contacts within register :), for other request methods it should use the request-uri).
Which makes me crazy related to your observations, it is supposed to be working this way (but you reported it as failing): ... lookup_user("$tu.uid", "@ruri"); if (lookup_contacts("location")) { t_relay(); drop; }
lookup_contacts() works but only in the 'first round' with the lookup_user("$t.uid","@ruri").
It works by accident, if you don't set user/to avp uid, then the TO header is used for the AOR building (I've already created SER-234 bug report). So in the first loop, the To and request uri are the same and the user is found correctly. The second round (e.g. due to sd_lookup) is not working, as the To header is the original one.
I tried to invoke lookup_user("$tu.uid","@ruri") after the positive invocation of lookup_user("$t.uid","@ruri") to have the uid in the to / user track but even with the uid avp present the result of the second lookup_contacts() was negative (user was registered and available - direct call worked without any problems).
That's strange as we use it everywhere and it works.... Check uid of the registered contact (location table) against the uid found by lookup_user before the lookup_contacts call (dump_attrs).
Ok I checked it and I think here is the problem!!:) The registration procedure and the invocation of the save_contacts("location") gives probably improper record because the uid column contains only the user name part of the sip uri without the '@domain' part. So this is probably a bug in the save_contacts() function. That is why lookup_contacts didn't find the user. When I changed it manually by adding the domain part to the value in the uid column it worked (with lookup_user("$tu.uid",""@ruri") as well as speeddial stuff) !! Strange that it somehow worked with "$t.uid".
What do you suggest to do to make it work??
contents of the location table:
mysql> select uid,aor,contact from location; +-------+---------------------------+--------------------------------------------------------+ | uid | aor | contact | +-------+---------------------------+--------------------------------------------------------+ | tomix | sip:tomix@tezet.no-ip.org | sip:tomix@192.168.1.2:7060 | | misia | sip:misia@tezet.no-ip.org | sip:misia@192.168.1.10:4532;rinstance=87be1b88955eac60 | +-------+---------------------------+--------------------------------------------------------+
dialog between ser and uac:
SEND TIME: 4013450560
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
Expires: 1800
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450588
RECEIVE << 192.168.1.2:5060
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK00AE1BA0140862663E62589D4B99BA2E
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.1ef1
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20674 REGISTER
WWW-Authenticate: Digest realm="tezet.no-ip.org", nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6", qop="auth"
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3880 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
SEND TIME: 4013450589
SEND >> 192.168.1.2:5060
REGISTER sip:tezet.no-ip.org SIP/2.0
Via: SIP/2.0/UDP 192.168.1.2:7060;rport;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org
Contact: "tomix" sip:tomix@192.168.1.2:7060
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Expires: 1800
Authorization: Digest username="tomix",realm="tezet.no-ip.org",nonce="45df09774a97d20cbdb5dba7d76f92a083a8f6c6",response="53452762af6fa51b21d4d40bd47cc991",uri="sip:tezet.no-ip.org",qop=auth,cnonce="08371BFB0A5C8A394D9ED6BB98BAC70F",nc=00000001
Max-Forwards: 70
User-Agent: X-Lite release 1105d
Content-Length: 0
RECEIVE TIME: 4013450645
RECEIVE << 192.168.1.2:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.1.2:7060;rport=7060;branch=z9hG4bK5D5EC629F3D67C6A54210C1CB8489E7D
From: tomix sip:tomix@tezet.no-ip.org;tag=1047748579
To: tomix sip:tomix@tezet.no-ip.org;tag=b27e1a1d33761e85846fc98f5f3a7e58.890b
Call-ID: 0FF3A0C155B1CD791DAF26938F078201@tezet.no-ip.org
CSeq: 20675 REGISTER
Contact: sip:tomix@192.168.1.2:7060;expires=1800
Server: Sip EXpress router (2.0.0-rc0-tls (i386/linux))
Content-Length: 0
Warning: 392 192.168.1.2:5060 "Noisy feedback tells: pid=3883 req_src_ip=192.168.1.2 req_src_port=7060 in_uri=sip:tezet.no-ip.org out_uri=sip:tezet.no-ip.org via_cnt==1"
Cheers Tomasz
Michal
-
Michal Matyska -
TZieleniewski