Subject: [cuss] draft-ietf-cuss-sip-uui-reqs-01: REQ-8 and REQ-10

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 22 Dec 2010 15:17:27 +0100

For the following two requirements, I am still not sure we understand how we want to use these, and more importantly, I am not sure we have sufficient understanding to allow us define a mechanism. I said this in Beijing, and I am repeating it now.

   REQ-8: The mechanism will allow a UAC to learn or request that a UAS
   understands the call control UUI mechanism.

      This could be useful in ensuring that a request destined for the
      PSTN is routed to a gateway that supports the ISDN UUI service
      rather than an otherwise equivalent PSTN gateway that does not
      support the ISDN UUI service.  Note that support of the UUI
      mechanism does not, by itself, imply that a particular user
      application is supported - see REQ-10.

   REQ-10: The mechanism will provide the ability for a UA to discover
   which types or application usages of UUI another UA understands or
   supports.

      The creation of a registry of application usages for the SIP UUI
      mechanism is implied by this requirement.  For the ISDN Service,
      there could be value in utilizing the protocol discriminator,
      which is the first octet of the ISDN UUI information, for this
      purpose.

Note that we have to consider these in requirements in terms of the 1st request in a dialog, and in terms of the first response in a dialog.

Looking at the first request:

For REQ-8 the way this is written implies that SIP routeing is impacted by it. Yet this is not stated by the requirement. If it is not, then you will reach a gateway where discard will occur anyway, or if it is Require: UUI, then the request will be rejected. But we have already said that we are emulating ISDN user to user service 1 implicit, which does not have such a required capability. That only occurs with UUS service 1 explicit. 

RFC 4485 states:

   Because of the possibility of interoperability and complexity
   problems that result from the usage of Require and Proxy-Require, we
   believe the following guidelines are appropriate:

   o  The usage of these header fields in requests for basic SIP
      services (in particular, session initiation and termination) is
      NOT RECOMMENDED.  The less frequently a particular extension is
      needed in a request, the more reasonable it is to use these header
      fields.

   o  The Proxy-Require header field SHOULD be avoided at all costs.
      The failure likelihood in an individual proxy stays constant, but
      the path failure grows exponentially with the number of hops.  On
      the other hand, the Require header field only mandates that a
      single entity, the UAS, support the extension.  Usage of
      Proxy-Require is thus considered exponentially worse than usage of
      the Require header field.

   o  If either Require or Proxy-Require are used by an extension, the
      extension SHOULD discuss how to fall back to baseline SIP
      operation if the request is rejected with a 420 response.

So I guess there are two major questions concerning this direction of operation:

1)	Do we intend REQ-8 to influence SIP routing?

2)	Do we intend REQ-8 to generally be used in the same way as a Require option tag?

For REQ-10, I am not sure how we make this work on the first request. If I wish to include UUI in the first request, that is surely an automatic indication that I support it in the first request.

Looking now at the usage in the first response.

I don't see how we make REQ-8 support the usage in the first response, unless you intend to do this with a Supported header field and option tag. However this is totally different to the operation of the ISDN mechanism. 

The ISDN mechanism requires inclusion of UUI in the request to allow the usage in the response. That could well be an empty element containing only the protocol discriminator. 

For REQ-10, the suggested feature tage mechanism does not really interwork cleanly with this.

Finally, I am unsure of the interaction of REQ-8 and REQ-10 with REQ-3 and REQ-4, i.e. in the presence of the forwarding and redirection. Does the forwarding user have access to either REQ-8 or REQ-10. How does the C (final destination) user distinguish between mechanisms supported by the A user (origin) and the various forwarding users?

regards

Keith