21 Feb
2006
21 Feb
'06
11:55 a.m.
Morning everyone,
Has anyone tried authentication of Re-INVITE on SER? When I add the
proxy_challenge to the ReInvite in the SER configure file, the ACK for 407
from the client is porxied by SER to the other side. The signalling looks
like:
caller----------------------SER---------------------Callee
------------------ normal call setup--------------------
--------------------------blha blha-----------------------
-------------------------------------------------------------
---call hold Re-Invite--->
<--- 407 challenge------
--------ACK----------------->
-------------ACK---------> *** This is not
to be proxied!
----ReInvite--------------->
----------------------etc etc............
Anyone seen this while doing similar thing on SER? How can I stop SER
proxing this ACK just like the way SER treat the original Invite with
authentiacion?
Here is the authentication part in the loose route block of my SER config
file:
if (method=="INVITE") {
if (!proxy_authorize("test.com", "subscriber")) {
proxy_challenge( "test.com", "0");
break;
};
};
Thanks,
Pat
21 Feb
21 Feb
2:04 p.m.
Pat wang wrote:
Morning everyone,
Has anyone tried authentication of Re-INVITE on SER? When I add the
proxy_challenge to the ReInvite in the SER configure file, the ACK for
407 from the client is porxied by SER to the other side. The signalling
looks like:
caller----------------------SER---------------------Callee
------------------ normal call setup--------------------
--------------------------blha blha-----------------------
-------------------------------------------------------------
---call hold Re-Invite--->
<--- 407 challenge------
--------ACK----------------->
-------------ACK---------> *** This is
not to be proxied!
----ReInvite--------------->
----------------------etc etc............
Anyone seen this while doing similar thing on SER? How can I stop SER
proxing this ACK just like the way SER treat the original Invite with
authentiacion?
Here is the authentication part in the loose route block of my SER
config file:
if (method=="INVITE") {
if (!proxy_authorize("test.com", "subscriber")) {
proxy_challenge( "test.com", "0");
break;
};
};
AFAIK, proxy challenge sends a stateless reply. ACK to stateless replies
should be absorbed by ser immediately without entering the ser.cfg
routing script. Thus, probably ser can't detect this ACK as stateless.
Please watch syslog (debug=4 and "tail -f /var/log/syslog|grep -v qm_")
and verify why ser does nto detect a "stateless" ACK.
Also verifiy the ACK if all the tags are correctly copied from 40x to
the ACK. Maybe this is cause by the branch=0 bug?
regards
klaus
5:36 p.m.
Hi Klaus,
The /var/log/messages does not show any thing but here is the ngrep of the
Re-Invite. I couldn't find anything wrong in the ACK for 407. Do you have
any other thoughts?
Thanks,
Pat
U 192.10.1.13:5060 -> 192.10.1.2:5060
INVITE sip:2101@192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
Route:
<sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>;ftag=9783CE70-D2E8B695;lr=on>.
CSeq: 2 INVITE.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY,
PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Supported: 100rel,timer,replace.
Allow-Events: talk,hold,conference.
Max-Forwards: 70.
Content-Type: application/sdp.
Content-Length: 197.
.
v=0.
o=- 1137681804 1137681804 IN IP4 192.10.1.13.
s=Polycom IP Phone.
c=IN IP4 192.10.1.13.
t=0 0.
m=audio 2252 RTP/AVP 0 101.
a=sendonly.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
U 192.10.1.2:5060 -> 192.10.1.13:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 INVITE.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Proxy-Authenticate: Digest realm="test.com",
nonce="43fb2e105733df37da780239bc94922da01a4177".
Server: Sip EXpress router (0.9.6 (i386/linux)).
Content-Length: 0.
Warning: 392 192.10.1.2:5060 "Noisy feedback tells: pid=26457
req_src_ip=192.10.1.13 req_src_port=5060 in_uri=sip:2101@192.10.1.11:5060
out_uri=sip:2101@192.10.1.11:5060 via_cnt==1".
.
U 192.10.1.13:5060 -> 192.10.1.2:5060
ACK sip:2101@192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
Route:
<sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>;ftag=9783CE70-D2E8B695;lr=on>.
CSeq: 2 ACK.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY,
PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Max-Forwards: 70.
Content-Length: 0.
.
U 192.10.1.2:5060 -> 192.10.1.11:5060
ACK sip:2101@192.10.1.11:5060 SIP/2.0.
Record-Route: <sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>.
Via: SIP/2.0/UDP 192.10.1.2;branch=0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 ACK.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE, NOTIFY,
PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Max-Forwards: 16.
Content-Length: 0.
P-hint: rr-enforced.
.
From: Klaus Darilion
<klaus.mailinglists(a)pernau.at>
To: Pat wang <wangyu39(a)hotmail.com>
CC: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Authentication of ReInvite
Date: Tue, 21 Feb 2006 13:04:59 +0100
Pat wang wrote:
Morning everyone,
Has anyone tried authentication of Re-INVITE on SER? When I add the
proxy_challenge to the ReInvite in the SER configure file, the ACK for 407
from the client is porxied by SER to the other side. The signalling looks
like:
caller----------------------SER---------------------Callee
------------------ normal call setup--------------------
--------------------------blha blha-----------------------
-------------------------------------------------------------
---call hold Re-Invite--->
<--- 407 challenge------
--------ACK----------------->
-------------ACK---------> *** This is
not to be proxied!
----ReInvite--------------->
----------------------etc etc............
Anyone seen this while doing similar thing on SER? How can I stop SER
proxing this ACK just like the way SER treat the original Invite with
authentiacion?
Here is the authentication part in the loose route block of my SER config
file:
if (method=="INVITE") {
if (!proxy_authorize("test.com", "subscriber")) {
proxy_challenge( "test.com", "0");
break;
};
};
AFAIK, proxy challenge sends a stateless reply. ACK to stateless replies
should be absorbed by ser immediately without entering the ser.cfg routing
script. Thus, probably ser can't detect this ACK as stateless.
Please watch syslog (debug=4 and "tail -f /var/log/syslog|grep -v qm_")
and verify why ser does nto detect a "stateless" ACK.
Also verifiy the ACK if all the tags are correctly copied from 40x to the
ACK. Maybe this is cause by the branch=0 bug?
regards
klaus
7:42 p.m.
Maybe the ACK is loose_route processed (because auf the Route header)?
sorry, no more ideas
klaus
Pat wang wrote:
Hi Klaus,
The /var/log/messages does not show any thing but here is the ngrep of
the Re-Invite. I couldn't find anything wrong in the ACK for 407. Do you
have any other thoughts?
Thanks,
Pat
U 192.10.1.13:5060 -> 192.10.1.2:5060
INVITE sip:2101@192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
Route:
<sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>;ftag=9783CE70-D2E8B695;lr=on>.
CSeq: 2 INVITE.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Supported: 100rel,timer,replace.
Allow-Events: talk,hold,conference.
Max-Forwards: 70.
Content-Type: application/sdp.
Content-Length: 197.
.
v=0.
o=- 1137681804 1137681804 IN IP4 192.10.1.13.
s=Polycom IP Phone.
c=IN IP4 192.10.1.13.
t=0 0.
m=audio 2252 RTP/AVP 0 101.
a=sendonly.
a=rtpmap:0 PCMU/8000.
a=rtpmap:101 telephone-event/8000.
U 192.10.1.2:5060 -> 192.10.1.13:5060
SIP/2.0 407 Proxy Authentication Required.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 INVITE.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Proxy-Authenticate: Digest realm="test.com",
nonce="43fb2e105733df37da780239bc94922da01a4177".
Server: Sip EXpress router (0.9.6 (i386/linux)).
Content-Length: 0.
Warning: 392 192.10.1.2:5060 "Noisy feedback tells: pid=26457
req_src_ip=192.10.1.13 req_src_port=5060
in_uri=sip:2101@192.10.1.11:5060 out_uri=sip:2101@192.10.1.11:5060
via_cnt==1".
.
U 192.10.1.13:5060 -> 192.10.1.2:5060
ACK sip:2101@192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
Route:
<sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>;ftag=9783CE70-D2E8B695;lr=on>.
CSeq: 2 ACK.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Max-Forwards: 70.
Content-Length: 0.
.
U 192.10.1.2:5060 -> 192.10.1.11:5060
ACK sip:2101@192.10.1.11:5060 SIP/2.0.
Record-Route: <sip:192.10.1.2;ftag=9783CE70-D2E8B695;lr=on>.
Via: SIP/2.0/UDP 192.10.1.2;branch=0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103@test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101@test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 ACK.
Call-ID: 688c36b4-5bb67582-27524277(a)192.10.1.13.
Contact: <sip:2103@192.10.1.13:5060>.
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, INFO, MESSAGE, SUBSCRIBE,
NOTIFY, PRACK, UPDATE, REFER.
User-Agent: PolycomSoundPointIP-SPIP_500-UA/1.3.0.
Max-Forwards: 16.
Content-Length: 0.
P-hint: rr-enforced.
.
From: Klaus Darilion
<klaus.mailinglists(a)pernau.at>
To: Pat wang <wangyu39(a)hotmail.com>
CC: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Authentication of ReInvite
Date: Tue, 21 Feb 2006 13:04:59 +0100
Pat wang wrote:
Morning everyone,
Has anyone tried authentication of Re-INVITE on SER? When I add the
proxy_challenge to the ReInvite in the SER configure file, the ACK
for 407 from the client is porxied by SER to the other side. The
signalling looks like:
caller----------------------SER---------------------Callee
------------------ normal call setup--------------------
--------------------------blha blha-----------------------
-------------------------------------------------------------
---call hold Re-Invite--->
<--- 407 challenge------
--------ACK----------------->
-------------ACK---------> *** This
is not to be proxied!
----ReInvite--------------->
----------------------etc etc............
Anyone seen this while doing similar thing on SER? How can I stop SER
proxing this ACK just like the way SER treat the original Invite with
authentiacion?
Here is the authentication part in the loose route block of my SER
config file:
if (method=="INVITE") {
if (!proxy_authorize("test.com", "subscriber")) {
proxy_challenge( "test.com", "0");
break;
};
};
AFAIK, proxy challenge sends a stateless reply. ACK to stateless
replies should be absorbed by ser immediately without entering the
ser.cfg routing script. Thus, probably ser can't detect this ACK as
stateless.
Please watch syslog (debug=4 and "tail -f /var/log/syslog|grep -v qm_")
and verify why ser does nto detect a "stateless" ACK.
Also verifiy the ACK if all the tags are correctly copied from 40x to
the ACK. Maybe this is cause by the branch=0 bug?
regards
klaus
6852
days inactive
6852
days old
3 comments
2 participants
participants (2)
-
Klaus Darilion -
Pat wang