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

Agreed.

Defining URNs "semantically" is what I had in mind. In an application
carried over from the PSTN, distinctive alerting takes one of two different
forms, depending upon whether it is rendered as power ringing or as a
call-waiting alert tone. I would want to use a single URN, which the UAS
would render in whatever way is appropriate for the current state of the
device. Other semantic forms are surely useful as well.

I can also see the potential value in having a URN that carries a specific
rendering.

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

             "Paul Kyzivat"                                                
             <pkyzivat@cisco.c                                             
             om>                                                        To 
                                       Dave C.                             
             10/27/2005 09:54          Robbins/EMPL/MA/Verizon@VZNotes     
             AM                                                         cc 
                                       "Dean Willis"                       
                                       <dean.willis@softarmor.com>,        
                                       sip@ietf.org, "MARJOU Xavier        
                                       RD-MAPS-LAN"                        
                                       <xavier.marjou@francetelecom.com>,  
                                       sip-bounces@ietf.org, leo@cisco.com 
                                                                   Subject 
                                       Re: [Sip] Alert-Info Idea (was Re:  
                                       Comment on                          
                                       draft-willis-sip-answeralert-01)    

I think it would be good if there was a set of URNs that are defined
*semantically* rather than defining precisely what should be rendered.
These would be of much broader applicability than those that specify
particular audio waveforms, etc., because they could be rendered in a
variety of ways: audio, video, tactile, in different languages, etc.

However there is probably value in having ones that have specific
renderings as well.

There could also be scenarios where one entity (e.g. representing the
caller) inserts a URN that is semantic in nature, and another entity
(e.g. representing the callee) replaces that with a different URN (or
URI) that identifies a specific rendering that is consistent with the
intended semantic, the capabilities of the UAS, and the desires of the
UAS in terms of culturally specific values.

             Paul

dave.robbins@verizon.com wrote:
> 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.         <xavier.marjou@francetelecom.com>

>              org
cc
>                                        sip@ietf.org, leo@cisco.com

>
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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
> Use sipping@ietf.org 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 sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip