Re: [Serusers] rfc3261 and ACKs

Hello: Me again. I'm still stuck in the maze of call transfer and call forward all problems. Our gateway vendor suggested a new code release. Using this release completely breaks "normal" 5-digit and other calls that traverse the gateway. The vendor may be onto the problem but their assessment points back to my SER proxy. Given that the proxy works fine in all other calling scenarios with the old gateway code I'd like to know what is significant about their new code and SER. By the way the proxy in question is running 0.8.14 stable. The vendor problem description follows: Thanks,Steve --- cut here --- Here is what I believe the summary of the problem. I believe that the SIP Proxy is not complying with rfc3261 on how to process the ACK when Loose Routing is enabled. Debug Snippet from 12.3(13) ======================= *Mar 2 00:02:16.546: Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 128.91.56.38:5060 From: <sip:343408@128.91.56.38>;tag=5286C18-13B5 To: <sip:68001@net.isc.upenn.edu>;tag=003094c38fd4003a29fa1f0f-264a55c1 Call-ID: 2C5BA6F-15B811CC-8122ED93-3017C386(a)128.91.56.38 Date: Thu, 17 Mar 2005 12:08:16 GMT CSeq: 101 INVITE Server: CSCO/7 Contact: <sip:68001@128.91.56.6:5060> Record-Route: <sip:68001@128.91.56.47;ftag=5286C18-13B5;lr=on> *Mar 2 00:02:16.578: Sent: ACK sip:68001@128.91.56.47:5060;ftag=5286C18-13B5;lr=on SIP/2.0 Via: SIP/2.0/UDP 128.91.56.38:5060 From: <sip:343408@128.91.56.38>;tag=5286C18-13B5 To: <sip:68001@net.isc.upenn.edu>;tag=003094c38fd4003a29fa1f0f-264a55c1 Date: Tue, 02 Mar 1993 00:02:15 GMT Call-ID: 2C5BA6F-15B811CC-8122ED93-3017C386(a)128.91.56.38 Route: <sip:68001@128.91.56.6:5060> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The IP Phones address and that is why the call proceeds further. Because the ACK gets to the phone Debug Snippet from 12.3(11)T3 ========================= As of this code release, the gateways added RFC3261 support for "Loose Routing". Received: SIP/2.0 200 OK Via: SIP/2.0/UDP 128.91.56.38:5060;branch=z9hG4bK0F86 From: <sip:4843433408@128.91.56.38>;tag=60040-250 To: <sip:68001@net.isc.upenn.edu>;tag=003094c38fd4003c61e999c2-43d890a2 Call-ID: 4479EFAB-2BF611D6-800BA01F-9B2E2BA3(a)128.91.56.38 Date: Thu, 17 Mar 2005 12:30:36 GMT CSeq: 101 INVITE Server: CSCO/7 Contact: <sip:68001@128.91.56.6:5060> Record-Route: <sip:68001@128.91.56.47;ftag=60040-250;lr=on> *Mar 1 02:52:58.151: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg: Sent: ACK sip:68001@128.91.56.6:5060 SIP/2.0 Via: SIP/2.0/UDP 128.91.56.38:5060;branch=z9hG4bK116B8 From: <sip:4843433408@128.91.56.38>;tag=60040-250 To: <sip:68001@net.isc.upenn.edu>;tag=003094c38fd4003c61e999c2-43d890a2 Date: Fri, 01 Mar 2002 02:52:57 GMT Call-ID: 4479EFAB-2BF611D6-800BA01F-9B2E2BA3(a)128.91.56.38 Route: <sip:68001@128.91.56.47;ftag=60040-250;lr=on> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Address of the Loose Router which is compliant to route processing in RFC3261 The SIP Proxy (Which is the loose router) should receive this ACK and forward onto the IP Phone or the address in the Req-URI which it isn't. The proxy is actually acting like a Strict router in this instance. The Proxy is adding the loose routing parameters in the headers but doesn't seem to processing the Requests correctly as a loose router. So that is why we are having issues with a basic call in this code release. _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers