[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BLISS] Initial ringtonesfordraft-alexeitsev-bliss-alert-info-urns
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.
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?
Laura
> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzivat at cisco.com]
> Sent: Monday, August 03, 2009 7:44 PM
> To: Liess, Laura
> Cc: john.elwell at siemens-enterprise.com; bliss at ietf.org
> Subject: Re: [BLISS] Initial
> ringtonesfordraft-alexeitsev-bliss-alert-info-urns
>
> 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 at 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 at siemens-enterprise.com]
> >> Sent: Thursday, July 30, 2009 3:49 PM
> >> To: Liess, Laura; audet at nortel.com; adam at nostrum.com;
> bliss at 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 at ietf.org [mailto:bliss-bounces at ietf.org]
> >>> On Behalf Of L.Liess at telekom.de
> >>> Sent: 30 July 2009 10:26
> >>> To: audet at nortel.com; adam at nostrum.com; bliss at 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 at nortel.com]
> >>>> Sent: Wednesday, July 29, 2009 1:50 PM
> >>>> To: Liess, Laura; adam at nostrum.com; bliss at 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 at ietf.org [mailto:bliss-bounces at ietf.org]
> >>>>> On Behalf Of L.Liess at telekom.de
> >>>>> Sent: Tuesday, July 28, 2009 08:59
> >>>>> To: adam at nostrum.com; bliss at 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 at 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 at ietf.org
> >>>>> [mailto:bliss-bounces at ietf.org] On Behalf
> >>>>>> Of Adam Roach
> >>>>>> Sent: Tuesday, July 28, 2009 2:30 PM
> >>>>>> To: bliss at 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 at ietf.org
> >>>>>> https://www.ietf.org/mailman/listinfo/bliss
> >>>>>>
> >>>>> _______________________________________________
> >>>>> BLISS mailing list
> >>>>> BLISS at ietf.org
> >>>>> https://www.ietf.org/mailman/listinfo/bliss
> >>>>>
> >>> _______________________________________________
> >>> BLISS mailing list
> >>> BLISS at ietf.org
> >>> https://www.ietf.org/mailman/listinfo/bliss
> >>>
> > _______________________________________________
> > BLISS mailing list
> > BLISS at ietf.org
> > https://www.ietf.org/mailman/listinfo/bliss
> >
>