[Serusers] Authentication of ReInvite
Vitaly Nikolaev
vnikolaev at intermedia.net
Tue Feb 21 20:27:11 CET 2006
What about loose_route ? ReINVITE must be catched by sloose_route and...
for example in my config almost in the beginning, before all kind of
auth checks:
if (loose_route()) {
if(method == "INVITE") {
xlog("L_DBG", "%ci: route, loose_route said yes
for INVITE msg\n");
route(1);
break;
} else {
xlog("L_DBG", "%ci: route, loose_route said yes
for non INVITE msg\n");
t_relay();
break;
}
};
Then on route(1) there is auth.. (it was before in main route) I do
usual nat stuff and forward the call to whenever Route: field pinted:
t_on_reply("1");
if (! loose_route()) {
if ((!lookup("location") && method == "INVITE" && uri ==
myself) || uri == myself) {
sl_send_reply("404", "Not Found");
break;
};
}
if(method == "INVITE") {
/* Handle re-INVITEs */
if (force_rtp_proxy("l")) {
t_on_reply("2");
} else {
if(force_rtp_proxy(""))
t_on_reply("2");
};
};
if (!t_relay()) {
sl_reply_error();
};
So, ReINVITE will be catched in forst loose_route if and bypass auth
section will be sent to route(1) where it will not do lookup(location)
but send wherever route field pointed.
I am wrong ? :)
-----Original Message-----
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of Pat wang
Sent: Tuesday, February 21, 2006 10:36 AM
To: klaus.mailinglists at pernau.at
Cc: serusers at lists.iptel.org
Subject: Re: [Serusers] Authentication of ReInvite
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 at 192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103 at test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101 at 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 at 192.10.1.13.
Contact: <sip:2103 at 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 at test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101 at test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 INVITE.
Call-ID: 688c36b4-5bb67582-27524277 at 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 at 192.10.1.11:5060
out_uri=sip:2101 at 192.10.1.11:5060 via_cnt==1".
.
U 192.10.1.13:5060 -> 192.10.1.2:5060
ACK sip:2101 at 192.10.1.11:5060 SIP/2.0.
Via: SIP/2.0/UDP 192.10.1.13:5060;branch=z9hG4bK9523f072DDFFC805.
From: "2103" <sip:2103 at test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101 at 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 at 192.10.1.13.
Contact: <sip:2103 at 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 at 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 at test.com:5060>;tag=9783CE70-D2E8B695.
To: <sip:2101 at test.com:5060>;tag=001280b9d20f80a2448c1c57-55a21cf1.
CSeq: 2 ACK.
Call-ID: 688c36b4-5bb67582-27524277 at 192.10.1.13.
Contact: <sip:2103 at 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 at pernau.at>
>To: Pat wang <wangyu39 at hotmail.com>
>CC: serusers at 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
_______________________________________________
Serusers mailing list
serusers at lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
More information about the sr-users
mailing list