From L.Liess@telekom.de Mon Aug 3 06:33:33 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CF7A28C176 for ; Mon, 3 Aug 2009 06:33:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PbUnpz7gP3ri for ; Mon, 3 Aug 2009 06:33:32 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 6871D28C1AB for ; Mon, 3 Aug 2009 06:33:31 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 03 Aug 2009 15:33:02 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 15:33:01 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-MIMEOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 3 Aug 2009 15:32:56 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9AALA5p8AAEuvxAAMDEaxA= References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> From: To: X-OriginalArrivalTime: 03 Aug 2009 13:33:01.0699 (UTC) FILETIME=[EC364D30:01CA143E] Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 13:33:33 -0000 John, I agree with you. Maybe we should add some new text with = recommendations about how new alert-identifiers should/ should not be = defined. E.g. we could insert following text at the end of chapter 7.1: = "When defining new alert-identifiers, names that reflect the meaning, = rather than the representation of a tone should be used. " What do you = think?=20 Laura > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, July 30, 2009 3:49 PM > To: Liess, Laura; audet@nortel.com; adam@nostrum.com; bliss@ietf.org > Subject: RE: [BLISS] Initial=20 > ringtonesfordraft-alexeitsev-bliss-alert-info-urns >=20 > We should at least try to avoid having two or more URNs with=20 > the same semantics, coming from different countries.=20 > Furthermore, we should try to register names that reflect the=20 > meaning, rather than the representation, of a tone, so that=20 > it can be rendered in the appropriate way for the locale=20 > concerned. For example "internal.short-short-short" tells me=20 > nothing about the meaning (other than that it is internal).=20 > If it is intended to denote three short bursts of tone, this=20 > could convey different meanings (or confusion) to a user=20 > outside the locale where it originated. >=20 > John >=20 > > -----Original Message----- > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > On Behalf Of L.Liess@telekom.de > > Sent: 30 July 2009 10:26 > > To: audet@nortel.com; adam@nostrum.com; bliss@ietf.org > > Subject: Re: [BLISS] Initial=20 > > ringtonesfordraft-alexeitsev-bliss-alert-info-urns > >=20 > >=20 > > Francois, > >=20 > > They would have to use the alredy registered alert urn=20 > > template and to register new alert-URN indications for "tone"=20 > > or "service" , e.g. internal.short-short-short. It's a=20 > > similar process as for the Emergency Service URN (5031).=20 > >=20 > > My personal opinion is that many of the tones defined in=20 > > national documents will be not longer used when PSTN moves to VoIP.=20 > >=20 > > Regards > > Laura > >=20 > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com]=20 > > > Sent: Wednesday, July 29, 2009 1:50 PM > > > To: Liess, Laura; adam@nostrum.com; bliss@ietf.org > > > Subject: RE: [BLISS] Initial ringtones=20 > > > fordraft-alexeitsev-bliss-alert-info-urns > > >=20 > > > It seems to me that if a specific national body requires the use > > > of national-specific ringback tones, they would then have=20 > > to register > > > their own URN space for it. > > >=20 > > > Hopefully we wouldn't go that route, but the option is=20 > definitively > > > there if required.=20 > > >=20 > > > > -----Original Message----- > > > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > > > On Behalf Of L.Liess@telekom.de > > > > Sent: Tuesday, July 28, 2009 08:59 > > > > To: adam@nostrum.com; bliss@ietf.org > > > > Subject: Re: [BLISS] Initial ringtones=20 > > > > fordraft-alexeitsev-bliss-alert-info-urns > > > >=20 > > > > Adam, > > > >=20 > > > > The intent of the draft is to provide a general mechanism, to=20 > > > > register the template and to do initial registration for=20 > > > > tones and service tones which we know that people intend to=20 > > > > use now and have interoperability problems. I don't think we=20 > > > > should now register every tone in every national=20 > > > > specification, which possible nobbody intends to use. =20 > > > > If, over time, people need additional tones or service tones,=20 > > > > they can use the general mechanism and template are free to=20 > > > > register their own tones. =20 > > > >=20 > > > > Or do you see a problem with this approach? > > > >=20 > > > > Thanks a lot > > > > Laura > > > >=20 > > > >=20 > > > > Mit freundlichen Gr=FC=DFen > > > > Laura Liess > > > >=20 > > > > Deutsche Telekom Netzproduktion GmbH > > > > Zentrum Technik Einf=FChrung > > > > Laura Liess > > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > > > +49 6151 628-2761 (Tel.) > > > > +49 6151 628-3395 (Fax) > > > > +49 175 2961015 (Mobil) > > > > l.liess@telekom.de (E-mail) > > > > http://www.telekom.com=20 > > > >=20 > > > > Deutsche Telekom Netzproduktion GmbH > > > > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > > > > Albert Matheis, Klaus Peren > > > > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > > > > Gesellschaft: Bonn > > > > USt-IdNr.: DE 814645262 > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: bliss-bounces@ietf.org=20 > > > > [mailto:bliss-bounces@ietf.org] On Behalf=20 > > > > > Of Adam Roach > > > > > Sent: Tuesday, July 28, 2009 2:30 PM > > > > > To: bliss@ietf.org > > > > > Subject: [BLISS] Initial ringtones for=20 > > > > > draft-alexeitsev-bliss-alert-info-urns > > > > >=20 > > > > > There are a number of additional tones that are=20 > probably worth=20 > > > > > considering as part of the initial set of symbols. If=20 > > you look at=20 > > > > > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone=20 > > > > > designations that are used in other standards. > > > > >=20 > > > > > A.S0014 defines: > > > > >=20 > > > > > 1. Normal Alerting > > > > > 2. Inter-group Alerting > > > > > 3. Special/Priority Alerting > > > > > 4. Ping Ring (abbreviated alert) > > > > > 5. Abbreviated intercept > > > > > 6. Abbreviated reorder > > > > >=20 > > > > > I think #1 and #4 are covered in the current document, but=20 > > > > the others=20 > > > > > aren't clearly represented. > > > > >=20 > > > > > If you throw in the TIA/EIA values, you also have things like: > > > > >=20 > > > > > 1. Long (Normal) > > > > > 2. Short-Short > > > > > 3. Short-Short-Long > > > > > 4. Short-Short2 > > > > > 5. Short-Long-Short > > > > > 6. Short-Short-Short-Short > > > > > 7. PBX Long (Normal) > > > > > 8. PBX Short-Short > > > > > 9. PBX Short-Short-Long > > > > > 10. PBX Short-Long-Short > > > > > 11. PBX Short-Short-Short-Short > > > > >=20 > > > > >=20 > > > > > Additionally, A.S0014 allows indication of pitch (high,=20 > > > > normal, low)=20 > > > > > as part of the ringtone designation. It would be nice if we=20 > > > > could tack=20 > > > > > this pitch data on to the end of the existing tokens (e.g.,=20 > > > > > "normal.short.low"). I note that this points to a=20 > combinatorial=20 > > > > > explosion of IANA values -- perhaps we need to re-think=20 > > how we're=20 > > > > > representing the registry. > > > > >=20 > > > > > /a > > > > >=20 > > > > > _______________________________________________ > > > > > BLISS mailing list > > > > > BLISS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bliss > > > > >=20 > > > > _______________________________________________ > > > > BLISS mailing list > > > > BLISS@ietf.org > > > > https://www.ietf.org/mailman/listinfo/bliss > > > >=20 > > >=20 > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 >=20 From adam@nostrum.com Mon Aug 3 08:41:30 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE3613A6E48 for ; Mon, 3 Aug 2009 08:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1 X-Spam-Level: * X-Spam-Status: No, score=1 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4UCw-NQZF7j2 for ; Mon, 3 Aug 2009 08:41:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EB4963A6E18 for ; Mon, 3 Aug 2009 08:41:28 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n73FfTco040747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 10:41:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A770529.9000600@nostrum.com> Date: Mon, 03 Aug 2009 10:41:29 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: L.Liess@telekom.de References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtones for draft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 15:41:30 -0000 L.Liess@telekom.de wrote: > The intent of the draft is to provide a general mechanism, to register the template and to do initial registration for tones and service tones which we know that people intend to use now and have interoperability problems. I don't think we should now register every tone in every national specification, which possible nobbody intends to use. > If, over time, people need additional tones or service tones, they can use the general mechanism and template are free to register their own tones. > > Or do you see a problem with this approach? > I'm okay with that for the specific ringtone names (with the caveats raised by John Elwell about not wanting two strings that effectively have the same semantic meaning). However, I think this is of considerably more importance: >> Additionally, A.S0014 allows indication of pitch (high, >> normal, low) as >> part of the ringtone designation. It would be nice if we >> could tack this >> pitch data on to the end of the existing tokens (e.g., >> "normal.short.low"). I note that this points to a combinatorial >> explosion of IANA values -- perhaps we need to re-think how we're >> representing the registry. >> I'll reiterate that the registry can become very, very full if we continue down this path. I would strongly suggest that you instead consider a scheme that defines discrete tokens, and then talks about how they can be combined. For example, instead of registering: 1. normal 2. normal.priority 3. normal.short 4. normal.delayed 5. internal 6. internal.priority 7. internal.short 8. internal.delayed 9. external 10. external.priority 11. external.short 12. external.delayed I think you should register: 1. normal 2. internal 3. external 4. priority 5. short 6. delayed And then define rules about how these can be stacked. In particular, one of the first things I'd be likely to try to add to the registry would be the pitch designations of A.S0014, but I don't think we *really* want a registry that looks like this: 1. normal 2. normal.high 3. normal.medium 4. normal.low 5. normal.priority 6. normal.priority.high 7. normal.priority.medium 8. normal.priority.low 9. normal.short 10. normal.short.high 11. normal.short.medium 12. normal.short.low 13. normal.delayed 14. normal.delayed.high 15. normal.delayed.medium 16. normal.delayed.low 17. internal 18. internal.high 19. internal.medium 20. internal.low 21. internal.priority 22. internal.priority.high 23. internal.priority.medium 24. internal.priority.low 25. internal.short 26. internal.short.high 27. internal.short.medium 28. internal.short.low 29. internal.delayed 30. internal.delayed.high 31. internal.delayed.medium 32. internal.delayed.low 33. external 34. external.high 35. external.medium 36. external.low 37. external.priority 38. external.priority.high 39. external.priority.medium 40. external.priority.low 41. external.short 42. external.short.high 43. external.short.medium 44. external.short.low 45. external.delayed 46. external.delayed.high 47. external.delayed.medium 48. external.delayed.low And that's just with the three pitches that I want to add. If someone adds another semantic dimension, the size of the registry continues to grow exponentially. /a From pkyzivat@cisco.com Mon Aug 3 10:45:07 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 12B283A6E65 for ; Mon, 3 Aug 2009 10:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSjZc94j0Lpt for ; Mon, 3 Aug 2009 10:45:05 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3535728C21B for ; Mon, 3 Aug 2009 10:44:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPu+dkpAZnme/2dsb2JhbAC8LogpjlAFhBiBTw X-IronPort-AV: E=Sophos;i="4.43,315,1246838400"; d="scan'208";a="52723423" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 03 Aug 2009 17:44:05 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n73Hi5cN028759; Mon, 3 Aug 2009 13:44:05 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n73Hi5GQ008145; Mon, 3 Aug 2009 17:44:05 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:44:04 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 3 Aug 2009 13:44:04 -0400 Message-ID: <4A7721E4.7040709@cisco.com> Date: Mon, 03 Aug 2009 13:44:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: L.Liess@telekom.de References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 03 Aug 2009 17:44:04.0392 (UTC) FILETIME=[FE46DA80:01CA1461] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8825; t=1249321445; x=1250185445; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[BLISS]=20Initial=09ringtonesfordraft-a lexeitsev-bliss-alert-info-urns |Sender:=20 |To:=20L.Liess@telekom.de; bh=Beve6RJkYtTXu1j4LR92TyofdtkooiVX+0ic6H5Wkts=; b=KmEHhjMU05M0PbJJf5k7uQSNkHWa/bppnfDogafn3vLv4ILe2u7QhR0xwA vaezMKjcOUoa8Gt6F4yF7UO0XaMI+LFCdRxbJWySqJShHf/b/Y03Zbd1mfgV HnwCs1IbEL; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 17:45:07 -0000 When I first started talking about using URNs for this (some years ago), I expected that there might be URNs that were defined by their semantics, without regard to how rendered, and others that were associated with a particular rendering - to some degree of fidelity. In general I would prefer to see the representation at least start out using a URN that defines a semantic. It could then perhaps be translated into one more related to form in cases where there is compelling reason to do so. Ideally that translation would be as late as possible. This becomes especially important as we get devices with more diverse rendering capabilities than was the case in the early days of telephony. The obvious use case is the widespread use of custom ring tones. These are typically selected near or at the callee, not by the caller. How should the use of custom ring tones by the callee be rationalized against an Alert-Info URN supplied by the caller? Ideally, if the Alert-Info includes the URN for the "normal ring tone", then the callee should feel comfortable in using its configured choice for ring tone. If the incoming Alert-Info contains something else, it will take more policy to decide what to render. Customized alerts get especially important if the UAS is for a deaf person. Then vibrators or lights are more likely to be used. Similarly, custom rendering of ringbacks are also important in such cases. Understanding the semantics is especially important is such cases, because a definition that is directly in terms of the audio rendering isn't useful if you aren't rendering it using audio. Semantic alerts are also helpful when the device has a video display, since then it gets easier to display something meaningful. Thanks, Paul L.Liess@telekom.de wrote: > John, > > I agree with you. Maybe we should add some new text with recommendations about how new alert-identifiers should/ should not be defined. E.g. we could insert following text at the end of chapter 7.1: "When defining new alert-identifiers, names that reflect the meaning, rather than the representation of a tone should be used. " What do you think? > > Laura > >> -----Original Message----- >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >> Sent: Thursday, July 30, 2009 3:49 PM >> To: Liess, Laura; audet@nortel.com; adam@nostrum.com; bliss@ietf.org >> Subject: RE: [BLISS] Initial >> ringtonesfordraft-alexeitsev-bliss-alert-info-urns >> >> We should at least try to avoid having two or more URNs with >> the same semantics, coming from different countries. >> Furthermore, we should try to register names that reflect the >> meaning, rather than the representation, of a tone, so that >> it can be rendered in the appropriate way for the locale >> concerned. For example "internal.short-short-short" tells me >> nothing about the meaning (other than that it is internal). >> If it is intended to denote three short bursts of tone, this >> could convey different meanings (or confusion) to a user >> outside the locale where it originated. >> >> John >> >>> -----Original Message----- >>> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >>> On Behalf Of L.Liess@telekom.de >>> Sent: 30 July 2009 10:26 >>> To: audet@nortel.com; adam@nostrum.com; bliss@ietf.org >>> Subject: Re: [BLISS] Initial >>> ringtonesfordraft-alexeitsev-bliss-alert-info-urns >>> >>> >>> Francois, >>> >>> They would have to use the alredy registered alert urn >>> template and to register new alert-URN indications for "tone" >>> or "service" , e.g. internal.short-short-short. It's a >>> similar process as for the Emergency Service URN (5031). >>> >>> My personal opinion is that many of the tones defined in >>> national documents will be not longer used when PSTN moves to VoIP. >>> >>> Regards >>> Laura >>> >>> >>> >>> >>>> -----Original Message----- >>>> From: Francois Audet [mailto:audet@nortel.com] >>>> Sent: Wednesday, July 29, 2009 1:50 PM >>>> To: Liess, Laura; adam@nostrum.com; bliss@ietf.org >>>> Subject: RE: [BLISS] Initial ringtones >>>> fordraft-alexeitsev-bliss-alert-info-urns >>>> >>>> It seems to me that if a specific national body requires the use >>>> of national-specific ringback tones, they would then have >>> to register >>>> their own URN space for it. >>>> >>>> Hopefully we wouldn't go that route, but the option is >> definitively >>>> there if required. >>>> >>>>> -----Original Message----- >>>>> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org] >>>>> On Behalf Of L.Liess@telekom.de >>>>> Sent: Tuesday, July 28, 2009 08:59 >>>>> To: adam@nostrum.com; bliss@ietf.org >>>>> Subject: Re: [BLISS] Initial ringtones >>>>> fordraft-alexeitsev-bliss-alert-info-urns >>>>> >>>>> Adam, >>>>> >>>>> The intent of the draft is to provide a general mechanism, to >>>>> register the template and to do initial registration for >>>>> tones and service tones which we know that people intend to >>>>> use now and have interoperability problems. I don't think we >>>>> should now register every tone in every national >>>>> specification, which possible nobbody intends to use. >>>>> If, over time, people need additional tones or service tones, >>>>> they can use the general mechanism and template are free to >>>>> register their own tones. >>>>> >>>>> Or do you see a problem with this approach? >>>>> >>>>> Thanks a lot >>>>> Laura >>>>> >>>>> >>>>> Mit freundlichen Grüßen >>>>> Laura Liess >>>>> >>>>> Deutsche Telekom Netzproduktion GmbH >>>>> Zentrum Technik Einführung >>>>> Laura Liess >>>>> Heinrich-Hertz-Straße 3-7, 64295 Darmstadt >>>>> +49 6151 628-2761 (Tel.) >>>>> +49 6151 628-3395 (Fax) >>>>> +49 175 2961015 (Mobil) >>>>> l.liess@telekom.de (E-mail) >>>>> http://www.telekom.com >>>>> >>>>> Deutsche Telekom Netzproduktion GmbH >>>>> Aufsichtsrat: Timotheus Höttges (Vorsitzender) >>>>> Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), >>>>> Albert Matheis, Klaus Peren >>>>> Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der >>>>> Gesellschaft: Bonn >>>>> USt-IdNr.: DE 814645262 >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: bliss-bounces@ietf.org >>>>> [mailto:bliss-bounces@ietf.org] On Behalf >>>>>> Of Adam Roach >>>>>> Sent: Tuesday, July 28, 2009 2:30 PM >>>>>> To: bliss@ietf.org >>>>>> Subject: [BLISS] Initial ringtones for >>>>>> draft-alexeitsev-bliss-alert-info-urns >>>>>> >>>>>> There are a number of additional tones that are >> probably worth >>>>>> considering as part of the initial set of symbols. If >>> you look at >>>>>> TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone >>>>>> designations that are used in other standards. >>>>>> >>>>>> A.S0014 defines: >>>>>> >>>>>> 1. Normal Alerting >>>>>> 2. Inter-group Alerting >>>>>> 3. Special/Priority Alerting >>>>>> 4. Ping Ring (abbreviated alert) >>>>>> 5. Abbreviated intercept >>>>>> 6. Abbreviated reorder >>>>>> >>>>>> I think #1 and #4 are covered in the current document, but >>>>> the others >>>>>> aren't clearly represented. >>>>>> >>>>>> If you throw in the TIA/EIA values, you also have things like: >>>>>> >>>>>> 1. Long (Normal) >>>>>> 2. Short-Short >>>>>> 3. Short-Short-Long >>>>>> 4. Short-Short2 >>>>>> 5. Short-Long-Short >>>>>> 6. Short-Short-Short-Short >>>>>> 7. PBX Long (Normal) >>>>>> 8. PBX Short-Short >>>>>> 9. PBX Short-Short-Long >>>>>> 10. PBX Short-Long-Short >>>>>> 11. PBX Short-Short-Short-Short >>>>>> >>>>>> >>>>>> Additionally, A.S0014 allows indication of pitch (high, >>>>> normal, low) >>>>>> as part of the ringtone designation. It would be nice if we >>>>> could tack >>>>>> this pitch data on to the end of the existing tokens (e.g., >>>>>> "normal.short.low"). I note that this points to a >> combinatorial >>>>>> explosion of IANA values -- perhaps we need to re-think >>> how we're >>>>>> representing the registry. >>>>>> >>>>>> /a >>>>>> >>>>>> _______________________________________________ >>>>>> BLISS mailing list >>>>>> BLISS@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/bliss >>>>>> >>>>> _______________________________________________ >>>>> BLISS mailing list >>>>> BLISS@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/bliss >>>>> >>> _______________________________________________ >>> BLISS mailing list >>> BLISS@ietf.org >>> https://www.ietf.org/mailman/listinfo/bliss >>> > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss > From adam@nostrum.com Mon Aug 3 13:59:39 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8F3B13A687F; Mon, 3 Aug 2009 13:59:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JPza3yn-bgis; Mon, 3 Aug 2009 13:59:38 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 790CA28C282; Mon, 3 Aug 2009 13:59:23 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n73KxNSK065784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 3 Aug 2009 15:59:23 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A774FAB.6010200@nostrum.com> Date: Mon, 03 Aug 2009 15:59:23 -0500 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: IETF RAI Dispatch , BLISS WG , HTTP working group Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [BLISS] New SIP HTTP Subscription Package Mailing List X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIP HTTP Event Package List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2009 20:59:39 -0000 We have established a new mailing list to discuss a new SIP event package for subscribing to the state of an HTTP resource. See for a current proposal. The list is intended to focus on closing technical issues in the document. It is currently left open whether the document will be published as an individual document or become part of a working group's chartered work. If you are interested in participating, please subscribe at: https://www.ietf.org/mailman/listinfo/sip-http-events /a From john.elwell@siemens-enterprise.com Tue Aug 4 02:00:40 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 703FA3A6ED6 for ; Tue, 4 Aug 2009 02:00:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qXEkN2u1dEFY for ; Tue, 4 Aug 2009 02:00:39 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9C18628C2FC for ; Tue, 4 Aug 2009 02:00:38 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNU0070KGTANG@siemenscomms.co.uk> for bliss@ietf.org; Tue, 04 Aug 2009 09:55:58 +0100 (BST) Date: Tue, 04 Aug 2009 09:56:01 +0100 From: "Elwell, John" In-reply-to: <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> To: L.Liess@telekom.de Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002393660@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9AALA5p8AAEuvxAAMDEaxAANZRbcA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 09:00:40 -0000 Laura, I am not sure that a simple statement as you suggest would be = sufficient. I just read the IANA Considerations section again, and I = have some comments: 1. Perhaps it is just a nit, but there seems to be some confusion = concerning terminology. I understand that an alert-identifier comprises = an alert-category followed by an alert-indication. Bu then in 7.1 I see: = "Alert URNs identifiers and alert-indications are identified by labels managed by IANA" Should it not be "Alert-categories and alert-indications ..."? Also sometimes alert-category is used, and sometimes alert-indication = category. 2. In 7.1 it states: " The policy for assigning labels to alert-indications may differ for each alert-identifier category and MUST be defined by the document describing the corresponding alert-identifier." This does not make sense. If different documents specify different = alert-identifiers belonging to the same category, they would all specify = the policy for assigning alert-indications to that category, leading to = possible conflict. Should policy not be defined in the document = specifying the category? 3. As a result of the previous comment, I believe the present document = should define policies for categories 'tone' and 'service', but I failed = to find such statements. This brings me back to my original concern. I = think we need a policy that requires at least expert review, in order to = avoid the sort of situation where an identifier is defined without clear = semantics or duplicating other identifiers in the registry. John > -----Original Message----- > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: 03 August 2009 14:33 > To: Elwell, John > Cc: bliss@ietf.org; alan@sipstation.com; audet@nortel.com;=20 > adam@nostrum.com > Subject: RE: [BLISS] Initial=20 > ringtonesfordraft-alexeitsev-bliss-alert-info-urns >=20 >=20 > John, >=20 > I agree with you. Maybe we should add some new text with=20 > recommendations about how new alert-identifiers should/=20 > should not be defined. E.g. we could insert following text=20 > at the end of chapter 7.1: "When defining new=20 > alert-identifiers, names that reflect the meaning, rather=20 > than the representation of a tone should be used. " What do=20 > you think?=20 >=20 > Laura >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Thursday, July 30, 2009 3:49 PM > > To: Liess, Laura; audet@nortel.com; adam@nostrum.com; bliss@ietf.org > > Subject: RE: [BLISS] Initial=20 > > ringtonesfordraft-alexeitsev-bliss-alert-info-urns > >=20 > > We should at least try to avoid having two or more URNs with=20 > > the same semantics, coming from different countries.=20 > > Furthermore, we should try to register names that reflect the=20 > > meaning, rather than the representation, of a tone, so that=20 > > it can be rendered in the appropriate way for the locale=20 > > concerned. For example "internal.short-short-short" tells me=20 > > nothing about the meaning (other than that it is internal).=20 > > If it is intended to denote three short bursts of tone, this=20 > > could convey different meanings (or confusion) to a user=20 > > outside the locale where it originated. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > > On Behalf Of L.Liess@telekom.de > > > Sent: 30 July 2009 10:26 > > > To: audet@nortel.com; adam@nostrum.com; bliss@ietf.org > > > Subject: Re: [BLISS] Initial=20 > > > ringtonesfordraft-alexeitsev-bliss-alert-info-urns > > >=20 > > >=20 > > > Francois, > > >=20 > > > They would have to use the alredy registered alert urn=20 > > > template and to register new alert-URN indications for "tone"=20 > > > or "service" , e.g. internal.short-short-short. It's a=20 > > > similar process as for the Emergency Service URN (5031).=20 > > >=20 > > > My personal opinion is that many of the tones defined in=20 > > > national documents will be not longer used when PSTN=20 > moves to VoIP.=20 > > >=20 > > > Regards > > > Laura > > >=20 > > >=20 > > >=20 > > >=20 > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com]=20 > > > > Sent: Wednesday, July 29, 2009 1:50 PM > > > > To: Liess, Laura; adam@nostrum.com; bliss@ietf.org > > > > Subject: RE: [BLISS] Initial ringtones=20 > > > > fordraft-alexeitsev-bliss-alert-info-urns > > > >=20 > > > > It seems to me that if a specific national body requires the use > > > > of national-specific ringback tones, they would then have=20 > > > to register > > > > their own URN space for it. > > > >=20 > > > > Hopefully we wouldn't go that route, but the option is=20 > > definitively > > > > there if required.=20 > > > >=20 > > > > > -----Original Message----- > > > > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > > > > On Behalf Of L.Liess@telekom.de > > > > > Sent: Tuesday, July 28, 2009 08:59 > > > > > To: adam@nostrum.com; bliss@ietf.org > > > > > Subject: Re: [BLISS] Initial ringtones=20 > > > > > fordraft-alexeitsev-bliss-alert-info-urns > > > > >=20 > > > > > Adam, > > > > >=20 > > > > > The intent of the draft is to provide a general mechanism, to=20 > > > > > register the template and to do initial registration for=20 > > > > > tones and service tones which we know that people intend to=20 > > > > > use now and have interoperability problems. I don't think we=20 > > > > > should now register every tone in every national=20 > > > > > specification, which possible nobbody intends to use. =20 > > > > > If, over time, people need additional tones or service tones,=20 > > > > > they can use the general mechanism and template are free to=20 > > > > > register their own tones. =20 > > > > >=20 > > > > > Or do you see a problem with this approach? > > > > >=20 > > > > > Thanks a lot > > > > > Laura > > > > >=20 > > > > >=20 > > > > > Mit freundlichen Gr=FC=DFen > > > > > Laura Liess > > > > >=20 > > > > > Deutsche Telekom Netzproduktion GmbH > > > > > Zentrum Technik Einf=FChrung > > > > > Laura Liess > > > > > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > > > > > +49 6151 628-2761 (Tel.) > > > > > +49 6151 628-3395 (Fax) > > > > > +49 175 2961015 (Mobil) > > > > > l.liess@telekom.de (E-mail) > > > > > http://www.telekom.com=20 > > > > >=20 > > > > > Deutsche Telekom Netzproduktion GmbH > > > > > Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > > > > > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), = > > > > > Albert Matheis, Klaus Peren > > > > > Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > > > > > Gesellschaft: Bonn > > > > > USt-IdNr.: DE 814645262 > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: bliss-bounces@ietf.org=20 > > > > > [mailto:bliss-bounces@ietf.org] On Behalf=20 > > > > > > Of Adam Roach > > > > > > Sent: Tuesday, July 28, 2009 2:30 PM > > > > > > To: bliss@ietf.org > > > > > > Subject: [BLISS] Initial ringtones for=20 > > > > > > draft-alexeitsev-bliss-alert-info-urns > > > > > >=20 > > > > > > There are a number of additional tones that are=20 > > probably worth=20 > > > > > > considering as part of the initial set of symbols. If=20 > > > you look at=20 > > > > > > TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a=20 > few tone=20 > > > > > > designations that are used in other standards. > > > > > >=20 > > > > > > A.S0014 defines: > > > > > >=20 > > > > > > 1. Normal Alerting > > > > > > 2. Inter-group Alerting > > > > > > 3. Special/Priority Alerting > > > > > > 4. Ping Ring (abbreviated alert) > > > > > > 5. Abbreviated intercept > > > > > > 6. Abbreviated reorder > > > > > >=20 > > > > > > I think #1 and #4 are covered in the current document, but=20 > > > > > the others=20 > > > > > > aren't clearly represented. > > > > > >=20 > > > > > > If you throw in the TIA/EIA values, you also have=20 > things like: > > > > > >=20 > > > > > > 1. Long (Normal) > > > > > > 2. Short-Short > > > > > > 3. Short-Short-Long > > > > > > 4. Short-Short2 > > > > > > 5. Short-Long-Short > > > > > > 6. Short-Short-Short-Short > > > > > > 7. PBX Long (Normal) > > > > > > 8. PBX Short-Short > > > > > > 9. PBX Short-Short-Long > > > > > > 10. PBX Short-Long-Short > > > > > > 11. PBX Short-Short-Short-Short > > > > > >=20 > > > > > >=20 > > > > > > Additionally, A.S0014 allows indication of pitch (high,=20 > > > > > normal, low)=20 > > > > > > as part of the ringtone designation. It would be nice if we=20 > > > > > could tack=20 > > > > > > this pitch data on to the end of the existing tokens (e.g.,=20 > > > > > > "normal.short.low"). I note that this points to a=20 > > combinatorial=20 > > > > > > explosion of IANA values -- perhaps we need to re-think=20 > > > how we're=20 > > > > > > representing the registry. > > > > > >=20 > > > > > > /a > > > > > >=20 > > > > > > _______________________________________________ > > > > > > BLISS mailing list > > > > > > BLISS@ietf.org > > > > > > https://www.ietf.org/mailman/listinfo/bliss > > > > > >=20 > > > > > _______________________________________________ > > > > > BLISS mailing list > > > > > BLISS@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/bliss > > > > >=20 > > > >=20 > > > _______________________________________________ > > > BLISS mailing list > > > BLISS@ietf.org > > > https://www.ietf.org/mailman/listinfo/bliss > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Tue Aug 4 02:02:55 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4ADC428C30B for ; Tue, 4 Aug 2009 02:02:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.787 X-Spam-Level: X-Spam-Status: No, score=-0.787 tagged_above=-999 required=5 tests=[AWL=-1.788, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vv9UfaMFHGtn for ; Tue, 4 Aug 2009 02:02:54 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1FAF828C30A for ; Tue, 4 Aug 2009 02:02:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KNU0079ZH3GNG@siemenscomms.co.uk> for bliss@ietf.org; Tue, 04 Aug 2009 10:02:04 +0100 (BST) Date: Tue, 04 Aug 2009 10:02:02 +0100 From: "Elwell, John" In-reply-to: <4A770529.9000600@nostrum.com> To: Adam Roach , L.Liess@telekom.de Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00239367B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoUUOg4lt0M3vv1SCyYSuKouQjymAAkLwfQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <4A770529.9000600@nostrum.com> Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 09:02:55 -0000 Adam, I am not necessarily disagreeing with this combinatorial approach, but I do have concerns about some of the examples. "Short" seems to stray into the territory of rendering rather than meaning. The "high", "medium", and "low" pitch designations certainly stray into that territory, and how would I render these on a visual, as opposed to audible, user interface? John > -----Original Message----- > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > On Behalf Of Adam Roach > Sent: 03 August 2009 16:41 > To: L.Liess@telekom.de > Cc: bliss@ietf.org > Subject: Re: [BLISS] Initial ringtones=20 > fordraft-alexeitsev-bliss-alert-info-urns >=20 > L.Liess@telekom.de wrote: > > The intent of the draft is to provide a general mechanism,=20 > to register the template and to do initial registration for=20 > tones and service tones which we know that people intend to=20 > use now and have interoperability problems. I don't think we=20 > should now register every tone in every national=20 > specification, which possible nobbody intends to use. =20 > > If, over time, people need additional tones or service=20 > tones, they can use the general mechanism and template are=20 > free to register their own tones. =20 > > > > Or do you see a problem with this approach? > > =20 >=20 > I'm okay with that for the specific ringtone names (with the caveats=20 > raised by John Elwell about not wanting two strings that effectively=20 > have the same semantic meaning). >=20 > However, I think this is of considerably more importance: >=20 > >> Additionally, A.S0014 allows indication of pitch (high,=20 > >> normal, low) as > >> part of the ringtone designation. It would be nice if we=20 > >> could tack this > >> pitch data on to the end of the existing tokens (e.g., > >> "normal.short.low"). I note that this points to a combinatorial > >> explosion of IANA values -- perhaps we need to re-think how we're > >> representing the registry. > >> =20 >=20 > I'll reiterate that the registry can become very, very full if we=20 > continue down this path. I would strongly suggest that you instead=20 > consider a scheme that defines discrete tokens, and then=20 > talks about how=20 > they can be combined. For example, instead of registering: >=20 > 1. normal > 2. normal.priority > 3. normal.short > 4. normal.delayed > 5. internal > 6. internal.priority > 7. internal.short > 8. internal.delayed > 9. external > 10. external.priority > 11. external.short > 12. external.delayed >=20 >=20 > I think you should register: >=20 > 1. normal > 2. internal > 3. external > 4. priority > 5. short > 6. delayed >=20 > And then define rules about how these can be stacked. In=20 > particular, one=20 > of the first things I'd be likely to try to add to the=20 > registry would be=20 > the pitch designations of A.S0014, but I don't think we=20 > *really* want a=20 > registry that looks like this: >=20 > 1. normal > 2. normal.high > 3. normal.medium > 4. normal.low > 5. normal.priority > 6. normal.priority.high > 7. normal.priority.medium > 8. normal.priority.low > 9. normal.short > 10. normal.short.high > 11. normal.short.medium > 12. normal.short.low > 13. normal.delayed > 14. normal.delayed.high > 15. normal.delayed.medium > 16. normal.delayed.low > 17. internal > 18. internal.high > 19. internal.medium > 20. internal.low > 21. internal.priority > 22. internal.priority.high > 23. internal.priority.medium > 24. internal.priority.low > 25. internal.short > 26. internal.short.high > 27. internal.short.medium > 28. internal.short.low > 29. internal.delayed > 30. internal.delayed.high > 31. internal.delayed.medium > 32. internal.delayed.low > 33. external > 34. external.high > 35. external.medium > 36. external.low > 37. external.priority > 38. external.priority.high > 39. external.priority.medium > 40. external.priority.low > 41. external.short > 42. external.short.high > 43. external.short.medium > 44. external.short.low > 45. external.delayed > 46. external.delayed.high > 47. external.delayed.medium > 48. external.delayed.low >=20 > And that's just with the three pitches that I want to add. If someone=20 > adds another semantic dimension, the size of the registry=20 > continues to=20 > grow exponentially. >=20 > /a > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20 From mmichelson@digium.com Tue Aug 4 16:50:20 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 392FC3A6920 for ; Tue, 4 Aug 2009 16:50:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.11 X-Spam-Level: X-Spam-Status: No, score=-105.11 tagged_above=-999 required=5 tests=[BAYES_05=-1.11, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FsVMvxqYybzH for ; Tue, 4 Aug 2009 16:50:19 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 74DE53A67A8 for ; Tue, 4 Aug 2009 16:50:19 -0700 (PDT) Received: from belew.digium.internal ([10.24.18.244]) by mail.digium.com with esmtp (Exim 4.63) (envelope-from ) id 1MYTlm-00012n-QE for bliss@ietf.org; Tue, 04 Aug 2009 18:50:14 -0500 Message-ID: <4A78C991.90905@digium.com> Date: Tue, 04 Aug 2009 18:51:45 -0500 From: Mark Michelson User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: bliss@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2009 23:50:20 -0000 Hi group, I've been reading through draft-ietf-bliss-call-completion-04, and there is a piece of information that I have been having difficulty locating. When a cc monitor sends a final response to an INVITE that indicates that CCBS/CCNR/CCNL may be requested, is there a way that an expiration time may be indicated in this response? I realize that as a cc monitor, I don't necessarily have to remember the original failed call forever, but I would think that it would be possible to indicate to an upstream element that its opportunity to request call completion services has expired. I did not see such a capability mentioned in the latest call completion draft, so I was wondering if such a facility may be considered. Or was this sort of facility left out of the draft for a specific reason? I apologize in advance if this topic has surfaced in previous discussions, but looking through the list archives, google, and the draft itself did not give me an answer to my question. Thanks for your time, Mark Michelson From L.Liess@telekom.de Wed Aug 5 06:19:55 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F2E3A6781 for ; Wed, 5 Aug 2009 06:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.449 X-Spam-Level: X-Spam-Status: No, score=-1.449 tagged_above=-999 required=5 tests=[AWL=-1.800, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_66=0.6, J_CHICKENPOX_83=0.6, J_CHICKENPOX_84=0.6, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SG0YDGfu4sJ1 for ; Wed, 5 Aug 2009 06:19:54 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 387CD28C0E5 for ; Wed, 5 Aug 2009 06:18:46 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 05 Aug 2009 15:18:41 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:18:40 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:18:40 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003430F4C@S4DE9JSAANI.ost.t-com.de> In-reply-to: <0D5F89FAC29E2C41B98A6A762007F5D00239367B@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoUUOg4lt0M3vv1SCyYSuKouQjymAAkLwfQADXhyjA= References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <4A770529.9000600@nostrum.com> <0D5F89FAC29E2C41B98A6A762007F5D00239367B@GBNTHT12009MSX.gb002.siemens.net> From: To: , , X-OriginalArrivalTime: 05 Aug 2009 13:18:40.0952 (UTC) FILETIME=[3FFE3B80:01CA15CF] Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:19:55 -0000 I like Adam's proposal to consider a scheme that defines discrete tokens which can be combined. I also agree with John that we should avoid pitch designation and use the semantic approach. =20 For the use-cases currently defined in the draft the definitions in chapters 3 and 4 already follow this approach.=20 We could change chapter 7 and register:=20 -the alert-categories "service and "tones".=20 -for the "service" alert-category the top-level alert-indications call-waiting, forward, transfer-recall, auto-callback, hold-recall and crisis.=20 -for the "tones" alert-category the top-level alert-indications ( "normal", "external", "internal") and the 1st-level sub-indications "priority", "short" ( or maybe "abreviated"?) and "delayed" =20 We could in principle add also 1st-level and 2nd-level sub-indications for A.S0014 tones if anybody knows the semantic. Other people can add later values for the different levels of sub-indications.=20 Maybe we should change the the ABNF syntax for the alert-category which is "tone"/"service" in let-dig [ *25let-dig-hyp let-dig ] to allow other people to add new alert-categories later ? Laura=20 =20 =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, August 04, 2009 11:02 AM > To: Adam Roach; Liess, Laura > Cc: bliss@ietf.org > Subject: RE: [BLISS] Initial ringtones=20 > fordraft-alexeitsev-bliss-alert-info-urns >=20 > Adam, >=20 > I am not necessarily disagreeing with this combinatorial=20 > approach, but I > do have concerns about some of the examples. "Short" seems to=20 > stray into > the territory of rendering rather than meaning. The "high", "medium", > and "low" pitch designations certainly stray into that territory, and > how would I render these on a visual, as opposed to audible, user > interface? >=20 > John >=20 > > -----Original Message----- > > From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > > On Behalf Of Adam Roach > > Sent: 03 August 2009 16:41 > > To: L.Liess@telekom.de > > Cc: bliss@ietf.org > > Subject: Re: [BLISS] Initial ringtones=20 > > fordraft-alexeitsev-bliss-alert-info-urns > >=20 > > L.Liess@telekom.de wrote: > > > The intent of the draft is to provide a general mechanism,=20 > > to register the template and to do initial registration for=20 > > tones and service tones which we know that people intend to=20 > > use now and have interoperability problems. I don't think we=20 > > should now register every tone in every national=20 > > specification, which possible nobbody intends to use. =20 > > > If, over time, people need additional tones or service=20 > > tones, they can use the general mechanism and template are=20 > > free to register their own tones. =20 > > > > > > Or do you see a problem with this approach? > > > =20 > >=20 > > I'm okay with that for the specific ringtone names (with=20 > the caveats=20 > > raised by John Elwell about not wanting two strings that=20 > effectively=20 > > have the same semantic meaning). > >=20 > > However, I think this is of considerably more importance: > >=20 > > >> Additionally, A.S0014 allows indication of pitch (high,=20 > > >> normal, low) as > > >> part of the ringtone designation. It would be nice if we=20 > > >> could tack this > > >> pitch data on to the end of the existing tokens (e.g., > > >> "normal.short.low"). I note that this points to a combinatorial > > >> explosion of IANA values -- perhaps we need to re-think how we're > > >> representing the registry. > > >> =20 > >=20 > > I'll reiterate that the registry can become very, very full if we=20 > > continue down this path. I would strongly suggest that you instead=20 > > consider a scheme that defines discrete tokens, and then=20 > > talks about how=20 > > they can be combined. For example, instead of registering: > >=20 > > 1. normal > > 2. normal.priority > > 3. normal.short > > 4. normal.delayed > > 5. internal > > 6. internal.priority > > 7. internal.short > > 8. internal.delayed > > 9. external > > 10. external.priority > > 11. external.short > > 12. external.delayed > >=20 > >=20 > > I think you should register: > >=20 > > 1. normal > > 2. internal > > 3. external > > 4. priority > > 5. short > > 6. delayed > >=20 > > And then define rules about how these can be stacked. In=20 > > particular, one=20 > > of the first things I'd be likely to try to add to the=20 > > registry would be=20 > > the pitch designations of A.S0014, but I don't think we=20 > > *really* want a=20 > > registry that looks like this: > >=20 > > 1. normal > > 2. normal.high > > 3. normal.medium > > 4. normal.low > > 5. normal.priority > > 6. normal.priority.high > > 7. normal.priority.medium > > 8. normal.priority.low > > 9. normal.short > > 10. normal.short.high > > 11. normal.short.medium > > 12. normal.short.low > > 13. normal.delayed > > 14. normal.delayed.high > > 15. normal.delayed.medium > > 16. normal.delayed.low > > 17. internal > > 18. internal.high > > 19. internal.medium > > 20. internal.low > > 21. internal.priority > > 22. internal.priority.high > > 23. internal.priority.medium > > 24. internal.priority.low > > 25. internal.short > > 26. internal.short.high > > 27. internal.short.medium > > 28. internal.short.low > > 29. internal.delayed > > 30. internal.delayed.high > > 31. internal.delayed.medium > > 32. internal.delayed.low > > 33. external > > 34. external.high > > 35. external.medium > > 36. external.low > > 37. external.priority > > 38. external.priority.high > > 39. external.priority.medium > > 40. external.priority.low > > 41. external.short > > 42. external.short.high > > 43. external.short.medium > > 44. external.short.low > > 45. external.delayed > > 46. external.delayed.high > > 47. external.delayed.medium > > 48. external.delayed.low > >=20 > > And that's just with the three pitches that I want to add.=20 > If someone=20 > > adds another semantic dimension, the size of the registry=20 > > continues to=20 > > grow exponentially. > >=20 > > /a > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 >=20 From L.Liess@telekom.de Wed Aug 5 06:50:14 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2C58828C580 for ; Wed, 5 Aug 2009 06:50:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ai77jF6gImA for ; Wed, 5 Aug 2009 06:50:12 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id E39D43A714B for ; Wed, 5 Aug 2009 06:50:10 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 05 Aug 2009 15:48:59 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 15:48:59 +0200 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 5 Aug 2009 15:48:54 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003430F75@S4DE9JSAANI.ost.t-com.de> In-reply-to: <4A7721E4.7040709@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns Thread-Index: AcoUYgBcYhdEYsDZRAq5piAOVF0Q3QBbeRnA References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de> <0D5F89FAC29E2C41B98A6A762007F5D00233D2D7@GBNTHT12009MSX.gb002.siemens.net> <40FB0FFB97588246A1BEFB05759DC8A0033EC2B2@S4DE9JSAANI.ost.t-com.de> <4A7721E4.7040709@cisco.com> From: To: X-OriginalArrivalTime: 05 Aug 2009 13:48:59.0009 (UTC) FILETIME=[7BA3B710:01CA15D3] Cc: bliss@ietf.org Subject: Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 13:50:14 -0000 Paul, I agree with you. We should try to define only URNs that define a = semantic and are valid in the Internet. I think the subindications = defined in the draft, maybe excepting "short", define a semantic. =20 The mapping between semantic and rendering is can be different in = different domains. Maybe URNs that define rendering e.g. = Short-Short-Long should be defined for particular domains and registered = with the domain owner?=20 =20 Laura > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, August 03, 2009 7:44 PM > To: Liess, Laura > Cc: john.elwell@siemens-enterprise.com; bliss@ietf.org > Subject: Re: [BLISS] Initial=20 > ringtonesfordraft-alexeitsev-bliss-alert-info-urns >=20 > When I first started talking about using URNs for this (some=20 > years ago), > I expected that there might be URNs that were defined by their=20 > semantics, without regard to how rendered, and others that were=20 > associated with a particular rendering - to some degree of fidelity. >=20 > In general I would prefer to see the representation at least=20 > start out=20 > using a URN that defines a semantic. It could then perhaps be=20 > translated=20 > into one more related to form in cases where there is=20 > compelling reason=20 > to do so. Ideally that translation would be as late as possible. >=20 > This becomes especially important as we get devices with more diverse=20 > rendering capabilities than was the case in the early days of=20 > telephony. >=20 > The obvious use case is the widespread use of custom ring=20 > tones. These=20 > are typically selected near or at the callee, not by the caller. How=20 > should the use of custom ring tones by the callee be rationalized=20 > against an Alert-Info URN supplied by the caller? Ideally, if the=20 > Alert-Info includes the URN for the "normal ring tone", then=20 > the callee=20 > should feel comfortable in using its configured choice for ring tone. > If the incoming Alert-Info contains something else, it will take more=20 > policy to decide what to render. >=20 > Customized alerts get especially important if the UAS is for a deaf=20 > person. Then vibrators or lights are more likely to be used.=20 > Similarly,=20 > custom rendering of ringbacks are also important in such cases.=20 > Understanding the semantics is especially important is such cases,=20 > because a definition that is directly in terms of the audio rendering=20 > isn't useful if you aren't rendering it using audio. >=20 > Semantic alerts are also helpful when the device has a video display,=20 > since then it gets easier to display something meaningful. >=20 > Thanks, > Paul >=20 > L.Liess@telekom.de wrote: > > John, > >=20 > > I agree with you. Maybe we should add some new text with=20 > recommendations about how new alert-identifiers should/=20 > should not be defined. E.g. we could insert following text=20 > at the end of chapter 7.1: "When defining new=20 > alert-identifiers, names that reflect the meaning, rather=20 > than the representation of a tone should be used. " What do=20 > you think?=20 > >=20 > > Laura > >=20 > >> -----Original Message----- > >> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > >> Sent: Thursday, July 30, 2009 3:49 PM > >> To: Liess, Laura; audet@nortel.com; adam@nostrum.com;=20 > bliss@ietf.org > >> Subject: RE: [BLISS] Initial=20 > >> ringtonesfordraft-alexeitsev-bliss-alert-info-urns > >> > >> We should at least try to avoid having two or more URNs with=20 > >> the same semantics, coming from different countries.=20 > >> Furthermore, we should try to register names that reflect the=20 > >> meaning, rather than the representation, of a tone, so that=20 > >> it can be rendered in the appropriate way for the locale=20 > >> concerned. For example "internal.short-short-short" tells me=20 > >> nothing about the meaning (other than that it is internal).=20 > >> If it is intended to denote three short bursts of tone, this=20 > >> could convey different meanings (or confusion) to a user=20 > >> outside the locale where it originated. > >> > >> John > >> > >>> -----Original Message----- > >>> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > >>> On Behalf Of L.Liess@telekom.de > >>> Sent: 30 July 2009 10:26 > >>> To: audet@nortel.com; adam@nostrum.com; bliss@ietf.org > >>> Subject: Re: [BLISS] Initial=20 > >>> ringtonesfordraft-alexeitsev-bliss-alert-info-urns > >>> > >>> > >>> Francois, > >>> > >>> They would have to use the alredy registered alert urn=20 > >>> template and to register new alert-URN indications for "tone"=20 > >>> or "service" , e.g. internal.short-short-short. It's a=20 > >>> similar process as for the Emergency Service URN (5031).=20 > >>> > >>> My personal opinion is that many of the tones defined in=20 > >>> national documents will be not longer used when PSTN=20 > moves to VoIP.=20 > >>> > >>> Regards > >>> Laura > >>> > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: Francois Audet [mailto:audet@nortel.com]=20 > >>>> Sent: Wednesday, July 29, 2009 1:50 PM > >>>> To: Liess, Laura; adam@nostrum.com; bliss@ietf.org > >>>> Subject: RE: [BLISS] Initial ringtones=20 > >>>> fordraft-alexeitsev-bliss-alert-info-urns > >>>> > >>>> It seems to me that if a specific national body requires the use > >>>> of national-specific ringback tones, they would then have=20 > >>> to register > >>>> their own URN space for it. > >>>> > >>>> Hopefully we wouldn't go that route, but the option is=20 > >> definitively > >>>> there if required.=20 > >>>> > >>>>> -----Original Message----- > >>>>> From: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > >>>>> On Behalf Of L.Liess@telekom.de > >>>>> Sent: Tuesday, July 28, 2009 08:59 > >>>>> To: adam@nostrum.com; bliss@ietf.org > >>>>> Subject: Re: [BLISS] Initial ringtones=20 > >>>>> fordraft-alexeitsev-bliss-alert-info-urns > >>>>> > >>>>> Adam, > >>>>> > >>>>> The intent of the draft is to provide a general mechanism, to=20 > >>>>> register the template and to do initial registration for=20 > >>>>> tones and service tones which we know that people intend to=20 > >>>>> use now and have interoperability problems. I don't think we=20 > >>>>> should now register every tone in every national=20 > >>>>> specification, which possible nobbody intends to use. =20 > >>>>> If, over time, people need additional tones or service tones,=20 > >>>>> they can use the general mechanism and template are free to=20 > >>>>> register their own tones. =20 > >>>>> > >>>>> Or do you see a problem with this approach? > >>>>> > >>>>> Thanks a lot > >>>>> Laura > >>>>> > >>>>> > >>>>> Mit freundlichen Gr=FC=DFen > >>>>> Laura Liess > >>>>> > >>>>> Deutsche Telekom Netzproduktion GmbH > >>>>> Zentrum Technik Einf=FChrung > >>>>> Laura Liess > >>>>> Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt=20 > >>>>> +49 6151 628-2761 (Tel.) > >>>>> +49 6151 628-3395 (Fax) > >>>>> +49 175 2961015 (Mobil) > >>>>> l.liess@telekom.de (E-mail) > >>>>> http://www.telekom.com=20 > >>>>> > >>>>> Deutsche Telekom Netzproduktion GmbH > >>>>> Aufsichtsrat: Timotheus H=F6ttges (Vorsitzender) > >>>>> Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender),=20 > >>>>> Albert Matheis, Klaus Peren > >>>>> Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der=20 > >>>>> Gesellschaft: Bonn > >>>>> USt-IdNr.: DE 814645262 > >>>>> > >>>>> =20 > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: bliss-bounces@ietf.org=20 > >>>>> [mailto:bliss-bounces@ietf.org] On Behalf=20 > >>>>>> Of Adam Roach > >>>>>> Sent: Tuesday, July 28, 2009 2:30 PM > >>>>>> To: bliss@ietf.org > >>>>>> Subject: [BLISS] Initial ringtones for=20 > >>>>>> draft-alexeitsev-bliss-alert-info-urns > >>>>>> > >>>>>> There are a number of additional tones that are=20 > >> probably worth=20 > >>>>>> considering as part of the initial set of symbols. If=20 > >>> you look at=20 > >>>>>> TIA/EIA-41-D and 3GPP2 A.S0014, you'll find quite a few tone=20 > >>>>>> designations that are used in other standards. > >>>>>> > >>>>>> A.S0014 defines: > >>>>>> > >>>>>> 1. Normal Alerting > >>>>>> 2. Inter-group Alerting > >>>>>> 3. Special/Priority Alerting > >>>>>> 4. Ping Ring (abbreviated alert) > >>>>>> 5. Abbreviated intercept > >>>>>> 6. Abbreviated reorder > >>>>>> > >>>>>> I think #1 and #4 are covered in the current document, but=20 > >>>>> the others=20 > >>>>>> aren't clearly represented. > >>>>>> > >>>>>> If you throw in the TIA/EIA values, you also have things like: > >>>>>> > >>>>>> 1. Long (Normal) > >>>>>> 2. Short-Short > >>>>>> 3. Short-Short-Long > >>>>>> 4. Short-Short2 > >>>>>> 5. Short-Long-Short > >>>>>> 6. Short-Short-Short-Short > >>>>>> 7. PBX Long (Normal) > >>>>>> 8. PBX Short-Short > >>>>>> 9. PBX Short-Short-Long > >>>>>> 10. PBX Short-Long-Short > >>>>>> 11. PBX Short-Short-Short-Short > >>>>>> > >>>>>> > >>>>>> Additionally, A.S0014 allows indication of pitch (high,=20 > >>>>> normal, low)=20 > >>>>>> as part of the ringtone designation. It would be nice if we=20 > >>>>> could tack=20 > >>>>>> this pitch data on to the end of the existing tokens (e.g.,=20 > >>>>>> "normal.short.low"). I note that this points to a=20 > >> combinatorial=20 > >>>>>> explosion of IANA values -- perhaps we need to re-think=20 > >>> how we're=20 > >>>>>> representing the registry. > >>>>>> > >>>>>> /a > >>>>>> > >>>>>> _______________________________________________ > >>>>>> BLISS mailing list > >>>>>> BLISS@ietf.org > >>>>>> https://www.ietf.org/mailman/listinfo/bliss > >>>>>> > >>>>> _______________________________________________ > >>>>> BLISS mailing list > >>>>> BLISS@ietf.org > >>>>> https://www.ietf.org/mailman/listinfo/bliss > >>>>> > >>> _______________________________________________ > >>> BLISS mailing list > >>> BLISS@ietf.org > >>> https://www.ietf.org/mailman/listinfo/bliss > >>> > > _______________________________________________ > > BLISS mailing list > > BLISS@ietf.org > > https://www.ietf.org/mailman/listinfo/bliss > >=20 >=20 From Martin.Huelsemann@telekom.de Wed Aug 5 08:47:15 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 085F33A6965 for ; Wed, 5 Aug 2009 08:47:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.392 X-Spam-Level: X-Spam-Status: No, score=-2.392 tagged_above=-999 required=5 tests=[AWL=0.858, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GcNaXHurLFkC for ; Wed, 5 Aug 2009 08:47:14 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id C18E43A6BED for ; Wed, 5 Aug 2009 08:47:12 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 05 Aug 2009 17:35:15 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Wed, 5 Aug 2009 17:35:15 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable x-mimeole: Produced By Microsoft Exchange V6.5 Date: Wed, 5 Aug 2009 17:35:29 +0200 Message-ID: In-Reply-To: <4A78C991.90905@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? Thread-Index: AcoVXlsS6dE7LdNJQ/StR9pYEHzS6gAf+KaA References: <4A78C991.90905@digium.com> From: To: , X-OriginalArrivalTime: 05 Aug 2009 15:35:15.0117 (UTC) FILETIME=[541895D0:01CA15E2] Subject: Re: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2009 15:47:15 -0000 Hi Mark, until now such a retention indication was not discussed. It's clear that = there will be a temporal relationship between failed call and CC = request, but the question is if we really have to indicate this via SIP? If we say that about 20 s should be enough to activate CC, incl. time = for signalling and user interaction, the definition of a 20 s retention = timer at the CC agent should be sufficient to prevent the expiry of the = possibility for CC.=20 BR, Martin > -----Urspr=FCngliche Nachricht----- > Von: bliss-bounces@ietf.org [mailto:bliss-bounces@ietf.org]=20 > Im Auftrag von Mark Michelson > Gesendet: Mittwoch, 5. August 2009 01:52 > An: bliss@ietf.org > Betreff: [BLISS] draft-ietf-bliss-call-completion-04=20 > Recommendation for retention time? >=20 > Hi group, >=20 > I've been reading through=20 > draft-ietf-bliss-call-completion-04, and there is a piece of=20 > information that I have been having difficulty locating. When=20 > a cc monitor sends a final response to an INVITE that=20 > indicates that CCBS/CCNR/CCNL may be requested, is there a=20 > way that an expiration time may be indicated in this response? >=20 > I realize that as a cc monitor, I don't necessarily have to=20 > remember the original failed call forever, but I would think=20 > that it would be possible to indicate to an upstream element=20 > that its opportunity to request call completion services has=20 > expired. I did not see such a capability mentioned in the=20 > latest call completion draft, so I was wondering if such a=20 > facility may be considered.=20 > Or was this sort of facility left out of the draft for a=20 > specific reason? >=20 > I apologize in advance if this topic has surfaced in previous=20 > discussions, but looking through the list archives, google,=20 > and the draft itself did not give me an answer to my question. >=20 > Thanks for your time, > Mark Michelson > _______________________________________________ > BLISS mailing list > BLISS@ietf.org > https://www.ietf.org/mailman/listinfo/bliss >=20 From mmichelson@digium.com Thu Aug 6 09:00:11 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 900363A6DF1 for ; Thu, 6 Aug 2009 09:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.855 X-Spam-Level: X-Spam-Status: No, score=-105.855 tagged_above=-999 required=5 tests=[AWL=0.744, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8yvpaH2E4oEB for ; Thu, 6 Aug 2009 09:00:10 -0700 (PDT) Received: from mail.digium.com (mail.digium.com [216.207.245.2]) by core3.amsl.com (Postfix) with ESMTP id 8079828C15F for ; Thu, 6 Aug 2009 09:00:04 -0700 (PDT) Received: from belew.digium.internal ([10.24.18.244]) by mail.digium.com with esmtp (Exim 4.63) (envelope-from ) id 1MZ5Ns-0000tZ-Ph; Thu, 06 Aug 2009 11:00:04 -0500 Message-ID: <4A7AFE63.5020606@digium.com> Date: Thu, 06 Aug 2009 11:01:39 -0500 From: Mark Michelson User-Agent: Thunderbird 2.0.0.18 (X11/20081125) MIME-Version: 1.0 To: Martin.Huelsemann@telekom.de References: <4A78C991.90905@digium.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Aug 2009 16:00:11 -0000 Martin.Huelsemann@telekom.de wrote: > Hi Mark, > > until now such a retention indication was not discussed. It's clear that there will be a temporal relationship between failed call and CC request, but the question is if we really have to indicate this via SIP? > > If we say that about 20 s should be enough to activate CC, incl. time for signalling and user interaction, the definition of a 20 s retention timer at the CC agent should be sufficient to prevent the expiry of the possibility for CC. > > > BR, Martin > Thank you for the response, Martin, and sorry for not replying sooner, myself. I'm not too concerned about what a reasonable default expiry for the CC offer should be. What I am concerned about is whether this may be expressed in some way. For instance, could an expires= parameter be added to the Call-Info header sent by the CC monitor in cases where call completion services are available? Mark Michelson From Martin.Huelsemann@telekom.de Mon Aug 10 08:53:22 2009 Return-Path: X-Original-To: bliss@core3.amsl.com Delivered-To: bliss@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D524D28C174 for ; Mon, 10 Aug 2009 08:53:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uh6zgUaJlMX1 for ; Mon, 10 Aug 2009 08:53:22 -0700 (PDT) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 8858628C16C for ; Mon, 10 Aug 2009 08:53:21 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail51.telekom.de with ESMTP; 10 Aug 2009 17:53:11 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 10 Aug 2009 17:53:11 +0200 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 10 Aug 2009 17:53:10 +0200 Message-ID: In-Reply-To: <4A7AFE63.5020606@digium.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: AW: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? Thread-Index: AcoWrvrGK79ye/suS4Cj+3UhmJjy6QDIh2DQ References: <4A78C991.90905@digium.com> <4A7AFE63.5020606@digium.com> From: To: X-OriginalArrivalTime: 10 Aug 2009 15:53:11.0185 (UTC) FILETIME=[A98C4810:01CA19D2] Cc: bliss@ietf.org Subject: Re: [BLISS] draft-ietf-bliss-call-completion-04 Recommendation for retention time? X-BeenThere: bliss@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: "Basic Level of Interoperability for SIP Services \(BLISS\) BoF" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2009 15:53:22 -0000 Hi Mark, of course we could specify how to indicate the retention time to the = agent. But again the question is if we really need it, because CC has to be = requested as soon as possible anyway. If you wait much longer than 20 to = 30 seconds, the more probable it becomes that someone else calls and = activates CC to the callee. So from my point of view the definition of a retention timer which is = known to agent and monitor will be sufficient. BR, Martin =20 > -----Urspr=FCngliche Nachricht----- > Von: Mark Michelson [mailto:mmichelson@digium.com]=20 > Gesendet: Donnerstag, 6. August 2009 18:02 > An: H=FClsemann, Martin > Cc: bliss@ietf.org > Betreff: Re: AW: [BLISS] draft-ietf-bliss-call-completion-04=20 > Recommendation for retention time? >=20 > Martin.Huelsemann@telekom.de wrote: > > Hi Mark, > >=20 > > until now such a retention indication was not discussed.=20 > It's clear that there will be a temporal relationship between=20 > failed call and CC request, but the question is if we really=20 > have to indicate this via SIP? > >=20 > > If we say that about 20 s should be enough to activate CC,=20 > incl. time for signalling and user interaction, the=20 > definition of a 20 s retention timer at the CC agent should=20 > be sufficient to prevent the expiry of the possibility for CC.=20 > >=20 > >=20 > > BR, Martin > >=20 >=20 > Thank you for the response, Martin, and sorry for not=20 > replying sooner, myself. >=20 > I'm not too concerned about what a reasonable default expiry=20 > for the CC offer should be. What I am concerned about is=20 > whether this may be expressed in some way. For instance,=20 > could an expires=3D parameter be added to the Call-Info header=20 > sent by the CC monitor in cases where call completion=20 > services are available? >=20 > Mark Michelson >=20