I think the reason why this is happening is a broken
ADSL router or
simular, that has a ALG that thinks it supports SIP.
try to turn off SIP_ALG or what it is called on your router. or change
the port on your sipserver to 5062 or something simular.. if you do
that I bet it will work.
-Atle
* Alex Vishnev <avishnev(a)optonline.net> [050416 19:41]:
Alex,
I found this interesting and don't know if this is what is causing
your problem. Normally, when register is issued the Via header
indicates where UAS/proxy should respond. In your first packet, here
is what's happening:
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060
REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..
Via: SIP/2.0/UDP sourceip:22115;
It looks like UA wants to receive the response back on port 22115.
Now, SER sends the response to that port, but it does not look like
UA is listening there, as UA just re-originates REGISTER. The
question I have is why do you have a strange port number, instead of
5060? So it looks to me the reason why you never getting another
REGISTER with credentials is because 401 Unauthorized never makes it
to your Grandstream UA.
So I would do the following:
1. Check with Grandstream to see if your firmware is the
latest/stable version. I use Grandstream Bt100 and have not
problems. I know grandstream is pretty good in resolving problems.
2. If UA is behind NAT, please make sure that grandstream is
configured for NAT traversal.
Hope this helps
Alex Vishnev
-----Original Message-----
From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org]
On Behalf Of Alex
Sent: Saturday, April 16, 2005 12:13 PM
To: aland(a)ox.org; freeradius-users(a)lists.freeradius.org;
serusers(a)lists.iptel.org; amack(a)fhm.edu; daniel(a)voice-system.ro
Subject: [Serusers] Can't solve the problem. Need help.
This is the answer i got on the list :
The second REGISTER (the block 3) must contains the response to the
authentication challenge carried by 401 reply (block 2). That means
that the block 3 must contain an Authorization header with
authentication credentials computed according to HTTP-Digest
authentication mechanism (RFC2617).
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060
REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP
sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex "
<sip:phonenumber@xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
<sip:phonenumber@xxx.xxx.xxx.xxx>..Contact:
<sip:phonenumber@sourceip:22115>..Call-ID:
c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires:
3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F
orwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0....
#
U xxx.xxx.xxx.xxx:5060 -> sourceip:22115
SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP
sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex "
<sip:phonenumber@xxx.xxx.xxx.xxx>;
tag=94a44507e03df901..To:
<sip:phonenumber@xxx.xxx.xxx.xxx>;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
.Call-I
D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate:
Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd595b3558cfdd4
46b83b081d1e2d3cc480"..Server: Sip EXpress router (0.8.14
(i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 "
Noisy feedback tells: pid=21363 req_src_ip=sourceip
req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx
out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
#
U sourceip:26012 -> xxx.xxx.xxx.xxx:5060
REGISTER sip:xxx.xxx.xxx.xxx SIP/2.0..Via: SIP/2.0/UDP
sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex "
<sip:phonenumber@xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
<sip:phonenumber@xxx.xxx.xxx.xxx>..Contact:
<sip:phonenumber@sourceip:22115>..Call-ID:
c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..Expires:
3600..User-Agent: Grandstream HT286 1.0.5.11..Max-F
orwards: 70..Allow:
INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE..Content-Length:
0....
#
U xxx.xxx.xxx.xxx:5060 -> sourceip:22115
SIP/2.0 401 Unauthorized..Via: SIP/2.0/UDP
sourceip:22115;branch=z9hG4bK4913f67fbbcfb571..From: "Alex "
<sip:phonenumber@xxx.xxx.xxx.xxx>;tag=94a44507e03df901..To:
<sip:phonenumber@xxx.xxx.xxx.xxx>;tag=b27e1a1d33761e85846fc98f5f3a7e58.eb04.
.Call-I
D: c9f64c0c2ef27cd1@10.0.0.6..CSeq: 100 REGISTER..WWW-Authenticate:
Digest realm="xxx.xxx.xxx.xxx", nonce="42612dd63c17bd54baef
0f620d6b9b066c23c8ce"..Server: Sip EXpress router (0.8.14
(i386/linux))..Content-Length: 0..Warning: 392 xxx.xxx.xxx.xxx:5060 "
Noisy feedback tells: pid=21360 req_src_ip=sourceip
req_src_port=26012 in_uri=sip:xxx.xxx.xxx.xxx
out_uri=sip:xxx.xxx.xxx.xxx via_cnt==1"....
here is my ser debug:
-------------------------------------
12(21360) SIP Request:
12(21360) method: <REGISTER>
12(21360) uri: <sip:xxx.xxx.xxx.xxx>
12(21360) version: <SIP/2.0>
12(21360) parse_headers: flags=1
12(21360) Found param type 232, <branch> = <z9hG4bKf776a5d04027adc6>;
state=16
12(21360) end of header reached, state=5
12(21360) parse_headers: Via found, flags=1
12(21360) parse_headers: this is the first via
12(21360) After parse_msg...
12(21360) preparing to run routing scripts...
12(21360) REGISTER message received
12(21360) REGISTER: Authenticating user
12(21360) parse_headers: flags=4
12(21360) end of header reached, state=9
12(21360) DEBUG: get_hdr_field: <To> [34];
uri=[sip:phonenumber@xxx.xxx.xxx.xxx]
12(21360) DEBUG: to body [<sip:phonenumber@xxx.xxx.xxx.xxx>
]
12(21360) parse_headers: flags=4096
12(21360) get_hdr_field: cseq <CSeq>: <100> <REGISTER>
12(21360) DEBUG: get_hdr_body : content_length=0
12(21360) found end of header
12(21360) pre_auth(): Credentials with given realm not found
12(21360) REGISTER: challenging user
12(21360) build_auth_hf(): 'WWW-Authenticate: Digest
realm="xxx.xxx.xxx.xxx",
nonce="42613540bb4462c045f7f3fe7714c3a1d6c0bca9"
'
12(21360) parse_headers: flags=-1
12(21360) check_via_address(62.219.160.40, 62.219.160.40, 1)
12(21360) DEBUG:destroy_avp_list: destroing list (nil)
12(21360) receive_msg: cleaning up
For some reason that i can not figure out i don't receive anything on
the radius logs.
it's looks like my granstream ATA286 not going through authectication
process.
when i change the ip of the sip server to different one (2-server)
it's working perfect.
The grandstream ATA286 sending same packets, on the 2 server it's
working, on 1- one nothing happens.
on the problematic server i have clean installation of
freeradius-1.02 radiusclient-4.8 ser-8.14
I tested the installation of the freeradius with the :
radclient -f digest localhost auth testing123
Received response ID 134, code 2, length = 45
Reply-Message = "Hello, test with digest"
radius logs:
----------------------------------------------
rad_recv: Access-Request packet from host 127.0.0.1:32844, id=134,
length=140
User-Name = "test"
Digest-Response = "631d6d73147add2f9e437f59bbc3aeb7"
Digest-Attributes = "\001\013testrealm"
Digest-Attributes = "\002\n1234abcd"
Digest-Attributes = "\003\010INVITE"
Digest-Attributes = "\004\034sip:5555551212@example.com"
Digest-Attributes = "\006\005MD5"
Digest-Attributes = "\n\006test"
Processing the authorize section of radiusd.conf
modcall: entering group authorize for request 0
modcall[authorize]: module "preprocess" returns ok for request 0
modcall[authorize]: module "chap" returns noop for request 0
modcall[authorize]: module "mschap" returns noop for request 0
rlm_digest: Converting Digest-Attributes to something sane...
Digest-Realm = "testrealm"
Digest-Nonce = "1234abcd"
Digest-Method = "INVITE"
Digest-URI = "sip:5555551212@example.com"
Digest-Algorithm = "MD5"
Digest-User-Name = "test"
rlm_digest: Adding Auth-Type = DIGEST
modcall[authorize]: module "digest" returns ok for request 0
rlm_realm: No '@' in User-Name = "test", looking up realm NULL
rlm_realm: No such realm "NULL"
modcall[authorize]: module "suffix" returns noop for request 0
rlm_eap: No EAP-Message, not doing EAP
modcall[authorize]: module "eap" returns noop for request 0
users: Matched entry DEFAULT at line 152
users: Matched entry test at line 215
modcall[authorize]: module "files" returns ok for request 0
modcall: group authorize returns ok for request 0
rad_check_password: Found Auth-Type Digest
auth: type "digest"
Processing the authenticate section of radiusd.conf
modcall: entering group authenticate for request 0
A1 = test:testrealm:test
A2 = INVITE:sip:5555551212@example.com
KD =
1e00d6dbd30441265df6064b9d9b7da9:1234abcd:675b8c827b388805aa252ea38bfb6804
modcall[authenticate]: module "digest" returns ok for request 0
modcall: group authenticate returns ok for request 0
radius_xlat: 'Hello, test with digest'
Sending Access-Accept of id 134 to 127.0.0.1:32844
Reply-Message = "Hello, test with digest"
Finished request 0
I need some help to figure out that's the problem with this server.
And what can be a reason what i don't see any authentication process
in the radius , when the packets coming from ATA286
to authenticate the the user.
Thanks for any help.
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org