Re: [cuss] Open Issue: REQ-8

I certainly agree with Paul that we need to work through if there are any use cases for it.

Let us consider the interworking with the ISDN. Currently the ISDN does provide an equivalent service to an option tag, in that it essentially says, only proceed with the call if you were able to deliver the UUI to the remote party. This is user user service 1 explicit required. However so far we have only said we want to support interworking with user user service 1 implicit, which is by definition preferred (i.e. the call goes through even if the UUI delivery is not supported). The support in the ISDN for the explicit capabilities depends on the support of the Facility information element in DSS1, and deployments of this are fewer than the implicit version.

So assuming I am only interworking with the UUS1 implicit, then if I send a SIP INVITE request with an option tag in Require, my response will contain a Supported header field with the same option tag, telling me that the ISDN gateway supports the interworking. Given that any number of intermediate points in the ISDN after the gateway could have removed the information, then this seems information that is best useless.

REQ-9 also says that there could be any number of entities in the path before the gateway that could also remove the information.

The other way of using option tags is to put it in the Supported header field of the request, which is essentially saying the sender supports the extension. The ISDN equivalent of this is to include the UUI in the SETUP message, thus turning the service on. That first data element does not need to contain anything except the protocol discriminator. In some ways this also works better, because not only does it tell the remote party that I support UUI, but it also tells them which protocol discriminator I also support (albeit only one). I also suspect this case is less relevant, as most UUI usage will in any case start with real UUI to transport in the initial INVITE request, even if there is data to come in the return direction.

So in conclusion, I don't think there is any need for this in the ISDN interworking use case, unless we are going to support interworking with user user service 1 explicit required.

regards

Keith

> -----Original Message-----
> From: cuss-bounces@ietf.org [mailto:cuss-bounces@ietf.org] On 
> Behalf Of Paul Kyzivat
> Sent: Friday, October 01, 2010 7:28 PM
> To: cuss@ietf.org
> Subject: Re: [cuss] Open Issue: REQ-8
> 
> I don't understand when the option mechanism would be useful 
> given the low level of guarantee is provided.
> 
> Can someone suggest a use case when a better outcome would 
> result from using this than not using it?
> 
> The feature-tag (callee capability), may increase the odds. 
> But if the UAS is a gateway, the odds aren't increased much if at all.
> 
> And there aren't any cases where there is a guarantee, or 
> even an after the fact indication that the UUI was processed.
> 
> It would be better if there was an acknowledgment of the UUI. 
> But even that won't be helpful in the interworking case. 
> Also, I presume if there was an ack, it would be by the UAS, 
> not necessarily the application above it. (At least that was 
> concluded about INFO messages.)
> 
> 	Thanks,
> 	Paul
> 
> On 10/1/2010 1:59 PM, Alan Johnston wrote:
> > REQ-8 is related to the ability to determine if another SIP UA 
> > supports the SIP UUI mechanism.
> >
> > On the call, some argued that this provided little value, since:
> >   1. If the UA was a gateway, there was no guarantee that the UUI 
> > would be transported over ISDN all the way to the termination
> >   2. Supporting the mechanism does not imply that the UUI 
> data itself 
> > was understood or processed by the UA.
> >
> > However, I still think there is value in this requirement.  
> If there 
> > are additional requirements for more granular support, we could add 
> > additional requirements.
> >
> > For example, Paul suggested that support for a particular UUI 
> > application could be indicated by a SIP feature tag.  This 
> would allow 
> > SIP caller prefs and callee capability mechanisms (RFC 3840 and RFC
> > 3841) to be used.  This could be a useful mechanism to provide this 
> > level of discovery.
> >
> > - Alan -
> > _______________________________________________
> > cuss mailing list
> > cuss@ietf.org
> > https://www.ietf.org/mailman/listinfo/cuss
> >
> _______________________________________________
> cuss mailing list
> cuss@ietf.org
> https://www.ietf.org/mailman/listinfo/cuss
> 