Subject: [dispatch] Call Control UUI Problem Statement

From: Alan Johnston <[email-masked]>
Date: Fri, 22 May 2009 12:20:50 -0500

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. 

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.

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

---

From: Dean Willis <[email-masked]>
Date: Fri, 22 May 2009 15:51:22 -0500

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

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.

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

--
Dean