[Serusers] rfc3261 and ACKs

[Steve Blair]

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.