Subject: Re: [dispatch] Call Control UUI Problem Statement

From: Alan Johnston <[email-masked]>
Date: Mon, 08 Jun 2009 11:17:03 -0500

Dean,

Thanks for your comments - see mine below.

Thanks,
Alan

Dean Willis wrote:
> Alan Johnston wrote:
>   
>> Since the INFO method, RFC2976, was developed for ISUP interworking of
>> user-to-user information, it might seem to be the logical choice here. 
>> For non-call control user-to-user information, INFO can be utilized for
>> end to end transport.  However, for transport of call control
>> user-to-user information, INFO can not be used.  Since the contents
>> carry information that can impact call handling at the UAC, the
>> information must be conveyed with the INVITE transaction.  As the call
>> flows in the previous section show, the information is related to an
>> attempt to establish a session and must be passed with the session setup
>> request (INVITE), responses to that INVITE, or session termination
>> requests.  As a result, it is not possible to use INFO in these cases.
>>     
>
> I favor extending the approach of INFO packages to allow inclusion of
> informational bodies in other transactions, notably INVITE.
>
> This lets us re-use the negotiation and encoding mechanisms already
> painfully worked out for INFO, and keeps us from having to invent yet
> another method for semantic content negotiation, which I see as the
> weakness of the UUI-as-a-new-header-field approach that has been proposed.
>   

I think this is worth discussing more.  I also think we can add some 
additional semantics and tagging with UUI.  However, I don't see how the 
INFO approach, which does the negotiation via header fields in the 
initial dialog setup (INVITE/200/ACK) can work here, given the Call 
Control UUI must be present in the INVITE/200 exchange prior to dialog 
establishment.

> Further, I really think that the headers belong in the realm of the SIP
> protocol machine, whereas the bodies belong to the applications that sue
> SIP. Extending SIP with application-specific header fields feels like a
> layer violation; we already have enough of those and I'd like to avoid
> introducing more.
>   

The problem is that for call control UUI, the body approach does not 
meet the requirements we have discussed and agreed to in SIPPING.  Also, 
a body would require no standardization and work in the IETF - if this 
approach worked, none of us would be pushing a SIP extension for this.

> >From a DISPATCH perspective, this raises the question of where to do the
> work.
>
> I'm inclined to propose a new working group, which I'll tentatively call
> INFORM. The INFORM working group would assume responsibility for
> informational supplementation of SIP messages, including finishing the
> INFO packages work, and addressing the requirements of UUI as raised in
> Alan's draft. I'd also propose a third deliverable, which would be an
> informational document giving guidance on the usage of SIP's
> user-to-user informational extensions, perhaps a design-usage tutorial.
>
> So, three deliverables, a fairly mature problem statement for UUI and a
> very mature document for INFO combine to give us a manageable,
> achieveable scope. This is exactly the sort of short-lived,
> narrowly-defined working group I've been saying we need to use to
> replace the nigh-immortal behemoths like SIP and SIPPING and that we
> need to be able to spin up in order to keep SIPCORE and DISPATCH from
> turning into undead reanimations of SIP and SIPPING. Zombies may be
> fashionable, but they don't make for effective management models.
>
> Of course, we could call the new working group SINFORM for "Sip
> INFORMation". That has a nice ring to it...
>   

As it does seem silly to form a separate working group to standardize a 
single, trivial header field, I would not be opposed to grouping it with 
the INFO package work.  However, this would only be for admin reasons - 
the mechanism and requirements are, in reality, very very different.

> --
> Dean

---

From: Dean Willis <[email-masked]>
Date: Tue, 09 Jun 2009 03:14:53 -0500

> Control UUI must be present in the INVITE/200 exchange prior to dialog 

I'm not saying use INFO per se, but use the "do you understand this 
usage of INFO" style of negotiation to solve the "do you understand this 
type of UUI" problem.

What happens before INVITE? OPTIONS can, of course.

How do you reject an INVITE that carries an informational body? By 
rejecting the option tag that says "Understanding this sort of UUI is 
required".

> approach worked, none of us would be pushing a SIP extension for this.

I'm not sure I believe that. Scratch that; I'm sure I don't believe it, 
and I don't think SIPPING had the right to say "This MUST be a header" 
anyhow.

Further, defining an option tag for "Understands this body type in this 
context" DOES require standardization.

> the mechanism and requirements are, in reality, very very different.

It's not a trivial header field. As worded, it's a 
cross-layer-violating, bad-usage-encouraging very dangerous hack that is 
going to put us into a must-fix-the-unnegotiated-usages problem in a few 
years if we don't fix it the first time.

--
Dean

---

From: Alan Johnston <[email-masked]>
Date: Tue, 09 Jun 2009 08:24:24 -0500

Dean,

SIPPING didn't say it had to be a header, but one of the most important 
requirements is that UUI be passable in Refer-To and redirection URIs.  
While most simple UAs support escaping header fields into URIs for 
transfer, none support escaping bodies into URIs, and for good reason.

However, these are discussions we can have post-DISPATCH.  I don't think 
there really are any open issues around the strong interest in this 
mechanism, and as I said, I'm not opposed to bundling the work with INFO.

Thanks,
Alan

Dean Willis wrote:
>> additional semantics and tagging with UUI.  However, I don't see how 
>> the INFO approach, which does the negotiation via header fields in 
>> the initial dialog setup (INVITE/200/ACK) can work here, given the 
>> Call Control UUI must be present in the INVITE/200 exchange prior to 
>> dialog establishment.
>
> usage of INFO" style of negotiation to solve the "do you understand 
> this type of UUI" problem.
>
>> meet the requirements we have discussed and agreed to in SIPPING.  
>> Also, a body would require no standardization and work in the IETF - 
>> if this approach worked, none of us would be pushing a SIP extension 
>> for this.
>
> I'm not sure I believe that. Scratch that; I'm sure I don't believe 
> it, and I don't think SIPPING had the right to say "This MUST be a 
> header" anyhow.
>
> Further, defining an option tag for "Understands this body type in 
> this context" DOES require standardization.
>
>> As it does seem silly to form a separate working group to standardize 
>> a single, trivial header field, I would not be opposed to grouping it 
>> with the INFO package work.  However, this would only be for admin 
>> reasons - the mechanism and requirements are, in reality, very very 
>> different.
>
> cross-layer-violating, bad-usage-encouraging very dangerous hack that 
> is going to put us into a must-fix-the-unnegotiated-usages problem in 
> a few years if we don't fix it the first time.
>
> -- 
> Dean
>

---

From: "Mary Barnes" <[email-masked]>
Date: Thu, 11 Jun 2009 09:40:32 -0500

Hi folks, 

Based on the amount of feedback received, as well as the level of
commitment to complete the work, we (ADs/chairs) have decided to propose
a new WG (a "mini-WG", if you will) for this topic.  It doesn't fit
SIPCORE, nor any other current WG and there is enough interest that this
shouldn't be individual/AD sponsored.  

The proposed WG would have a single deliverable and would provide a
focused venue for discussions. The idea would be that it would finish
very quickly. 

We will be allocating 30 minutes of agenda time for this topic, with the
focus being on the charter for the WG. 

Regards,
Mary.
DISPATCH WG co-chair

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan Johnston
Sent: Friday, May 22, 2009 12:21 PM
To: [email-masked]
Cc: Joanne McMillen
Subject: [dispatch] Call Control UUI Problem Statement

Several approaches to transporting the ITU-T Q.931 User to User
Information Element (UU IE) data in SIP have been proposed.  As networks
move to SIP it is important that applications requiring this data can
continue to function in SIP networks as well as the ability to interwork
with this ISDN service for end-to-end transparency.  While the
information is carried in ISUP, the contents can be in a number of
protocols that are not ISUP, and as such it is architecturally
unreasonable to interwork these protocols at the SIP / ISUP gateway. 
This work area involves defining a new SIP mechanism to transport this
information. 

Also, the use of message body is another obvious mechanism, but this is
not suitable for a number of reasons including difficulty with multipart
MIME INVITEs and 200 OKs, and in escaping UUI information into redirects
and REFERs.

The I-D draft-johnston-sipping-cc-uui will be used as the basis for this
work.  This draft was first submitted 3 years ago and has had plenty of
discussion in the old SIPPING Working Group.  The requirements in this
document completed a WGLC in SIPPING in December 2008 with strong
support from the group.  This draft proposes a new SIP header field
User-to-User and parameters for transporting this information.

This extension will also be used for native SIP endpoints implementing
similar services and interworking with ISDN services.  Example use cases
include an exchange between two user agents, retargeting by a proxy, and
redirection.  An example application is an Automatic Call Distributor
(ACD) in a contact center.

The coordinators for this work will be Alan Johnston
<[email-masked]> and Keith Drage <[email-masked]>

Thanks,
Alan

_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch