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

From: [email-masked]
Date: Tue, 17 Apr 2001 09:35:53 -0500

(See attached file: loop.doc)
It is important to have the same ReqURI in the ACK as presented in the
RouteHeader because
this will also help in the loop detection. As in the attached diagram although
the two sip requests
may have identical CallIds, they may have different ReqURI on account of number
translation
being done at one of the intermediate proxies and the call looping back to the
proxy. As Keith
pointed out having the ReqURI identical to the INVITE will help determine the
correct state
machine for processing the call.

-Deepak

"Keith Robinson" <[email-masked]> on 04/17/2001 05:58:27 AM

Sent by:  "Keith Robinson" <[email-masked]>

To:   "Fairlie-Cuninghame, Robert" <[email-masked]>
cc:   "'Arunachalam Venkatraman'" <[email-masked]>, Sherman Gong
      <[email-masked]>, [email-masked], "'Jonathan Rosenberg'"
      <[email-masked]> (Deepak Pant/MW/US/3Com)
Subject:  RE: [SIP] Request-uri does not match record-route header...

Hello,

Shouldn't the Request-Uri in the ACK should be :

ACK
sip:[email-masked]:5060;maddr=192.168.10.141;transport=udp;user=phone
SIP/2.0

This will then be sent to 192.168.10.141 using the maddr.

It is important that the Request-Uri in the subsequent messages is that given in
the Record-Route
as stateful proxies may well use this to identify the correct state machine to
process the request.

Like Robert, I think this touches upon the issues with Route headers, outbound
proxies and UA
without DNS capability which I feel hasn't yet been resolved.

Regards,

Keith Robinson

"Fairlie-Cuninghame, Robert" <[email-masked]> on 13/04/2001 12:24:12

 To:      "'Arunachalam Venkatraman'" <[email-masked]>,
          Sherman Gong <[email-masked]>,
          [email-masked]

 cc:      "'Jonathan Rosenberg'"
          <[email-masked]>(bcc: Keith
          Robinson/MAIN/MC1)

 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.

Content-Type: multipart/alternative;
boundary="----_=_NextPart_003_01C0C40C.43A8EE10"

------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/plain;
     charset="iso-8859-1"

Folks,

I took a stab at the new text for record routing. Its much, much more
verbose than rfc2543, and hopefully, as a result, will make it much clearer
what you need to do. Record-routing remains one of the most oft
misimplemnted features. This text incorporates everything in rfc2543 plus
all the decisions we've made on the list along the way. As you can see, the
structure is much more processing focused, rather than syntactic focused,
and much more explicit as well.

The text is in latex format. If you don't know latex, you should be able to
ignore all the slashes and brackets and still get the idea.

Please comment; alternate text related to those comments is requested.

-Jonathan R.

\section{Record-Routing}
\label{sec:rr}

Record routing is the process whereby a proxy server can request to
receive all messages between two UAs for a
particular call leg. The proxy accomplishes this by inserting a
header, called
\header{Record-Route} into the initial \INVITE request that begins the
call leg. The user agents use these headers to construct a set of
\header{Route} headers, that gets inserted into subsequent requests in
the call leg. The \header{Route} headers contain a set of proxies that
the request must visit on its way from one UA to another. Proxies use
these to forward the requests, much like strict IP source routing.

All user agents \MUST support the processing rules below which apply
to them. As such, they \MUST be able to parse and process both
\header{Record-Route} and \header{Route} headers. Proxies \MAY support
the record routing procedures of Section \ref{sec:rr:proxy}, but they
\MUST support the route header procedures of Section{sec:rr:proxy2}.

\motivation{This is a change from RFC2543, where all record-route and
route processing was optional for user agents.}

The syntax for the \header{Route} header is described in Section
XXX. The syntax for the \header{Record-Route} header is described in
Section XXX.

\subsection{UAC Processing for initial \INVITE transaction}
\label{sec:rr:uac}

The UAC formulates its {\em initial} \INVITE request for the call leg
as defined in section XXX. If the final response is a 200 class
response, it may contain \header{Record-Route} headers, and may
contain a \header{Contact} header. \annotate{Contact was not mandatory
in RFC2543. Thus, if the UAC is talking to an older UAS, the UAS might
not insert the \header{Contact} header. Thats why this text says that
the \header{Contact} may be present in the response. Note also that
this may is lower case; it is NOT saying that a UAS can optionally
insert the \header{Contact} header into the 200 class response.} The
UAC \MUST construct a {\em route set}, defined as a list of URLs, in
the following manner:

\begin{enumerate}
\item The list of URIs present in the \header{Record-Route} headers in
the 200 class response are taken, if present, and their order is reversed.
\item The URI in the \header{Contact} header from the 200 class response, if
present, is taken, and appended to the end of the list from the
previous step.
\item The list of URIs resulting from the above two operations is
referred to as the {\em route set}.
\end{enumerate}

The UAC \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the 200 class response. NOTE that since there
may be multiple 200 OK responses to an \INVITE request, each response
constitutes a separate call leg, and thus has a separate route
set. The UAC \MUST also remember whether the bottom-most entry in the
route set was constructed from a \header{Contact} header or not. This
is effectively a boolean value, which we refer to as CONTACT_SET.

The \ACK request for the initial \INVITE transaction \MUST be
formulated according to the rules of Section XXX, as if it were a
subsequent request within the call leg.

OPEN-ISSUE: Handling for non-200 responses, including provisionals
and certain 400 class responses. Are we supporting record-routing for
non-200 class responses? Record-routing for provisional responses is
discussed in the 100rel spec. What needs to be said here?

\subsection{UAS Processing of initial \INVITE transaction}
\label{sec:rr:uas}

When a UAS receives an \INVITE for a new call leg, and it responds
with a 200 class response, it \MUST copy the contents of the
\header{Record-Route} headers from the request to the response. This
includes the URIs, URI parameters, and any \header{Record-Route}
header parameters, whether they are known or unknown to the
UAS. \annotate{Record-Route parameters are very useful for
proxies. They allow the proxy to match the record-route entry in the
response with the one in the request.} The
order of the \header{Record-Route} headers \MUST be preserved in the
response.

The UAS \MUST construct a {\em route set} in the following manner:

\begin{enumerate}
\item The list of URIs in the \header{Record-Route} headers in the
\INVITE request, if present, are taken, including any URI parameters.
\item The URI in the \header{Contact} header from the request, if present,
is
taken, including any URI parameters. The URI is appended to the bottom
of the list of URIs from the previous step.
\item The resulting list of URIs is called the {\em route set}.
\end{enumerate}

The UAS \MUST store the route set for the duration of the call
leg. NOTE that it is possible for the route set to be empty. This will
occur if neither \header{Record-Route} headers nor a \header{Contact}
header were present in the \INVITE request. The UAS \MUST also
remember whether the bottom-most entry in the route set was
constructed from a \header{Contact} header or not. This is effectively
a boolean value, which we refer to as CONTACT_SET.

OPEN ISSUE: this new text does not have the record-routes copied into
non-200 responses. RFC2543 talks about other failure codes, but is not
specific enough. Do we really need them in other response codes? If
so, we must list them explicitly.

\subsection{Proxy processing of an initial \INVITE transaction}
\label{sec:rr:proxy}

Each proxy \MAY independently decide to record-route an initial
\INVITE transaction. For a proxy, {\em initial} is defined
as any \INVITE request that does not contain a \header{Route}
header. Generally, the choice about whether to record-route or not is
a tradeoff of features vs. performance. Faster call processing and
higher scalability is achieved when proxies do not record
route. However, provision of certain services may require a proxy to
observe all messages for a call leg. It is \RECOMMENDED that proxies
do not automatically record route. They should do so only if
specifically required.

To record-route, the proxy inserts a \header{Record-Route} header into
the request before proxying it onwards. A forking proxy \MAY insert a
different \header{Record-Route} header into each forked request. The
\header{Record-Route} header that it inserts \MUST be inserted as the
first \header{Record-Route} header, appearing before any existing ones
in the request. The URL in the header \MUST be a SIP
URL. \annotate{This is because the URLs in the Record-Route headers
are used for forwarding requests by other proxies. Since no other URL
but a SIP URL is mandatory, a proxy could not be sure that any other
URL is interpretable by other proxies. Thus, SIP URLs are
mandatory}. The URL \MUSTNOT contain the transport
parameter. \annotate{Thats because only UDP is mandatory. If a proxy
inserts a transport parameter in the URL with TCP or TLS as the
transport, the proxy that ends up using that URL to forward the
request might not support that transport. The result, according to the
``Locating a SIP Server'' procedure, would be for the proxy to give
up.} The URL \MUST have the property that when the processing
described in Section XXX ``locaing a SIP server'' is followed for that
URL, the result of the lookup is an address/port of the proxy server
inserting the
\header{Record-Route}. The URL and the proxy configuration \SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to one of the previous-hop servers that the initial
\INVITE request traversed, including the UAS. \annotate{These two
properties are
important. The first one guarantees that subsequent requests from the
called party are routed back to this actually proxy. The second property is
there for robustness. It guarantees that the request URI always
contain meaningful information, even if there are no \header{Route}
headers that tell the proxy where to forward the request to next.} The
proxy \MAY insert
\header{Record-Route} parameters into the request. These will be
returned to the proxy in any 200 class response to the \INVITE, and
are useful for pushing state into the message.

If a 200 class response arrives for a proxied request, the response
will contain the entire list of \header{Record-Route} headers inserted
by proxies along the request path. The proxy \MAY modify the
\header{Record-Route} value matching the one it inserted into the
request. Like the URL in the request, it \MUST be a SIP URL and
\MUSTNOT contain a transport parameter. The URL in this
\header{Record-Route} header \MUST have the
property that when the processing described in Section XXX ``locating
a SIP server'' is followed for that URL, the result of the lookup is
an address/port of the proxy server that inserted the
\header{Record-Route}. The URL in this header, and the proxy configuration
\SHOULD be
such that if a request is received with this URL in the
\header{Request-URI}, the proxy's normal request processing will cause
it to be forwarded to the same next hop server that the initial
\INVITE request was forwarded to.

The four properties (two for the request, two for the response), can
be satisfied in a number of ways. One way is that the URI inserted
into the \header{Record-Route} in the request is the same as the
\header{Contact} header in the \INVITE (if present, else the
\header{From} field), but with the maddr and port set to
resolve to the proxy. Then, the proxy modifies the URL in the
\header{Record-Route} header in the response, setting it to be the URL
from the \header{Request-URI} of the initial \INVITE, but with the maddr
and port set to resolve to the proxy.

As an example, consider a proxy at 10.0.1.1 listening on port 5061
which receives the following request (many headers are omitted for
brevity):

\begin{verbatim}
INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP callerspc.univ.edu
Contact: sip:[email-masked]
\end{verbatim}

The proxy forwards this request to
\header{sip:[email-masked]}, and record-routes:

\begin{verbatim}
INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 <sip:[email-masked]:5061;maddr=10.0.1.1>
Contact: sip:[email-masked]
\end{verbatim}

The 200 response will look like, in part:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP 10.0.1.1:5061
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 <sip:[email-masked]:5061;maddr=10.0.1.1>
Contact: sip:[email-masked]
\end{verbatim}

The proxy modifies its \header{Record-Route} header in the response to
and forwards the request upstream:

\begin{verbatim}
SIP/2.0 200 OK
Via: SIP/2.0/UDP callerspc.univ.edu
Record-Route:
 <sip:[email-masked]:5061;maddr=10.0.1.1>;myparam=9877
Contact: sip:[email-masked]
\end{verbatim}

The route set computed by the UAS is:

\begin{verbatim}
sip:[email-masked]:5061;maddr=10.0.1.1
sip:[email-masked]
\end{verbatim}

and the route set computed by the UAC is:

\begin{verbatim}
sip:[email-masked]:5061;maddr=10.0.1.1
sip:[email-masked]
\end{verbatim}

There are other ways to meet these requirements. The proxy could
construct a URL for the request which encodes all of the needed
information, by placing it in the user portion, for example. A call
stateful proxy could insert a URL into the request with the form
sip:proxy.example.com, and not modify it in the response. This URL
clearly satisfies the first required property (of getting routed back
to the proxy that inserted it). The second property can be maintained
by being call stateful, and extracting the needed parameters from
local storage.

When a proxy does decide to modify the \header{Record-Route} header in
the response, one of the operations it must perform is to locate the
\header{Record-Route} that it had inserted. If the request spiraled,
and the proxy inserted a \header{Record-Route} in each iteration of
the spiral, locating the correct header in the response (which must be
the proper iteration in the reverse direction) is tricky. One
mechanism that is \RECOMMENDED is for the proxy to insert a
\header{Record-Route} parameter into the new \header{Record-Route} header
in the request each time the request spirals. This parameter \MUST
uniquely identify the proxy. When the 200 class respone arrives, the
proxy looks for the topmost \header{Record-Route} header containing
this parameter. This header is the one for the current iteration. The
proxy \MUST remove this parameter before forwarding the response
upstream. Upon the next iteration, the same algorithm (find the
topmost \header{Record-Route} header with the parameter) will
correctly extract the next \header{Record-Route}
header.

\subsection{UA Processing of Subsequent Requests in a Call Leg}
\label{sec:rr:uasubsequent}

When a UA wishes to send another request for the call-leg (such as a
\header{BYE} or \header{INVITE}), it follows the procedures defined in
this subsection. The
procedures here \MUST also be followed for an \ACK request for a 200
response to the initial \INVITE for the call leg. The procedures here
\MUSTNOT be followed for a \CANCEL request or an \ACK request for a
non-200 response. This implies that \CANCEL never contains a
\header{Route} header, nor does an \ACK for a non-200 response.

The request is constructed as specified in Section XXX. The UA then
takes the list of URI in the route set. The top URI is inserted into
the request URI of the request, including all parameters. Any URI
parameters not allowed in the request URI \MUST then be stripped. Each
of the remaining URIs (if any) from the route set, including any
URI parameters, are placed into a \header{Route} header into the request,
in order. The procedures of Section XXX ``locating a SIP server'' are
then applied to the URI in the request URI, the the request is
forwarded to the resulting server.

If a UAS has a route set for a call leg, and receives a re-INVITE for
that call leg containing \header{Record-Route} headers, it \MUST copy
those headers into any 200 class response to that request. If the
boolean variable CONTACT_SET is true, the \header{Contact} header in
the re-INVITE (if present) replaces the last
entry in the route set. If the boolean variable CONTACT_SET is false,
the UAS \MUST add the URL in the
\header{Contact} header in the re-INVITE to the bottom of the route
set, and then set CONTACT_SET to true. If the re-INVITE did not
contain a \header{Contact} header, the route-set at the UAS remains
unchanged.

Similarly, if a UAC has a route set for a call leg, and receives a 200
class response to a re-INVITE it sent, the \header{Contact} header is
examined. If not present, the route set remains unchanged. If the
re-INVITE response had a \header{Contact} header, and the boolean
variable CONTACT_SET is false, the URL in the \header{Contact} header
in the response is added to the bottom of the route set, and
CONTACT_SET is set to true. If the re-INVITE response had a
\header{Contact} header, and CONTACT_SET is true, the URL in the
\header{Contact} header of the re-INVITE response replaces the bottom
value in the route set.

The above two paragraphs allow a UA to update its \header{Contact}
address mid-call, but proxies cannot update their route address.  Once
on the route, a proxy remains on the route for the duration of the
call leg. \annotate{Why the different treatment for Contact and
Record-Route in a re-INVITE? It has to do with backwards
compatibility. RFC2543 did not mandate that a proxy needs to refresh
its record-route headers. As a result, the lack of a record-route in a
re-INVITE cannot be interpreted to mean that the proxy does not want
to be included on the route any longer. Updating of the Contact header
mid-call is useful for mobility applications, and is also useful for
forms of third party call control}.

OPEN-ISSUE: should the UA remove the maddr param, if present, if the
request is sent to the server at that maddr?

OPEN-ISSUE: should we mention handling of route with local outbound
proxies here? RFC2543 has some text on DNS-less UAs, but there are
issues with this.

\header{Proxy processing of a non-initial request}
\label{sec:rr:proxy2}

The rules in this section \MUST be followed when a proxy receives a request
that contains a \header{Route} header. The \header{Route} header is
used to forward the request to the next hop. It \MUST override any other
routing decisions that the proxy would otherwise make. Proxies \MAY
respond to requests with \header{Route} headers for any reason (in order
to perform proxy authorization, for example). But, if the request is
proxied, the procedures here \MUST be used to determine where the
request is proxied to. The procedures in this section apply indepedent
of the request method. They \MUST be followed even if the request
method is unknown to the proxy. \annotate{This last sentence is
really, really important. It allows for other methods, defined in the
future, to have record-routing applied to them. As an example, an
instant messaging session run over SIP might begin with a MESSAGE
request. That extension can allow for these sessions to be
record-routed by proxies that know of this extension. However, the
record-routing will only work if proxies that don't know about the
extension follow the Route headers properly. As such, supporting
\header{Route} headers for all methods, known or unknown, is very
important for a robust and future proof proxy implementation.}
Since \CANCEL can never contain
\header{Route}, these procedures never apply to \CANCEL. However, they
do apply to \ACK requests for a 200 OK response, which do contain
\header{Route} headers.

The proxy \MUST remove the top \header{Route} header from the
request. The URI from that \header{Route} \MUST be placed into the
\header{Request-URI} of the proxied request, including URI
parameters. Any URL parameters present in the top \header{Route}
header which are not allowed in the request URI \MUST be removed from
the \header{Request-URI} by the proxy. The procedures of section XXX
``Locating a SIP Server'' \MUST be followed to compute the next hop
server to forward the request to.

If the request is an \INVITE request (thus, a re-INVITE) for a call
leg that the proxy wishes to receive messages for (very likely the
case, since the request probably arrived at the proxy because the
proxy record routed in the initial \INVITE), the proxy \MUST
re-insert the
\header{Record-Route} header with the same value it placed in the
initial request. Similarly, it should modify the \header{Record-Route}
header in any 200 class response in the same way the
\header{Record-Route} header was modified in the response to the
initial \INVITE (which may be no modifications at all). The purpose of
this is twofold. First, it allows for proper record-routing in the
case of pre-loaded Route headers (see Section XXX). Secondly, it
allows for recovery from a UA crash and restart, in which case the UA
loses call state, and as a result, its route set as well. The result
is that the route set will be re-established through the
re-INVITE. When coupled with the Session Timer \cite{RFCXXX}, the
result is a robust way to recover from crashes.

\subsection{Pre-Loaded Route Headers}

Normally, a UA constructs the Route headers in a request from the
route set learned through \header{Record-Route} headers. However, in
some circumstances, it is useful for a UA to insert \header{Route}
headers into an initial \INVITE. These headers may have been learnt by
the UA through some out of bands means. When an initial \INVITE
(initial as far as the UAC and UAS are concerned) contains
\header{Route} headers, this is referred to as a ``pre-loaded
Route''. It is equivalent to strict source routing in IP. Proxies will
often not be able to distinguish this case from the case described in
Section \ref{sec:rr:proxy}, and will therefore properly use these
route headers to forward the request. If the proxies are interested in
receiving subsequent messages for the call leg, their insertion of
\header{Record-Route} as mandated by Section \ref{sec:rr:proxy} will
establish a correct route set at both UAC and UAS. This route set may
end up being different from the pre-loaded Route used by the UAC. As
such, a UAC that inserts a pre-loaded route set \MUST follow the
procedures of Section \ref{sec:rr:uac} in processing the response to
this initial \INVITE.

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

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

------_=_NextPart_003_01C0C40C.43A8EE10
Content-Type: text/html;
     charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2653.12">
<TITLE>[SIP] new record-route text!</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2>Folks,</FONT>
</P>

<P><FONT SIZE=2>I took a stab at the new text for record routing. Its much, much
more</FONT>
<BR><FONT SIZE=2>verbose than rfc2543, and hopefully, as a result, will make it
much clearer</FONT>
<BR><FONT SIZE=2>what you need to do. Record-routing remains one of the most
oft</FONT>
<BR><FONT SIZE=2>misimplemnted features. This text incorporates everything in
rfc2543 plus</FONT>
<BR><FONT SIZE=2>all the decisions we've made on the list along the way. As you
can see, the</FONT>
<BR><FONT SIZE=2>structure is much more processing focused, rather than
syntactic focused,</FONT>
<BR><FONT SIZE=2>and much more explicit as well.</FONT>
</P>

<P><FONT SIZE=2>The text is in latex format. If you don't know latex, you should
be able to</FONT>
<BR><FONT SIZE=2>ignore all the slashes and brackets and still get the
idea.</FONT>
</P>

<P><FONT SIZE=2>Please comment; alternate text related to those comments is
requested.</FONT>
</P>

<P><FONT SIZE=2>-Jonathan R.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>\section{Record-Routing}</FONT>
<BR><FONT SIZE=2>\label{sec:rr}</FONT>
</P>

<P><FONT SIZE=2>Record routing is the process whereby a proxy server can request
to</FONT>
<BR><FONT SIZE=2>receive all messages between two UAs for a </FONT>
<BR><FONT SIZE=2>particular call leg. The proxy accomplishes this by inserting
a</FONT>
<BR><FONT SIZE=2>header, called</FONT>
<BR><FONT SIZE=2>\header{Record-Route} into the initial \INVITE request that
begins the</FONT>
<BR><FONT SIZE=2>call leg. The user agents use these headers to construct a set
of</FONT>
<BR><FONT SIZE=2>\header{Route} headers, that gets inserted into subsequent
requests in</FONT>
<BR><FONT SIZE=2>the call leg. The \header{Route} headers contain a set of
proxies that</FONT>
<BR><FONT SIZE=2>the request must visit on its way from one UA to another.
Proxies use</FONT>
<BR><FONT SIZE=2>these to forward the requests, much like strict IP source
routing.</FONT>
</P>

<P><FONT SIZE=2>All user agents \MUST support the processing rules below which
apply</FONT>
<BR><FONT SIZE=2>to them. As such, they \MUST be able to parse and process
both</FONT>
<BR><FONT SIZE=2>\header{Record-Route} and \header{Route} headers. Proxies \MAY
support</FONT>
<BR><FONT SIZE=2>the record routing procedures of Section \ref{sec:rr:proxy},
but they</FONT>
<BR><FONT SIZE=2>\MUST support the route header procedures of
Section{sec:rr:proxy2}. </FONT>
</P>

<P><FONT SIZE=2>\motivation{This is a change from RFC2543, where all
record-route and</FONT>
<BR><FONT SIZE=2>route processing was optional for user agents.}</FONT>
</P>

<P><FONT SIZE=2>The syntax for the \header{Route} header is described in
Section</FONT>
<BR><FONT SIZE=2>XXX. The syntax for the \header{Record-Route} header is
described in</FONT>
<BR><FONT SIZE=2>Section XXX.</FONT>
</P>

<P><FONT SIZE=2>\subsection{UAC Processing for initial \INVITE
transaction}</FONT>
<BR><FONT SIZE=2>\label{sec:rr:uac}</FONT>
</P>

<P><FONT SIZE=2>The UAC formulates its {\em initial} \INVITE request for the
call leg</FONT>
<BR><FONT SIZE=2>as defined in section XXX. If the final response is a 200
class</FONT>
<BR><FONT SIZE=2>response, it may contain \header{Record-Route} headers, and
may</FONT>
<BR><FONT SIZE=2>contain a \header{Contact} header. \annotate{Contact was not
mandatory</FONT>
<BR><FONT SIZE=2>in RFC2543. Thus, if the UAC is talking to an older UAS, the
UAS might</FONT>
<BR><FONT SIZE=2>not insert the \header{Contact} header. Thats why this text
says that</FONT>
<BR><FONT SIZE=2>the \header{Contact} may be present in the response. Note also
that</FONT>
<BR><FONT SIZE=2>this may is lower case; it is NOT saying that a UAS can
optionally</FONT>
<BR><FONT SIZE=2>insert the \header{Contact} header into the 200 class
response.} The</FONT>
<BR><FONT SIZE=2>UAC \MUST construct a {\em route set}, defined as a list of
URLs, in</FONT>
<BR><FONT SIZE=2>the following manner:</FONT>
</P>

<P><FONT SIZE=2>\begin{enumerate}</FONT>
<BR><FONT SIZE=2>\item The list of URIs present in the \header{Record-Route}
headers in</FONT>
<BR><FONT SIZE=2>the 200 class response are taken, if present, and their order
is reversed. </FONT>
<BR><FONT SIZE=2>\item The URI in the \header{Contact} header from the 200 class
response, if</FONT>
<BR><FONT SIZE=2>present, is taken, and appended to the end of the list from
the</FONT>
<BR><FONT SIZE=2>previous step.</FONT>
<BR><FONT SIZE=2>\item The list of URIs resulting from the above two operations
is</FONT>
<BR><FONT SIZE=2>referred to as the {\em route set}.</FONT>
<BR><FONT SIZE=2>\end{enumerate}</FONT>
</P>

<P><FONT SIZE=2>The UAC \MUST store the route set for the duration of the
call</FONT>
<BR><FONT SIZE=2>leg. NOTE that it is possible for the route set to be empty.
This will</FONT>
<BR><FONT SIZE=2>occur if neither \header{Record-Route} headers nor a
\header{Contact}</FONT>
<BR><FONT SIZE=2>header were present in the 200 class response. NOTE that since
there</FONT>
<BR><FONT SIZE=2>may be multiple 200 OK responses to an \INVITE request, each
response</FONT>
<BR><FONT SIZE=2>constitutes a separate call leg, and thus has a separate
route</FONT>
<BR><FONT SIZE=2>set. The UAC \MUST also remember whether the bottom-most entry
in the</FONT>
<BR><FONT SIZE=2>route set was constructed from a \header{Contact} header or
not. This</FONT>
<BR><FONT SIZE=2>is effectively a boolean value, which we refer to as
CONTACT_SET.</FONT>
</P>

<P><FONT SIZE=2>The \ACK request for the initial \INVITE transaction \MUST
be</FONT>
<BR><FONT SIZE=2>formulated according to the rules of Section XXX, as if it were
a</FONT>
<BR><FONT SIZE=2>subsequent request within the call leg. </FONT>
</P>

<P><FONT SIZE=2>OPEN-ISSUE: Handling for non-200 responses, including
provisionals</FONT>
<BR><FONT SIZE=2>and certain 400 class responses. Are we supporting
record-routing for</FONT>
<BR><FONT SIZE=2>non-200 class responses? Record-routing for provisional
responses is</FONT>
<BR><FONT SIZE=2>discussed in the 100rel spec. What needs to be said
here?</FONT>
</P>

<P><FONT SIZE=2>\subsection{UAS Processing of initial \INVITE
transaction}</FONT>
<BR><FONT SIZE=2>\label{sec:rr:uas}</FONT>
</P>

<P><FONT SIZE=2>When a UAS receives an \INVITE for a new call leg, and it
responds</FONT>
<BR><FONT SIZE=2>with a 200 class response, it \MUST copy the contents of
the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} headers from the request to the response.
This</FONT>
<BR><FONT SIZE=2>includes the URIs, URI parameters, and any
\header{Record-Route}</FONT>
<BR><FONT SIZE=2>header parameters, whether they are known or unknown to
the</FONT>
<BR><FONT SIZE=2>UAS. \annotate{Record-Route parameters are very useful
for</FONT>
<BR><FONT SIZE=2>proxies. They allow the proxy to match the record-route entry
in the</FONT>
<BR><FONT SIZE=2>response with the one in the request.} The</FONT>
<BR><FONT SIZE=2>order of the \header{Record-Route} headers \MUST be preserved
in the</FONT>
<BR><FONT SIZE=2>response.</FONT>
</P>

<P><FONT SIZE=2>The UAS \MUST construct a {\em route set} in the following
manner:</FONT>
</P>

<P><FONT SIZE=2>\begin{enumerate}</FONT>
<BR><FONT SIZE=2>\item The list of URIs in the \header{Record-Route} headers in
the</FONT>
<BR><FONT SIZE=2>\INVITE request, if present, are taken, including any URI
parameters.</FONT>
<BR><FONT SIZE=2>\item The URI in the \header{Contact} header from the request,
if present,</FONT>
<BR><FONT SIZE=2>is</FONT>
<BR><FONT SIZE=2>taken, including any URI parameters. The URI is appended to the
bottom</FONT>
<BR><FONT SIZE=2>of the list of URIs from the previous step.</FONT>
<BR><FONT SIZE=2>\item The resulting list of URIs is called the {\em route set}.
</FONT>
<BR><FONT SIZE=2>\end{enumerate}</FONT>
</P>

<P><FONT SIZE=2>The UAS \MUST store the route set for the duration of the
call</FONT>
<BR><FONT SIZE=2>leg. NOTE that it is possible for the route set to be empty.
This will</FONT>
<BR><FONT SIZE=2>occur if neither \header{Record-Route} headers nor a
\header{Contact}</FONT>
<BR><FONT SIZE=2>header were present in the \INVITE request. The UAS \MUST
also</FONT>
<BR><FONT SIZE=2>remember whether the bottom-most entry in the route set
was</FONT>
<BR><FONT SIZE=2>constructed from a \header{Contact} header or not. This is
effectively</FONT>
<BR><FONT SIZE=2>a boolean value, which we refer to as CONTACT_SET. </FONT>
</P>

<P><FONT SIZE=2>OPEN ISSUE: this new text does not have the record-routes copied
into</FONT>
<BR><FONT SIZE=2>non-200 responses. RFC2543 talks about other failure codes, but
is not</FONT>
<BR><FONT SIZE=2>specific enough. Do we really need them in other response
codes? If</FONT>
<BR><FONT SIZE=2>so, we must list them explicitly.</FONT>
</P>

<P><FONT SIZE=2>\subsection{Proxy processing of an initial \INVITE
transaction}</FONT>
<BR><FONT SIZE=2>\label{sec:rr:proxy}</FONT>
</P>

<P><FONT SIZE=2>Each proxy \MAY independently decide to record-route an
initial</FONT>
<BR><FONT SIZE=2>\INVITE transaction. For a proxy, {\em initial} is
defined</FONT>
<BR><FONT SIZE=2>as any \INVITE request that does not contain a
\header{Route}</FONT>
<BR><FONT SIZE=2>header. Generally, the choice about whether to record-route or
not is</FONT>
<BR><FONT SIZE=2>a tradeoff of features vs. performance. Faster call processing
and</FONT>
<BR><FONT SIZE=2>higher scalability is achieved when proxies do not
record</FONT>
<BR><FONT SIZE=2>route. However, provision of certain services may require a
proxy to</FONT>
<BR><FONT SIZE=2>observe all messages for a call leg. It is \RECOMMENDED that
proxies</FONT>
<BR><FONT SIZE=2>do not automatically record route. They should do so only
if</FONT>
<BR><FONT SIZE=2>specifically required.</FONT>
</P>

<P><FONT SIZE=2>To record-route, the proxy inserts a \header{Record-Route}
header into</FONT>
<BR><FONT SIZE=2>the request before proxying it onwards. A forking proxy \MAY
insert a</FONT>
<BR><FONT SIZE=2>different \header{Record-Route} header into each forked
request. The</FONT>
<BR><FONT SIZE=2>\header{Record-Route} header that it inserts \MUST be inserted
as the</FONT>
<BR><FONT SIZE=2>first \header{Record-Route} header, appearing before any
existing ones</FONT>
<BR><FONT SIZE=2>in the request. The URL in the header \MUST be a SIP</FONT>
<BR><FONT SIZE=2>URL. \annotate{This is because the URLs in the Record-Route
headers</FONT>
<BR><FONT SIZE=2>are used for forwarding requests by other proxies. Since no
other URL</FONT>
<BR><FONT SIZE=2>but a SIP URL is mandatory, a proxy could not be sure that any
other</FONT>
<BR><FONT SIZE=2>URL is interpretable by other proxies. Thus, SIP URLs
are</FONT>
<BR><FONT SIZE=2>mandatory}. The URL \MUSTNOT contain the transport</FONT>
<BR><FONT SIZE=2>parameter. \annotate{Thats because only UDP is mandatory. If a
proxy</FONT>
<BR><FONT SIZE=2>inserts a transport parameter in the URL with TCP or TLS as
the</FONT>
<BR><FONT SIZE=2>transport, the proxy that ends up using that URL to forward
the</FONT>
<BR><FONT SIZE=2>request might not support that transport. The result, according
to the</FONT>
<BR><FONT SIZE=2>``Locating a SIP Server'' procedure, would be for the proxy to
give</FONT>
<BR><FONT SIZE=2>up.} The URL \MUST have the property that when the
processing</FONT>
<BR><FONT SIZE=2>described in Section XXX ``locaing a SIP server'' is followed
for that</FONT>
<BR><FONT SIZE=2>URL, the result of the lookup is an address/port of the proxy
server</FONT>
<BR><FONT SIZE=2>inserting the</FONT>
<BR><FONT SIZE=2>\header{Record-Route}. The URL and the proxy configuration
\SHOULD be</FONT>
<BR><FONT SIZE=2>such that if a request is received with this URL in the</FONT>
<BR><FONT SIZE=2>\header{Request-URI}, the proxy's normal request processing
will cause</FONT>
<BR><FONT SIZE=2>it to be forwarded to one of the previous-hop servers that the
initial</FONT>
<BR><FONT SIZE=2>\INVITE request traversed, including the UAS. \annotate{These
two</FONT>
<BR><FONT SIZE=2>properties are </FONT>
<BR><FONT SIZE=2>important. The first one guarantees that subsequent requests
from the</FONT>
<BR><FONT SIZE=2>called party are routed back to this actually proxy. The second
property is</FONT>
<BR><FONT SIZE=2>there for robustness. It guarantees that the request URI
always</FONT>
<BR><FONT SIZE=2>contain meaningful information, even if there are no
\header{Route}</FONT>
<BR><FONT SIZE=2>headers that tell the proxy where to forward the request to
next.} The</FONT>
<BR><FONT SIZE=2>proxy \MAY insert </FONT>
<BR><FONT SIZE=2>\header{Record-Route} parameters into the request. These will
be</FONT>
<BR><FONT SIZE=2>returned to the proxy in any 200 class response to the \INVITE,
and</FONT>
<BR><FONT SIZE=2>are useful for pushing state into the message.</FONT>
</P>

<P><FONT SIZE=2>If a 200 class response arrives for a proxied request, the
response</FONT>
<BR><FONT SIZE=2>will contain the entire list of \header{Record-Route} headers
inserted</FONT>
<BR><FONT SIZE=2>by proxies along the request path. The proxy \MAY modify
the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} value matching the one it inserted into
the</FONT>
<BR><FONT SIZE=2>request. Like the URL in the request, it \MUST be a SIP URL
and</FONT>
<BR><FONT SIZE=2>\MUSTNOT contain a transport parameter. The URL in this</FONT>
<BR><FONT SIZE=2>\header{Record-Route} header \MUST have the</FONT>
<BR><FONT SIZE=2>property that when the processing described in Section XXX
``locating</FONT>
<BR><FONT SIZE=2>a SIP server'' is followed for that URL, the result of the
lookup is</FONT>
<BR><FONT SIZE=2>an address/port of the proxy server that inserted the</FONT>
<BR><FONT SIZE=2>\header{Record-Route}. The URL in this header, and the proxy
configuration</FONT>
<BR><FONT SIZE=2>\SHOULD be</FONT>
<BR><FONT SIZE=2>such that if a request is received with this URL in the</FONT>
<BR><FONT SIZE=2>\header{Request-URI}, the proxy's normal request processing
will cause</FONT>
<BR><FONT SIZE=2>it to be forwarded to the same next hop server that the
initial</FONT>
<BR><FONT SIZE=2>\INVITE request was forwarded to.</FONT>
</P>

<P><FONT SIZE=2>The four properties (two for the request, two for the response),
can</FONT>
<BR><FONT SIZE=2>be satisfied in a number of ways. One way is that the URI
inserted</FONT>
<BR><FONT SIZE=2>into the \header{Record-Route} in the request is the same as
the</FONT>
<BR><FONT SIZE=2>\header{Contact} header in the \INVITE (if present, else
the</FONT>
<BR><FONT SIZE=2>\header{From} field), but with the maddr and port set to</FONT>
<BR><FONT SIZE=2>resolve to the proxy. Then, the proxy modifies the URL in
the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} header in the response, setting it to be
the URL</FONT>
<BR><FONT SIZE=2>from the \header{Request-URI} of the initial \INVITE, but with
the maddr</FONT>
<BR><FONT SIZE=2>and port set to resolve to the proxy. </FONT>
</P>

<P><FONT SIZE=2>As an example, consider a proxy at 10.0.1.1 listening on port
5061</FONT>
<BR><FONT SIZE=2>which receives the following request (many headers are omitted
for</FONT>
<BR><FONT SIZE=2>brevity):</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>INVITE sip:[email-masked] SIP/2.0</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP callerspc.univ.edu</FONT>
<BR><FONT SIZE=2>Contact: sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>The proxy forwards this request to</FONT>
<BR><FONT SIZE=2>\header{sip:[email-masked]}, and
record-routes:</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>INVITE sip:[email-masked] SIP/2.0</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP 10.0.1.1:5061</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP callerspc.univ.edu</FONT>
<BR><FONT SIZE=2>Record-Route:</FONT>
<BR><FONT
SIZE=2>&nbsp;&lt;sip:[email-masked]:5061;maddr=10.0.1.1&gt;</FONT>
<BR><FONT SIZE=2>Contact: sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>The 200 response will look like, in part:</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>SIP/2.0 200 OK</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP 10.0.1.1:5061</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP callerspc.univ.edu</FONT>
<BR><FONT SIZE=2>Record-Route:</FONT>
<BR><FONT
SIZE=2>&nbsp;&lt;sip:[email-masked]:5061;maddr=10.0.1.1&gt;</FONT>
<BR><FONT SIZE=2>Contact: sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>The proxy modifies its \header{Record-Route} header in the
response to</FONT>
<BR><FONT SIZE=2>and forwards the request upstream:</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>SIP/2.0 200 OK</FONT>
<BR><FONT SIZE=2>Via: SIP/2.0/UDP callerspc.univ.edu</FONT>
<BR><FONT SIZE=2>Record-Route:</FONT>
<BR><FONT
SIZE=2>&nbsp;&lt;sip:[email-masked]:5061;maddr=10.0.1.1&gt;;myparam=9877</FONT>

<BR><FONT SIZE=2>Contact: sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>The route set computed by the UAS is:</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>sip:[email-masked]:5061;maddr=10.0.1.1</FONT>
<BR><FONT SIZE=2>sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>and the route set computed by the UAC is:</FONT>
</P>

<P><FONT SIZE=2>\begin{verbatim}</FONT>
<BR><FONT SIZE=2>sip:[email-masked]:5061;maddr=10.0.1.1</FONT>
<BR><FONT SIZE=2>sip:[email-masked]</FONT>
<BR><FONT SIZE=2>\end{verbatim}</FONT>
</P>

<P><FONT SIZE=2>There are other ways to meet these requirements. The proxy
could</FONT>
<BR><FONT SIZE=2>construct a URL for the request which encodes all of the
needed</FONT>
<BR><FONT SIZE=2>information, by placing it in the user portion, for example. A
call</FONT>
<BR><FONT SIZE=2>stateful proxy could insert a URL into the request with the
form</FONT>
<BR><FONT SIZE=2>sip:proxy.example.com, and not modify it in the response. This
URL</FONT>
<BR><FONT SIZE=2>clearly satisfies the first required property (of getting
routed back</FONT>
<BR><FONT SIZE=2>to the proxy that inserted it). The second property can be
maintained</FONT>
<BR><FONT SIZE=2>by being call stateful, and extracting the needed parameters
from</FONT>
<BR><FONT SIZE=2>local storage.</FONT>
</P>

<P><FONT SIZE=2>When a proxy does decide to modify the \header{Record-Route}
header in</FONT>
<BR><FONT SIZE=2>the response, one of the operations it must perform is to
locate the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} that it had inserted. If the request
spiraled,</FONT>
<BR><FONT SIZE=2>and the proxy inserted a \header{Record-Route} in each
iteration of</FONT>
<BR><FONT SIZE=2>the spiral, locating the correct header in the response (which
must be</FONT>
<BR><FONT SIZE=2>the proper iteration in the reverse direction) is tricky.
One</FONT>
<BR><FONT SIZE=2>mechanism that is \RECOMMENDED is for the proxy to insert
a</FONT>
<BR><FONT SIZE=2>\header{Record-Route} parameter into the new
\header{Record-Route} header</FONT>
<BR><FONT SIZE=2>in the request each time the request spirals. This parameter
\MUST</FONT>
<BR><FONT SIZE=2>uniquely identify the proxy. When the 200 class respone
arrives, the</FONT>
<BR><FONT SIZE=2>proxy looks for the topmost \header{Record-Route} header
containing</FONT>
<BR><FONT SIZE=2>this parameter. This header is the one for the current
iteration. The</FONT>
<BR><FONT SIZE=2>proxy \MUST remove this parameter before forwarding the
response</FONT>
<BR><FONT SIZE=2>upstream. Upon the next iteration, the same algorithm (find
the</FONT>
<BR><FONT SIZE=2>topmost \header{Record-Route} header with the parameter)
will</FONT>
<BR><FONT SIZE=2>correctly extract the next \header{Record-Route}</FONT>
<BR><FONT SIZE=2>header.</FONT>
</P>
<BR>

<P><FONT SIZE=2>\subsection{UA Processing of Subsequent Requests in a Call
Leg}</FONT>
<BR><FONT SIZE=2>\label{sec:rr:uasubsequent}</FONT>
</P>

<P><FONT SIZE=2>When a UA wishes to send another request for the call-leg (such
as a</FONT>
<BR><FONT SIZE=2>\header{BYE} or \header{INVITE}), it follows the procedures
defined in</FONT>
<BR><FONT SIZE=2>this subsection. The</FONT>
<BR><FONT SIZE=2>procedures here \MUST also be followed for an \ACK request for
a 200</FONT>
<BR><FONT SIZE=2>response to the initial \INVITE for the call leg. The
procedures here</FONT>
<BR><FONT SIZE=2>\MUSTNOT be followed for a \CANCEL request or an \ACK request
for a</FONT>
<BR><FONT SIZE=2>non-200 response. This implies that \CANCEL never contains
a</FONT>
<BR><FONT SIZE=2>\header{Route} header, nor does an \ACK for a non-200
response.</FONT>
</P>

<P><FONT SIZE=2>The request is constructed as specified in Section XXX. The UA
then</FONT>
<BR><FONT SIZE=2>takes the list of URI in the route set. The top URI is inserted
into</FONT>
<BR><FONT SIZE=2>the request URI of the request, including all parameters. Any
URI</FONT>
<BR><FONT SIZE=2>parameters not allowed in the request URI \MUST then be
stripped. Each</FONT>
<BR><FONT SIZE=2>of the remaining URIs (if any) from the route set, including
any</FONT>
<BR><FONT SIZE=2>URI parameters, are placed into a \header{Route} header into
the request,</FONT>
<BR><FONT SIZE=2>in order. The procedures of Section XXX ``locating a SIP
server'' are</FONT>
<BR><FONT SIZE=2>then applied to the URI in the request URI, the the request
is</FONT>
<BR><FONT SIZE=2>forwarded to the resulting server.</FONT>
</P>

<P><FONT SIZE=2>If a UAS has a route set for a call leg, and receives a
re-INVITE for</FONT>
<BR><FONT SIZE=2>that call leg containing \header{Record-Route} headers, it
\MUST copy</FONT>
<BR><FONT SIZE=2>those headers into any 200 class response to that request. If
the</FONT>
<BR><FONT SIZE=2>boolean variable CONTACT_SET is true, the \header{Contact}
header in</FONT>
<BR><FONT SIZE=2>the re-INVITE (if present) replaces the last </FONT>
<BR><FONT SIZE=2>entry in the route set. If the boolean variable CONTACT_SET is
false,</FONT>
<BR><FONT SIZE=2>the UAS \MUST add the URL in the </FONT>
<BR><FONT SIZE=2>\header{Contact} header in the re-INVITE to the bottom of the
route</FONT>
<BR><FONT SIZE=2>set, and then set CONTACT_SET to true. If the re-INVITE did
not</FONT>
<BR><FONT SIZE=2>contain a \header{Contact} header, the route-set at the UAS
remains</FONT>
<BR><FONT SIZE=2>unchanged.</FONT>
</P>

<P><FONT SIZE=2>Similarly, if a UAC has a route set for a call leg, and receives
a 200</FONT>
<BR><FONT SIZE=2>class response to a re-INVITE it sent, the \header{Contact}
header is</FONT>
<BR><FONT SIZE=2>examined. If not present, the route set remains unchanged. If
the</FONT>
<BR><FONT SIZE=2>re-INVITE response had a \header{Contact} header, and the
boolean</FONT>
<BR><FONT SIZE=2>variable CONTACT_SET is false, the URL in the \header{Contact}
header</FONT>
<BR><FONT SIZE=2>in the response is added to the bottom of the route set,
and</FONT>
<BR><FONT SIZE=2>CONTACT_SET is set to true. If the re-INVITE response had
a</FONT>
<BR><FONT SIZE=2>\header{Contact} header, and CONTACT_SET is true, the URL in
the</FONT>
<BR><FONT SIZE=2>\header{Contact} header of the re-INVITE response replaces the
bottom</FONT>
<BR><FONT SIZE=2>value in the route set.</FONT>
</P>

<P><FONT SIZE=2>The above two paragraphs allow a UA to update its
\header{Contact}</FONT>
<BR><FONT SIZE=2>address mid-call, but proxies cannot update their route
address.&nbsp; Once</FONT>
<BR><FONT SIZE=2>on the route, a proxy remains on the route for the duration of
the</FONT>
<BR><FONT SIZE=2>call leg. \annotate{Why the different treatment for Contact
and</FONT>
<BR><FONT SIZE=2>Record-Route in a re-INVITE? It has to do with backwards</FONT>
<BR><FONT SIZE=2>compatibility. RFC2543 did not mandate that a proxy needs to
refresh</FONT>
<BR><FONT SIZE=2>its record-route headers. As a result, the lack of a
record-route in a</FONT>
<BR><FONT SIZE=2>re-INVITE cannot be interpreted to mean that the proxy does not
want</FONT>
<BR><FONT SIZE=2>to be included on the route any longer. Updating of the Contact
header</FONT>
<BR><FONT SIZE=2>mid-call is useful for mobility applications, and is also
useful for</FONT>
<BR><FONT SIZE=2>forms of third party call control}.</FONT>
</P>
<BR>

<P><FONT SIZE=2>OPEN-ISSUE: should the UA remove the maddr param, if present, if
the</FONT>
<BR><FONT SIZE=2>request is sent to the server at that maddr?</FONT>
</P>

<P><FONT SIZE=2>OPEN-ISSUE: should we mention handling of route with local
outbound</FONT>
<BR><FONT SIZE=2>proxies here? RFC2543 has some text on DNS-less UAs, but there
are</FONT>
<BR><FONT SIZE=2>issues with this.</FONT>
</P>

<P><FONT SIZE=2>\header{Proxy processing of a non-initial request}</FONT>
<BR><FONT SIZE=2>\label{sec:rr:proxy2}</FONT>
</P>

<P><FONT SIZE=2>The rules in this section \MUST be followed when a proxy
receives a request</FONT>
<BR><FONT SIZE=2>that contains a \header{Route} header. The \header{Route}
header is</FONT>
<BR><FONT SIZE=2>used to forward the request to the next hop. It \MUST override
any other</FONT>
<BR><FONT SIZE=2>routing decisions that the proxy would otherwise make. Proxies
\MAY</FONT>
<BR><FONT SIZE=2>respond to requests with \header{Route} headers for any reason
(in order</FONT>
<BR><FONT SIZE=2>to perform proxy authorization, for example). But, if the
request is</FONT>
<BR><FONT SIZE=2>proxied, the procedures here \MUST be used to determine where
the</FONT>
<BR><FONT SIZE=2>request is proxied to. The procedures in this section apply
indepedent</FONT>
<BR><FONT SIZE=2>of the request method. They \MUST be followed even if the
request</FONT>
<BR><FONT SIZE=2>method is unknown to the proxy. \annotate{This last sentence
is</FONT>
<BR><FONT SIZE=2>really, really important. It allows for other methods, defined
in the</FONT>
<BR><FONT SIZE=2>future, to have record-routing applied to them. As an example,
an</FONT>
<BR><FONT SIZE=2>instant messaging session run over SIP might begin with a
MESSAGE</FONT>
<BR><FONT SIZE=2>request. That extension can allow for these sessions to
be</FONT>
<BR><FONT SIZE=2>record-routed by proxies that know of this extension. However,
the</FONT>
<BR><FONT SIZE=2>record-routing will only work if proxies that don't know about
the</FONT>
<BR><FONT SIZE=2>extension follow the Route headers properly. As such,
supporting</FONT>
<BR><FONT SIZE=2>\header{Route} headers for all methods, known or unknown, is
very</FONT>
<BR><FONT SIZE=2>important for a robust and future proof proxy
implementation.}</FONT>
<BR><FONT SIZE=2>Since \CANCEL can never contain</FONT>
<BR><FONT SIZE=2>\header{Route}, these procedures never apply to \CANCEL.
However, they</FONT>
<BR><FONT SIZE=2>do apply to \ACK requests for a 200 OK response, which do
contain</FONT>
<BR><FONT SIZE=2>\header{Route} headers. </FONT>
</P>

<P><FONT SIZE=2>The proxy \MUST remove the top \header{Route} header from
the</FONT>
<BR><FONT SIZE=2>request. The URI from that \header{Route} \MUST be placed into
the</FONT>
<BR><FONT SIZE=2>\header{Request-URI} of the proxied request, including
URI</FONT>
<BR><FONT SIZE=2>parameters. Any URL parameters present in the top
\header{Route}</FONT>
<BR><FONT SIZE=2>header which are not allowed in the request URI \MUST be
removed from</FONT>
<BR><FONT SIZE=2>the \header{Request-URI} by the proxy. The procedures of
section XXX</FONT>
<BR><FONT SIZE=2>``Locating a SIP Server'' \MUST be followed to compute the next
hop</FONT>
<BR><FONT SIZE=2>server to forward the request to. </FONT>
</P>

<P><FONT SIZE=2>If the request is an \INVITE request (thus, a re-INVITE) for a
call</FONT>
<BR><FONT SIZE=2>leg that the proxy wishes to receive messages for (very likely
the</FONT>
<BR><FONT SIZE=2>case, since the request probably arrived at the proxy because
the</FONT>
<BR><FONT SIZE=2>proxy record routed in the initial \INVITE), the proxy
\MUST</FONT>
<BR><FONT SIZE=2>re-insert the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} header with the same value it placed in
the</FONT>
<BR><FONT SIZE=2>initial request. Similarly, it should modify the
\header{Record-Route}</FONT>
<BR><FONT SIZE=2>header in any 200 class response in the same way the</FONT>
<BR><FONT SIZE=2>\header{Record-Route} header was modified in the response to
the</FONT>
<BR><FONT SIZE=2>initial \INVITE (which may be no modifications at all). The
purpose of</FONT>
<BR><FONT SIZE=2>this is twofold. First, it allows for proper record-routing in
the</FONT>
<BR><FONT SIZE=2>case of pre-loaded Route headers (see Section XXX). Secondly,
it</FONT>
<BR><FONT SIZE=2>allows for recovery from a UA crash and restart, in which case
the UA</FONT>
<BR><FONT SIZE=2>loses call state, and as a result, its route set as well. The
result</FONT>
<BR><FONT SIZE=2>is that the route set will be re-established through the</FONT>
<BR><FONT SIZE=2>re-INVITE. When coupled with the Session Timer \cite{RFCXXX},
the</FONT>
<BR><FONT SIZE=2>result is a robust way to recover from crashes.</FONT>
</P>

<P><FONT SIZE=2>\subsection{Pre-Loaded Route Headers}</FONT>
</P>

<P><FONT SIZE=2>Normally, a UA constructs the Route headers in a request from
the</FONT>
<BR><FONT SIZE=2>route set learned through \header{Record-Route} headers.
However, in</FONT>
<BR><FONT SIZE=2>some circumstances, it is useful for a UA to insert
\header{Route}</FONT>
<BR><FONT SIZE=2>headers into an initial \INVITE. These headers may have been
learnt by</FONT>
<BR><FONT SIZE=2>the UA through some out of bands means. When an initial
\INVITE</FONT>
<BR><FONT SIZE=2>(initial as far as the UAC and UAS are concerned)
contains</FONT>
<BR><FONT SIZE=2>\header{Route} headers, this is referred to as a
``pre-loaded</FONT>
<BR><FONT SIZE=2>Route''. It is equivalent to strict source routing in IP.
Proxies will</FONT>
<BR><FONT SIZE=2>often not be able to distinguish this case from the case
described in</FONT>
<BR><FONT SIZE=2>Section \ref{sec:rr:proxy}, and will therefore properly use
these</FONT>
<BR><FONT SIZE=2>route headers to forward the request. If the proxies are
interested in</FONT>
<BR><FONT SIZE=2>receiving subsequent messages for the call leg, their insertion
of</FONT>
<BR><FONT SIZE=2>\header{Record-Route} as mandated by Section \ref{sec:rr:proxy}
will</FONT>
<BR><FONT SIZE=2>establish a correct route set at both UAC and UAS. This route
set may</FONT>
<BR><FONT SIZE=2>end up being different from the pre-loaded Route used by the
UAC. As</FONT>
<BR><FONT SIZE=2>such, a UAC that inserts a pre-loaded route set \MUST follow
the</FONT>
<BR><FONT SIZE=2>procedures of Section \ref{sec:rr:uac} in processing the
response to</FONT>
<BR><FONT SIZE=2>this initial \INVITE.</FONT>
</P>
<BR>
<BR>
<BR>

<P><FONT SIZE=2>---</FONT>
<BR><FONT SIZE=2>Jonathan D.
Rosenberg&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

72 Eagle Rock Ave.</FONT>
<BR><FONT SIZE=2>Chief
Scientist&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

First Floor</FONT>
<BR><FONT
SIZE=2>dynamicsoft&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

East Hanover, NJ 07936</FONT>
<BR><FONT
SIZE=2>[email-masked]&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

FAX:&nbsp;&nbsp; (973) 952-5050</FONT>
<BR><FONT SIZE=2><A HREF="http://www.cs.columbia.edu/~jdrosen"
TARGET="_blank">http://www.cs.columbia.edu/~jdrosen</A>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;

PHONE: (973) 952-5000</FONT>
<BR><FONT SIZE=2><A HREF="http://www.dynamicsoft.com"
TARGET="_blank">http://www.dynamicsoft.com</A></FONT>
<BR><FONT SIZE=2>&nbsp;</FONT>
</P>

<P><FONT SIZE=2>_______________________________________________</FONT>
<BR><FONT SIZE=2>SIP mailing list</FONT>
<BR><FONT SIZE=2>[email-masked]</FONT>
<BR><FONT SIZE=2><A HREF="http://lists.bell-labs.com/mailman/listinfo/sip"
TARGET="_blank">http://lists.bell-labs.com/mailman/listinfo/sip</A></FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_003_01C0C40C.43A8EE10--

---

From: "Arunachalam Venkatraman" <[email-masked]>
Date: Tue, 17 Apr 2001 10:02:48 -0500

I understand the routing rule to be (from 6.39 of bis) - Once a Route is
established, at every host, copy the topmost route to the req-uri and then
use the maddr part to route the call.
So, where is the translation occurring?  Each host is using the maddr of the
topmost Route to route the request; the Req-URI seems to be irrelevant here.
The last Route entry, the Contact, ensures the request is ultimately
delivered to the UAS.
Once a route is established, why is translation required?

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

 << File: att1.htm >> << File: ATT00281.txt >> << File: loop.doc >>

(See attached file: loop.doc)
It is important to have the same ReqURI in the ACK as presented in the
RouteHeader because
this will also help in the loop detection. As in the attached diagram
although
the two sip requests
may have identical CallIds, they may have different ReqURI on account of
number
translation
being done at one of the intermediate proxies and the call looping back to
the
proxy. As Keith
pointed out having the ReqURI identical to the INVITE will help determine
the
correct state
machine for processing the call.

-Deepak

Hello,

ACK
sip:[email-masked]:5060;maddr=192.168.10.141;transport=udp;user=p
hone
SIP/2.0

It is important that the Request-Uri in the subsequent messages is that
given in
the Record-Route
as stateful proxies may well use this to identify the correct state machine
to
process the request.

Like Robert, I think this touches upon the issues with Route headers,
outbound
proxies and UA
without DNS capability which I feel hasn't yet been resolved.

Regards,

Keith Robinson

Hi,

Robert.

 -----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

  6.33 Route

Or

c5300-3#

v=0

v=0

Thanks

SG