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

["Vaidya, Maulik" <[e-mail]>]

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.

-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