[Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01)

[Dean Willis <[e-mail]>]

On Sep 13, 2005, at 4:59 PM, MARJOU Xavier RD-MAPS-LAN wrote:

> Hi,
>
> When reading Req-5 with "some sorts of emergency session", I  
> understand
> that an "emergency mass alert" is a candidate use-case.
>
> Thus, in section 6, I suggest a new value for the Alert-Mode header
> field: "Amplified" so that as many people as possible are alerted  
> (e.g.
> an amplified ring tone). In this case, a UAS could also decide to
> increase the volume of audio.
>

I've been thinking about this, and working on some client specs, and  
I'm beginning to think that maybe the Alert-Info header might offer a  
better way to do this, as well as do a number of other things  
(including possibly the alert-mode function of the draft in  
question). Maybe somebody already suggested this, and it just now  
percolated through my brain, so I apologize if I'm failing to credit  
this idea correctly.

The problem with Alert-Info is that it's almost completely  
unspecified. As I read it, 3261 says it takes a URL as a value,  
without providing any way to negotiate (or confirm) the range of URLs  
that might be meaningful to the UAS. Not good.

Some implementations (aka Cisco) use totally bogus integers or  
cadence-maps or other stuff in the Alert-Info header.  Also not good.

What if we were to define a series of URNs that refer to standardized  
alert-behaviors? We could have registered URNS for:

1) Normal alert
2) Distinctive alert (possibly indexed by an integer, for different  
distinctive alerts)
3) Null alert (which provides for the alert-mode behavior from this  
draft)
4) One or more types of request-encoded alerts, like the Cisco  
integers, where the encoded value is carried as a URN parameter set
5) Emergency alert

We could lump these into one URN set (namespace?) and associate a SIP  
OPTION tag with support for the entire set of alerting behaviors. I  
think of this as "basic alerting options", and we could bound up the  
whole set in one I-D.

Thus, an INVITE request might carry something like:

Alert-Info: urn:org.ietf.sip.alert.basic//emergency
Require: alert.basic

or maybe:

Alert-Info: urn:org.ietf.sip.alert.basic//distinct.1

or

Alert-Info: urn:org.ietf.sip.alert.basic//cadence?3,1,3,5


Then for "downloaded" alert sets (aka HTTP or other URLS) we could  
potentially have additional URN sets, perhaps by URL type, or by  
payload type, or some other combination. This could provide subject  
material for additional IDs.

--
Dean


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip