Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01)
Paul Kyzivat <pkyzivat@cisco.com> Thu, 27 October 2005 13:55 UTC
Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Df-0003Jy-62; Thu, 27 Oct 2005 09:55:03 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EV8Dc-0003JE-Hi; Thu, 27 Oct 2005 09:55:00 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00817; Thu, 27 Oct 2005 09:54:45 -0400 (EDT)
Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EV8Qy-0002oY-9k; Thu, 27 Oct 2005 10:08:50 -0400
Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 27 Oct 2005 06:54:49 -0700
X-IronPort-AV: i="3.97,258,1125903600"; d="scan'208"; a="357474570:sNHT62126824"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j9RDsfuh025521; Thu, 27 Oct 2005 06:54:46 -0700 (PDT)
Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:54:09 -0400
Received: from [161.44.79.76] ([161.44.79.76]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 27 Oct 2005 09:54:08 -0400
Message-ID: <4360DC00.80303@cisco.com>
Date: Thu, 27 Oct 2005 09:54:08 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dave.robbins@verizon.com
Subject: Re: [Sip] Alert-Info Idea (was Re: Comment on draft-willis-sip-answeralert-01)
References: <OFE5A2F71E.14ECABBA-ON852570A7.00426BE9-852570A7.0043630D@CORE.VERIZON.COM>
In-Reply-To: <OFE5A2F71E.14ECABBA-ON852570A7.00426BE9-852570A7.0043630D@CORE.VERIZON.COM>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 27 Oct 2005 13:54:08.0763 (UTC) FILETIME=[E708ECB0:01C5DAFD]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: c54bc2f42d02429833c0ca4b8725abd7
Content-Transfer-Encoding: 7bit
Cc: sip@ietf.org, MARJOU Xavier RD-MAPS-LAN <xavier.marjou@francetelecom.com>, sip-bounces@ietf.org, leo@cisco.com, Dean Willis <dean.willis@softarmor.com>
X-BeenThere: sip@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Session Initiation Protocol <sip.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:sip@ietf.org>
List-Help: <mailto:sip-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/sip>, <mailto:sip-request@ietf.org?subject=subscribe>
Sender: sip-bounces@ietf.org
Errors-To: sip-bounces@ietf.org
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
- [Sip] Comment on draft-willis-sip-answeralert-01 MARJOU Xavier RD-MAPS-LAN
- [Sip] Alert-Info Idea (was Re: Comment on draft-w… Dean Willis
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… dave.robbins
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… Paul Kyzivat
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… Paul Kyzivat
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… dave.robbins
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… Dean Willis
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… Paul Kyzivat
- Re: [Sip] Alert-Info Idea (was Re: Comment on dra… Dean Willis