[Serusers] Authentication of ReInvite

[Klaus Darilion]

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 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
> 
>