[Serusers] rfc3261 and ACKs

[Jiri Kuthan]

 From these messages we can only see that the upgraded version of the gateway
behaves correctly. It is not sufficient to judge what is going (or not going)
on in the proxy.

-jiri

At 10:24 PM 3/17/2005, Steve Blair wrote:

>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 at 128.91.56.38>;tag=5286C18-13B5
>To: <sip:68001 at net.isc.upenn.edu>;tag=003094c38fd4003a29fa1f0f-264a55c1
>Call-ID: 2C5BA6F-15B811CC-8122ED93-3017C386 at 128.91.56.38
>Date: Thu, 17 Mar 2005 12:08:16 GMT
>CSeq: 101 INVITE
>Server: CSCO/7
>Contact: <sip:68001 at 128.91.56.6:5060>
>Record-Route: <sip:68001 at 128.91.56.47;ftag=5286C18-13B5;lr=on>
>
>*Mar  2 00:02:16.578: Sent:
>ACK sip:68001 at 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 at 128.91.56.38>;tag=5286C18-13B5
>To: <sip:68001 at net.isc.upenn.edu>;tag=003094c38fd4003a29fa1f0f-264a55c1
>Date: Tue, 02 Mar 1993 00:02:15 GMT
>Call-ID: 2C5BA6F-15B811CC-8122ED93-3017C386 at 128.91.56.38
>Route: <sip:68001 at 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 at 128.91.56.38>;tag=60040-250
>To: <sip:68001 at net.isc.upenn.edu>;tag=003094c38fd4003c61e999c2-43d890a2
>Call-ID: 4479EFAB-2BF611D6-800BA01F-9B2E2BA3 at 128.91.56.38
>Date: Thu, 17 Mar 2005 12:30:36 GMT
>CSeq: 101 INVITE
>Server: CSCO/7
>Contact: <sip:68001 at 128.91.56.6:5060>
>Record-Route: <sip:68001 at 128.91.56.47;ftag=60040-250;lr=on>
>
>*Mar  1 02:52:58.151: //-1/xxxxxxxxxxxx/SIP/Msg/ccsipDisplayMsg:
>Sent:
>ACK sip:68001 at 128.91.56.6:5060 SIP/2.0
>Via: SIP/2.0/UDP  128.91.56.38:5060;branch=z9hG4bK116B8
>From: <sip:4843433408 at 128.91.56.38>;tag=60040-250
>To: <sip:68001 at net.isc.upenn.edu>;tag=003094c38fd4003c61e999c2-43d890a2
>Date: Fri, 01 Mar 2002 02:52:57 GMT
>Call-ID: 4479EFAB-2BF611D6-800BA01F-9B2E2BA3 at 128.91.56.38
>Route: <sip:68001 at 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 at lists.iptel.org
>http://lists.iptel.org/mailman/listinfo/serusers

--
Jiri Kuthan            http://iptel.org/~jiri/