RE: [Serusers] Authentication of ReInvite - sr-users

21 Feb 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(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.
.

...
 From: Klaus Darilion
&lt;klaus.mailinglists(a)pernau.at&gt;
To: Pat wang &lt;wangyu39(a)hotmail.com&gt;
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 

_______________________________________________
Serusers mailing list
serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers