Subject: [Sip] Construction of Path URI, Service-Route and Record-Route in draft-rosenberg-sip-outbound-discovery-mid-dialog-00

From: <[email-masked]>
Date: Mon, 12 Feb 2007 15:02:27 +0200

Hi Jonathan,

I have been studying
draft-rosenberg-sip-outbound-discovery-mid-dialog-00
and find that the way it suggests to construct and use the Path URI is
not
totally consistent within the spec.

>From the example in Chapter 15, the reader can get an impression that
the Path URI would be identical for all the outbound proxies within
the proxy set assigned to the user:

   Finally, it extracts the URI from the Alternative-Proxies header
   field, which points to proxy 3.  It runs through an identical
   registration procedure with proxy 3.  This procedure will leave the
   UA with two outbound proxies, both of which have exactly the same
   URI.  Its connection table will look like:

   TLS connection to 2:
     sip:outbound.example.com
 
sip:[email-masked];keepalive=stun

   TCP connection to 3:
 
sip:[email-masked];maddr=192.0.2.1
 
sip:[email-masked];keepalive=stun

In this example the URI for proxy 2 and 3 seem to be identical and
the user part of it would have the following properties:

- It encodes all the proxies in the outbound proxy set.
  Furthermore those proxies are there in the same order.

- However the reg-id seems to be incorrectly '1' for both the
registrations.

But reading the normative text it would seem that the user part of the
Path URI would be different for each of the outbound proxies:

- When encoding the user part the proxy would not include itself,
  it would only include the other proxies of the proxy set.

- The reg-id would be different for each proxy.

It seems to me that there would actually be two options how to
use construct the URIs for Path, Service-Route and Record-Route 
headers in this draft:

1. To have each proxy to construct a different Path URI so that
   the user part of the Path URI would be specific to one single
   flow between the UA and the outbound proxy. The differentiation
   would be done by including the reg-id to the encoding of the 
   user part (and possibly proxy not including itself to the proxy set).

2. To have each proxy within the proxy set construct an identical
   Path URI so that the Path URI would be common to all flows
   maintained by the UA towards the proxy set. This would mean
   not using the reg-id when encoding the user part of the URI
   and using the whole proxy set for the encoding.

Using the reflected Path URI within both the Service-Route
and Alternative-Proxies headers, it would seem to me that the
option 2 would be the correct way out of those.

For the option 1 (different Path URI for each proxy) there seem to 
be the following issues:

- The Service-Route header within the 200 OK response of REGISTER
  would be different for each proxy. I belive there should be only
  one single URI to be used within each Service-Route header,
  irrespective of the proxy used.

- The normative text for Alternative-Proxies seem to assume that
  all the alternative proxies would have same URI but different
  maddr parameter to identify the specific proxy. This same URI
  should be the one single common Path URI for the proxy set.

- If the Path URI is not common to the proxy set but each flow
  maintained by the UA would have a different Path URI, then
  why would the Record-Route need to have an additional 
  dialog-specific URI parameter ? I assumed this parameter was
  needed to identify a single specific flow amongst the set of 
  flows when all flows within the set would have the common Path 
  URI. But if the Path URI already maps to a single flow then
  what would be the purpose of the dialog-specific URI parameter ?

- Even if suggesting the usage of reg-id within the user part
  of the Path URI, the draft does not suggest any use for this 
  piece of information to any purpose. 

- The proxies would need complicated procedures in mid-dialog
  failover case to find the correct flow to the same user and UA.
  When having a common Path URI for all the flows and proxies,
  finding the correct flow would become trivial even for the
  mid-dialog failover case. The new proxy would just have to
  ignore the dialog-specific URI parameter.

Having the Path URI to be identical for all flows maintained
by the UA instance, the "stickiness" properties
of the Record-Routed URI would finally be as follows:

- URI + dialog-specific parameter: map to one single flow and proxy
- URI (user and host parts included): map to all flows from the UA
- host part of the URI: map to the ob proxy farm of the domain

Regards,

Erkki
____________________________________

  Erkki Koivusalo
  Nokia Mobile Software
  tel:+358 40 7571197
  mailto:[email-masked]
____________________________________ 

_______________________________________________
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