From internet-drafts@ietf.org Tue Jan 17 04:24:17 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E3D321F85E4; Tue, 17 Jan 2012 04:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ieCJPlR4r2p; Tue, 17 Jan 2012 04:24:16 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCBD221F8596; Tue, 17 Jan 2012 04:24:16 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p1 Message-ID: <20120117122416.25235.51990.idtracker@ietfa.amsl.com> Date: Tue, 17 Jan 2012 04:24:16 -0800 Cc: salud@ietf.org Subject: [salud] I-D Action: draft-ietf-salud-alert-info-urns-05.txt X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 12:24:17 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Sip ALerting for User Devices Working= Group of the IETF. Title : Alert-Info URNs for the Session Initiation Protocol (SIP) Author(s) : Laura Liess Roland Jesske Alan Johnston Dale R. Worley Paul Kyzivat Filename : draft-ietf-salud-alert-info-urns-05.txt Pages : 36 Date : 2012-01-17 The Session Initiation Protocol (SIP) supports the capability to provide a reference to a specific rendering to be used by the UA when the user is alerted. This is done using the Alert-Info header field. However, the reference addresses only network resources with specific rendering properties. There is currently no support for predefined standard identifiers for describing the semantics of the alerting situation or the characteristics of the alerting signal, without being tied to a particular rendering. To overcome this limitation and support new applications, a new family of URNs for use in SIP Alert-Info header fields is defined in this specification. This document normatively updates [RFC3261], the Session Initiation Protocol (SIP). It changes the usage of the SIP Alert-Info header field defined in the [RFC3261] by additionally allowing its use in all provisional responses to INVITE (except the 100 response). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-salud-alert-info-urns-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-salud-alert-info-urns-05.txt From laura.liess.dt@googlemail.com Tue Jan 17 05:22:48 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2CD2F21F85E4 for ; Tue, 17 Jan 2012 05:22:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jmCBwWWrZF1s for ; Tue, 17 Jan 2012 05:22:47 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 35D0C21F85DF for ; Tue, 17 Jan 2012 05:22:47 -0800 (PST) Received: by wgbdq11 with SMTP id dq11so1332994wgb.13 for ; Tue, 17 Jan 2012 05:22:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=iloNUXojAGtwIL+b9bs3wDKPLrgmTxpLaQU7U5bDl34=; b=TC6o6jDBLsQAA97mMgN8lkChTtP9vepWEAhJCV/UYY4z5PMmopUId8aTefgm84bAVW wmFChoWjsctCekyaUAKyccBfPL2uAHtHRXZJX0dAxTYsVD2KZxeSSrECS1Qi47wHKsSU KbTqPo/4kdjkZC4KHnuMP0w1fIUDxGcW1PIMA= MIME-Version: 1.0 Received: by 10.181.11.163 with SMTP id ej3mr28297254wid.4.1326806566414; Tue, 17 Jan 2012 05:22:46 -0800 (PST) Received: by 10.227.23.197 with HTTP; Tue, 17 Jan 2012 05:22:46 -0800 (PST) Date: Tue, 17 Jan 2012 14:22:46 +0100 Message-ID: From: Laura Liess To: salud@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [salud] New version draft-ietf-salud-alert-info-urns-05 X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Jan 2012 13:22:48 -0000 Hi, A new version of the draft was submitted. There are mainly editorial and text consistency changes. I think the current version covers all known open issues. Please send your comments. Thanks a lot Laura ---------- Forwarded message ---------- From: Date: 2012/1/17 Subject: [salud] I-D Action: draft-ietf-salud-alert-info-urns-05.txt To: i-d-announce@ietf.org Cc: salud@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Sip ALerting for User Devices Working Group of the IETF. =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : Alert-Info URNs for the Session = Initiation Protocol (SIP) =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : Laura Liess =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Roland Jesske =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Alan Johnston =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dale R. Worley =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul Kyzivat =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-salud-alert-info-urns-0= 5.txt =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 36 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2012-01-17 =A0 The Session Initiation Protocol (SIP) supports the capability to =A0 provide a reference to a specific rendering to be used by the UA when =A0 the user is alerted. =A0This is done using the Alert-Info header field. =A0 However, the reference addresses only network resources with specific =A0 rendering properties. =A0There is currently no support for predefined =A0 standard identifiers for describing the semantics of the alerting =A0 situation or the characteristics of the alerting signal, without =A0 being tied to a particular rendering. =A0To overcome this limitation =A0 and support new applications, a new family of URNs for use in SIP =A0 Alert-Info header fields is defined in this specification. =A0 This document normatively updates [RFC3261], the Session Initiation =A0 Protocol (SIP). =A0It changes the usage of the SIP Alert-Info header =A0 field defined in the [RFC3261] by additionally allowing its use in =A0 all provisional responses to INVITE (except the 100 response). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-salud-alert-info-urns-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-salud-alert-info-urns-05.txt _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud From jewel@ssd-tech.com Fri Jan 20 07:08:03 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9D421F8571 for ; Fri, 20 Jan 2012 07:08:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDQdLSlc58GK for ; Fri, 20 Jan 2012 07:08:03 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7CA2821F8532 for ; Fri, 20 Jan 2012 07:08:02 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Fri, 20 Jan 2012 21:03:27 +0600 From: "Firoze M. Zahidur Rahman" To: "salud@ietf.org" Date: Fri, 20 Jan 2012 21:03:25 +0600 Thread-Topic: Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXhKjpXJ8O3QfLQIW4jP8BNzrGEg== Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18656.005 x-tm-as-result: No--46.909200-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:09:07 -0000 Hi=20 Greetings! I am very new to this area. Advance apologies if my ideas sounds completely= misaligned. I found current way of using multiple Alert-Info URNs and Priority Rules a = bit difficult to use and implement. I can see that we have 6 fixed alert-ca= tegories and the Alert URN Format is=20 "URN:alert:" alert-identifier And format of alert-identifier is alert-category ":" alert-indication and alert-indication is a single value. If we can allow to include multiple value in alert-indication separated by = comma (,) and the order of appearance will decide the order of priority for= the alert-indication value then I think it will be easy to implement from = the device side. So instead of sending multiple URN like=20 URN:alert:source:family=20 URN:alert:source:friend URN:alert:source:internal URN:alert:source:unclassified device will send URN as=20 URN:alert:source:family,friend,internal,unclassified Besides, if we disallow or ignore (or latest appearance overrides earlier) = multiple appearance of alert-category then it will be more easier to implem= ent. I have another suggestion regarding the values of alert-category priority. = If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-= 9 to make it simple, then I think devices will have the provision to priori= tize 2 calls/sessions (in case of call waiting or line busy) easily and dev= ices will be able to implement specific logics for them. And if we can introduce another alert-category to guide the call/session ha= ndle behavoir according to service or priority for the devices e.g. force c= onnect on busy, notify back when free, delivery report (read, delivered, no= t delivered etc) (as we are handing SIP sessions - the URNs should cover IM= and short messages as well may be). Thanks & Best Regards JEWEL Firoze M Zahidur Rahman From pkyzivat@alum.mit.edu Fri Jan 20 07:43:00 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 797B721F8619 for ; Fri, 20 Jan 2012 07:43:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ekIMS4YjN2bf for ; Fri, 20 Jan 2012 07:42:59 -0800 (PST) Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [76.96.62.32]) by ietfa.amsl.com (Postfix) with ESMTP id 80EAA21F860F for ; Fri, 20 Jan 2012 07:42:59 -0800 (PST) Received: from omta01.westchester.pa.mail.comcast.net ([76.96.62.11]) by qmta03.westchester.pa.mail.comcast.net with comcast id Prci1i0010EZKEL53rizeW; Fri, 20 Jan 2012 15:42:59 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta01.westchester.pa.mail.comcast.net with comcast id Priy1i00S07duvL3Mrizy1; Fri, 20 Jan 2012 15:42:59 +0000 Message-ID: <4F198B8B.5040008@alum.mit.edu> Date: Fri, 20 Jan 2012 10:43:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: salud@ietf.org References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 15:43:00 -0000 On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: > Hi > > Greetings! > > I am very new to this area. Advance apologies if my ideas sounds completely misaligned. > > I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is > > "URN:alert:" alert-identifier > > And format of alert-identifier is > > alert-category ":" alert-indication > > and alert-indication is a single value. > > If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side. > > So instead of sending multiple URN like > URN:alert:source:family > URN:alert:source:friend > URN:alert:source:internal > URN:alert:source:unclassified > > device will send URN as > > URN:alert:source:family,friend,internal,unclassified In the above you have not included the header. It would really be: Alert-Info: URN:alert:source:family Alert-Info: URN:alert:source:friend Alert-Info: URN:alert:source:internal Alert-Info: URN:alert:source:unclassified and your preference would seem to be: Alert-Info: URN:alert:source:family,friend,internal,unclassified But the latter cannot work. The key point is that Alert-Info takes URIs as arguments (including URNs), which can be separated by commas or as separate header fields. Because of that, in your latter case, "friend" is syntactically incorrect because it is not a URI. Aside from that I don't understand why you think what you propose is easier to use or implement. (I agree that is uses fewer bytes, but that doesn't make it easier.) Thanks, Paul > Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement. > > > I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them. > > And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be). > > Thanks& Best Regards > > > JEWEL > Firoze M Zahidur Rahman > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From jewel@ssd-tech.com Fri Jan 20 08:58:51 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 788E021F8677 for ; Fri, 20 Jan 2012 08:58:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijPhWJQ-y-FE for ; Fri, 20 Jan 2012 08:58:50 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id E441821F863B for ; Fri, 20 Jan 2012 08:58:49 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Fri, 20 Jan 2012 22:54:17 +0600 From: "Firoze M. Zahidur Rahman" To: "salud@ietf.org" Date: Fri, 20 Jan 2012 22:54:17 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXiZchU8xBCwcmRIihhOOfy/m8PQACFChO Message-ID: <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> In-Reply-To: <4F198B8B.5040008@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18656.005 x-tm-as-result: No--65.101600-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 16:58:51 -0000 Hi=20 Its not really usage of lesser no of bytes, the overall idea was to accommo= date multiple values in the same URN. As this extension enables UA or devic= es to choose/implement features as per internal implementation logic - my i= dea was to make the structure as - all values in single line. So that while= implementing device will not have to think about same category multiple ti= mes. Even if same category multiple times is allowed - it will completely r= efresh/overrule earlier appearance. And the order of appearance wise priority (I think corrent approach is also= same, priority is decided by order of appearance of URN in header field) a= lso handles the priority decision making process unchanged. Instead of comma(,) we can use dot(.) or slash(/) separated values may be. = Or we can find some other way to make it URI compatible. But that can be th= ough/found out if everyone thinks that bundling all values of a category in= single URN makes sense. Thanks & Best Regards Jewel ________________________________________ From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@alum.mit.edu] Sent: Friday, January 20, 2012 11:43 PM To: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: > Hi > > Greetings! > > I am very new to this area. Advance apologies if my ideas sounds complete= ly misaligned. > > I found current way of using multiple Alert-Info URNs and Priority Rules = a bit difficult to use and implement. I can see that we have 6 fixed alert-= categories and the Alert URN Format is > > "URN:alert:" alert-identifier > > And format of alert-identifier is > > alert-category ":" alert-indication > > and alert-indication is a single value. > > If we can allow to include multiple value in alert-indication separated b= y comma (,) and the order of appearance will decide the order of priority f= or the alert-indication value then I think it will be easy to implement fro= m the device side. > > So instead of sending multiple URN like > URN:alert:source:family > URN:alert:source:friend > URN:alert:source:internal > URN:alert:source:unclassified > > device will send URN as > > URN:alert:source:family,friend,internal,unclassified In the above you have not included the header. It would really be: Alert-Info: URN:alert:source:family Alert-Info: URN:alert:source:friend Alert-Info: URN:alert:source:internal Alert-Info: URN:alert:source:unclassified and your preference would seem to be: Alert-Info: URN:alert:source:family,friend,internal,unclassified But the latter cannot work. The key point is that Alert-Info takes URIs as arguments (including URNs), which can be separated by commas or as separate header fields. Because of that, in your latter case, "friend" is syntactically incorrect because it is not a URI. Aside from that I don't understand why you think what you propose is easier to use or implement. (I agree that is uses fewer bytes, but that doesn't make it easier.) Thanks, Paul > Besides, if we disallow or ignore (or latest appearance overrides earlier= ) multiple appearance of alert-category then it will be more easier to impl= ement. > > > I have another suggestion regarding the values of alert-category priority= . If we make it a number like 0, 1, 10 anything may be between 00 to 99 or = 0-9 to make it simple, then I think devices will have the provision to prio= ritize 2 calls/sessions (in case of call waiting or line busy) easily and d= evices will be able to implement specific logics for them. > > And if we can introduce another alert-category to guide the call/session = handle behavoir according to service or priority for the devices e.g. force= connect on busy, notify back when free, delivery report (read, delivered, = not delivered etc) (as we are handing SIP sessions - the URNs should cover = IM and short messages as well may be). > > Thanks& Best Regards > > > JEWEL > Firoze M Zahidur Rahman > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud= From pkyzivat@alum.mit.edu Fri Jan 20 11:49:58 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C4C821F8656 for ; Fri, 20 Jan 2012 11:49:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.626 X-Spam-Level: X-Spam-Status: No, score=-2.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyg3B7WPnz6e for ; Fri, 20 Jan 2012 11:49:57 -0800 (PST) Received: from qmta10.westchester.pa.mail.comcast.net (qmta10.westchester.pa.mail.comcast.net [76.96.62.17]) by ietfa.amsl.com (Postfix) with ESMTP id A53DF21F8650 for ; Fri, 20 Jan 2012 11:49:57 -0800 (PST) Received: from omta17.westchester.pa.mail.comcast.net ([76.96.62.89]) by qmta10.westchester.pa.mail.comcast.net with comcast id PsM21i0051vXlb85AvpxUi; Fri, 20 Jan 2012 19:49:57 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta17.westchester.pa.mail.comcast.net with comcast id Pvpw1i00V07duvL3dvpwf7; Fri, 20 Jan 2012 19:49:57 +0000 Message-ID: <4F19C562.4050006@alum.mit.edu> Date: Fri, 20 Jan 2012 14:49:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: salud@ietf.org References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Jan 2012 19:49:58 -0000 On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: > Hi > > Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. As this extension enables UA or devices to choose/implement features as per internal implementation logic - my idea was to make the structure as - all values in single line. So that while implementing device will not have to think about same category multiple times. Even if same category multiple times is allowed - it will completely refresh/overrule earlier appearance. > > And the order of appearance wise priority (I think corrent approach is also same, priority is decided by order of appearance of URN in header field) also handles the priority decision making process unchanged. > > Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling all values of a category in single URN makes sense. If you look through the salud mail archives you will see that combining things into a single URN was proposed and discussed, but we settled on what we have now. Thanks, Paul > Thanks& Best Regards > > Jewel > > ________________________________________ > From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Friday, January 20, 2012 11:43 PM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules > > On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Greetings! >> >> I am very new to this area. Advance apologies if my ideas sounds completely misaligned. >> >> I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is >> >> "URN:alert:" alert-identifier >> >> And format of alert-identifier is >> >> alert-category ":" alert-indication >> >> and alert-indication is a single value. >> >> If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side. >> >> So instead of sending multiple URN like >> URN:alert:source:family >> URN:alert:source:friend >> URN:alert:source:internal >> URN:alert:source:unclassified >> >> device will send URN as >> >> URN:alert:source:family,friend,internal,unclassified > > In the above you have not included the header. It would really be: > > Alert-Info: URN:alert:source:family > Alert-Info: URN:alert:source:friend > Alert-Info: URN:alert:source:internal > Alert-Info: URN:alert:source:unclassified > > and your preference would seem to be: > > Alert-Info: URN:alert:source:family,friend,internal,unclassified > > But the latter cannot work. The key point is that Alert-Info takes URIs > as arguments (including URNs), which can be separated by commas or as > separate header fields. Because of that, in your latter case, "friend" > is syntactically incorrect because it is not a URI. > > Aside from that I don't understand why you think what you propose is > easier to use or implement. (I agree that is uses fewer bytes, but that > doesn't make it easier.) > > Thanks, > Paul > > >> Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement. >> >> >> I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them. >> >> And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be). >> >> Thanks& Best Regards >> >> >> JEWEL >> Firoze M Zahidur Rahman >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From jewel@ssd-tech.com Fri Jan 20 20:44:47 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A127F21F8557 for ; Fri, 20 Jan 2012 20:44:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mCbpSL1WCWl7 for ; Fri, 20 Jan 2012 20:44:46 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id DE32121F8552 for ; Fri, 20 Jan 2012 20:44:28 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Sat, 21 Jan 2012 10:40:00 +0600 From: "Firoze M. Zahidur Rahman" To: "salud@ietf.org" Date: Sat, 21 Jan 2012 10:39:58 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXrBc+AW1uErBYR/u6KSMh12/tTQAR8g+Q Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> In-Reply-To: <4F19C562.4050006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18656.005 x-tm-as-result: No--75.359400-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 04:44:47 -0000 Hi=20 It will be very nice if you please can refer the discussion date or thread = of the multiple value discussion. I am not able to find it. However, there are couple of things I wanted to highlight in my first mail. 1. URN string format - bundling multiple values (on which I may be wrong as= this is already discussed and decided - I will go through the earlier mail= s from the archive to clarify my understanding) 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 3. Can we have another category to define UA/device reaction/behavior? Particularly for 2 and 3 the reason I am proposing this is 1. Alert-Info can be present in INVITE and if it is present in Invite then = it will be nice to have a mechanism to guide/standardize the handling proce= ss/logic of the Alert-Info for the devices receiving Alert-Info 2. As we have multiple URN and URNs defining the service, source, priority = etc. I assume the priority is the priority for the session/call. If we impl= ement priority as a number then sorting on the priority number for currentl= y ongoing sessions can be done at the device side - and logics can be imple= mented like force disconnect for higher priority calls, do not notify for l= ower priority calls, notify back the user for certain priority calls, diver= t if priority is less than some specific values. And we can leave it up to = the implementation. With these features I think we will be able to standardize the implementati= on of Reverse Ring Back Tone, Custom Ringtone/Notification decided by calle= r, Call Back Notification Services (where caller will be notified whenever = the line is free), Handling of Promotional/Low Priority Calls (Voice or Mes= sage/SMS Broadcasts) etc. Thanks & Regards JEWEL Firoze M Zahidur Rahman F=A0=A0+88 017 13014806, +6 013 6349764 3=A0+88 02 9882314,=A0+6 03 90581043 -----Original Message----- From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Saturday, January 21, 2012 1:50 AM To: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: > Hi > > Its not really usage of lesser no of bytes, the overall idea was to accom= modate multiple values in the same URN. As this extension enables UA or dev= ices to choose/implement features as per internal implementation logic - my= idea was to make the structure as - all values in single line. So that whi= le implementing device will not have to think about same category multiple = times. Even if same category multiple times is allowed - it will completely= refresh/overrule earlier appearance. > > And the order of appearance wise priority (I think corrent approach is al= so same, priority is decided by order of appearance of URN in header field)= also handles the priority decision making process unchanged. > > Instead of comma(,) we can use dot(.) or slash(/) separated values may be= . Or we can find some other way to make it URI compatible. But that can be = though/found out if everyone thinks that bundling all values of a category = in single URN makes sense. If you look through the salud mail archives you will see that combining=20 things into a single URN was proposed and discussed, but we settled on=20 what we have now. Thanks, Paul > Thanks& Best Regards > > Jewel > > ________________________________________ > From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul K= yzivat [pkyzivat@alum.mit.edu] > Sent: Friday, January 20, 2012 11:43 PM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Greetings! >> >> I am very new to this area. Advance apologies if my ideas sounds complet= ely misaligned. >> >> I found current way of using multiple Alert-Info URNs and Priority Rules= a bit difficult to use and implement. I can see that we have 6 fixed alert= -categories and the Alert URN Format is >> >> "URN:alert:" alert-identifier >> >> And format of alert-identifier is >> >> alert-category ":" alert-indication >> >> and alert-indication is a single value. >> >> If we can allow to include multiple value in alert-indication separated = by comma (,) and the order of appearance will decide the order of priority = for the alert-indication value then I think it will be easy to implement fr= om the device side. >> >> So instead of sending multiple URN like >> URN:alert:source:family >> URN:alert:source:friend >> URN:alert:source:internal >> URN:alert:source:unclassified >> >> device will send URN as >> >> URN:alert:source:family,friend,internal,unclassified > > In the above you have not included the header. It would really be: > > Alert-Info: URN:alert:source:family > Alert-Info: URN:alert:source:friend > Alert-Info: URN:alert:source:internal > Alert-Info: URN:alert:source:unclassified > > and your preference would seem to be: > > Alert-Info: URN:alert:source:family,friend,internal,unclassified > > But the latter cannot work. The key point is that Alert-Info takes URIs > as arguments (including URNs), which can be separated by commas or as > separate header fields. Because of that, in your latter case, "friend" > is syntactically incorrect because it is not a URI. > > Aside from that I don't understand why you think what you propose is > easier to use or implement. (I agree that is uses fewer bytes, but that > doesn't make it easier.) > > Thanks, > Paul > > >> Besides, if we disallow or ignore (or latest appearance overrides earlie= r) multiple appearance of alert-category then it will be more easier to imp= lement. >> >> >> I have another suggestion regarding the values of alert-category priorit= y. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or= 0-9 to make it simple, then I think devices will have the provision to pri= oritize 2 calls/sessions (in case of call waiting or line busy) easily and = devices will be able to implement specific logics for them. >> >> And if we can introduce another alert-category to guide the call/session= handle behavoir according to service or priority for the devices e.g. forc= e connect on busy, notify back when free, delivery report (read, delivered,= not delivered etc) (as we are handing SIP sessions - the URNs should cover= IM and short messages as well may be). >> >> Thanks& Best Regards >> >> >> JEWEL >> Firoze M Zahidur Rahman >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud From pkyzivat@alum.mit.edu Fri Jan 20 20:53:56 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C75811E8080 for ; Fri, 20 Jan 2012 20:53:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.624 X-Spam-Level: X-Spam-Status: No, score=-2.624 tagged_above=-999 required=5 tests=[AWL=-0.025, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pltTFnjahUvi for ; Fri, 20 Jan 2012 20:53:55 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [76.96.59.227]) by ietfa.amsl.com (Postfix) with ESMTP id F1D5011E8074 for ; Fri, 20 Jan 2012 20:53:54 -0800 (PST) Received: from omta22.westchester.pa.mail.comcast.net ([76.96.62.73]) by qmta12.westchester.pa.mail.comcast.net with comcast id Q4mT1i0031ap0As5C4tvE0; Sat, 21 Jan 2012 04:53:55 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta22.westchester.pa.mail.comcast.net with comcast id Q4tv1i00507duvL3i4tvfN; Sat, 21 Jan 2012 04:53:55 +0000 Message-ID: <4F1A44E0.3070708@alum.mit.edu> Date: Fri, 20 Jan 2012 23:53:52 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: salud@ietf.org References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 04:53:56 -0000 On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: > Hi > > It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it. I don't know offhand. The proposal was made by Dale Worley, so look from mails from him. It was several months ago, perhaps more than a year. > However, there are couple of things I wanted to highlight in my first mail. > > 1. URN string format - bundling multiple values (on which I may be wrong as this is already discussed and decided - I will go through the earlier mails from the archive to clarify my understanding) Already decided - above discussion. > 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 Keep in mind that the point of this is to guide the rendering of alerts to a user. I find it hard to believe that the user will distinguish 10 or 100 different alert variations based on priority. There is already a sip Priority header to indicate the priority of the message itself. > 3. Can we have another category to define UA/device reaction/behavior? I don't understand what you mean. > Particularly for 2 and 3 the reason I am proposing this is > > 1. Alert-Info can be present in INVITE and if it is present in Invite then it will be nice to have a mechanism to guide/standardize the handling process/logic of the Alert-Info for the devices receiving Alert-Info That is already provided. > 2. As we have multiple URN and URNs defining the service, source, priority etc. I assume the priority is the priority for the session/call. If we implement priority as a number then sorting on the priority number for currently ongoing sessions can be done at the device side - and logics can be implemented like force disconnect for higher priority calls, do not notify for lower priority calls, notify back the user for certain priority calls, divert if priority is less than some specific values. And we can leave it up to the implementation. See above. Thanks, Paul > With these features I think we will be able to standardize the implementation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by caller, Call Back Notification Services (where caller will be notified whenever the line is free), Handling of Promotional/Low Priority Calls (Voice or Message/SMS Broadcasts) etc. > > Thanks& Regards > > JEWEL > Firoze M Zahidur Rahman > F +88 017 13014806, +6 013 6349764 > 3 +88 02 9882314, +6 03 90581043 > > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Saturday, January 21, 2012 1:50 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules > > On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. As this extension enables UA or devices to choose/implement features as per internal implementation logic - my idea was to make the structure as - all values in single line. So that while implementing device will not have to think about same category multiple times. Even if same category multiple times is allowed - it will completely refresh/overrule earlier appearance. >> >> And the order of appearance wise priority (I think corrent approach is also same, priority is decided by order of appearance of URN in header field) also handles the priority decision making process unchanged. >> >> Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling all values of a category in single URN makes sense. > > If you look through the salud mail archives you will see that combining > things into a single URN was proposed and discussed, but we settled on > what we have now. > > Thanks, > Paul > >> Thanks& Best Regards >> >> Jewel >> >> ________________________________________ >> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Friday, January 20, 2012 11:43 PM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules >> >> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Greetings! >>> >>> I am very new to this area. Advance apologies if my ideas sounds completely misaligned. >>> >>> I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is >>> >>> "URN:alert:" alert-identifier >>> >>> And format of alert-identifier is >>> >>> alert-category ":" alert-indication >>> >>> and alert-indication is a single value. >>> >>> If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side. >>> >>> So instead of sending multiple URN like >>> URN:alert:source:family >>> URN:alert:source:friend >>> URN:alert:source:internal >>> URN:alert:source:unclassified >>> >>> device will send URN as >>> >>> URN:alert:source:family,friend,internal,unclassified >> >> In the above you have not included the header. It would really be: >> >> Alert-Info: URN:alert:source:family >> Alert-Info: URN:alert:source:friend >> Alert-Info: URN:alert:source:internal >> Alert-Info: URN:alert:source:unclassified >> >> and your preference would seem to be: >> >> Alert-Info: URN:alert:source:family,friend,internal,unclassified >> >> But the latter cannot work. The key point is that Alert-Info takes URIs >> as arguments (including URNs), which can be separated by commas or as >> separate header fields. Because of that, in your latter case, "friend" >> is syntactically incorrect because it is not a URI. >> >> Aside from that I don't understand why you think what you propose is >> easier to use or implement. (I agree that is uses fewer bytes, but that >> doesn't make it easier.) >> >> Thanks, >> Paul >> >> >>> Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement. >>> >>> >>> I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them. >>> >>> And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be). >>> >>> Thanks& Best Regards >>> >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From jewel@ssd-tech.com Sat Jan 21 01:29:56 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2B0221F85FD for ; Sat, 21 Jan 2012 01:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1qhRkQjvIJ7Q for ; Sat, 21 Jan 2012 01:29:51 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id 8EDD021F85FC for ; Sat, 21 Jan 2012 01:29:50 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Sat, 21 Jan 2012 15:25:24 +0600 From: "Firoze M. Zahidur Rahman" To: "salud@ietf.org" Date: Sat, 21 Jan 2012 15:25:21 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczX+BP5fQdikcK1TXKZP8jZcAE8gAAIrfzw Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> In-Reply-To: <4F1A44E0.3070708@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18658.004 x-tm-as-result: No--79.825000-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 21 Jan 2012 09:29:56 -0000 Hi SIP Call priority will not help this case. User will not have to identify d= ifferent alerts - the UA will have to identify different alerts. And I am t= hinking about alert notifications like 1. Call Waiting Notifications 2. Disconnect the ongoing call and establish the higher priority call 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messenger) 4. For SMS/IMs - Message Not Delivered=20 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) 6. For video calls - User has muted his/her mic 7. Presence Services - User Status Changed=20 8. Etc. And all these different types of notifications should have different priori= ty and UA/Device should have its own implementation of handling these alert= notifications. And I think all these are targeted for different types of S= IP Sessions/Applications. I am not sure if the RFC scope is for Voice Calls= only or not. >> 3. Can we have another category to define UA/device reaction/behavior? > I don't understand what you mean. When we use IM Clients - and someone knocks you - IMs can directly pop up a= n window with message. Or IM can display a notification that "Mr. X is invi= ting you for a conversation". So for the same request - the handling of the= UA is different. In many case this is set from the UA itself. Or, if we allow the behaviors like display Customized Picture decided by Ca= ller, Or Play Ringtone (decided by caller) this type of features then I thi= nk this additional category will help. I am not sure if I could make myself clear or I am completely sounding irre= levant. If I am please do point that out.=20 Thanks & Regards Jewel -----Original Message----- From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Saturday, January 21, 2012 10:54 AM To: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: > Hi > > It will be very nice if you please can refer the discussion date or threa= d of the multiple value discussion. I am not able to find it. I don't know offhand. The proposal was made by Dale Worley, so look from=20 mails from him. It was several months ago, perhaps more than a year. > However, there are couple of things I wanted to highlight in my first mai= l. > > 1. URN string format - bundling multiple values (on which I may be wrong = as this is already discussed and decided - I will go through the earlier ma= ils from the archive to clarify my understanding) Already decided - above discussion. > 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 Keep in mind that the point of this is to guide the rendering of alerts=20 to a user. I find it hard to believe that the user will distinguish 10=20 or 100 different alert variations based on priority. There is already a sip Priority header to indicate the priority of the=20 message itself. > 3. Can we have another category to define UA/device reaction/behavior? I don't understand what you mean. > Particularly for 2 and 3 the reason I am proposing this is > > 1. Alert-Info can be present in INVITE and if it is present in Invite the= n it will be nice to have a mechanism to guide/standardize the handling pro= cess/logic of the Alert-Info for the devices receiving Alert-Info That is already provided. > 2. As we have multiple URN and URNs defining the service, source, priorit= y etc. I assume the priority is the priority for the session/call. If we im= plement priority as a number then sorting on the priority number for curren= tly ongoing sessions can be done at the device side - and logics can be imp= lemented like force disconnect for higher priority calls, do not notify for= lower priority calls, notify back the user for certain priority calls, div= ert if priority is less than some specific values. And we can leave it up t= o the implementation. See above. Thanks, Paul > With these features I think we will be able to standardize the implementa= tion of Reverse Ring Back Tone, Custom Ringtone/Notification decided by cal= ler, Call Back Notification Services (where caller will be notified wheneve= r the line is free), Handling of Promotional/Low Priority Calls (Voice or M= essage/SMS Broadcasts) etc. > > Thanks& Regards > > JEWEL > Firoze M Zahidur Rahman > F +88 017 13014806, +6 013 6349764 > 3 +88 02 9882314, +6 03 90581043 > > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Saturday, January 21, 2012 1:50 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Its not really usage of lesser no of bytes, the overall idea was to acco= mmodate multiple values in the same URN. As this extension enables UA or de= vices to choose/implement features as per internal implementation logic - m= y idea was to make the structure as - all values in single line. So that wh= ile implementing device will not have to think about same category multiple= times. Even if same category multiple times is allowed - it will completel= y refresh/overrule earlier appearance. >> >> And the order of appearance wise priority (I think corrent approach is a= lso same, priority is decided by order of appearance of URN in header field= ) also handles the priority decision making process unchanged. >> >> Instead of comma(,) we can use dot(.) or slash(/) separated values may b= e. Or we can find some other way to make it URI compatible. But that can be= though/found out if everyone thinks that bundling all values of a category= in single URN makes sense. > > If you look through the salud mail archives you will see that combining > things into a single URN was proposed and discussed, but we settled on > what we have now. > > Thanks, > Paul > >> Thanks& Best Regards >> >> Jewel >> >> ________________________________________ >> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul = Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Friday, January 20, 2012 11:43 PM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Greetings! >>> >>> I am very new to this area. Advance apologies if my ideas sounds comple= tely misaligned. >>> >>> I found current way of using multiple Alert-Info URNs and Priority Rule= s a bit difficult to use and implement. I can see that we have 6 fixed aler= t-categories and the Alert URN Format is >>> >>> "URN:alert:" alert-identifier >>> >>> And format of alert-identifier is >>> >>> alert-category ":" alert-indication >>> >>> and alert-indication is a single value. >>> >>> If we can allow to include multiple value in alert-indication separated= by comma (,) and the order of appearance will decide the order of priority= for the alert-indication value then I think it will be easy to implement f= rom the device side. >>> >>> So instead of sending multiple URN like >>> URN:alert:source:family >>> URN:alert:source:friend >>> URN:alert:source:internal >>> URN:alert:source:unclassified >>> >>> device will send URN as >>> >>> URN:alert:source:family,friend,internal,unclassified >> >> In the above you have not included the header. It would really be: >> >> Alert-Info: URN:alert:source:family >> Alert-Info: URN:alert:source:friend >> Alert-Info: URN:alert:source:internal >> Alert-Info: URN:alert:source:unclassified >> >> and your preference would seem to be: >> >> Alert-Info: URN:alert:source:family,friend,internal,unclassified >> >> But the latter cannot work. The key point is that Alert-Info takes URIs >> as arguments (including URNs), which can be separated by commas or as >> separate header fields. Because of that, in your latter case, "friend" >> is syntactically incorrect because it is not a URI. >> >> Aside from that I don't understand why you think what you propose is >> easier to use or implement. (I agree that is uses fewer bytes, but that >> doesn't make it easier.) >> >> Thanks, >> Paul >> >> >>> Besides, if we disallow or ignore (or latest appearance overrides earli= er) multiple appearance of alert-category then it will be more easier to im= plement. >>> >>> >>> I have another suggestion regarding the values of alert-category priori= ty. If we make it a number like 0, 1, 10 anything may be between 00 to 99 o= r 0-9 to make it simple, then I think devices will have the provision to pr= ioritize 2 calls/sessions (in case of call waiting or line busy) easily and= devices will be able to implement specific logics for them. >>> >>> And if we can introduce another alert-category to guide the call/sessio= n handle behavoir according to service or priority for the devices e.g. for= ce connect on busy, notify back when free, delivery report (read, delivered= , not delivered etc) (as we are handing SIP sessions - the URNs should cove= r IM and short messages as well may be). >>> >>> Thanks& Best Regards >>> >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Mon Jan 23 06:54:02 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C35FD21F8746 for ; Mon, 23 Jan 2012 06:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E4SUOv9hURnQ for ; Mon, 23 Jan 2012 06:54:01 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id 3474821F8749 for ; Mon, 23 Jan 2012 06:53:55 -0800 (PST) Received: by wgbed3 with SMTP id ed3so2204740wgb.13 for ; Mon, 23 Jan 2012 06:53:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=lQGonCPL/ScOHEneh21Xc8DHkRC+1X8QipII6nu9DpM=; b=gEgStq7K0Z7y36amcwb/KIFix7C+BZR8LOI/VO81ujiDmISqsWq955aQMT+z0TZe0T WYDQDY0j/l+5TlmP6GcRIlNp6wJ3733wzwDHhtVpSsBRXzeeSoIYShC9E88dAW7EMyYS wa9o/Zv8u/vmisgXuvAvt6wSUtA4yE/8zZqCk= MIME-Version: 1.0 Received: by 10.180.19.138 with SMTP id f10mr17637196wie.3.1327330434908; Mon, 23 Jan 2012 06:53:54 -0800 (PST) Received: by 10.227.23.197 with HTTP; Mon, 23 Jan 2012 06:53:54 -0800 (PST) In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> Date: Mon, 23 Jan 2012 15:53:54 +0100 Message-ID: From: Laura Liess To: "Firoze M. Zahidur Rahman" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 14:54:02 -0000 2012/1/21 Firoze M. Zahidur Rahman : > Hi > > It will be very nice if you please can refer the discussion date or threa= d of the multiple value discussion. I am not able to find it. As Paul already pointed out we already had this discussion, not only once. The first discussion was in BLISS, back in 2009. (This draft was first submitted in BLISS, then moved to DISPATCH, then we got our own miniWG SALUD. ) In the first versions of the draft in BLISS followed a similar direction as you propose. See Section 7.3 in http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt . In http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html Adam Roach pointed out that we have to register all combinations with IANA an "If someone adds another semantic dimension, the size of the registry continues to grow exponentially". The second discussion on this issue was in SALUD, see the messages around http://www.ietf.org/mail-archive/web/salud/current/msg00038.html . We call this issue "multiple URN vs. single URN". Again, we came to the conclusion that also "single URN" is much more simple to implement for the receiving UA, we run with it into the problem identified by Adam, the IANA registry grow exponentially when new values are registred. With "multiple URNs", we don't have this problem. A receiving UA has to be able to deal with combinations of Alert-Info URNs anyway because more than one SIP network elements in the message path (the sending UA, proxies, B2BUAs) may insert Alert-Info URNs. Kind regards Laura > > However, there are couple of things I wanted to highlight in my first mai= l. > > 1. URN string format - bundling multiple values (on which I may be wrong = as this is already discussed and decided - I will go through the earlier ma= ils from the archive to clarify my understanding) > > 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 > > 3. Can we have another category to define UA/device reaction/behavior? > > Particularly for 2 and 3 the reason I am proposing this is > > 1. Alert-Info can be present in INVITE and if it is present in Invite the= n it will be nice to have a mechanism to guide/standardize the handling pro= cess/logic of the Alert-Info for the devices receiving Alert-Info > > 2. As we have multiple URN and URNs defining the service, source, priorit= y etc. I assume the priority is the priority for the session/call. If we im= plement priority as a number then sorting on the priority number for curren= tly ongoing sessions can be done at the device side - and logics can be imp= lemented like force disconnect for higher priority calls, do not notify for= lower priority calls, notify back the user for certain priority calls, div= ert if priority is less than some specific values. And we can leave it up t= o the implementation. > > With these features I think we will be able to standardize the implementa= tion of Reverse Ring Back Tone, Custom Ringtone/Notification decided by cal= ler, Call Back Notification Services (where caller will be notified wheneve= r the line is free), Handling of Promotional/Low Priority Calls (Voice or M= essage/SMS Broadcasts) etc. > > Thanks & Regards > > JEWEL > Firoze M Zahidur Rahman > F=A0=A0+88 017 13014806, +6 013 6349764 > 3=A0+88 02 9882314,=A0+6 03 90581043 > > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Saturday, January 21, 2012 1:50 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Its not really usage of lesser no of bytes, the overall idea was to acco= mmodate multiple values in the same URN. As this extension enables UA or de= vices to choose/implement features as per internal implementation logic - m= y idea was to make the structure as - all values in single line. So that wh= ile implementing device will not have to think about same category multiple= times. Even if same category multiple times is allowed - it will completel= y refresh/overrule earlier appearance. >> >> And the order of appearance wise priority (I think corrent approach is a= lso same, priority is decided by order of appearance of URN in header field= ) also handles the priority decision making process unchanged. >> >> Instead of comma(,) we can use dot(.) or slash(/) separated values may b= e. Or we can find some other way to make it URI compatible. But that can be= though/found out if everyone thinks that bundling all values of a category= in single URN makes sense. > > If you look through the salud mail archives you will see that combining > things into a single URN was proposed and discussed, but we settled on > what we have now. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Thanks& =A0Best Regards >> >> Jewel >> >> ________________________________________ >> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul = Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Friday, January 20, 2012 11:43 PM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Greetings! >>> >>> I am very new to this area. Advance apologies if my ideas sounds comple= tely misaligned. >>> >>> I found current way of using multiple Alert-Info URNs and Priority Rule= s a bit difficult to use and implement. I can see that we have 6 fixed aler= t-categories and the Alert URN Format is >>> >>> "URN:alert:" alert-identifier >>> >>> And format of alert-identifier is >>> >>> alert-category ":" alert-indication >>> >>> and alert-indication is a single value. >>> >>> If we can allow to include multiple value in alert-indication separated= by comma (,) and the order of appearance will decide the order of priority= for the alert-indication value then I think it will be easy to implement f= rom the device side. >>> >>> So instead of sending multiple URN like >>> URN:alert:source:family >>> URN:alert:source:friend >>> URN:alert:source:internal >>> URN:alert:source:unclassified >>> >>> device will send URN as >>> >>> URN:alert:source:family,friend,internal,unclassified >> >> In the above you have not included the header. It would really be: >> >> Alert-Info: URN:alert:source:family >> Alert-Info: URN:alert:source:friend >> Alert-Info: URN:alert:source:internal >> Alert-Info: URN:alert:source:unclassified >> >> and your preference would seem to be: >> >> Alert-Info: URN:alert:source:family,friend,internal,unclassified >> >> But the latter cannot work. The key point is that Alert-Info takes URIs >> as arguments (including URNs), which can be separated by commas or as >> separate header fields. Because of that, in your latter case, "friend" >> is syntactically incorrect because it is not a URI. >> >> Aside from that I don't understand why you think what you propose is >> easier to use or implement. (I agree that is uses fewer bytes, but that >> doesn't make it easier.) >> >> =A0 =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0 =A0Paul >> >> >>> Besides, if we disallow or ignore (or latest appearance overrides earli= er) multiple appearance of alert-category then it will be more easier to im= plement. >>> >>> >>> I have another suggestion regarding the values of alert-category priori= ty. If we make it a number like 0, 1, 10 anything may be between 00 to 99 o= r 0-9 to make it simple, then I think devices will have the provision to pr= ioritize 2 calls/sessions (in case of call waiting or line busy) easily and= devices will be able to implement specific logics for them. >>> >>> And if we can introduce another alert-category to guide the call/sessio= n handle behavoir according to service or priority for the devices e.g. for= ce connect on busy, notify back when free, delivery report (read, delivered= , not delivered etc) (as we are handing SIP sessions - the URNs should cove= r IM and short messages as well may be). >>> >>> Thanks& =A0 Best Regards >>> >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From jewel@ssd-tech.com Mon Jan 23 07:10:03 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E93A21F86CA for ; Mon, 23 Jan 2012 07:10:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dAUicfItQZXd for ; Mon, 23 Jan 2012 07:10:01 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id AA6CC21F86C7 for ; Mon, 23 Jan 2012 07:09:59 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Mon, 23 Jan 2012 21:05:27 +0600 From: "Firoze M. Zahidur Rahman" To: Laura Liess Date: Mon, 23 Jan 2012 21:05:25 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczZ3jaUCRAOmuhXQfWDgx8lmbGhMwAAJIOA Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18662.004 x-tm-as-result: No--74.398200-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:10:03 -0000 Hi Thanks a lot for the clarification. I think my proposal and the your discus= sion point is not same. My proposal was a URNs like Alert-Info: Alert-Info: Alert-Info: =20 etc Or may be Alert-Info: , , Or something similar. This will help the UA to decide e.g. regarding "servi= ce" -priority is normal then call-waiting and finally forward. So UA will t= ry to alert for normal call, if not possible (may be busy in another call) = notify for call-waiting or finally notify for forwarding. And the priority = for the selection can be determined by the order of appearance. And I am not sure if this will increase no of IANA registration. The regist= ration can follow service RFCXXXX source RFCYYYY etc. Best Regards Jewel -----Original Message----- From: Laura Liess [mailto:laura.liess.dt@googlemail.com]=20 Sent: Monday, January 23, 2012 8:54 PM To: Firoze M. Zahidur Rahman Cc: salud@ietf.org; Paul Kyzivat; Roland Jesske Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules 2012/1/21 Firoze M. Zahidur Rahman : > Hi > > It will be very nice if you please can refer the discussion date or threa= d of the multiple value discussion. I am not able to find it. As Paul already pointed out we already had this discussion, not only once. The first discussion was in BLISS, back in 2009. (This draft was first submitted in BLISS, then moved to DISPATCH, then we got our own miniWG SALUD. ) In the first versions of the draft in BLISS followed a similar direction as you propose. See Section 7.3 in http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt . In http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html Adam Roach pointed out that we have to register all combinations with IANA an "If someone adds another semantic dimension, the size of the registry continues to grow exponentially". The second discussion on this issue was in SALUD, see the messages around http://www.ietf.org/mail-archive/web/salud/current/msg00038.html . We call this issue "multiple URN vs. single URN". Again, we came to the conclusion that also "single URN" is much more simple to implement for the receiving UA, we run with it into the problem identified by Adam, the IANA registry grow exponentially when new values are registred. With "multiple URNs", we don't have this problem. A receiving UA has to be able to deal with combinations of Alert-Info URNs anyway because more than one SIP network elements in the message path (the sending UA, proxies, B2BUAs) may insert Alert-Info URNs. Kind regards Laura > > However, there are couple of things I wanted to highlight in my first mai= l. > > 1. URN string format - bundling multiple values (on which I may be wrong = as this is already discussed and decided - I will go through the earlier ma= ils from the archive to clarify my understanding) > > 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 > > 3. Can we have another category to define UA/device reaction/behavior? > > Particularly for 2 and 3 the reason I am proposing this is > > 1. Alert-Info can be present in INVITE and if it is present in Invite the= n it will be nice to have a mechanism to guide/standardize the handling pro= cess/logic of the Alert-Info for the devices receiving Alert-Info > > 2. As we have multiple URN and URNs defining the service, source, priorit= y etc. I assume the priority is the priority for the session/call. If we im= plement priority as a number then sorting on the priority number for curren= tly ongoing sessions can be done at the device side - and logics can be imp= lemented like force disconnect for higher priority calls, do not notify for= lower priority calls, notify back the user for certain priority calls, div= ert if priority is less than some specific values. And we can leave it up t= o the implementation. > > With these features I think we will be able to standardize the implementa= tion of Reverse Ring Back Tone, Custom Ringtone/Notification decided by cal= ler, Call Back Notification Services (where caller will be notified wheneve= r the line is free), Handling of Promotional/Low Priority Calls (Voice or M= essage/SMS Broadcasts) etc. > > Thanks & Regards > > JEWEL > Firoze M Zahidur Rahman > F=A0=A0+88 017 13014806, +6 013 6349764 > 3=A0+88 02 9882314,=A0+6 03 90581043 > > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Saturday, January 21, 2012 1:50 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> Its not really usage of lesser no of bytes, the overall idea was to acco= mmodate multiple values in the same URN. As this extension enables UA or de= vices to choose/implement features as per internal implementation logic - m= y idea was to make the structure as - all values in single line. So that wh= ile implementing device will not have to think about same category multiple= times. Even if same category multiple times is allowed - it will completel= y refresh/overrule earlier appearance. >> >> And the order of appearance wise priority (I think corrent approach is a= lso same, priority is decided by order of appearance of URN in header field= ) also handles the priority decision making process unchanged. >> >> Instead of comma(,) we can use dot(.) or slash(/) separated values may b= e. Or we can find some other way to make it URI compatible. But that can be= though/found out if everyone thinks that bundling all values of a category= in single URN makes sense. > > If you look through the salud mail archives you will see that combining > things into a single URN was proposed and discussed, but we settled on > what we have now. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Thanks& =A0Best Regards >> >> Jewel >> >> ________________________________________ >> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul = Kyzivat [pkyzivat@alum.mit.edu] >> Sent: Friday, January 20, 2012 11:43 PM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Greetings! >>> >>> I am very new to this area. Advance apologies if my ideas sounds comple= tely misaligned. >>> >>> I found current way of using multiple Alert-Info URNs and Priority Rule= s a bit difficult to use and implement. I can see that we have 6 fixed aler= t-categories and the Alert URN Format is >>> >>> "URN:alert:" alert-identifier >>> >>> And format of alert-identifier is >>> >>> alert-category ":" alert-indication >>> >>> and alert-indication is a single value. >>> >>> If we can allow to include multiple value in alert-indication separated= by comma (,) and the order of appearance will decide the order of priority= for the alert-indication value then I think it will be easy to implement f= rom the device side. >>> >>> So instead of sending multiple URN like >>> URN:alert:source:family >>> URN:alert:source:friend >>> URN:alert:source:internal >>> URN:alert:source:unclassified >>> >>> device will send URN as >>> >>> URN:alert:source:family,friend,internal,unclassified >> >> In the above you have not included the header. It would really be: >> >> Alert-Info: URN:alert:source:family >> Alert-Info: URN:alert:source:friend >> Alert-Info: URN:alert:source:internal >> Alert-Info: URN:alert:source:unclassified >> >> and your preference would seem to be: >> >> Alert-Info: URN:alert:source:family,friend,internal,unclassified >> >> But the latter cannot work. The key point is that Alert-Info takes URIs >> as arguments (including URNs), which can be separated by commas or as >> separate header fields. Because of that, in your latter case, "friend" >> is syntactically incorrect because it is not a URI. >> >> Aside from that I don't understand why you think what you propose is >> easier to use or implement. (I agree that is uses fewer bytes, but that >> doesn't make it easier.) >> >> =A0 =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0 =A0Paul >> >> >>> Besides, if we disallow or ignore (or latest appearance overrides earli= er) multiple appearance of alert-category then it will be more easier to im= plement. >>> >>> >>> I have another suggestion regarding the values of alert-category priori= ty. If we make it a number like 0, 1, 10 anything may be between 00 to 99 o= r 0-9 to make it simple, then I think devices will have the provision to pr= ioritize 2 calls/sessions (in case of call waiting or line busy) easily and= devices will be able to implement specific logics for them. >>> >>> And if we can introduce another alert-category to guide the call/sessio= n handle behavoir according to service or priority for the devices e.g. for= ce connect on busy, notify back when free, delivery report (read, delivered= , not delivered etc) (as we are handing SIP sessions - the URNs should cove= r IM and short messages as well may be). >>> >>> Thanks& =A0 Best Regards >>> >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Mon Jan 23 07:19:01 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DCB221F8714 for ; Mon, 23 Jan 2012 07:19:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u+kK5a66VN+V for ; Mon, 23 Jan 2012 07:19:00 -0800 (PST) Received: from mail-we0-f172.google.com (mail-we0-f172.google.com [74.125.82.172]) by ietfa.amsl.com (Postfix) with ESMTP id E816821F8709 for ; Mon, 23 Jan 2012 07:18:59 -0800 (PST) Received: by werp11 with SMTP id p11so2696637wer.31 for ; Mon, 23 Jan 2012 07:18:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=oHC7lhI450KKK+XrvDu2iOvAsr7pF2cUff2Rwz+JNbc=; b=rN3lD6MNMpPNEFCsRmBPXiLPn8PxCWhFWVCmSL99oauZI6PXIlfU31JN+l8oIbFfru AO/3Yo1dMDTfXrS53AxLv5fXemdX0yAj+4YBV1N1GrHJRQZitZYgYwCfxXQur9kU5mnS WbkYquBHnKYUYRj4dJh+5Khhn6iDxh27+CZy0= MIME-Version: 1.0 Received: by 10.216.136.202 with SMTP id w52mr3735259wei.57.1327331939134; Mon, 23 Jan 2012 07:18:59 -0800 (PST) Received: by 10.227.23.197 with HTTP; Mon, 23 Jan 2012 07:18:59 -0800 (PST) In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> Date: Mon, 23 Jan 2012 16:18:59 +0100 Message-ID: From: Laura Liess To: "Firoze M. Zahidur Rahman" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:19:01 -0000 Hi, During the discussions on this draft, not only in SALUD but also in BLISS and DISPATCH, people identified additional possible use cases which we did not include in the draft. If we try to include every use case which comes up, we will never get the draft ready (which is now already 3 years old, first version was back in Feb. 2009). What we do whith this draft is to provide the basic mechanism which is extenssible in any way, see requirement 5, so that people and organisations can define extenssions, this means, new categories or values. We should finish the basic draft as soon as possible. For your use cases, which seem to me to be quite interesting, I propose you write a new draft which defines and registers with IANA a new category e. g. "priority_for_services" or something like that. Kind regards Laura 2012/1/21 Firoze M. Zahidur Rahman : > Hi > > SIP Call priority will not help this case. User will not have to identify= different alerts - the UA will have to identify different alerts. And I am= thinking about alert notifications like > > 1. Call Waiting Notifications > 2. Disconnect the ongoing call and establish the higher priority call > 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messenge= r) > 4. For SMS/IMs - Message Not Delivered > 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) > 6. For video calls - User has muted his/her mic > 7. Presence Services - User Status Changed > 8. Etc. > > And all these different types of notifications should have different prio= rity and UA/Device should have its own implementation of handling these ale= rt notifications. And I think all these are targeted for different types of= SIP Sessions/Applications. I am not sure if the RFC scope is for Voice Cal= ls only or not. > >>> 3. Can we have another category to define UA/device reaction/behavior? >> I don't understand what you mean. > > When we use IM Clients - and someone knocks you - IMs can directly pop up= an window with message. Or IM can display a notification that "Mr. X is in= viting you for a conversation". So for the same request - the handling of t= he UA is different. In many case this is set from the UA itself. > > Or, if we allow the behaviors like display Customized Picture decided by = Caller, Or Play Ringtone (decided by caller) this type of features then I t= hink this additional category will help. > > I am not sure if I could make myself clear or I am completely sounding ir= relevant. If I am please do point that out. > > Thanks & Regards > > Jewel > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Saturday, January 21, 2012 10:54 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> It will be very nice if you please can refer the discussion date or thre= ad of the multiple value discussion. I am not able to find it. > > I don't know offhand. The proposal was made by Dale Worley, so look from > mails from him. It was several months ago, perhaps more than a year. > >> However, there are couple of things I wanted to highlight in my first ma= il. >> >> 1. URN string format - bundling multiple values (on which I may be wrong= as this is already discussed and decided - I will go through the earlier m= ails from the archive to clarify my understanding) > > Already decided - above discussion. > >> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 > > Keep in mind that the point of this is to guide the rendering of alerts > to a user. I find it hard to believe that the user will distinguish 10 > or 100 different alert variations based on priority. > > There is already a sip Priority header to indicate the priority of the > message itself. > >> 3. Can we have another category to define UA/device reaction/behavior? > > I don't understand what you mean. > >> Particularly for 2 and 3 the reason I am proposing this is >> >> 1. Alert-Info can be present in INVITE and if it is present in Invite th= en it will be nice to have a mechanism to guide/standardize the handling pr= ocess/logic of the Alert-Info for the devices receiving Alert-Info > > That is already provided. > >> 2. As we have multiple URN and URNs defining the service, source, priori= ty etc. I assume the priority is the priority for the session/call. If we i= mplement priority as a number then sorting on the priority number for curre= ntly ongoing sessions can be done at the device side - and logics can be im= plemented like force disconnect for higher priority calls, do not notify fo= r lower priority calls, notify back the user for certain priority calls, di= vert if priority is less than some specific values. And we can leave it up = to the implementation. > > See above. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> With these features I think we will be able to standardize the implement= ation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by ca= ller, Call Back Notification Services (where caller will be notified whenev= er the line is free), Handling of Promotional/Low Priority Calls (Voice or = Message/SMS Broadcasts) etc. >> >> Thanks& =A0Regards >> >> JEWEL >> Firoze M Zahidur Rahman >> F =A0+88 017 13014806, +6 013 6349764 >> 3 +88 02 9882314, +6 03 90581043 >> >> >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf O= f Paul Kyzivat >> Sent: Saturday, January 21, 2012 1:50 AM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Its not really usage of lesser no of bytes, the overall idea was to acc= ommodate multiple values in the same URN. As this extension enables UA or d= evices to choose/implement features as per internal implementation logic - = my idea was to make the structure as - all values in single line. So that w= hile implementing device will not have to think about same category multipl= e times. Even if same category multiple times is allowed - it will complete= ly refresh/overrule earlier appearance. >>> >>> And the order of appearance wise priority (I think corrent approach is = also same, priority is decided by order of appearance of URN in header fiel= d) also handles the priority decision making process unchanged. >>> >>> Instead of comma(,) we can use dot(.) or slash(/) separated values may = be. Or we can find some other way to make it URI compatible. But that can b= e though/found out if everyone thinks that bundling all values of a categor= y in single URN makes sense. >> >> If you look through the salud mail archives you will see that combining >> things into a single URN was proposed and discussed, but we settled on >> what we have now. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >>> Thanks& =A0 Best Regards >>> >>> Jewel >>> >>> ________________________________________ >>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: Friday, January 20, 2012 11:43 PM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs = and Priority Rules >>> >>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> Greetings! >>>> >>>> I am very new to this area. Advance apologies if my ideas sounds compl= etely misaligned. >>>> >>>> I found current way of using multiple Alert-Info URNs and Priority Rul= es a bit difficult to use and implement. I can see that we have 6 fixed ale= rt-categories and the Alert URN Format is >>>> >>>> "URN:alert:" alert-identifier >>>> >>>> And format of alert-identifier is >>>> >>>> alert-category ":" alert-indication >>>> >>>> and alert-indication is a single value. >>>> >>>> If we can allow to include multiple value in alert-indication separate= d by comma (,) and the order of appearance will decide the order of priorit= y for the alert-indication value then I think it will be easy to implement = from the device side. >>>> >>>> So instead of sending multiple URN like >>>> URN:alert:source:family >>>> URN:alert:source:friend >>>> URN:alert:source:internal >>>> URN:alert:source:unclassified >>>> >>>> device will send URN as >>>> >>>> URN:alert:source:family,friend,internal,unclassified >>> >>> In the above you have not included the header. It would really be: >>> >>> Alert-Info: URN:alert:source:family >>> Alert-Info: URN:alert:source:friend >>> Alert-Info: URN:alert:source:internal >>> Alert-Info: URN:alert:source:unclassified >>> >>> and your preference would seem to be: >>> >>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>> >>> But the latter cannot work. The key point is that Alert-Info takes URIs >>> as arguments (including URNs), which can be separated by commas or as >>> separate header fields. Because of that, in your latter case, "friend" >>> is syntactically incorrect because it is not a URI. >>> >>> Aside from that I don't understand why you think what you propose is >>> easier to use or implement. (I agree that is uses fewer bytes, but that >>> doesn't make it easier.) >>> >>> =A0 =A0 =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 =A0 =A0 Paul >>> >>> >>>> Besides, if we disallow or ignore (or latest appearance overrides earl= ier) multiple appearance of alert-category then it will be more easier to i= mplement. >>>> >>>> >>>> I have another suggestion regarding the values of alert-category prior= ity. If we make it a number like 0, 1, 10 anything may be between 00 to 99 = or 0-9 to make it simple, then I think devices will have the provision to p= rioritize 2 calls/sessions (in case of call waiting or line busy) easily an= d devices will be able to implement specific logics for them. >>>> >>>> And if we can introduce another alert-category to guide the call/sessi= on handle behavoir according to service or priority for the devices e.g. fo= rce connect on busy, notify back when free, delivery report (read, delivere= d, not delivered etc) (as we are handing SIP sessions - the URNs should cov= er IM and short messages as well may be). >>>> >>>> Thanks& =A0 =A0Best Regards >>>> >>>> >>>> JEWEL >>>> Firoze M Zahidur Rahman >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From jewel@ssd-tech.com Mon Jan 23 07:34:22 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BFFD421F8701 for ; Mon, 23 Jan 2012 07:34:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djxvxya1Q-VG for ; Mon, 23 Jan 2012 07:34:21 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id 7073B21F86AF for ; Mon, 23 Jan 2012 07:34:20 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Mon, 23 Jan 2012 21:29:52 +0600 From: "Firoze M. Zahidur Rahman" To: Laura Liess Date: Mon, 23 Jan 2012 21:29:51 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczZ4bcxjo/pDwtWQpak0il8Csl33QAAGuWQ Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18662.004 x-tm-as-result: No--68.200700-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 15:34:22 -0000 Hi=20 My proposal is for changing the priorities to 0-9 or 00-99 - I mean numbers= instead of high, normal and low. I think that will cover the handling of p= riority. If we don't want the additional category its fine as devices can h= ave their own logic and configuration option to implement that. Another question - are you completely discontinuing URI support of Alert-In= fo with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely de= ployed across many operators may get impacted if we completely remove URI s= upport and will be a significant bottleneck to migrate to SIP. Because in t= his case the URI is going to be inserted by Switch/Proxy mostly. Regards JEWEL Firoze M Zahidur Rahman F=A0=A0+88 017 13014806, +6 013 6349764 3=A0+88 02 9882314,=A0+6 03 90581043 -----Original Message----- From: Laura Liess [mailto:laura.liess.dt@googlemail.com]=20 Sent: Monday, January 23, 2012 9:19 PM To: Firoze M. Zahidur Rahman Cc: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules Hi, During the discussions on this draft, not only in SALUD but also in BLISS and DISPATCH, people identified additional possible use cases which we did not include in the draft. If we try to include every use case which comes up, we will never get the draft ready (which is now already 3 years old, first version was back in Feb. 2009). What we do whith this draft is to provide the basic mechanism which is extenssible in any way, see requirement 5, so that people and organisations can define extenssions, this means, new categories or values. We should finish the basic draft as soon as possible. For your use cases, which seem to me to be quite interesting, I propose you write a new draft which defines and registers with IANA a new category e. g. "priority_for_services" or something like that. Kind regards Laura 2012/1/21 Firoze M. Zahidur Rahman : > Hi > > SIP Call priority will not help this case. User will not have to identify= different alerts - the UA will have to identify different alerts. And I am= thinking about alert notifications like > > 1. Call Waiting Notifications > 2. Disconnect the ongoing call and establish the higher priority call > 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messenge= r) > 4. For SMS/IMs - Message Not Delivered > 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) > 6. For video calls - User has muted his/her mic > 7. Presence Services - User Status Changed > 8. Etc. > > And all these different types of notifications should have different prio= rity and UA/Device should have its own implementation of handling these ale= rt notifications. And I think all these are targeted for different types of= SIP Sessions/Applications. I am not sure if the RFC scope is for Voice Cal= ls only or not. > >>> 3. Can we have another category to define UA/device reaction/behavior? >> I don't understand what you mean. > > When we use IM Clients - and someone knocks you - IMs can directly pop up= an window with message. Or IM can display a notification that "Mr. X is in= viting you for a conversation". So for the same request - the handling of t= he UA is different. In many case this is set from the UA itself. > > Or, if we allow the behaviors like display Customized Picture decided by = Caller, Or Play Ringtone (decided by caller) this type of features then I t= hink this additional category will help. > > I am not sure if I could make myself clear or I am completely sounding ir= relevant. If I am please do point that out. > > Thanks & Regards > > Jewel > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Saturday, January 21, 2012 10:54 AM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> It will be very nice if you please can refer the discussion date or thre= ad of the multiple value discussion. I am not able to find it. > > I don't know offhand. The proposal was made by Dale Worley, so look from > mails from him. It was several months ago, perhaps more than a year. > >> However, there are couple of things I wanted to highlight in my first ma= il. >> >> 1. URN string format - bundling multiple values (on which I may be wrong= as this is already discussed and decided - I will go through the earlier m= ails from the archive to clarify my understanding) > > Already decided - above discussion. > >> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 > > Keep in mind that the point of this is to guide the rendering of alerts > to a user. I find it hard to believe that the user will distinguish 10 > or 100 different alert variations based on priority. > > There is already a sip Priority header to indicate the priority of the > message itself. > >> 3. Can we have another category to define UA/device reaction/behavior? > > I don't understand what you mean. > >> Particularly for 2 and 3 the reason I am proposing this is >> >> 1. Alert-Info can be present in INVITE and if it is present in Invite th= en it will be nice to have a mechanism to guide/standardize the handling pr= ocess/logic of the Alert-Info for the devices receiving Alert-Info > > That is already provided. > >> 2. As we have multiple URN and URNs defining the service, source, priori= ty etc. I assume the priority is the priority for the session/call. If we i= mplement priority as a number then sorting on the priority number for curre= ntly ongoing sessions can be done at the device side - and logics can be im= plemented like force disconnect for higher priority calls, do not notify fo= r lower priority calls, notify back the user for certain priority calls, di= vert if priority is less than some specific values. And we can leave it up = to the implementation. > > See above. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> With these features I think we will be able to standardize the implement= ation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by ca= ller, Call Back Notification Services (where caller will be notified whenev= er the line is free), Handling of Promotional/Low Priority Calls (Voice or = Message/SMS Broadcasts) etc. >> >> Thanks& =A0Regards >> >> JEWEL >> Firoze M Zahidur Rahman >> F =A0+88 017 13014806, +6 013 6349764 >> 3 +88 02 9882314, +6 03 90581043 >> >> >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf O= f Paul Kyzivat >> Sent: Saturday, January 21, 2012 1:50 AM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Its not really usage of lesser no of bytes, the overall idea was to acc= ommodate multiple values in the same URN. As this extension enables UA or d= evices to choose/implement features as per internal implementation logic - = my idea was to make the structure as - all values in single line. So that w= hile implementing device will not have to think about same category multipl= e times. Even if same category multiple times is allowed - it will complete= ly refresh/overrule earlier appearance. >>> >>> And the order of appearance wise priority (I think corrent approach is = also same, priority is decided by order of appearance of URN in header fiel= d) also handles the priority decision making process unchanged. >>> >>> Instead of comma(,) we can use dot(.) or slash(/) separated values may = be. Or we can find some other way to make it URI compatible. But that can b= e though/found out if everyone thinks that bundling all values of a categor= y in single URN makes sense. >> >> If you look through the salud mail archives you will see that combining >> things into a single URN was proposed and discussed, but we settled on >> what we have now. >> >> =A0 =A0 =A0 Thanks, >> =A0 =A0 =A0 Paul >> >>> Thanks& =A0 Best Regards >>> >>> Jewel >>> >>> ________________________________________ >>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: Friday, January 20, 2012 11:43 PM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs = and Priority Rules >>> >>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> Greetings! >>>> >>>> I am very new to this area. Advance apologies if my ideas sounds compl= etely misaligned. >>>> >>>> I found current way of using multiple Alert-Info URNs and Priority Rul= es a bit difficult to use and implement. I can see that we have 6 fixed ale= rt-categories and the Alert URN Format is >>>> >>>> "URN:alert:" alert-identifier >>>> >>>> And format of alert-identifier is >>>> >>>> alert-category ":" alert-indication >>>> >>>> and alert-indication is a single value. >>>> >>>> If we can allow to include multiple value in alert-indication separate= d by comma (,) and the order of appearance will decide the order of priorit= y for the alert-indication value then I think it will be easy to implement = from the device side. >>>> >>>> So instead of sending multiple URN like >>>> URN:alert:source:family >>>> URN:alert:source:friend >>>> URN:alert:source:internal >>>> URN:alert:source:unclassified >>>> >>>> device will send URN as >>>> >>>> URN:alert:source:family,friend,internal,unclassified >>> >>> In the above you have not included the header. It would really be: >>> >>> Alert-Info: URN:alert:source:family >>> Alert-Info: URN:alert:source:friend >>> Alert-Info: URN:alert:source:internal >>> Alert-Info: URN:alert:source:unclassified >>> >>> and your preference would seem to be: >>> >>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>> >>> But the latter cannot work. The key point is that Alert-Info takes URIs >>> as arguments (including URNs), which can be separated by commas or as >>> separate header fields. Because of that, in your latter case, "friend" >>> is syntactically incorrect because it is not a URI. >>> >>> Aside from that I don't understand why you think what you propose is >>> easier to use or implement. (I agree that is uses fewer bytes, but that >>> doesn't make it easier.) >>> >>> =A0 =A0 =A0 =A0 =A0 Thanks, >>> =A0 =A0 =A0 =A0 =A0 Paul >>> >>> >>>> Besides, if we disallow or ignore (or latest appearance overrides earl= ier) multiple appearance of alert-category then it will be more easier to i= mplement. >>>> >>>> >>>> I have another suggestion regarding the values of alert-category prior= ity. If we make it a number like 0, 1, 10 anything may be between 00 to 99 = or 0-9 to make it simple, then I think devices will have the provision to p= rioritize 2 calls/sessions (in case of call waiting or line busy) easily an= d devices will be able to implement specific logics for them. >>>> >>>> And if we can introduce another alert-category to guide the call/sessi= on handle behavoir according to service or priority for the devices e.g. fo= rce connect on busy, notify back when free, delivery report (read, delivere= d, not delivered etc) (as we are handing SIP sessions - the URNs should cov= er IM and short messages as well may be). >>>> >>>> Thanks& =A0 =A0Best Regards >>>> >>>> >>>> JEWEL >>>> Firoze M Zahidur Rahman >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From pkyzivat@alum.mit.edu Mon Jan 23 08:02:31 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D92CB21F86B6 for ; Mon, 23 Jan 2012 08:02:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.623 X-Spam-Level: X-Spam-Status: No, score=-2.623 tagged_above=-999 required=5 tests=[AWL=-0.024, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FObFYHNUpxQD for ; Mon, 23 Jan 2012 08:02:30 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [76.96.59.243]) by ietfa.amsl.com (Postfix) with ESMTP id EB71421F86B8 for ; Mon, 23 Jan 2012 08:02:29 -0800 (PST) Received: from omta10.westchester.pa.mail.comcast.net ([76.96.62.28]) by qmta13.westchester.pa.mail.comcast.net with comcast id R3vu1i00A0cZkys5D42WPj; Mon, 23 Jan 2012 16:02:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.229.5]) by omta10.westchester.pa.mail.comcast.net with comcast id R42U1i00F07duvL3W42VnK; Mon, 23 Jan 2012 16:02:29 +0000 Message-ID: <4F1D849A.4050608@alum.mit.edu> Date: Mon, 23 Jan 2012 11:02:34 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:8.0) Gecko/20111105 Thunderbird/8.0 MIME-Version: 1.0 To: salud@ietf.org References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 16:02:32 -0000 On 1/23/12 10:29 AM, Firoze M. Zahidur Rahman wrote: > Hi > > My proposal is for changing the priorities to 0-9 or 00-99 - I mean numbers instead of high, normal and low. I think that will cover the handling of priority. If we don't want the additional category its fine as devices can have their own logic and configuration option to implement that. If you look at the example algorithm that has been proposed, making this change would complicate things. If you don't have different handling for every distinct priority value, then configuring things to handle ranges of priorities equivalently would be messy. Do you seriously think that there would be separate forms of alerting for each of 10 or 100 different priority values? > Another question - are you completely discontinuing URI support of Alert-Info with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely deployed across many operators may get impacted if we completely remove URI support and will be a significant bottleneck to migrate to SIP. Because in this case the URI is going to be inserted by Switch/Proxy mostly. We aren't discontinuing anything with this draft. Other uses of Alert-Info, with URIs that are not the form of URN specified in this draft, is still possible and unchanged. However other usage is not well standardized. Presumably its clear that when a dereferencable URL is provided, then the intent was that it be rendered. But there are great impediments to that usage, and it isn't widely supported. And usage with non-dereferencable URIs was never defined. We do not specify what to do if both our URNs and other URIs are included. It was in the past always local policy to decide what to do with multiple URIs, and it remains so when there are multiple URIs that are not all of the form we specify. I don't think there is anything we can usefully add in that case. Thanks, Paul > Regards > > JEWEL > Firoze M Zahidur Rahman > F +88 017 13014806, +6 013 6349764 > 3 +88 02 9882314, +6 03 90581043 > > > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Monday, January 23, 2012 9:19 PM > To: Firoze M. Zahidur Rahman > Cc: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules > > Hi, > > During the discussions on this draft, not only in SALUD but also in > BLISS and DISPATCH, people identified additional possible use cases > which we did not include in the draft. If we try to include every use > case which comes up, we will never get the draft ready (which is now > already 3 years old, first version was back in Feb. 2009). What we do > whith this draft is to provide the basic mechanism which is > extenssible in any way, see requirement 5, so that people and > organisations can define extenssions, this means, new categories or > values. > > We should finish the basic draft as soon as possible. For your use > cases, which seem to me to be quite interesting, I propose you write a > new draft which defines and registers with IANA a new category e. g. > "priority_for_services" or something like that. > > Kind regards > Laura > > > > 2012/1/21 Firoze M. Zahidur Rahman: >> Hi >> >> SIP Call priority will not help this case. User will not have to identify different alerts - the UA will have to identify different alerts. And I am thinking about alert notifications like >> >> 1. Call Waiting Notifications >> 2. Disconnect the ongoing call and establish the higher priority call >> 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messenger) >> 4. For SMS/IMs - Message Not Delivered >> 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) >> 6. For video calls - User has muted his/her mic >> 7. Presence Services - User Status Changed >> 8. Etc. >> >> And all these different types of notifications should have different priority and UA/Device should have its own implementation of handling these alert notifications. And I think all these are targeted for different types of SIP Sessions/Applications. I am not sure if the RFC scope is for Voice Calls only or not. >> >>>> 3. Can we have another category to define UA/device reaction/behavior? >>> I don't understand what you mean. >> >> When we use IM Clients - and someone knocks you - IMs can directly pop up an window with message. Or IM can display a notification that "Mr. X is inviting you for a conversation". So for the same request - the handling of the UA is different. In many case this is set from the UA itself. >> >> Or, if we allow the behaviors like display Customized Picture decided by Caller, Or Play Ringtone (decided by caller) this type of features then I think this additional category will help. >> >> I am not sure if I could make myself clear or I am completely sounding irrelevant. If I am please do point that out. >> >> Thanks& Regards >> >> Jewel >> >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Saturday, January 21, 2012 10:54 AM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules >> >> On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it. >> >> I don't know offhand. The proposal was made by Dale Worley, so look from >> mails from him. It was several months ago, perhaps more than a year. >> >>> However, there are couple of things I wanted to highlight in my first mail. >>> >>> 1. URN string format - bundling multiple values (on which I may be wrong as this is already discussed and decided - I will go through the earlier mails from the archive to clarify my understanding) >> >> Already decided - above discussion. >> >>> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 >> >> Keep in mind that the point of this is to guide the rendering of alerts >> to a user. I find it hard to believe that the user will distinguish 10 >> or 100 different alert variations based on priority. >> >> There is already a sip Priority header to indicate the priority of the >> message itself. >> >>> 3. Can we have another category to define UA/device reaction/behavior? >> >> I don't understand what you mean. >> >>> Particularly for 2 and 3 the reason I am proposing this is >>> >>> 1. Alert-Info can be present in INVITE and if it is present in Invite then it will be nice to have a mechanism to guide/standardize the handling process/logic of the Alert-Info for the devices receiving Alert-Info >> >> That is already provided. >> >>> 2. As we have multiple URN and URNs defining the service, source, priority etc. I assume the priority is the priority for the session/call. If we implement priority as a number then sorting on the priority number for currently ongoing sessions can be done at the device side - and logics can be implemented like force disconnect for higher priority calls, do not notify for lower priority calls, notify back the user for certain priority calls, divert if priority is less than some specific values. And we can leave it up to the implementation. >> >> See above. >> >> Thanks, >> Paul >> >>> With these features I think we will be able to standardize the implementation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by caller, Call Back Notification Services (where caller will be notified whenever the line is free), Handling of Promotional/Low Priority Calls (Voice or Message/SMS Broadcasts) etc. >>> >>> Thanks& Regards >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> F +88 017 13014806, +6 013 6349764 >>> 3 +88 02 9882314, +6 03 90581043 >>> >>> >>> -----Original Message----- >>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of Paul Kyzivat >>> Sent: Saturday, January 21, 2012 1:50 AM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules >>> >>> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. As this extension enables UA or devices to choose/implement features as per internal implementation logic - my idea was to make the structure as - all values in single line. So that while implementing device will not have to think about same category multiple times. Even if same category multiple times is allowed - it will completely refresh/overrule earlier appearance. >>>> >>>> And the order of appearance wise priority (I think corrent approach is also same, priority is decided by order of appearance of URN in header field) also handles the priority decision making process unchanged. >>>> >>>> Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling all values of a category in single URN makes sense. >>> >>> If you look through the salud mail archives you will see that combining >>> things into a single URN was proposed and discussed, but we settled on >>> what we have now. >>> >>> Thanks, >>> Paul >>> >>>> Thanks& Best Regards >>>> >>>> Jewel >>>> >>>> ________________________________________ >>>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@alum.mit.edu] >>>> Sent: Friday, January 20, 2012 11:43 PM >>>> To: salud@ietf.org >>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules >>>> >>>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>>> Hi >>>>> >>>>> Greetings! >>>>> >>>>> I am very new to this area. Advance apologies if my ideas sounds completely misaligned. >>>>> >>>>> I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is >>>>> >>>>> "URN:alert:" alert-identifier >>>>> >>>>> And format of alert-identifier is >>>>> >>>>> alert-category ":" alert-indication >>>>> >>>>> and alert-indication is a single value. >>>>> >>>>> If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side. >>>>> >>>>> So instead of sending multiple URN like >>>>> URN:alert:source:family >>>>> URN:alert:source:friend >>>>> URN:alert:source:internal >>>>> URN:alert:source:unclassified >>>>> >>>>> device will send URN as >>>>> >>>>> URN:alert:source:family,friend,internal,unclassified >>>> >>>> In the above you have not included the header. It would really be: >>>> >>>> Alert-Info: URN:alert:source:family >>>> Alert-Info: URN:alert:source:friend >>>> Alert-Info: URN:alert:source:internal >>>> Alert-Info: URN:alert:source:unclassified >>>> >>>> and your preference would seem to be: >>>> >>>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>>> >>>> But the latter cannot work. The key point is that Alert-Info takes URIs >>>> as arguments (including URNs), which can be separated by commas or as >>>> separate header fields. Because of that, in your latter case, "friend" >>>> is syntactically incorrect because it is not a URI. >>>> >>>> Aside from that I don't understand why you think what you propose is >>>> easier to use or implement. (I agree that is uses fewer bytes, but that >>>> doesn't make it easier.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>>> Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement. >>>>> >>>>> >>>>> I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them. >>>>> >>>>> And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be). >>>>> >>>>> Thanks& Best Regards >>>>> >>>>> >>>>> JEWEL >>>>> Firoze M Zahidur Rahman >>>>> >>>>> _______________________________________________ >>>>> salud mailing list >>>>> salud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/salud >>>>> >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > From dworley@avaya.com Mon Jan 23 12:23:48 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F18021F873C for ; Mon, 23 Jan 2012 12:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.127 X-Spam-Level: X-Spam-Status: No, score=-103.127 tagged_above=-999 required=5 tests=[AWL=0.472, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ejXHDx65b4jg for ; Mon, 23 Jan 2012 12:23:48 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id A917D21F8721 for ; Mon, 23 Jan 2012 12:23:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAIHBHU/GmAcF/2dsb2JhbABCnTuQb4EFgXIBAQEBAgESKEQLAgEIDQUDIRAyFwkFAQEEARIIGodanRqbKYtDYwSIO5JXjHM X-IronPort-AV: E=Sophos;i="4.71,557,1320642000"; d="scan'208";a="326028009" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 23 Jan 2012 15:23:45 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Jan 2012 15:18:43 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Mon, 23 Jan 2012 15:23:45 -0500 From: "Worley, Dale R (Dale)" To: "Firoze M. Zahidur Rahman" , "salud@ietf.org" Date: Mon, 23 Jan 2012 15:23:44 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXhKjpXJ8O3QfLQIW4jP8BNzrGEgChPYph Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Jan 2012 20:23:48 -0000 I am just starting to read this thread. These are my preliminary responses. > From: Firoze M. Zahidur Rahman [jewel@ssd-tech.com] >=20 > I found current way of using multiple Alert-Info URNs and Priority > Rules a bit difficult to use and implement. I can see that we have 6 > fixed alert-categories and the Alert URN Format is >=20 > "URN:alert:" alert-identifier >=20 > And format of alert-identifier is >=20 > alert-category ":" alert-indication >=20 > and alert-indication is a single value. >=20 > If we can allow to include multiple value in alert-indication > separated by comma (,) and the order of appearance will decide the > order of priority for the alert-indication value then I think it will > be easy to implement from the device side. >=20 > So instead of sending multiple URN like > URN:alert:source:family > URN:alert:source:friend > URN:alert:source:internal > URN:alert:source:unclassified >=20 > device will send URN as >=20 > URN:alert:source:family,friend,internal,unclassified Overall, there is the architectural choice: (1) use one URN to provide multiple values (for possibly many categories), or (2) use multiple URNs, each one of which provides one value for one category. Note that the implementation effort is the same for either approach, as the UA must be able to process all the values together to select its alerting signal. So the choice is driven by two considerations: (1) Is the approach compatible with the concept of URN(s) describing alerting signals? (2) How difficult is it to describe the architecture to implementers? The consensus of the WG is that the "multiple URNs" approach is preferable because it is architecturally acceptable, and much easier to describe to implementers. > Besides, if we disallow or ignore (or latest appearance overrides > earlier) multiple appearance of alert-category then it will be more > easier to implement. The current design is that the *earlier* URN overrides the *later* URN, which we believe is somewhat more natural. Of course, the reverse rule would have no greater or lesser descriptive power. In the case of your example: > URN:alert:source:family,friend,internal,unclassified the approach in the draft is: Alert-Info: urn:alert:source:family, urn:alert:source:friend, urn:alert:source:internal, urn:alert:source:unclassified which means to alert the call as "family" if possible, and if that is not possible, then to alert it as "friend" if possible, and if that is not possible, etc. > I have another suggestion regarding the values of alert-category > priority. If we make it a number like 0, 1, 10 anything may be between > 00 to 99 or 0-9 to make it simple, then I think devices will have the > provision to prioritize 2 calls/sessions (in case of call waiting or > line busy) easily and devices will be able to implement specific > logics for them. It would be reasonable to specify priorities as numbers. Effectively, the current draft provides three values, 1, 2, and 3. However, we only consider priority as a characteristic affecting how a call is alerted, not how the UA handles the call. But I suppose that the priority could be used for that. > And if we can introduce another alert-category to guide the > call/session handle behavoir according to service or priority for the > devices e.g. force connect on busy, notify back when free, delivery > report (read, delivered, not delivered etc) (as we are handing SIP > sessions - the URNs should cover IM and short messages as well may > be). The alert URNs are not intended to control how the call is handled, only its alerting signal. And alert URNs would not be sufficient for many handling specifications. For example, "notify back when free" is the "call completion on busy subscriber" function, which is much more complicated to implement in an effective manner than simply attaching an indication to the INVITE. (See draft-ietf-bliss-call-completion-14.) However, alert URNs can be used when initiating IM sessions using MSRP, as those sessions are set up using SIP INVITE. In regard to paging IM, using the NOTIFY method, RFC 3428 does not envision using Alert-Info to specify how the message is announced to the recipient, but using Alert-Info seems to be a natural extension. Dale From jewel@ssd-tech.com Mon Jan 23 19:26:33 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2DB511E8073 for ; Mon, 23 Jan 2012 19:26:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.583 X-Spam-Level: X-Spam-Status: No, score=-3.583 tagged_above=-999 required=5 tests=[AWL=1.016, BAYES_00=-2.599, GB_I_INVITATION=-2] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7VWVLfO6m6u for ; Mon, 23 Jan 2012 19:26:32 -0800 (PST) Received: from leo.ssd-tech.com (home.ssd-tech.com [202.22.193.178]) by ietfa.amsl.com (Postfix) with ESMTP id 3FB2D11E8071 for ; Mon, 23 Jan 2012 19:26:31 -0800 (PST) Received: from aries.ssd-tech.com ([::1]) by aries.ssd-tech.com ([::1]) with mapi; Tue, 24 Jan 2012 09:21:58 +0600 From: "Firoze M. Zahidur Rahman" To: Paul Kyzivat , "salud@ietf.org" Date: Tue, 24 Jan 2012 09:21:56 +0600 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczZ588oqWd5QIPXT7eEfg0ObivNTAAWn8pA Message-ID: <5783EF37C9CBA043B84517F864F8D0CE046605F546@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> <4F1D849A.4050608@alum.mit.edu> In-Reply-To: <4F1D849A.4050608@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-tm-as-product-ver: SMEX-8.6.0.1386-6.800.1017-18662.004 x-tm-as-result: No--35.997800-5.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 03:26:34 -0000 Hi >Do you seriously think that there would be separate forms of alerting >for each of 10 or 100 different priority values? There are different incidents when users will be required to be notified in= a SIP UA/Device e.g Incoming Voice Call Indicatin, IM Request, Incoming Vi= deo Call Indication etc. For all these incidents I think users will need di= fferent types of notification. The role of priority will come into the pict= ure when you already in a session and another incident comes up e.g. You ar= e in a voice call, another IM invitation comes up, or another IM Request co= mes up, or may be 2 incidents - one voice call is ringing and and another I= M comes or other way round. In such cases I think priority will be able to = play a role. My proposal is primarily change the priority values to numbers instead of h= igh, normal and low. And we can also decide on a range of values to be used= without making it widely open to the implementers - may be 10 or 100. >However other usage is not well standardized. Presumably its clear that >when a dereferencable URL is provided, then the intent was that it be >rendered. But there are great impediments to that usage, and it isn't >widely supported. And usage with non-dereferencable URIs was never defined= . Shouldn't this RFC provide a guidance regarding this? As one of the main ta= rget of this effort is to standardize the Alert Notification. Standardizati= on of user alert notification on UA/Devices are very much required (you can= find so many option to set up the notification/alert tones of smart phones= to be set up and every vendor implements it differently). Standardization = of Alert Notifications will enable a lot of content based services to be de= veloped around this. [Only the option of having 3 way call and opening up o= f Media channel after ACM message of SS7 signaling enabled to develop servi= ces like Personalized Ring Back Tone which is a very popular service in man= y operators]. So if alert notifications can be standardized properly this w= ill open up a lot of service opportunities I think. >We do not specify what to do if both our URNs and other URIs are >included. It was in the past always local policy to decide what to do >with multiple URIs, and it remains so when there are multiple URIs that >are not all of the form we specify. I don't think there is anything we >can usefully add in that case. Shouldn't this be covered as part of this work? Jewel -----Original Message----- From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of P= aul Kyzivat Sent: Monday, January 23, 2012 10:03 PM To: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules On 1/23/12 10:29 AM, Firoze M. Zahidur Rahman wrote: > Hi > > My proposal is for changing the priorities to 0-9 or 00-99 - I mean numbe= rs instead of high, normal and low. I think that will cover the handling of= priority. If we don't want the additional category its fine as devices can= have their own logic and configuration option to implement that. If you look at the example algorithm that has been proposed, making this change would complicate things. If you don't have different handling for every distinct priority value, then configuring things to handle ranges of priorities equivalently would be messy. Do you seriously think that there would be separate forms of alerting for each of 10 or 100 different priority values? > Another question - are you completely discontinuing URI support of Alert-= Info with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely = deployed across many operators may get impacted if we completely remove URI= support and will be a significant bottleneck to migrate to SIP. Because in= this case the URI is going to be inserted by Switch/Proxy mostly. We aren't discontinuing anything with this draft. Other uses of Alert-Info, with URIs that are not the form of URN specified in this draft, is still possible and unchanged. However other usage is not well standardized. Presumably its clear that when a dereferencable URL is provided, then the intent was that it be rendered. But there are great impediments to that usage, and it isn't widely supported. And usage with non-dereferencable URIs was never defined. We do not specify what to do if both our URNs and other URIs are included. It was in the past always local policy to decide what to do with multiple URIs, and it remains so when there are multiple URIs that are not all of the form we specify. I don't think there is anything we can usefully add in that case. Thanks, Paul > Regards > > JEWEL > Firoze M Zahidur Rahman > F +88 017 13014806, +6 013 6349764 > 3 +88 02 9882314, +6 03 90581043 > > > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Monday, January 23, 2012 9:19 PM > To: Firoze M. Zahidur Rahman > Cc: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > Hi, > > During the discussions on this draft, not only in SALUD but also in > BLISS and DISPATCH, people identified additional possible use cases > which we did not include in the draft. If we try to include every use > case which comes up, we will never get the draft ready (which is now > already 3 years old, first version was back in Feb. 2009). What we do > whith this draft is to provide the basic mechanism which is > extenssible in any way, see requirement 5, so that people and > organisations can define extenssions, this means, new categories or > values. > > We should finish the basic draft as soon as possible. For your use > cases, which seem to me to be quite interesting, I propose you write a > new draft which defines and registers with IANA a new category e. g. > "priority_for_services" or something like that. > > Kind regards > Laura > > > > 2012/1/21 Firoze M. Zahidur Rahman: >> Hi >> >> SIP Call priority will not help this case. User will not have to identif= y different alerts - the UA will have to identify different alerts. And I a= m thinking about alert notifications like >> >> 1. Call Waiting Notifications >> 2. Disconnect the ongoing call and establish the higher priority call >> 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messeng= er) >> 4. For SMS/IMs - Message Not Delivered >> 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) >> 6. For video calls - User has muted his/her mic >> 7. Presence Services - User Status Changed >> 8. Etc. >> >> And all these different types of notifications should have different pri= ority and UA/Device should have its own implementation of handling these al= ert notifications. And I think all these are targeted for different types o= f SIP Sessions/Applications. I am not sure if the RFC scope is for Voice Ca= lls only or not. >> >>>> 3. Can we have another category to define UA/device reaction/behavior? >>> I don't understand what you mean. >> >> When we use IM Clients - and someone knocks you - IMs can directly pop u= p an window with message. Or IM can display a notification that "Mr. X is i= nviting you for a conversation". So for the same request - the handling of = the UA is different. In many case this is set from the UA itself. >> >> Or, if we allow the behaviors like display Customized Picture decided by= Caller, Or Play Ringtone (decided by caller) this type of features then I = think this additional category will help. >> >> I am not sure if I could make myself clear or I am completely sounding i= rrelevant. If I am please do point that out. >> >> Thanks& Regards >> >> Jewel >> >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf O= f Paul Kyzivat >> Sent: Saturday, January 21, 2012 10:54 AM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> It will be very nice if you please can refer the discussion date or thr= ead of the multiple value discussion. I am not able to find it. >> >> I don't know offhand. The proposal was made by Dale Worley, so look from >> mails from him. It was several months ago, perhaps more than a year. >> >>> However, there are couple of things I wanted to highlight in my first m= ail. >>> >>> 1. URN string format - bundling multiple values (on which I may be wron= g as this is already discussed and decided - I will go through the earlier = mails from the archive to clarify my understanding) >> >> Already decided - above discussion. >> >>> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 >> >> Keep in mind that the point of this is to guide the rendering of alerts >> to a user. I find it hard to believe that the user will distinguish 10 >> or 100 different alert variations based on priority. >> >> There is already a sip Priority header to indicate the priority of the >> message itself. >> >>> 3. Can we have another category to define UA/device reaction/behavior? >> >> I don't understand what you mean. >> >>> Particularly for 2 and 3 the reason I am proposing this is >>> >>> 1. Alert-Info can be present in INVITE and if it is present in Invite t= hen it will be nice to have a mechanism to guide/standardize the handling p= rocess/logic of the Alert-Info for the devices receiving Alert-Info >> >> That is already provided. >> >>> 2. As we have multiple URN and URNs defining the service, source, prior= ity etc. I assume the priority is the priority for the session/call. If we = implement priority as a number then sorting on the priority number for curr= ently ongoing sessions can be done at the device side - and logics can be i= mplemented like force disconnect for higher priority calls, do not notify f= or lower priority calls, notify back the user for certain priority calls, d= ivert if priority is less than some specific values. And we can leave it up= to the implementation. >> >> See above. >> >> Thanks, >> Paul >> >>> With these features I think we will be able to standardize the implemen= tation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by c= aller, Call Back Notification Services (where caller will be notified whene= ver the line is free), Handling of Promotional/Low Priority Calls (Voice or= Message/SMS Broadcasts) etc. >>> >>> Thanks& Regards >>> >>> JEWEL >>> Firoze M Zahidur Rahman >>> F +88 017 13014806, +6 013 6349764 >>> 3 +88 02 9882314, +6 03 90581043 >>> >>> >>> -----Original Message----- >>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf = Of Paul Kyzivat >>> Sent: Saturday, January 21, 2012 1:50 AM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs = and Priority Rules >>> >>> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> Its not really usage of lesser no of bytes, the overall idea was to ac= commodate multiple values in the same URN. As this extension enables UA or = devices to choose/implement features as per internal implementation logic -= my idea was to make the structure as - all values in single line. So that = while implementing device will not have to think about same category multip= le times. Even if same category multiple times is allowed - it will complet= ely refresh/overrule earlier appearance. >>>> >>>> And the order of appearance wise priority (I think corrent approach is= also same, priority is decided by order of appearance of URN in header fie= ld) also handles the priority decision making process unchanged. >>>> >>>> Instead of comma(,) we can use dot(.) or slash(/) separated values may= be. Or we can find some other way to make it URI compatible. But that can = be though/found out if everyone thinks that bundling all values of a catego= ry in single URN makes sense. >>> >>> If you look through the salud mail archives you will see that combining >>> things into a single URN was proposed and discussed, but we settled on >>> what we have now. >>> >>> Thanks, >>> Paul >>> >>>> Thanks& Best Regards >>>> >>>> Jewel >>>> >>>> ________________________________________ >>>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Pau= l Kyzivat [pkyzivat@alum.mit.edu] >>>> Sent: Friday, January 20, 2012 11:43 PM >>>> To: salud@ietf.org >>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs= and Priority Rules >>>> >>>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>>> Hi >>>>> >>>>> Greetings! >>>>> >>>>> I am very new to this area. Advance apologies if my ideas sounds comp= letely misaligned. >>>>> >>>>> I found current way of using multiple Alert-Info URNs and Priority Ru= les a bit difficult to use and implement. I can see that we have 6 fixed al= ert-categories and the Alert URN Format is >>>>> >>>>> "URN:alert:" alert-identifier >>>>> >>>>> And format of alert-identifier is >>>>> >>>>> alert-category ":" alert-indication >>>>> >>>>> and alert-indication is a single value. >>>>> >>>>> If we can allow to include multiple value in alert-indication separat= ed by comma (,) and the order of appearance will decide the order of priori= ty for the alert-indication value then I think it will be easy to implement= from the device side. >>>>> >>>>> So instead of sending multiple URN like >>>>> URN:alert:source:family >>>>> URN:alert:source:friend >>>>> URN:alert:source:internal >>>>> URN:alert:source:unclassified >>>>> >>>>> device will send URN as >>>>> >>>>> URN:alert:source:family,friend,internal,unclassified >>>> >>>> In the above you have not included the header. It would really be: >>>> >>>> Alert-Info: URN:alert:source:family >>>> Alert-Info: URN:alert:source:friend >>>> Alert-Info: URN:alert:source:internal >>>> Alert-Info: URN:alert:source:unclassified >>>> >>>> and your preference would seem to be: >>>> >>>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>>> >>>> But the latter cannot work. The key point is that Alert-Info takes URI= s >>>> as arguments (including URNs), which can be separated by commas or as >>>> separate header fields. Because of that, in your latter case, "friend" >>>> is syntactically incorrect because it is not a URI. >>>> >>>> Aside from that I don't understand why you think what you propose is >>>> easier to use or implement. (I agree that is uses fewer bytes, but tha= t >>>> doesn't make it easier.) >>>> >>>> Thanks, >>>> Paul >>>> >>>> >>>>> Besides, if we disallow or ignore (or latest appearance overrides ear= lier) multiple appearance of alert-category then it will be more easier to = implement. >>>>> >>>>> >>>>> I have another suggestion regarding the values of alert-category prio= rity. If we make it a number like 0, 1, 10 anything may be between 00 to 99= or 0-9 to make it simple, then I think devices will have the provision to = prioritize 2 calls/sessions (in case of call waiting or line busy) easily a= nd devices will be able to implement specific logics for them. >>>>> >>>>> And if we can introduce another alert-category to guide the call/sess= ion handle behavoir according to service or priority for the devices e.g. f= orce connect on busy, notify back when free, delivery report (read, deliver= ed, not delivered etc) (as we are handing SIP sessions - the URNs should co= ver IM and short messages as well may be). >>>>> >>>>> Thanks& Best Regards >>>>> >>>>> >>>>> JEWEL >>>>> Firoze M Zahidur Rahman >>>>> >>>>> _______________________________________________ >>>>> salud mailing list >>>>> salud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/salud >>>>> >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ salud mailing list salud@ietf.org https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Tue Jan 24 05:41:21 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B06C321F84DD for ; Tue, 24 Jan 2012 05:41:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wc5RxJOo84+6 for ; Tue, 24 Jan 2012 05:41:20 -0800 (PST) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by ietfa.amsl.com (Postfix) with ESMTP id E739C21F84DE for ; Tue, 24 Jan 2012 05:41:19 -0800 (PST) Received: by wgbgn7 with SMTP id gn7so308846wgb.1 for ; Tue, 24 Jan 2012 05:41:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=B3xi1jxlvrTJ8dEVDtVc2bZUGxvC4yrKA7+YDmY3Y/4=; b=EC02aka+V6hcn/vPyPZzj4gq7+Dx2B1GVwb8aKW04xAcEXin8gw+o+z0+Ry010h4Bp 3UnG2FY94FVcHkVe1yiNaR/JrVV3lUNjb3adjKBLptzuiJ4NJieJ770yYyB4emy9G3Gb NIO0zJozmesBIs1k//Bh53MlPDF8zEcYpBYWI= MIME-Version: 1.0 Received: by 10.180.106.202 with SMTP id gw10mr4616347wib.3.1327412478966; Tue, 24 Jan 2012 05:41:18 -0800 (PST) Received: by 10.227.23.197 with HTTP; Tue, 24 Jan 2012 05:41:18 -0800 (PST) In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com> Date: Tue, 24 Jan 2012 14:41:18 +0100 Message-ID: From: Laura Liess To: "Firoze M. Zahidur Rahman" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 13:41:21 -0000 2012/1/23 Firoze M. Zahidur Rahman : > Hi > > Thanks a lot for the clarification. I think my proposal and the your disc= ussion point is not same. My proposal was a URNs like > > Alert-Info: > Alert-Info: > Alert-Info: > etc > > Or may be > > Alert-Info: , , > > Or something similar. This will help the UA to decide e.g. regarding "ser= vice" -priority is normal then call-waiting and finally forward. So UA will= try to alert for normal call, if not possible (may be busy in another call= ) notify for call-waiting or finally notify for forwarding. And the priorit= y for the selection can be determined by the order of appearance. > If I understand correctly, in your proposal the rendering for would depend of the state of the end device. The rendering for this URN would be the "normal" when the end device is idle and "call-waiting" or "forward" when the device is "busy". I am not an expert for URIs/URNs, but I would say this is not allowed by the definition of the URNs. The RFC 1737 describes the requirements for URNs: o Global scope: A URN is a name with global scope which does not imply a location. It has the same meaning everywhere. o Global uniqueness: The same URN will never be assigned to two different resources. o Persistence: It is intended that the lifetime of a URN be permanent. That is, the URN will be globally unique forever, and may well be used as a reference to a resource well beyond the lifetime of the resource it identifies or of any naming authority involved in the assignment of its name. I think your proposal does not allign with the definition of the URNs. It can not be that the meaning of a URN depends on the algorithm at the receiving end device. I am not aware of examples where one URN contains names with contradictory meanings and using such syntax would be, if not forbidden, very confusing. I think it would be difficult to pass this syntax through the IESG review. The syntax we have now was discussed and reviewed by IETF experts in the past. I am not willing to change it now into a syntax which may be incorrect. And I really don't see why should be easier to implement than . The algorithm described in the draft is not mandatory, it is just an example. You are free to use an algorithm of your choice. However, it would make sense for me to consider your use case within the priority rules in Section 7, because they are mandatory. We eventually ( if the WG agrees to that) could add following at the end of the text inside the brackets in the requirement b.: "(because it does not recognize the URN or the URN's effect is precluded by preceding URNs *** or not compatible with the current state of the end device or explicitely not desired *** )" . (The new text is between ***.) Would you agree to that? Regards Laura . > And I am not sure if this will increase no of IANA registration. The regi= stration can follow > > service RFCXXXX > source RFCYYYY > > etc. > > Best Regards > > Jewel > > -----Original Message----- > From: Laura Liess [mailto:laura.liess.dt@googlemail.com] > Sent: Monday, January 23, 2012 8:54 PM > To: Firoze M. Zahidur Rahman > Cc: salud@ietf.org; Paul Kyzivat; Roland Jesske > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > 2012/1/21 Firoze M. Zahidur =A0Rahman : >> Hi >> >> It will be very nice if you please can refer the discussion date or thre= ad of the multiple value discussion. I am not able to find it. > > As Paul already pointed out we already had this discussion, not only once= . > > The first discussion was in BLISS, back in 2009. =A0(This draft was > first submitted in BLISS, then moved to DISPATCH, then we got our own > miniWG SALUD. ) In the first versions of the draft in BLISS followed a > similar direction as you propose. See Section 7.3 in > http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt > =A0. > In http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html > Adam Roach pointed out that we have to register all combinations with > IANA an "If someone adds another semantic dimension, the size of the > registry continues to grow exponentially". > > The second discussion on this issue was in SALUD, see =A0the messages > around =A0http://www.ietf.org/mail-archive/web/salud/current/msg00038.htm= l > . We call =A0this issue "multiple URN vs. single URN". Again, we came to > the conclusion that also "single URN" is much more simple to implement > for the receiving UA, we run with it into the problem identified by > Adam, the IANA registry grow exponentially when new values are > registred. With "multiple URNs", =A0we don't have this problem. > > A receiving UA has to be able to deal with combinations of Alert-Info > URNs anyway because =A0more than one SIP network elements in the message > path (the sending UA, proxies, B2BUAs) may insert Alert-Info URNs. > > Kind regards > Laura > > > > > > > > > >> >> However, there are couple of things I wanted to highlight in my first ma= il. >> >> 1. URN string format - bundling multiple values (on which I may be wrong= as this is already discussed and decided - I will go through the earlier m= ails from the archive to clarify my understanding) >> >> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 >> >> 3. Can we have another category to define UA/device reaction/behavior? >> >> Particularly for 2 and 3 the reason I am proposing this is >> >> 1. Alert-Info can be present in INVITE and if it is present in Invite th= en it will be nice to have a mechanism to guide/standardize the handling pr= ocess/logic of the Alert-Info for the devices receiving Alert-Info >> >> 2. As we have multiple URN and URNs defining the service, source, priori= ty etc. I assume the priority is the priority for the session/call. If we i= mplement priority as a number then sorting on the priority number for curre= ntly ongoing sessions can be done at the device side - and logics can be im= plemented like force disconnect for higher priority calls, do not notify fo= r lower priority calls, notify back the user for certain priority calls, di= vert if priority is less than some specific values. And we can leave it up = to the implementation. >> >> With these features I think we will be able to standardize the implement= ation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by ca= ller, Call Back Notification Services (where caller will be notified whenev= er the line is free), Handling of Promotional/Low Priority Calls (Voice or = Message/SMS Broadcasts) etc. >> >> Thanks & Regards >> >> JEWEL >> Firoze M Zahidur Rahman >> F=A0=A0+88 017 13014806, +6 013 6349764 >> 3=A0+88 02 9882314,=A0+6 03 90581043 >> >> >> -----Original Message----- >> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf O= f Paul Kyzivat >> Sent: Saturday, January 21, 2012 1:50 AM >> To: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>> Hi >>> >>> Its not really usage of lesser no of bytes, the overall idea was to acc= ommodate multiple values in the same URN. As this extension enables UA or d= evices to choose/implement features as per internal implementation logic - = my idea was to make the structure as - all values in single line. So that w= hile implementing device will not have to think about same category multipl= e times. Even if same category multiple times is allowed - it will complete= ly refresh/overrule earlier appearance. >>> >>> And the order of appearance wise priority (I think corrent approach is = also same, priority is decided by order of appearance of URN in header fiel= d) also handles the priority decision making process unchanged. >>> >>> Instead of comma(,) we can use dot(.) or slash(/) separated values may = be. Or we can find some other way to make it URI compatible. But that can b= e though/found out if everyone thinks that bundling all values of a categor= y in single URN makes sense. >> >> If you look through the salud mail archives you will see that combining >> things into a single URN was proposed and discussed, but we settled on >> what we have now. >> >> =A0 =A0 =A0 =A0Thanks, >> =A0 =A0 =A0 =A0Paul >> >>> Thanks& =A0Best Regards >>> >>> Jewel >>> >>> ________________________________________ >>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@alum.mit.edu] >>> Sent: Friday, January 20, 2012 11:43 PM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs = and Priority Rules >>> >>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> Greetings! >>>> >>>> I am very new to this area. Advance apologies if my ideas sounds compl= etely misaligned. >>>> >>>> I found current way of using multiple Alert-Info URNs and Priority Rul= es a bit difficult to use and implement. I can see that we have 6 fixed ale= rt-categories and the Alert URN Format is >>>> >>>> "URN:alert:" alert-identifier >>>> >>>> And format of alert-identifier is >>>> >>>> alert-category ":" alert-indication >>>> >>>> and alert-indication is a single value. >>>> >>>> If we can allow to include multiple value in alert-indication separate= d by comma (,) and the order of appearance will decide the order of priorit= y for the alert-indication value then I think it will be easy to implement = from the device side. >>>> >>>> So instead of sending multiple URN like >>>> URN:alert:source:family >>>> URN:alert:source:friend >>>> URN:alert:source:internal >>>> URN:alert:source:unclassified >>>> >>>> device will send URN as >>>> >>>> URN:alert:source:family,friend,internal,unclassified >>> >>> In the above you have not included the header. It would really be: >>> >>> Alert-Info: URN:alert:source:family >>> Alert-Info: URN:alert:source:friend >>> Alert-Info: URN:alert:source:internal >>> Alert-Info: URN:alert:source:unclassified >>> >>> and your preference would seem to be: >>> >>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>> >>> But the latter cannot work. The key point is that Alert-Info takes URIs >>> as arguments (including URNs), which can be separated by commas or as >>> separate header fields. Because of that, in your latter case, "friend" >>> is syntactically incorrect because it is not a URI. >>> >>> Aside from that I don't understand why you think what you propose is >>> easier to use or implement. (I agree that is uses fewer bytes, but that >>> doesn't make it easier.) >>> >>> =A0 =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0 =A0Paul >>> >>> >>>> Besides, if we disallow or ignore (or latest appearance overrides earl= ier) multiple appearance of alert-category then it will be more easier to i= mplement. >>>> >>>> >>>> I have another suggestion regarding the values of alert-category prior= ity. If we make it a number like 0, 1, 10 anything may be between 00 to 99 = or 0-9 to make it simple, then I think devices will have the provision to p= rioritize 2 calls/sessions (in case of call waiting or line busy) easily an= d devices will be able to implement specific logics for them. >>>> >>>> And if we can introduce another alert-category to guide the call/sessi= on handle behavoir according to service or priority for the devices e.g. fo= rce connect on busy, notify back when free, delivery report (read, delivere= d, not delivered etc) (as we are handing SIP sessions - the URNs should cov= er IM and short messages as well may be). >>>> >>>> Thanks& =A0 Best Regards >>>> >>>> >>>> JEWEL >>>> Firoze M Zahidur Rahman >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> >> >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud From laura.liess.dt@googlemail.com Tue Jan 24 07:23:50 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA17B21F8661 for ; Tue, 24 Jan 2012 07:23:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.977 X-Spam-Level: X-Spam-Status: No, score=-3.977 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AU33ImLzZ-BB for ; Tue, 24 Jan 2012 07:23:49 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by ietfa.amsl.com (Postfix) with ESMTP id A84E521F8658 for ; Tue, 24 Jan 2012 07:23:48 -0800 (PST) Received: by wgbed3 with SMTP id ed3so3156175wgb.13 for ; Tue, 24 Jan 2012 07:23:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=nUvX4MK4MsYtiT/Iou2cUVwxwRXNT6yuxDJUw7Q/Qhs=; b=iOU9O7S97yKWNVNF/t6esmqxkwNseB2apmy/OqN3FiRXDz0pnoaQ5yGLGMS3bVszvF SnQIkKCCDHCzaI3xPUXy5xMVxkpVZ0bd7+KNtG3SomY9UI6v4jKA9XlgaLnrP8WYKurT 1sT6ye3JWvsO3oocZJdLuxOru4aevbDd6+OaA= MIME-Version: 1.0 Received: by 10.180.19.138 with SMTP id f10mr27140201wie.3.1327418627775; Tue, 24 Jan 2012 07:23:47 -0800 (PST) Received: by 10.227.23.197 with HTTP; Tue, 24 Jan 2012 07:23:47 -0800 (PST) In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F546@aries.ssd-tech.com> References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> <4F1D849A.4050608@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F546@aries.ssd-tech.com> Date: Tue, 24 Jan 2012 16:23:47 +0100 Message-ID: From: Laura Liess To: "Firoze M. Zahidur Rahman" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 15:23:50 -0000 Hi, Please see inline. 2012/1/24 Firoze M. Zahidur Rahman : > Hi > >>Do you seriously think that there would be separate forms of alerting >>for each of 10 or 100 different priority values? > > There are different incidents when users will be required to be notified = in a SIP UA/Device e.g Incoming Voice Call Indicatin, IM Request, Incoming = Video Call Indication etc. For all these incidents I think users will need = different types of notification. The role of priority will come into the pi= cture when you already in a session and another incident comes up e.g. You = are in a voice call, another IM invitation comes up, or another IM Request = comes up, or may be 2 incidents - one voice call is ringing and and another= IM comes or other way round. In such cases I think priority will be able t= o play a role. > > My proposal is primarily change the priority values to numbers instead of= high, normal and low. And we can also decide on a range of values to be us= ed without making it widely open to the implementers - may be 10 or 100. > [LL] The WG deliberately choosed names which are understandable for humans and not numbers, where the exact meaning must be defined in the RFC. If you choose numbers for priorities, you have to define if 1 is the highest or the lowest priority. Many systems only understand three priorities: normal, low and high. As Paul already said, using more priorities then this would complicate things for these devices. So, I would do not agree to change the current definition for the priority stuff. But it seems that you have quite nice and interesting use cases, so it would probably make sense for you to write a new draft, describe the use cases and define a new category or just numerical subindications for the current priority indicatios, e.g. urn:alert:priority:normal: where n=3D1...100. >>However other usage is not well standardized. Presumably its clear that >>when a dereferencable URL is provided, then the intent was that it be >>rendered. But there are great impediments to that usage, and it isn't >>widely supported. And usage with non-dereferencable URIs was never define= d. > > Shouldn't this RFC provide a guidance regarding this? As one of the main = target of this effort is to standardize the Alert Notification. Standardiza= tion of user alert notification on UA/Devices are very much required (you c= an find so many option to set up the notification/alert tones of smart phon= es to be set up and every vendor implements it differently). Standardizatio= n of Alert Notifications will enable a lot of content based services to be = developed around this. [Only the option of having 3 way call and opening up= of Media channel after ACM message of SS7 signaling enabled to develop ser= vices like Personalized Ring Back Tone which is a very popular service in m= any operators]. So if alert notifications can be standardized properly this= will open up a lot of service opportunities I think. > [LL] It was already agreed by the WG that this issue is not in the scope of this draft, I think it is not in scope for the WG charter. And we have to finish the basic draft soon, we should have submitted it to the IESG in August last year. But this is sure an interesting issue so why don't you go ahead and submitt a new draft whith the requirements, use cases and whatever else about this subject? Kind regards Laura >>We do not specify what to do if both our URNs and other URIs are >>included. It was in the past always local policy to decide what to do >>with multiple URIs, and it remains so when there are multiple URIs that >>are not all of the form we specify. I don't think there is anything we >>can usefully add in that case. > > Shouldn't this be covered as part of this work? > > Jewel > > -----Original Message----- > From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf Of= Paul Kyzivat > Sent: Monday, January 23, 2012 10:03 PM > To: salud@ietf.org > Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs an= d Priority Rules > > On 1/23/12 10:29 AM, Firoze M. Zahidur Rahman wrote: >> Hi >> >> My proposal is for changing the priorities to 0-9 or 00-99 - I mean numb= ers instead of high, normal and low. I think that will cover the handling o= f priority. If we don't want the additional category its fine as devices ca= n have their own logic and configuration option to implement that. > > If you look at the example algorithm that has been proposed, making this > change would complicate things. If you don't have different handling for > every distinct priority value, then configuring things to handle ranges > of priorities equivalently would be messy. > > Do you seriously think that there would be separate forms of alerting > for each of 10 or 100 different priority values? > >> Another question - are you completely discontinuing URI support of Alert= -Info with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely= deployed across many operators may get impacted if we completely remove UR= I support and will be a significant bottleneck to migrate to SIP. Because i= n this case the URI is going to be inserted by Switch/Proxy mostly. > > We aren't discontinuing anything with this draft. > Other uses of Alert-Info, with URIs that are not the form of URN > specified in this draft, is still possible and unchanged. > > However other usage is not well standardized. Presumably its clear that > when a dereferencable URL is provided, then the intent was that it be > rendered. But there are great impediments to that usage, and it isn't > widely supported. And usage with non-dereferencable URIs was never define= d. > > We do not specify what to do if both our URNs and other URIs are > included. It was in the past always local policy to decide what to do > with multiple URIs, and it remains so when there are multiple URIs that > are not all of the form we specify. I don't think there is anything we > can usefully add in that case. > > =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, > =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul > >> Regards >> >> JEWEL >> Firoze M Zahidur Rahman >> F =C2=A0+88 017 13014806, +6 013 6349764 >> 3 +88 02 9882314, +6 03 90581043 >> >> >> -----Original Message----- >> From: Laura Liess [mailto:laura.liess.dt@googlemail.com] >> Sent: Monday, January 23, 2012 9:19 PM >> To: Firoze M. Zahidur Rahman >> Cc: salud@ietf.org >> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs a= nd Priority Rules >> >> Hi, >> >> During the discussions on this draft, not only in SALUD but also in >> BLISS and DISPATCH, =C2=A0people identified additional possible use case= s >> which we did not include in the draft. If we try to include every use >> case which comes up, we will never get the draft ready (which is now >> already 3 years old, first version was back in Feb. 2009). =C2=A0What we= do >> whith this draft is to provide the basic mechanism which is >> extenssible in any way, see requirement 5, so that people and >> organisations can define extenssions, this means, new categories or >> values. >> >> We should finish the basic draft as soon as possible. For your use >> cases, which seem to me to be quite interesting, I propose you write a >> new draft which defines and registers with IANA a new category e. g. >> "priority_for_services" or something like that. >> >> Kind regards >> Laura >> >> >> >> 2012/1/21 Firoze M. Zahidur =C2=A0Rahman: >>> Hi >>> >>> SIP Call priority will not help this case. User will not have to identi= fy different alerts - the UA will have to identify different alerts. And I = am thinking about alert notifications like >>> >>> 1. Call Waiting Notifications >>> 2. Disconnect the ongoing call and establish the higher priority call >>> 3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messen= ger) >>> 4. For SMS/IMs - Message Not Delivered >>> 5. For SMS/IMs - User is typing a message (Like Blackberry Messenger) >>> 6. For video calls - User has muted his/her mic >>> 7. Presence Services - User Status Changed >>> 8. Etc. >>> >>> And all these different types of notifications should have different pr= iority and UA/Device should have its own implementation of handling these a= lert notifications. And I think all these are targeted for different types = of SIP Sessions/Applications. I am not sure if the RFC scope is for Voice C= alls only or not. >>> >>>>> 3. Can we have another category to define UA/device reaction/behavior= ? >>>> I don't understand what you mean. >>> >>> When we use IM Clients - and someone knocks you - IMs can directly pop = up an window with message. Or IM can display a notification that "Mr. X is = inviting you for a conversation". So for the same request - the handling of= the UA is different. In many case this is set from the UA itself. >>> >>> Or, if we allow the behaviors like display Customized Picture decided b= y Caller, Or Play Ringtone (decided by caller) this type of features then I= think this additional category will help. >>> >>> I am not sure if I could make myself clear or I am completely sounding = irrelevant. If I am please do point that out. >>> >>> Thanks& =C2=A0Regards >>> >>> Jewel >>> >>> -----Original Message----- >>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf = Of Paul Kyzivat >>> Sent: Saturday, January 21, 2012 10:54 AM >>> To: salud@ietf.org >>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs = and Priority Rules >>> >>> On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote: >>>> Hi >>>> >>>> It will be very nice if you please can refer the discussion date or th= read of the multiple value discussion. I am not able to find it. >>> >>> I don't know offhand. The proposal was made by Dale Worley, so look fro= m >>> mails from him. It was several months ago, perhaps more than a year. >>> >>>> However, there are couple of things I wanted to highlight in my first = mail. >>>> >>>> 1. URN string format - bundling multiple values (on which I may be wro= ng as this is already discussed and decided - I will go through the earlier= mails from the archive to clarify my understanding) >>> >>> Already decided - above discussion. >>> >>>> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 >>> >>> Keep in mind that the point of this is to guide the rendering of alerts >>> to a user. I find it hard to believe that the user will distinguish 10 >>> or 100 different alert variations based on priority. >>> >>> There is already a sip Priority header to indicate the priority of the >>> message itself. >>> >>>> 3. Can we have another category to define UA/device reaction/behavior? >>> >>> I don't understand what you mean. >>> >>>> Particularly for 2 and 3 the reason I am proposing this is >>>> >>>> 1. Alert-Info can be present in INVITE and if it is present in Invite = then it will be nice to have a mechanism to guide/standardize the handling = process/logic of the Alert-Info for the devices receiving Alert-Info >>> >>> That is already provided. >>> >>>> 2. As we have multiple URN and URNs defining the service, source, prio= rity etc. I assume the priority is the priority for the session/call. If we= implement priority as a number then sorting on the priority number for cur= rently ongoing sessions can be done at the device side - and logics can be = implemented like force disconnect for higher priority calls, do not notify = for lower priority calls, notify back the user for certain priority calls, = divert if priority is less than some specific values. And we can leave it u= p to the implementation. >>> >>> See above. >>> >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Thanks, >>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Paul >>> >>>> With these features I think we will be able to standardize the impleme= ntation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by = caller, Call Back Notification Services (where caller will be notified when= ever the line is free), Handling of Promotional/Low Priority Calls (Voice o= r Message/SMS Broadcasts) etc. >>>> >>>> Thanks& =C2=A0 =C2=A0Regards >>>> >>>> JEWEL >>>> Firoze M Zahidur Rahman >>>> F =C2=A0+88 017 13014806, +6 013 6349764 >>>> 3 +88 02 9882314, +6 03 90581043 >>>> >>>> >>>> -----Original Message----- >>>> From: salud-bounces@ietf.org [mailto:salud-bounces@ietf.org] On Behalf= Of Paul Kyzivat >>>> Sent: Saturday, January 21, 2012 1:50 AM >>>> To: salud@ietf.org >>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs= and Priority Rules >>>> >>>> On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: >>>>> Hi >>>>> >>>>> Its not really usage of lesser no of bytes, the overall idea was to a= ccommodate multiple values in the same URN. As this extension enables UA or= devices to choose/implement features as per internal implementation logic = - my idea was to make the structure as - all values in single line. So that= while implementing device will not have to think about same category multi= ple times. Even if same category multiple times is allowed - it will comple= tely refresh/overrule earlier appearance. >>>>> >>>>> And the order of appearance wise priority (I think corrent approach i= s also same, priority is decided by order of appearance of URN in header fi= eld) also handles the priority decision making process unchanged. >>>>> >>>>> Instead of comma(,) we can use dot(.) or slash(/) separated values ma= y be. Or we can find some other way to make it URI compatible. But that can= be though/found out if everyone thinks that bundling all values of a categ= ory in single URN makes sense. >>>> >>>> If you look through the salud mail archives you will see that combinin= g >>>> things into a single URN was proposed and discussed, but we settled on >>>> what we have now. >>>> >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, >>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul >>>> >>>>> Thanks& =C2=A0 =C2=A0 Best Regards >>>>> >>>>> Jewel >>>>> >>>>> ________________________________________ >>>>> From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Pa= ul Kyzivat [pkyzivat@alum.mit.edu] >>>>> Sent: Friday, January 20, 2012 11:43 PM >>>>> To: salud@ietf.org >>>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URN= s and Priority Rules >>>>> >>>>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote: >>>>>> Hi >>>>>> >>>>>> Greetings! >>>>>> >>>>>> I am very new to this area. Advance apologies if my ideas sounds com= pletely misaligned. >>>>>> >>>>>> I found current way of using multiple Alert-Info URNs and Priority R= ules a bit difficult to use and implement. I can see that we have 6 fixed a= lert-categories and the Alert URN Format is >>>>>> >>>>>> "URN:alert:" alert-identifier >>>>>> >>>>>> And format of alert-identifier is >>>>>> >>>>>> alert-category ":" alert-indication >>>>>> >>>>>> and alert-indication is a single value. >>>>>> >>>>>> If we can allow to include multiple value in alert-indication separa= ted by comma (,) and the order of appearance will decide the order of prior= ity for the alert-indication value then I think it will be easy to implemen= t from the device side. >>>>>> >>>>>> So instead of sending multiple URN like >>>>>> URN:alert:source:family >>>>>> URN:alert:source:friend >>>>>> URN:alert:source:internal >>>>>> URN:alert:source:unclassified >>>>>> >>>>>> device will send URN as >>>>>> >>>>>> URN:alert:source:family,friend,internal,unclassified >>>>> >>>>> In the above you have not included the header. It would really be: >>>>> >>>>> Alert-Info: URN:alert:source:family >>>>> Alert-Info: URN:alert:source:friend >>>>> Alert-Info: URN:alert:source:internal >>>>> Alert-Info: URN:alert:source:unclassified >>>>> >>>>> and your preference would seem to be: >>>>> >>>>> Alert-Info: URN:alert:source:family,friend,internal,unclassified >>>>> >>>>> But the latter cannot work. The key point is that Alert-Info takes UR= Is >>>>> as arguments (including URNs), which can be separated by commas or as >>>>> separate header fields. Because of that, in your latter case, "friend= " >>>>> is syntactically incorrect because it is not a URI. >>>>> >>>>> Aside from that I don't understand why you think what you propose is >>>>> easier to use or implement. (I agree that is uses fewer bytes, but th= at >>>>> doesn't make it easier.) >>>>> >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Thanks, >>>>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Paul >>>>> >>>>> >>>>>> Besides, if we disallow or ignore (or latest appearance overrides ea= rlier) multiple appearance of alert-category then it will be more easier to= implement. >>>>>> >>>>>> >>>>>> I have another suggestion regarding the values of alert-category pri= ority. If we make it a number like 0, 1, 10 anything may be between 00 to 9= 9 or 0-9 to make it simple, then I think devices will have the provision to= prioritize 2 calls/sessions (in case of call waiting or line busy) easily = and devices will be able to implement specific logics for them. >>>>>> >>>>>> And if we can introduce another alert-category to guide the call/ses= sion handle behavoir according to service or priority for the devices e.g. = force connect on busy, notify back when free, delivery report (read, delive= red, not delivered etc) (as we are handing SIP sessions - the URNs should c= over IM and short messages as well may be). >>>>>> >>>>>> Thanks& =C2=A0 =C2=A0 =C2=A0Best Regards >>>>>> >>>>>> >>>>>> JEWEL >>>>>> Firoze M Zahidur Rahman >>>>>> >>>>>> _______________________________________________ >>>>>> salud mailing list >>>>>> salud@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/salud >>>>>> >>>>> >>>>> _______________________________________________ >>>>> salud mailing list >>>>> salud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/salud >>>>> _______________________________________________ >>>>> salud mailing list >>>>> salud@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/salud >>>>> >>>> >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> _______________________________________________ >>>> salud mailing list >>>> salud@ietf.org >>>> https://www.ietf.org/mailman/listinfo/salud >>>> >>> >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >>> _______________________________________________ >>> salud mailing list >>> salud@ietf.org >>> https://www.ietf.org/mailman/listinfo/salud >> _______________________________________________ >> salud mailing list >> salud@ietf.org >> https://www.ietf.org/mailman/listinfo/salud >> > > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud > _______________________________________________ > salud mailing list > salud@ietf.org > https://www.ietf.org/mailman/listinfo/salud From dworley@avaya.com Tue Jan 24 12:10:19 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 372F81F0C3F for ; Tue, 24 Jan 2012 12:10:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.732 X-Spam-Level: X-Spam-Status: No, score=-102.732 tagged_above=-999 required=5 tests=[AWL=-0.133, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7+YgzZgJiDf for ; Tue, 24 Jan 2012 12:10:17 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id 244C121F844F for ; Tue, 24 Jan 2012 12:10:17 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAKcPH0/GmAcF/2dsb2JhbABCrjWBBYFyAQEBAQMSKDQbAgEIDQQEAQEBHhAyHQMFAQEEEwgBGYdinHGbKIkEDgwIAgEZCAoDBYNkHIJQYwSIP5JWjHQ X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="228359446" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Jan 2012 15:10:09 -0500 Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2012 15:05:03 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Tue, 24 Jan 2012 15:10:08 -0500 From: "Worley, Dale R (Dale)" To: "salud@ietf.org" Date: Tue, 24 Jan 2012 15:07:39 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXrLQPUzsuxloqSjCf8r6dww4Y7wDJx6fu Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com>, <4F19C562.4050006@alum.mit.edu> In-Reply-To: <4F19C562.4050006@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:10:19 -0000 The mailing list archive of the most recent discussion of the "multiple URN vs. single URN" issue starts at=20 "Currently known technical issues" (http://www.ietf.org/mail-archive/web/salud/current/msg00131.html) in http://www.ietf.org/mail-archive/web/salud/current/maillist.html and continues through July 2011. Dale ________________________________________ From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Paul Kyz= ivat [pkyzivat@alum.mit.edu] Sent: Friday, January 20, 2012 2:49 PM To: salud@ietf.org Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and = Priority Rules On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote: > > Its not really usage of lesser no of bytes, the overall idea was to accom= modate multiple values in the same URN. [...] If you look through the salud mail archives you will see that combining things into a single URN was proposed and discussed, but we settled on what we have now. Thanks, Paul From dworley@avaya.com Tue Jan 24 12:20:14 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D96B21F84DA for ; Tue, 24 Jan 2012 12:20:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.218 X-Spam-Level: X-Spam-Status: No, score=-103.218 tagged_above=-999 required=5 tests=[AWL=0.381, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iAUnGRtMjQok for ; Tue, 24 Jan 2012 12:20:14 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id D22A121F84D7 for ; Tue, 24 Jan 2012 12:20:13 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EANYRH0+HCzI1/2dsb2JhbABCrjWBBYFyAQEBAQIBEihECwIBCA0IIRAyIAUBAQQBEggah1qcfpsoiRIMCAIBGQgKAwWDZIJsYwSIP5JWjHQ X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="287864745" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jan 2012 15:20:12 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Jan 2012 15:06:33 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 24 Jan 2012 15:20:11 -0500 From: "Worley, Dale R (Dale)" To: "Firoze M. Zahidur Rahman" , "salud@ietf.org" Date: Tue, 24 Jan 2012 15:20:11 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczXrBc+AW1uErBYR/u6KSMh12/tTQAR8g+QALgpKNY= Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu>, <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:20:14 -0000 [as individual] > From: Firoze M. Zahidur Rahman [jewel@ssd-tech.com] >=20 > However, there are couple of things I wanted to highlight in my first mai= l. >=20 > 1. URN string format - [...] >=20 > 2. Values of Priority Field - Can we use numbers 0-9 or 00-99 It would make sense to use numerical priority values. But it seems unlikely that there will be any practical difference between more than the 3 values that are now envisioned. > 3. Can we have another category to define UA/device reaction/behavior? This is definitely "out of scope" for the Salud working group -- the working group is only considering "how calls are alerted to the user". However, we intend that the URN design be easily extensible in many ways to accommodate the many alerting alternatives that various vendors already implement. So it is possible to define a vendor extension that is intended to control the callee UA behavior. And one can clearly construct a UA that changes how it handles a call based on the alerting URN. But standardizing that as a way for the caller to guide the behavior of the callee is out of scope for this working group. You may want to take this idea to the Dispatch working group. Dale From dworley@avaya.com Tue Jan 24 12:26:12 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C83E221F8532 for ; Tue, 24 Jan 2012 12:26:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.253 X-Spam-Level: X-Spam-Status: No, score=-103.253 tagged_above=-999 required=5 tests=[AWL=0.346, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X-ehlKxhO4DM for ; Tue, 24 Jan 2012 12:26:12 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id 181DA21F852D for ; Tue, 24 Jan 2012 12:26:11 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAA0TH0/GmAcF/2dsb2JhbABCrjWBBYFyAQEBAQIBEihECwIBCA0IIRAyIAUBAQQBEggah1qcfJsoiRIMCAIBGQgKAwIBAgGDYxyCUGMEiD+SVox0 X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="287865582" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Jan 2012 15:26:10 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2012 15:21:04 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Tue, 24 Jan 2012 15:26:09 -0500 From: "Worley, Dale R (Dale)" To: "Firoze M. Zahidur Rahman" , "salud@ietf.org" Date: Tue, 24 Jan 2012 15:21:23 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczX+BP5fQdikcK1TXKZP8jZcAE8gAAIrfzwAK68ej4= Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com>, <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu>, <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:26:12 -0000 > From: salud-bounces@ietf.org [salud-bounces@ietf.org] On Behalf Of Firoze= M. Zahidur Rahman [jewel@ssd-tech.com] >=20 > 2. Disconnect the ongoing call and establish the higher priority call You may want to look at the "resource priority" mechanism (RFC 4412) to see some of the machinery that SIP has for prioritizing calls. Dale From dworley@avaya.com Tue Jan 24 12:42:16 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E157321F85D7 for ; Tue, 24 Jan 2012 12:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.282 X-Spam-Level: X-Spam-Status: No, score=-104.282 tagged_above=-999 required=5 tests=[AWL=1.317, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8pGQPlZWhHR1 for ; Tue, 24 Jan 2012 12:42:16 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 92A8921F85D2 for ; Tue, 24 Jan 2012 12:42:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EABUWH0/GmAcF/2dsb2JhbABCDq4ngQWBcgEBAQECARIoRAsCAQgNCCEQMiAFAQEEARIIGodanHybKYkSDAgCARkICgODaYJsYwSIP5JWjB9V X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="326253865" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 24 Jan 2012 15:42:04 -0500 Received: from unknown (HELO DC-US1HCEX4.global.avaya.com) ([135.11.52.35]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2012 15:36:57 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX4.global.avaya.com ([135.11.52.35]) with mapi; Tue, 24 Jan 2012 15:42:03 -0500 From: "Worley, Dale R (Dale)" To: "Firoze M. Zahidur Rahman" , Paul Kyzivat , "salud@ietf.org" Date: Tue, 24 Jan 2012 15:42:03 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczZ588oqWd5QIPXT7eEfg0ObivNTAAWn8pAACUubn0= Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <4F1A44E0.3070708@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F47E@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F541@aries.ssd-tech.com> <4F1D849A.4050608@alum.mit.edu>, <5783EF37C9CBA043B84517F864F8D0CE046605F546@aries.ssd-tech.com> In-Reply-To: <5783EF37C9CBA043B84517F864F8D0CE046605F546@aries.ssd-tech.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:42:17 -0000 [as individual] > From: Firoze M. Zahidur Rahman [jewel@ssd-tech.com] >=20 > >Do you seriously think that there would be separate forms of alerting > >for each of 10 or 100 different priority values? >=20 > There are different incidents when users will be required to be > notified in a SIP UA/Device e.g Incoming Voice Call Indicatin, IM > Request, Incoming Video Call Indication etc. For all these incidents I > think users will need different types of notification. The role of > priority will come into the picture when you already in a session and > another incident comes up e.g. You are in a voice call, another IM > invitation comes up, or another IM Request comes up, or may be 2 > incidents - one voice call is ringing and and another IM comes or > other way round. In such cases I think priority will be able to play a > role. >=20 > My proposal is primarily change the priority values to numbers instead > of high, normal and low. And we can also decide on a range of values > to be used without making it widely open to the implementers - may be > 10 or 100. It is true that there may be many different types of notifications, and the callee UA may want to prioritize them in a particular order. But it would be very difficult to have the *caller* specify the priority in a useful way, and we expect the caller, or a device acting on his behalf, may have provided the Alert-Info. Worse, we would not expect every caller creating a video call to use the *same* priority number when there are 100 values to choose from, so the callee could not use the priority that the caller specified to decide to handle the call as Incoming Video Call. There is some hope that callers will consistently chose from the set of three values, High, Normal, and Low. If the question is about a PBX inserting a URN into an incoming INVITE to control how one of *its* phones handles a call (rather than usage across the Internet), the PBX can insert an Alert-Info URN with an appropriate extension category and value. But that does not need to be standardized. > >However other usage is not well standardized. Presumably its clear that > >when a dereferencable URL is provided, then the intent was that it be > >rendered. But there are great impediments to that usage, and it isn't > >widely supported. And usage with non-dereferencable URIs was never defin= ed. >=20 > Shouldn't this RFC provide a guidance regarding this? As one of the > main target of this effort is to standardize the Alert > Notification. In theory, RFC 3261 defines using a URI to provide a source for the alerting signal, and in practice, nobody implements it because it is a security problem. The goal of this working group is to provide a set of standard *meanings* that each device can render as it chooses, along with extension mechanisms to allow specifying more detailed meanings, and indications of different ways to alert, without requiring fetching media via a URI. > Standardization of user alert notification on UA/Devices > are very much required (you can find so many option to set up the > notification/alert tones of smart phones to be set up and every vendor > implements it differently). Standardization of Alert Notifications > will enable a lot of content based services to be developed around > this. [Only the option of having 3 way call and opening up of Media > channel after ACM message of SS7 signaling enabled to develop services > like Personalized Ring Back Tone which is a very popular service in > many operators]. So if alert notifications can be standardized > properly this will open up a lot of service opportunities I think. Currently, a UA can provide "early media" that gives a customized ringback. Dale From dworley@avaya.com Tue Jan 24 12:47:36 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FBB121F8637 for ; Tue, 24 Jan 2012 12:47:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.883 X-Spam-Level: X-Spam-Status: No, score=-102.883 tagged_above=-999 required=5 tests=[AWL=-0.284, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MCdsQIOklcBH for ; Tue, 24 Jan 2012 12:47:35 -0800 (PST) Received: from p-us1-iereast-outbound.us1.avaya.com (p-us1-iereast-outbound.us1.avaya.com [135.11.29.13]) by ietfa.amsl.com (Postfix) with ESMTP id B0B3521F862D for ; Tue, 24 Jan 2012 12:47:35 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAMoXH0/GmAcF/2dsb2JhbABCrjWBBYFyAQEBAQIBEig/BQsCAQgNCCEQMiAFAQEEAQ0FCBqHWpx/myaJEgwIAgEZCAoDAgODZIJsYwSIP5JWjHQ X-IronPort-AV: E=Sophos;i="4.71,563,1320642000"; d="scan'208";a="228364957" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound.us1.avaya.com with ESMTP; 24 Jan 2012 15:47:34 -0500 Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 24 Jan 2012 15:42:28 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Tue, 24 Jan 2012 15:47:34 -0500 From: "Worley, Dale R (Dale)" To: Laura Liess , "Firoze M. Zahidur Rahman" Date: Tue, 24 Jan 2012 15:44:12 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczaneZq7yTwGwnMRxKWhSi8y0gaggAOwb1G Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com>, In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Jan 2012 20:47:36 -0000 [as individual] > From: Laura Liess [laura.liess.dt@googlemail.com] >=20 > However, it would make sense for me to consider your use case within > the priority rules in Section 7, because they are mandatory. We > eventually ( if the WG agrees to that) could add following at the end > of the text inside the brackets in the requirement b.: "(because it > does not recognize the URN or the URN's effect is precluded by > preceding URNs *** or not compatible with the current state of the > end device or explicitely not desired *** )" . (The new text is > between ***.) Would you agree to that? Yes, it makes sense to me that the selection of the alerting signal may be modified by the current state of the UA: it could change what indications it is able to provide, or which of two alternatives is more preferred. Dale From laura.liess.dt@googlemail.com Wed Jan 25 07:00:18 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9758121F86E3 for ; Wed, 25 Jan 2012 07:00:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SlZFXMJio1U1 for ; Wed, 25 Jan 2012 07:00:17 -0800 (PST) Received: from mail-wi0-f172.google.com (mail-wi0-f172.google.com [209.85.212.172]) by ietfa.amsl.com (Postfix) with ESMTP id EE85521F86EA for ; Wed, 25 Jan 2012 07:00:16 -0800 (PST) Received: by wibhn9 with SMTP id hn9so5084354wib.31 for ; Wed, 25 Jan 2012 07:00:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; bh=ht+Ovy9KGuDx6ac/WK9iPAuJmNNn9esmhq/cDCGJgOA=; b=uCqInZo1BVv0YTG3QapSHocKg7A3ku5Ag5qvS7AABHwHwR7SFYaUNwlqUebH21dzwn +vMjA1H+7UOaTW0bCYuSpcVefiCOJQel4agrFV2mbXrbHSNI8WHAoTyoEqzNWzXLZzKt 6p24AZUzvuRt0vPITR3kULXHFAmpL6IN1cRu8= MIME-Version: 1.0 Received: by 10.180.106.202 with SMTP id gw10mr14723585wib.3.1327503615812; Wed, 25 Jan 2012 07:00:15 -0800 (PST) Received: by 10.227.23.197 with HTTP; Wed, 25 Jan 2012 07:00:15 -0800 (PST) In-Reply-To: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com> Date: Wed, 25 Jan 2012 16:00:15 +0100 Message-ID: From: Laura Liess To: "Worley, Dale R (Dale)" , "Firoze M. Zahidur Rahman" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 15:00:18 -0000 2012/1/24 Worley, Dale R (Dale) : > [as individual] > >> From: Laura Liess [laura.liess.dt@googlemail.com] >> >> However, it would make sense for me to consider your use case within >> the priority rules in Section 7, because they are mandatory. We >> eventually ( if the WG agrees to that) could add following at the end >> of the text inside the brackets in the requirement b.: "(because it >> does not recognize the URN or the URN's effect is precluded by >> preceding URNs =C2=A0 *** or not compatible with the current state of th= e >> end device or explicitely not desired *** =C2=A0)" . (The new text is >> between ***.) Would you agree to that? > > Yes, it makes sense to me that the selection of the alerting signal > may be modified by the current state of the UA: =C2=A0it could change wha= t > indications it is able to provide, or which of two alternatives is > more preferred. Should we add this text as an additional separate requirement instead of the previously proposed text in the requirement b. within the brackets? Laura > > Dale From dworley@avaya.com Wed Jan 25 14:45:07 2012 Return-Path: X-Original-To: salud@ietfa.amsl.com Delivered-To: salud@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E416411E80D8 for ; Wed, 25 Jan 2012 14:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.345 X-Spam-Level: X-Spam-Status: No, score=-103.345 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E2qU-1R2jtnB for ; Wed, 25 Jan 2012 14:45:07 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 625A411E807A for ; Wed, 25 Jan 2012 14:45:07 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAG+FIE/GmAcF/2dsb2JhbABCrkWBBYFyAQEBAQIBEig/BQsCAQgNCCEQMiAFAQEEAQ0FCBqHWpxNm0eJFwwIAgEZCAoDAgECAYNjgmxjBIg/kliMdg X-IronPort-AV: E=Sophos;i="4.71,570,1320642000"; d="scan'208";a="326516731" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 25 Jan 2012 17:44:59 -0500 Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 25 Jan 2012 17:39:48 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.137]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 25 Jan 2012 17:44:58 -0500 From: "Worley, Dale R (Dale)" To: Laura Liess , "Firoze M. Zahidur Rahman" Date: Wed, 25 Jan 2012 17:42:29 -0500 Thread-Topic: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules Thread-Index: AczbchAW9q3l7AFmQ3SUiXUMStJOSAAQI3Ts Message-ID: References: <5783EF37C9CBA043B84517F864F8D0CE046605F46C@aries.ssd-tech.com> <4F198B8B.5040008@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE04660EF118@aries.ssd-tech.com> <4F19C562.4050006@alum.mit.edu> <5783EF37C9CBA043B84517F864F8D0CE046605F470@aries.ssd-tech.com> <5783EF37C9CBA043B84517F864F8D0CE046605F540@aries.ssd-tech.com> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "salud@ietf.org" Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules X-BeenThere: salud@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Sip ALerting for User Devices working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jan 2012 22:45:08 -0000 > From: Laura Liess [laura.liess.dt@googlemail.com] >=20 > Should we add this text as an additional separate requirement instead > of the previously proposed text in the requirement b. within the > brackets? I've got to go over the draft again and remember what I was going to suggest before I can suggest where I think this change should go. Dale Laura > > Dale