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
[email protected] 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:[email protected]]
Sent: Thursday, July 30, 2009 3:49 PM
To: Liess, Laura; [email protected]; [email protected]; [email protected]
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: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: 30 July 2009 10:26
To: [email protected]; [email protected]; [email protected]
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:[email protected]]
Sent: Wednesday, July 29, 2009 1:50 PM
To: Liess, Laura; [email protected]; [email protected]
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: [email protected] [mailto:[email protected]]
On Behalf Of [email protected]
Sent: Tuesday, July 28, 2009 08:59
To: [email protected]; [email protected]
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)
[email protected] (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: [email protected]
[mailto:[email protected]] On Behalf
Of Adam Roach
Sent: Tuesday, July 28, 2009 2:30 PM
To: [email protected]
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
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
