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

[[e-mail]]

I agree wholeheartedly with Dean. A URL is a nice, generic way to specify
an alert signal, but unless you know what sort of URLs your client
understands, it's not very useful. Some clients might understand a URL that
returns an audio file, but for other clients that might be totally useless.
A set of standardized URNs that includes the various alerting patterns
typically used in traditional telephony applications would be of great
interest to me and my work. This would include the standard North American
alerting patterns generically identified by the integers one through five,
perhaps expressed more generically in some manner. And I imagine that there
are other forms of alerting that could be accepted as standard. In my
current work, we have had to invent a notation for this, and I've been
suggesting that we think about promoting a standard of some sort.

Dave Robbins
Verizon Laboratories
40 Sylvan Rd.
Waltham, MA 02451-1128
781 466 4188


                                                                           
             "Dean Willis"                                                 
             <dean.willis@soft                                             
             armor.com>                                                 To 
             Sent by:                  "MARJOU Xavier RD-MAPS-LAN"         
             sip-bounces@ietf.         <[e-mail]>   
             org                                                        cc 
                                       [e-mail], [e-mail]         
                                                                   Subject 
             10/26/2005 11:20          [Sip] Alert-Info Idea (was Re:      
             PM                        Comment on                          
                                       draft-willis-sip-answeralert-01)    
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           
                                                                           





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





_______________________________________________
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