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; }; };
Thanks,
Pat
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
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
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@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
-
Klaus Darilion -
Pat wang