Re: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns

<L.Liess@telekom.de> Thu, 30 July 2009 09:25 UTC

Return-Path: <L.Liess@telekom.de>
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 53FEC3A69E5 for <bliss@core3.amsl.com>; Thu, 30 Jul 2009 02:25:59 -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 oKy8biKQUZAa for <bliss@core3.amsl.com>; Thu, 30 Jul 2009 02:25:58 -0700 (PDT)
Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 9C1723A68C2 for <bliss@ietf.org>; Thu, 30 Jul 2009 02:25:57 -0700 (PDT)
Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail51.telekom.de with ESMTP; 30 Jul 2009 11:25:57 +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); Thu, 30 Jul 2009 11:25:57 +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: Thu, 30 Jul 2009 11:25:56 +0200
Message-ID: <40FB0FFB97588246A1BEFB05759DC8A0033EB69F@S4DE9JSAANI.ost.t-com.de>
In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-topic: [BLISS] Initial ringtones fordraft-alexeitsev-bliss-alert-info-urns
Thread-index: AcoPfzVjfWOKe69nRiyST8drYni1LQAHP6pwACmVU9AALA5p8A==
References: <4A6EEF5C.1060107@nostrum.com> <40FB0FFB97588246A1BEFB05759DC8A0033A7D3A@S4DE9JSAANI.ost.t-com.de> <1ECE0EB50388174790F9694F77522CCF1F36370E@zrc2hxm0.corp.nortel.com>
From: L.Liess@telekom.de
To: audet@nortel.com, adam@nostrum.com, bliss@ietf.org
X-OriginalArrivalTime: 30 Jul 2009 09:25:57.0173 (UTC) FILETIME=[BE742650:01CA10F7]
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" <bliss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/bliss>
List-Post: <mailto:bliss@ietf.org>
List-Help: <mailto:bliss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bliss>, <mailto:bliss-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Jul 2009 09:25:59 -0000

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
> > 
>