Subject: RE: [Sip] New Path Extension Header Draft (long)

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Thu, 7 Feb 2002 17:16:41 -0000

You've beaten me to this draft so here are comments based on the text I had
already written in order to get this together quicker.

Keith

1)	Abstract.

I suggest this rather than the one in your proposal. Your abstract contains
too much about service-routes which are not part of the proposal, and which
are already meant to be in the bis draft. 

	This draft provides a mechanism to be used in the REGISTER method,
that allows the proxies that wish to be outbound proxies in future
transactions, or inbound proxies in future transactions, and which are
situated on the signalling path between the UA and the registrar, to
communicate their URL to the UA and the registrar, such that these URLs can
form part of a preloaded route list for future transactions.

References to any 3GPP requirements should be moved to the background
section.

2)	In section 4, you mention that Path header is based on the Route
header. It is surely more correct to say it is based on the Record-Route
header, as that is where the rr-param comes from.

I notice that you have an extra level of decomposition in the BNF. Based on
the Record-Route header I had envisaged only:

	Path          =  "Path" HCOLON 1#
	                 ( name-addr *( SEMI rr-param ))
	rr-param      =  generic-param 

where rr-param is already defined. If we need the extra level of
decomposition, then surely this should also exist in the Record-Route header
in the bis draft.

As introductory text to the section defining the BNF I would suggest the
following text:

	Path header is a mechanism whereby a proxy can request to be on a
signalling path for the request exchanged between the UE and the registrar.
The path-establishment procedure is originated by the P-CSCF during the
registration process. The procedure is performed during registration and all
subsequent reregistrations. The list of Path headers obtained by a
reregistration overwrites the existing list of Path headers at the
registrar. Each reregistration of the same UA may result in new list of Path
headers. The UA uses the list of Path headers to construct a list of Route
headers. When initiating a dialog or standalone transaction, the list of
Route headers will be pre-loaded into the initial INVITE request.. If a CSCF
wants to receive subsequent requests, it will insert its own name to the
Record Route header of the initial INVITE request. Once on the route, a CSCF
remains on the route for the duration of the call. The path learned while
re-registering during an active call does not affect the existing call,
since the routing path for the respective call has already been established.
The list of Path headers is not forwarded to the UE.

3)	I notice that your proposal operates independently in both
directions, i.e. a proxy can choose to be on the path as an inbound proxy,
an outbound proxy, or both. This means that you have ended with with a
different mechanism to that which 3GPP has currently documented. In 3GPP the
current mechanism operates with proxies being on the path as both inbound
and outbound proxies, and therefore the addition of URLs to the Path header
is much more similar to Record-Route (i.e. the path is built on the request,
and the entire path is passed back in the response). 

In the example you have given in the text, the changes would be as follows:
F2	Path: <sip:P1>		as currently
F4	Path: <sip:P2>,<sip:P1>
F5	Path: <sip:P2>,<sip:P1>	(this is your 2nd F4)

If you wish to change the 3GPP current intentions then we need to agree
something quickly. The 3GPP requirements do not need to separate outbound
from inbound proxies. I also cannot envisage when one would want to do this,
so I am not sure it is really a requirement. 

4)	Your procedures seem to imply that the registrar is always located
at an outbound proxy. While this is the case in 3GPP, I had envisaged that a
registrar can be located at an outbound proxy, but that this is not
mandatory.

5)	I was envisaging separate sections for

-	procedures at the UAC
-	procedures at the proxy
-	procedures at the registrar

The text of the procedures according to the 3GPP way of operation that I
have is as follows:

Procedures at the UAC

	When a UAC receives a response to REGISTER containing the Path
header, the UAC shall remove its SIP URL from the list of Path headers,
reverse the order of the list and save the resulting list of Path headers.
This list shall be stored during the entire registration period of the
respective ???public user identity. If this registration is a
reregistration, the P-CSCF shall replace the already existing Path headers
with the new list

	A UAC MUST use any route list created by the Path mechanism during a
registration procedure as the pre-loaded route in the Route header of the
first request in a dialog, or in any request that does not form part of a
dialog.

Procedures at the UAS

	There are no procedures for the UAS.

Procedures at the proxy

	An outbound proxy that wishes to be on the path for future
transactions or dialogs relating to a REGISTER request MUST insert a
resolveable identifier that will reach the proxy as the topmost entry in the
Path header before proxying that request.

	Proxies that are not on the path of the REGISTER request cannot use
this mechanism.

Procedures at the registrar

	If a Path header exists in a sucessful REGISTER request, the
registrar shall construct a list of preloaded Route headers from the list of
entries in the Path header. The order in the lists is preserved. The
registrar MUST bind to each contact information the respective Path header
entries, that were received in the same REGISTER message as that contact
information. The registrar shall also return the path list as a Path header
in a 200 OK response to the REGISTER request.

	An inbound proxy which uses the location server to determine the
Contact address of the user MUST also use this list of preloaded Route
headers in the transaction request.

	The registrar can also act as a proxy as described above (in which
case it inserts a resolvable identifier identifying itself in the Path
header) before storing the list of preloaded Route headers.

I think the current text you have in section 5 would be best treated as an
example of operation, as appears in a number of other SIP drafts, and we
should concentrate on detailing procedures as I have identified.

6)	3GPP consider that an option-tag should also be defined where such
operation is considered essential. This would need to appear in the Require
header (where it is understood by the registrar) and the Proxy-Require
header (where it is understood by proxies) of the REGISTER request.

The text I had drafted for this is as follows:

Option-tag

	This draft defines the option-tag "path" for use in the Require,
Proxy-Require, Supported and Unsupported headers specified in bisdraft [xx].
A server responding to an OPTION request MUST include this option-tag in
accordance with bisdraft [xx]

	A UAC MAY include a "Require: path" in a REGISTER request if it
wants the registration to fail if the registrar does not support this
feature. 

	A proxy MAY add a "Require: path" in a REGISTER request if it wants
the registration to fail if the registrar does not support this feature. 

	A UAC MAY include a "Proxy-Require: path" in a REGISTER request if
it wants the registration to fail if any outbound proxies before the
registrar do not support this feature. 

	A proxy MAY add a "Proxy-Require: path" in a REGISTER request if it
wants the registration to fail if any subsequent outbound proxies before the
registrar do not support this feature. 

7)	And finally, in the acknowledgements can you include Min Huang and
Stinson Mathai, as they put together the original proposal in 3GPP for this
mechanism, and worked most of the 3GPP procedures in 24.229.

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

> ----------
> From: 	Dean Willis[SMTP:[email-masked]]
> Sent: 	07 February 2002 5:49
> To: 	[email-masked]
> Subject: 	[Sip] New Path Extension Header Draft
> 
> I've cobbled together a rough draft of a Path header extension in an
> attempt to meet the a requirement for service route discovery during
> REGISTER for 3GPP established in the Garcia 3GPP requirements draft in the
> SIPPING group.
>  
> It will be announced on internet-drafts soon, and you can pull from:
>  
> http://www.softarmor.com/sipwg/drafts/draft-willis-sip-path-00.txt
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Feb 2002 12:03:04 -0600

----- Original Message -----
From: "Drage, Keith (Keith)" <[email-masked]>
To: <[email-masked]>; "'Dean Willis'" <[email-masked]>
Sent: Thursday, February 07, 2002 11:16 AM
Subject: RE: [Sip] New Path Extension Header Draft (long)

> form part of a preloaded route list for future transactions.

I've modified your suggestion and will include

> References to any 3GPP requirements should be moved to the background

done

> header, as that is where the rr-param comes from.

done

> decomposition, then surely this should also exist in the Record-Route
header

I've included both forms pending further comment

> The list of Path headers is not forwarded to the UE.

I've added some discussion here, but your suggested wording is very 3GPP
specific. I invite further suggestions mode generic in nature.

> and the entire path is passed back in the response).

That's correct. I like my way better. It's very reasonable (as noted by JDR)
to use PATH to discover weird proxy routes toward a UA, without using it to
discover a "home outbound proxy", simply because one may not use or need a
"home outbound proxy" As is. it neatly solves the problem of a "multihop
registration".

> so I am not sure it is really a requirement.

Please consider the mechanism as documented further.

> registrar can be located at an outbound proxy, but that this is not

I've amended to include "It is also possible for a node with specific
knowledge
of network topology to add a Path header referencing another node, thereby
allowing construction of a Path which is discongreunt with the route taken
by the REGISTER or REGISTER Response." in the Usage section.

> - procedures at the registrar

Absolutely needed. I agree.

> in a 200 OK response to the REGISTER request.

The last section of the preceding disagrees with the unidirectional path
model.

> should concentrate on detailing procedures as I have identified.

fair.

> header (where it is understood by proxies) of the REGISTER request.

I disagree. If a UA is expecting a Path on its register resposne and doesn't
get one, it knows the registrar doesn't supply it and none of the proxies in
between cared. Nodes that are unaware of Path will forward it correctly.

> The text I had drafted for this is as follows:
. . .

> mechanism, and worked most of the 3GPP procedures in 24.229.

Sure.

---

From: "Dean Willis" <[email-masked]>
Date: Thu, 7 Feb 2002 12:10:44 -0600

----- Original Message -----
From: "Drage, Keith (Keith)" <[email-masked]>
To: <[email-masked]>; "'Dean Willis'" <[email-masked]>
Sent: Thursday, February 07, 2002 11:16 AM
Subject: RE: [Sip] New Path Extension Header Draft (long)

done

done

fair.

. . .

Sure.