Re: [dispatch] Call Control UUI Problem Statement

[Dean Willis <[e-mail]>]

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.

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