Re: [Sip] Alert-Info Idea (was Re: Commenton draft-willis-sip-an sweralert-01)

[Paul Kyzivat <[e-mail]>]

Vaidya, Maulik wrote:
> Gents, pardon my ignorance if I say something really stupid
> 
> Shouldn't 'semantic URNs' in some manner, shape or form include the format
> of alert (i.e. wav, mp3 etc), and the preferred medium of download (i.e.
> HTTP, WAP etc)? (because not all UACs will have the capability to support
> all forms of alert tones and download mechanisms.

In my mind, a *semantic* URN representing an alert would be something like:
- normal alert
- emergency alert
- distintive alert N

Then the receiving device would have complete freedom to render whatever 
it thinks is suitable to achieve that semantic. Most likely devices 
would be provisionable with a suitable value.

There is no implication that the alert would be audio. It might be 
rendered using a "ringer" on a phone with traditional form factor, by 
playing a tune on a device with a speaker, by a flashing light on a 
device for a deaf user, and by a popup window on the screen of a PC 
running a softphone with audio disabled. Or it could be a combination of 
things.

What you are describing isn't a URN at all, it is a URL that can be used 
to locate some representation to be rendered. That is ok too, but it 
isn't the same thing.

	Paul

> -Maulik
> 
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of
> [e-mail]
> Sent: Thursday, October 27, 2005 10:08 AM
> To: Paul Kyzivat
> Cc: [e-mail]; MARJOU Xavier RD-MAPS-LAN; [e-mail];
> [e-mail]; Dean Willis
> Subject: Re: [Sip] Alert-Info Idea (was Re: Commenton
> 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"                       
>                                        <[e-mail]>,        
>                                        [e-mail], "MARJOU Xavier        
>                                        RD-MAPS-LAN"                        
>                                        <[e-mail]>,  
>                                        [e-mail], [e-mail] 
>                                                                    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
> 
> [e-mail] 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.         <[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
>>
> 
> 
> 
> 
> 
> 
> _______________________________________________
> 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
> 

_______________________________________________
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