Subject: Re: [cuss] Open Issue: REQ-8

From: Alan Johnston <[email-masked]>
Date: Wed, 3 Nov 2010 09:42:48 -0500

I agree with Christer that feature tags are under utilized in SIP and can be
very useful.

I think we can develop a feature tag mechanism instead of the SIP option tag
that had been proposed.

I'm also planning to change REQ-8 to:

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

What do others think?

- Alan -

On Sat, Oct 2, 2010 at 3:14 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> >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?
>
> 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
>
>
> On 10/1/2010 5:19 PM, Christer Holmberg wrote:
> > 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
> >
> > 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
> >>
> >> 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
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/cuss
> >>>
> >> _______________________________________________
> >> cuss mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/cuss
> >>
> > _______________________________________________
> > cuss mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/cuss
> _______________________________________________
> cuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cuss
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 03 Nov 2010 11:01:09 -0400

On 11/3/2010 10:42 AM, Alan Johnston wrote:
> I agree with Christer that feature tags are under utilized in SIP and
> can be very useful.
>
> I think we can develop a feature tag mechanism instead of the SIP option
> tag that had been proposed.
>
> REQ-8:  The mechanism will provide the ability for a UA to discover
> which types or application usages of UUI another UA understands or supports.
>
> What do others think?

I think it is potentially an improvement.

But its still not very useful unless it is reliable, and it seems, based 
on what Keith has said, that it can't be reliable in the ISDN 
interworking case. The GW can say that it supports ISDN interworking 
format, but that gives no guarantee that the actual termination point 
for the call does. So in spite of this indication I may still be sending 
UUI info into the bit bucket.

If we had such a discovery mechanism, ISTM it would be much more useful 
if this went down to the level of the individual ISDN protocol 
discriminators. But I guess an ISDN GW won't be able to provide that 
level - or will it be able to do so once the call signaling is established?

	Thanks,
	Paul

> - Alan -
>
> On Sat, Oct 2, 2010 at 3:14 AM, Christer Holmberg
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     Hi,
>
>     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
>
>
>      > 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] <mailto:[email-masked]>
>     [[email-masked] <mailto:[email-masked]>] On Behalf Of
>     DRAGE, Keith (Keith) [[email-masked]
>     <mailto:[email-masked]>]
>      > To: Paul Kyzivat; [email-masked] <mailto:[email-masked]>
>      > 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
>     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
>      > 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
>      >
>      >> From: [email-masked] <mailto:[email-masked]>
>     [mailto:[email-masked] <mailto:[email-masked]>] On
>      >> Behalf Of Paul Kyzivat
>      >> To: [email-masked] <mailto:[email-masked]>
>      >>> [email-masked] <mailto:[email-masked]>
>      >> [email-masked] <mailto:[email-masked]>
>      > [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 3 Nov 2010 16:46:15 +0100

It certainly will not achieve anything useful in respect of communication with an ISDN user.

In the ISDN if I start service 1, I can use protocol discriminator x on the first packet exchanged. You can reply with protocol discriminator y in respect of your packet, and then I can use z on my next packet. There is no ISDN negotiation mechanism or advertisment mechanism that involves the protocol discriminator.

I agree that there are proposals for an application identifier over and above the protocol discriminator. But all that might do is tell me that I am communicating with an entity that happens to support the ISDN application. It will not tell me which protocol discriminator I intend to use.

I think we left this on the previous discussion as work out some useful use cases where it provides valuable information that enhances the communication. So maybe we should ask for just that.

regards

Keith 

> Sent: Wednesday, November 03, 2010 3:01 PM
> To: Alan Johnston
> Cc: [email-masked]
> > I think we can develop a feature tag mechanism instead of the SIP 
> > option tag that had been proposed.
> >
> But its still not very useful unless it is reliable, and it 
> seems, based on what Keith has said, that it can't be 
> reliable in the ISDN interworking case. The GW can say that 
> it supports ISDN interworking format, but that gives no 
> guarantee that the actual termination point for the call 
> does. So in spite of this indication I may still be sending 
> If we had such a discovery mechanism, ISTM it would be much 
> more useful if this went down to the level of the individual 
> ISDN protocol discriminators. But I guess an ISDN GW won't be 
> able to provide that level - or will it be able to do so once 
> the call signaling is established?
> 
> 	Thanks,
> 	Paul
> 
> > - Alan -
> >
> >      >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,
> >      >> But if the UAS is a gateway, the odds aren't 
> increased much if
> >     at all.
> >      >>

---

From: Cullen Jennings <[email-masked]>
Date: Sun, 7 Nov 2010 15:53:53 -0700

On Nov 3, 2010, at 8:42 AM, Alan Johnston wrote:

> REQ-8:  The mechanism will provide the ability for a UA to discover which types or application usages of UUI another UA understands or supports.
> 
> What do others think?
> 

I'd probably argue this was a a req in addition to current 8 but either way, yes sounds like a good idea. Clearly when doing PSTN interop, this will only be as good as what the near end gateway claims it can do and not what the far end PSTN GW actually does but it still seem worth doing.