Subject: [dispatch] Alert-Info thoughts

From: "WORLEY, Dale R (Dale)" <[email-masked]>
Date: Thu, 13 May 2010 16:38:32 -0400

The charter is probably well enough baked.  We can adjust the details of what we do later, regardless of what the charter says.

It might be useful to replace the terms "semantic" and "non-semantic", as they're not very clear.  I've been thinking of "intentional" vs. "rendering":  An "intentional URN" tells something about the status of the dialog, a "rendering URN" tells something about how the alert/ringback signal is to be rendered.

The critical difference between "Alert URNs" (whatever SIP syntax we use to carry them) and status codes is that we expect there to be a small set of status codes so that automata can act upon them reliably.  The space of Alert URNs is expected to be broad and extensible, and likely to have numerous extensions that are proprietary or for use in specific applications (e.g., IMS).  In particular, there is a market need for the Alert URN mechanism to support forward compatibility of the signaling features of existing non-SIP telephone systems.  To prevent chaos, Alert URNs do *not* control the actions of automata.  It is also assumed that almost all UAs can render distinctly only a small subset of Alert URNs, and the mechanism should permit and support such "best efforts" rendering.

Conversely, if these two categories of signal (SIP response codes and Alert URNs) are not distinct enough, we should not create an "Alert URN" mechanism.

It is probably open-ended the set of messages that could carry Alert URNs.  INVITE is obvious, but for the same reason MESSAGE or any dialog-forming message could potentially carry one.  Similarly, re-INVITE and UPDATE and any other request that performs a "major" change to a dialog might need to carry one.  In regard to responses, we can probably safely restrict Alert URNs to the 18x family among provisional responses, though we might want to allow them in *any* final response.

We can generalize slightly the current proposals to create a framework that will allow almost unlimited flexibility, with a standardized algorithm for UAs to choose the "best fit" rendering from the small set of renderings that they support.  That is, let the marketers go wild without bothering anyone.  More about that later...

Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 14 May 2010 12:18:39 -0400

I like the direction Dale is going here.

	Thanks,
	Paul

WORLEY, Dale R (Dale) wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>