17 Mar
2005
17 Mar
'05
10:24 p.m.
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.