Subject: [SIP] Request-uri does not match record-route header...

From: Sherman Gong <[email-masked]>
Date: Thu, 12 Apr 2001 09:09:06 -0600

Having a problem whereby the request-uri used in the ACK does not match 
that which was in the record-route header in the 200 OK.  Per the SIP bis 
draft (section 6.39 in the 02 version), the first Route header (constructed 
from the record-route header) should be removed and used as the 
Request-URI.  I included a couple of notes below asterisks (******).

I have been getting conflicting arguments on which requirement this should 
follow.  Need to determine which spec. is correct.

1)  6.29 Record-Route

     The Record-Route request and response header field is added to a
     request by any proxy that insists on being in the path of subsequent
     requests for the same call leg. It contains a globally reachable
     Request-URI that identifies the proxy server. Each proxy server adds
     its Request-URI to the beginning of the list.

      The server copies the Record-Route header field unchanged into the
      response. (Record-Route is only relevant for 2xx responses.)

      The calling user agent client copies the Record-Route header into a
      Route header field of subsequent requests within the same call leg,
      reversing the order of requests, so that the first entry is closest
      to the user agent client. If the response contained a Contact header
      field, the calling user agent adds its content as the last Route
      header. Unless this would cause a loop, any client MUST send any
      subsequent requests for this call leg to the first Request-URI in the
      Route request header field and remove that entry.

    The above describes building Route headers from the Record-Route headers,
    and sending subsequent requests to the first Route, removing that entry.

  6.33 Route

      The Route request-header field determines the route taken by a
      request. Each host removes the first entry and then proxies the
      request to the host listed in that entry, also using it as the
      Request-URI. The operation is further described in Section 6.29.

    The above notes that the Route header used to proxy a request should also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request 
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).

Or

2)  from page 20 of the draft

     The maddr parameter indicates the server address to be contacted for 
this user, overriding the address supplied in the host field. This
     address is typically, but not necessarily, a multicast address. The 
maddr field can be used to force requests from traveling users to visit
     a home proxy even if an outbound proxy is used.

c5300-3#
*Jan 22 08:34:05.632: ISDN Se0:23: RX <-  SETUP pd = 8  callref = 0x0001
*Jan 22 08:34:05.632:         Bearer Capability i = 0x8090A2
*Jan 22 08:34:05.636:         Channel ID i = 0xA98381
*Jan 22 08:34:05.636:         Calling Party Number i = 0x2180, '2062011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.636:         Called Party Number i = 0xA1, '3032011001',
Plan:ISDN, Type:National
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_NONE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_NONE)
*Jan 22 08:34:05.652:  Queued event from SIP SPI : SIPSPI_EV_CC_CALL_SETUP
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_call_setup
*Jan 22 08:34:05.652:  act_idle_call_setup:Not using Voice Class Codec

*Jan 22 08:34:05.652: act_idle_call_setup: preferred_codec set[0] type
:g711ulaw bytes: 160
*Jan 22 08:34:05.652:  Queued event from SIP SPI :
SIPSPI_EV_CREATE_CONNECTION
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_NONE)  to (STATE_IDLE, SUBSTATE_CONNECTING)
*Jan 22 08:34:05.652: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_IDLE, SUBSTATE_CONNECT
ING)
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created
*Jan 22 08:34:05.652: CCSIP-SPI-CONTROL:  act_idle_connection_created:
Connid(1) created to 192.168.10.114:5060, local_p
ort 50727
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sipSPIOutgoingCallSDP
*Jan 22 08:34:05.656: sipSPIAddLocalContact
*Jan 22 08:34:05.656:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:05.656: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:05.656: 0x6221E11C : State change from (STATE_IDLE,
SUBSTATE_CONNECTING)  to (STATE_SENT_INVITE, SUBSTATE_
NONE)
*Jan 22 08:34:05.660: ISDN Se0:23: TX ->  CALL_PROC pd = 8  callref = 0x8001
*Jan 22 08:34:05.660:         Channel ID i = 0xA98381
*Jan 22 08:34:05.660: Sent:
INVITE sip:[email-masked];user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" <sip:[email-masked]>
To: <sip:[email-masked];user=phone>
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: [email-masked]
Cisco-Guid: 3954197371-3232041567-0-1845248076
User-Agent: Cisco SIP Gateway (UAC)/IOS 12.x
CSeq: 101 INVITE
Max-Forwards: 6
Timestamp: 948530045
Contact: <sip:[email-masked]:5060;user=phone>
Expires: 180
Content-Type: application/sdp
Content-Length: 138

v=0
o=CiscoSystemsSIP-GW-UserAgent 7656 9288 IN IP4 192.168.66.184
s=SIP Call
c=IN IP4 192.168.66.184
t=0 0
m=audio 20492 RTP/AVP 0

*Jan 22 08:34:05.672: Received:
SIP/2.0 100 Trying
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" <sip:[email-masked]>
To: <sip:[email-masked];user=phone>
Call-ID: [email-masked]
CSeq: 101 INVITE
Content-Length: 0

*Jan 22 08:34:05.672: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  act_sentinvite_new_message
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.672: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.672:  Roundtrip delay 16 milliseconds for method INVITE

*Jan 22 08:34:05.672: 0x6221E11C : State change from (STATE_SENT_INVITE,
SUBSTATE_NONE)  to (STATE_RECD_PROCEEDING, SUBS
TATE_PROCEEDING_PROCEEDING)
*Jan 22 08:34:05.852: Received:
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" <sip:[email-masked]>
To: <sip:[email-masked];user=phone>
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: [email-masked]
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
CSeq: 101 INVITE
Content-Length: 0

*Jan 22 08:34:05.856: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:05.856: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:05.856:  Roundtrip delay 200 milliseconds for method INVITE

*Jan 22 08:34:05.856: HandleSIP1xxRinging No SDP Body in 180 RINGING - would
wait for 200OK to do negotiation.

*Jan 22 08:34:05.856: HandleSIP1xxRinging: MediaNegotiation expected in 200
OK

*Jan 22 08:34:05.856: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_PROCEEDING)  to (STATE_
RECD_PROCEEDING, SUBSTATE_PROCEEDING_ALERTING)
*Jan 22 08:34:05.856: ISDN Se0:23: TX ->  ALERTING pd = 8  callref = 0x8001
*Jan 22 08:34:06.356: Received:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.66.184:50727
From: "2062011001" <sip:[email-masked]>
To: <sip:[email-masked];user=phone>;tag=6DFC2C58-820
Date:Sat, 22 Jan 2000 08:33:50 GMT
Call-ID: [email-masked]
Timestamp:948530045
Server:Cisco SIP Gateway (UAS)/IOS 12.x
Contact:<sip:[email-masked]:5060;user=phone>
Record-Route:<sip:[email-masked]:5070;maddr=192.168.10.141;trans
port=udp>
Record-Route:<sip:[email-masked]:5060;user=phone;maddr=192.168.10
.141;transport=udp>
CSeq: 101 INVITE
Content-Type:application/sdp
Content-Length: 126
Session-Expires:300

v=0
o=CiscoSystemsSIP-GW-UserAgent 6565 3960 IN IP4 10.1.1.2
s=SIP Call
t=0 0
m=audio 4036 RTP/AVP 0
c=IN IP4 209.6.0.2

************************************* Note
****************************************
Note that the record route header:

Record-Route:<sip:[email-masked]:5060;user=phone;maddr=192.168.10
.141;transport=udp>

  is the one that should be used for the subsequent ACK.

*Jan 22 08:34:06.356: HandleUdpSocketReads :Msg enqueued for SPI with
IPaddr: 192.168.1.114:34050
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  act_recdproc_new_message
*Jan 22 08:34:06.356: CCSIP-SPI-CONTROL:  sipSPICheckResponse
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_status_code
*Jan 22 08:34:06.360:  Roundtrip delay 704 milliseconds for method INVITE

*Jan 22 08:34:06.360: sipSPIGetSdpBody : Parse incoming session description
*Jan 22 08:34:06.360: sipSPICompareRespMediaInfo No Comparsion needed as 18x
messages did not have SDP
*Jan 22 08:34:06.360: sipSPIDoMediaNegotiation: Codec Negotiation Successful

*Jan 22 08:34:06.360: sipSPIUpdCcbWithSdpInfo: SDP Media Information:
Negotiated Codec      : g711ulaw , bytes :160
Early Media           : 0
Delayed Media         : 0
Bridge Done           : 0
New Media             : 0
DSP DNLD Reqd         : 0
Media Dest addr/Port  : 209.6.0.2:4036

*Jan 22 08:34:06.360: sipSPIProcessMediaChanges
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIReconnectConnection
*Jan 22 08:34:06.360:  Queued event from SIP SPI :
SIPSPI_EV_RECONNECT_CONNECTION
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIProcess200OKforinvite
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sipSPIAddRouteHeaders status =
TRUE Route <sip:[email-masked]:5070
;maddr=192.168.10.141>, <sip:[email-masked]:5060;user=phone>
*Jan 22 08:34:06.360:  Queued event from SIP SPI : SIPSPI_EV_SEND_MESSAGE
*Jan 22 08:34:06.360: CCSIP-SPI-CONTROL:  sip_stats_method
*Jan 22 08:34:06.360: 0x6221E11C : State change from (STATE_RECD_PROCEEDING,
SUBSTATE_PROCEEDING_ALERTING)  to (STATE_AC
TIVE, SUBSTATE_NONE)
*Jan 22 08:34:06.360: The Call Setup Information is :
  Call Control Block (CCB) : 0x6221E11C
  State of The Call        : STATE_ACTIVE
  TCP Sockets Used         : NO
  Calling Number           : 2062011001
  Called Number            : 3032011001
  Negotiated Codec         : g711ulaw
  Negotiated Codec Bytes   : 160
  Negotiated Dtmf-relay    : 0
  Source IP Address (Media): 192.168.66.184
  Source IP Port    (Media): 20492
  Destn  IP Address (Media): 209.6.0.2
  Destn  IP Port    (Media): 4036
  Destn SIP Req Addr:Port  : 192.168.10.141:5060
  Destn SIP Resp Addr:Port : 0.0.0.0:0
  Destination Name         : 192.168.10.114

*Jan 22 08:34:06.364: HandleUdpReconnection: Udp socket connected for fd: 1
with 192.168.10.141:5060
*Jan 22 08:34:06.364: Sent:
ACK sip:[email-masked]:5060;user=phone SIP/2.0
Via: SIP/2.0/UDP  192.168.66.184:50727
From: "2062011001" <sip:[email-masked]>
To: <sip:[email-masked];user=phone>;tag=6DFC2C58-820
Date: Sat, 22 Jan 2000 01:34:05 GMT
Call-ID: [email-masked]
Route: <sip:[email-masked]:5070;maddr=192.168.10.141>,
<sip:[email-masked]:5060;user=phone>
Max-Forwards: 6
Content-Length: 0
CSeq: 101 ACK

********************************* Note ***********************************
Request-URI in above ACK has domain of 192.168.10.141, should have been
192.168.10.114 when the record-route was turned into a Route header,
removed, and used as the Request-URI.

*Jan 22 08:34:06.364:  sipSPIRtcpUpdates No rtp session in bridge, create a
new one

*Jan 22 08:34:06.364: CCSIP-SPI-CONTROL:  ccsip_caps_ind
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: CURRENT VALUES:
ccCallID=1276, current_seq_num=0x217C
*Jan 22 08:34:06.364: ccsip_get_rtcp_session_parameters: NEW VALUES:
ccCallID=1276, current_seq_num=0x9EC
*Jan 22 08:34:06.364: ccsip_caps_ind: Load DSP with negotiated codec :
g711ulaw, Bytes=160
*Jan 22 08:34:06.368: sipSPIGetDTMFRelayMode: set DSP for dtmf-relay =
CC_CAP_DTMF_RELAY_INBAND_VOICE
*Jan 22 08:34:06.368: ccsip_caps_ind: Load DSP with codec : g711ulaw,
Bytes=160
*Jan 22 08:34:06.368: CCSIP-SPI-CONTROL:  ccsip_caps_ack
*Jan 22 08:34:06.372: ISDN Se0:23: TX ->  CONNECT pd = 8  callref = 0x8001
*Jan 22 08:34:06.372:         Progress Ind i = 0x8182 - Destination address
is non-ISDN
*Jan 22 08:34:06.388: ISDN Se0:23: RX <-  CONNECT_ACK pd = 8  callref =
0x0001
*Jan 22 08:34:06.388: ISDN Se0:23: CALL_PROGRESS: CALL_CONNECTED call id
0x227, bchan 0, dsl 0
3w0d: %ISDN-6-CONNECT: Interface Serial0:0 is now connected to 2062011001
c5300-3#

Thanks

SG 

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Thu, 12 Apr 2001 11:45:47 -0500

You are correct in that  the REQ URI in ACK of your example should be
192.168.10.114.
However, I don't know what is the value of copying the topmost route to the
REQ URI .
If the port of the UAS is different from that in the Route, it looks wrong!
The fact is, the REQ URI is not used for routing when there is a ROUTE
header in the message.
I have found that the REQ URI in the ACK to a proxy I have been testing
with, can be anything (so long as it parses ok) when there is a ROUTE
header. The proxy uses the Route header for routing and not the REQ URI,
when a ROUTE header is present.

 -----Original Message-----
From: 	[email-masked] [mailto:[email-masked]]
On Behalf Of Sherman Gong
Sent:	Thursday, April 12, 2001 10:09 AM
To:	[email-masked]
Subject:	[SIP] Request-uri does not match record-route header...

1)  6.29 Record-Route

    The above describes building Route headers from the Record-Route
headers,
    and sending subsequent requests to the first Route, removing that entry.

  6.33 Route

    The above notes that the Route header used to proxy a request should
also
     be used as the Request-URI.  This is the part that is not being done
     correctly by the 5300.  The 5300 is building it's own request URI based
on
     the destination of the request, rather than using the URI in the Route
    header as the Request-URI.  Note that the 5300 is sending the request
to the
    correct destination, which in our case does not match that in the Route
    header (but they don't have to match).

Or

c5300-3#

v=0

v=0

Thanks

SG