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@iptel.org [mailto:serusers-bounces@lists.iptel.org] On Behalf Of Pat wang Sent: Tuesday, February 21, 2006 10:36 AM To: klaus.mailinglists@pernau.at Cc: serusers@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@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@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@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@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@pernau.at To: Pat wang wangyu39@hotmail.com CC: serusers@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@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers