21 Feb
2006
21 Feb
'06
2:27 p.m.
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(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On
Behalf Of Pat wang
Sent: Tuesday, February 21, 2006 10:36 AM
To: klaus.mailinglists(a)pernau.at
Cc: serusers(a)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@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.
.
replies
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 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(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers