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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 25 Apr 2001 15:20:49 -0400

-----Original Message-----
>From: Arunachalam Venkatraman [mailto:[email-masked]]
>Sent: Tuesday, April 17, 2001 11:14 AM
>To: Fairlie-Cuninghame, Robert; Sherman Gong; [email-masked]
>Cc: 'Jonathan Rosenberg'
>Subject: RE: [SIP] Request-uri does not match record-route header...
>
>
>How does the proxy know if the client is DNS capable? If the proxy know it
is the default 
>proxy and should not Record Route, it can then simply route the call based
on the maddr in 
>the Route. Again, the name-addr in the Req-URI is irrelevant.

As always with record-routing, there are multiple issues being mixed here.

The issues are:

1. does the value of the userhost portion of the request URI in ACK matter
to the proxy that receives it, given a Route header is present
2. how do we handle record-routing with local outbound proxies

The original question raised by Sherman is (1). The 5300 seems to have
correctly computed the Route set (flipped the order of RR, add Contact at
the bottom). THen, it popped the top route set element, and placed that in
the R-URI, but modified the host portion. Arunachalam has argued that it
doesn't matter, since the request can be routed by the proxy without the
correct userhost field, as a Route header is present.

This is absolutely not correct.

As others have pointed out, the Request URI is used for transaction
identification. A UA MUST NOT modify the URI (stripping maddr/port is a
separate issue that I don't want to intersperse here) when it places it into
the R-URI. 

A separate issue (2) is whether the proxy will use the Route header or the
R-URI to forward the request, when the domain (or maddr) in the request URI
is not its own, as is the case for local outbound proxy. I think we are best
off by starting a new thread on that topic, which I will do.

-Jonathan R.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, April 13, 2001 6:24 AM
To: 'Arunachalam Venkatraman'; Sherman Gong; [email-masked]
Cc: 'Jonathan Rosenberg'
Subject: RE: [SIP] Request-uri does not match record-route header...
 
Hi, 
I believe the Record-Route test has been completely rewritten (message
attached). I personally believe however Arunachalam's response should be
qualified by the saying that a proxy should only use the next Route header
if
a.       the proxy knows that it record-routed this call leg
b.      or the Request-URI resolves to the local proxy's address.
 
I don't believe this is reflected in the new Record-Route text. It touches
on an unresolved (or at least that was my feeling) discussion a long time
about whether a Record-Routing's interaction with "Outbound Proxies".
For instance, when a UA or Proxy, puts the first Route header in the
Request-URI but then sends the message to an outbound proxy because the UA
lacks DNS capability. The outbound proxy may not have Record-Route'd but it
must not remove/process the next Route header either.
At risk of reopening this discussion, did we reach at conclusion on this
point, that is, when a proxy should use the next Route header and when
should it not (if the Request-URI is does not resolve to the proxy's
address)?
Robert. 
<<[SIP] new record-route text!>> 
-----Original Message---- 
From:   Arunachalam Venkatraman [mailto:[email-masked]] 
Sent:   Thursday, April 12, 2001 5:46 PM 
To:     Sherman Gong; [email-masked] 
Subject:        RE: [SIP] Request-uri does not match record-route header... 
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... 
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. 
 
_______________________________________________ 
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. 

---
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: Wed, 25 Apr 2001 15:18:15 -0500

I am sorry I missed this but I did not know the Req_URI is used for
transaction identification.
As per the bis document in the definition of SIP transaction   (Section
1.4), it says the transaction is identifed by the CSEQ number within a call
leg and the Call Leg is defined as the combinationof Call_ID, FROM and TO
headers.
Please refer me to the relevant portion of the document so I can understand
this better.

Also, when the Req-URI is used to identify a transaction, what component of
the REQ-URI are used?
Since the port is modified in a Route set entry, it will not match the port
of the Original Invite.

Regards

 -----Original Message-----
From: 	Jonathan Rosenberg [mailto:[email-masked]]
Sent:	Wednesday, April 25, 2001 2:21 PM
To:	'Arunachalam Venkatraman'; Fairlie-Cuninghame, Robert; Sherman Gong;
[email-masked]
Cc:	Jonathan Rosenberg

-----Original Message-----
is the default
on the maddr in

The issues are:

-Jonathan R.

-----Original Message-----
From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
Sent: Friday, April 13, 2001 6:24 AM
To: 'Arunachalam Venkatraman'; Sherman Gong; [email-masked]
Cc: 'Jonathan Rosenberg'
Subject: RE: [SIP] Request-uri does not match record-route header...

Hi,

 -----Original Message-----

  6.33 Route

on

Or

c5300-3#

Plan:ISDN, Type:National

port=udp>

.141;transport=udp>
CSeq: 101 INVITE

.141;transport=udp>

Thanks
SG

---