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

From: Alan Johnston <[email-masked]>
Date: Tue, 12 Apr 2011 08:41:49 -0500

Keith,

Thanks for your comments on the drafts.  In getting the document ready
for WGLC, I have given some thoughts to your questions - see my
answers below.

- Alan -

On Wed, Dec 22, 2010 at 8:17 AM, DRAGE, Keith (Keith)
<[email-masked]> wrote:
> 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.

Not necessarily.  SIP has all kinds of discovery mechanisms including
OPTIONs, and presence, and reg-events that allow quite a bit of
information to be known prior to sending an INVITE.  To couch the
entire discussion of these requirements in these terms is not accurate
for SIP.

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

I could expect SIP routing to be impacted by this.  If you feel this
needs to be included in the requirement, then we can add it.

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

My personal opinion is perhaps and perhaps.

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

Again, I don't think it is appropriate to limit the analysis to a blind INVITE.

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

No, the current thinking is to use feature tags instead of option tags.

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

I don't think we want to do exactly this in SIP - we should just
include the feature tag.  A SIP/ISDN GW could then map this into an
empty element containing only a protocol discriminator, if this is
appropriate.  We should deal with this in the ISDN Interworking draft.

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

We should discuss this in the ISDN Interworking draft.  I think we can
make this good enough.

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

This will depend on the mechanism - I don't think there is any value
in speculation or theoretical analysis in the requirements draft on
this.

>
>
> regards
>
> Keith
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Alan Johnston <[email-masked]>
Date: Mon, 25 Apr 2011 15:40:09 -0500

Keith,

I've been thinking of some text to describe how these discovery
requirements map to the ISDN service.  I'll share on the list shortly.

- Alan -