Subject: [cuss] Open Issue: REQ-8

From: Alan Johnston <[email-masked]>
Date: Fri, 01 Oct 2010 12:59:02 -0500

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 -

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Oct 2010 14:28:00 -0400

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:
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 1 Oct 2010 22:18:22 +0200

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: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Paul Kyzivat
> Sent: Friday, October 01, 2010 7:28 PM
> To: [email-masked]
> 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
> 
> > REQ-8 is related to the ability to determine if another SIP UA 
> > supports the SIP UUI mechanism.
> >
> >   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.
> >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 1 Oct 2010 23:19:15 +0200

Hi,

An advantage with an indicator (option-tag or feature-tag) is that it could prevent DSS1 information from being sent to entities that don't support it. A registrar could remove (something we seem to consider allowing) the DSS1 information before forwarding a request to a UA that hasn't registered support of DSS1. 

At least on bandwidth sensitive wireless networks it is good if one can prevent sending useless stuff.

Regards,

Christer

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of DRAGE, Keith (Keith) [[email-masked]]
Sent: Friday, October 01, 2010 11:18 PM
To: Paul Kyzivat; [email-masked]
Subject: Re: [cuss] Open Issue: REQ-8

regards

Keith

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 01 Oct 2010 22:27:32 -0400

If you want the registrar (actually the proxy or S-CSCF associated with 
the registrar) removing stuff that the registered UAs don't want to see, 
why don't you come up with a real policy mechanism that the UA can 
configure, rather than trying to infer everything?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Oct 2010 10:14:36 +0200

Hi,

>configure, rather than trying to infer everything?

The feature tag is only a way for the UA to tell the regstrar/proxy/S-CSCF whehther it supports DSS1 or not.

What the registrar/proxy/S-CSCF then actually does with the information (e.g. removes the DSS1 information), in addition to using it for forking decissions, can of course be done based on some policy. The feture tag just provides "input" for such policy making.

As I've said before, in my opinon RFC 3840 is the forgotten treasure of SIP, and I really think the default for all extensions should be that UAs can use it.

Regards,

Christer