Subject: [Sip] draft-ietf-sip-outbound-03/routing mid-dialog requests

From: "Kevin Johns" <[email-masked]>
Date: Tue, 23 May 2006 11:15:10 -0600

Section 5.3 of draft-ietf-sip-outbound-03 states:
"Note that techniques to ensure that mid-dialog requests are routed over
an existing flow are out of scope and therefore not part of this
specification. However, an approach such as having the Edge Proxy
Record-Route with a flow token is one way to ensure that mid-dialog
requests are routed over the correct flow."
 
Record-Routing at the Edge Proxy seems like the right thing to do as it
parallels the approach used during Registration (adding a flow token to
the PATH header) for routing of dialog initiating requests. The sticking
point with this approach is that once the Edge Proxy record routes
itself, the route set cannot be updated and Edge Proxy failover is
compromised. The primary reason being that the algorithms proposed in
draft-ietf-sip-outbound-03 for generating the flow token result in a
flow token which is only understandable only to the Edge Proxy which
generated it. Thus, mid-dialog Edge Proxy failover is complicated as the
backup Edge Proxy will not understand the flow token (unless the primary
Edge Proxy shares such state data to the backup Edge Proxy) and cannot
identify the flow to forward the request on.
 
One approach to addressing this issue is to use a token value that has
meaning to both Edge Proxies without requiring the sharing of state
data. To me, the most obvious value is to use the instance ID of the UA
as the flow token. Based on the definition of the instance ID, it is
expected to be globally unique so collisions are not expected. The UA
includes the instance ID in all registrations and thus both Edge Proxies
(primary and secondary) would see this value and can associate it with
the flow.
 
I am planning on authoring an ID that covers this and would like to see
if anyone has any feedback on the proposed solution.
 
Kevin

~~~~~~~~~~~~~~~~~~~~~~
Kevin C. Johns
Project Director - PacketCable Communications Protocols
CableLabs(r)
858 Coal Creek Circle
Louisville, CO 80027-9750
Phone:  303.661.9100
Direct: 303.661.3303
HTTP://www.CableLabs.com <http://www.cablelabs.com/>  

_______________________________________________
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: "Dale R. Worley" <[email-masked]>
Date: Sun, 28 May 2006 21:23:46 -0400

Section 1: Introduction

   Since, such detection takes time and leaves a window of opportunity
   ...

should be 

   Since such detection takes time and leaves a window of opportunity
   ...

Section 4.2.1: Registration by Other Instances

   A User Agent MUST NOT include an instance-id or reg-id in the Contact
   header field of a registration if the registering UA is not the same
   instance as the UA referred to by the target Contact header field.
   (This practice is occasionally used to install forwarding policy into
   registrars.)

This seems overly restrictive.  In regard to instance-id, it makes it
impossible for a compliant UA to do a third-party registration that
obtains a GRUU, even if the UA has no intentions of using the flow
mechanism in regard to requests to/from the Contact UA.  ISTM that
there should be no restriction on using instance-id independently of
Outbound.

In regard to reg-id, this restriction would make it difficult for an
edge-proxy to open a flow to a registrar/proxy to provide service for
a UA in some cases, because the edge-proxy could not perform a
third-party registration of the UA.  (Although it could forge a
first-party registration to the same effect.)

Section 5.3: Forwarding Requests

   Note that techniques to ensure that mid-dialog requests are routed
   over an existing flow are out of scope and therefore not part of this
   specification.  However, an approach such as having the Edge Proxy
   Record-Route with a flow token is one way to ensure that mid-dialog
   requests are routed over the correct flow.

ISTM that to achieve the goals of this I-D, it is vital for mid-dialog
requests to be routed over an existing flow.  But this paragraph is
not clear as to whether the I-D specifies that "techniques" MUST be
used (but is not specifying what ones are to be used) or just noting
that it's possible to do so.

Section 7: Mechanisms for All Servers (Proxys, Registars, UAS)

   A SIP device that receives SIP messages directly from a UA needs to
   behave as specified in this section.  Such devices would generally
   include a Registrar and an Edge Proxy, as they both receive register
   requests directly from a UA.

This should be tightened up, as *any* SIP device can receive SIP
messages directly from a UA.  Also, this paragraph does not use the
BCP 14 key words.

Section 8: Example Message Flow

In this message flow, there are three REGISTERs: F1, F3, and F15.  F1
and F3, which create flows to two different registrars, have different
Call-Ids, which makes sense.  But the I-D says that F15 has a
different Call-Id than F1, despite being a REGISTER to the same proxy,
for the same flow, albeit after the proxy rebooted.  It seems to me
that F15 should be a successor to F1, with the same Call-Id and higher
CSeq, as F15 is meant to refresh or replace F1.

Dale