Paul,
One comment below.
Thanks,
Alan
Paul Kyzivat wrote:
This seems to be shaping up well. I think the requirements are quite
clear now.
I don't fully understand what is intended regarding combination of
multiple alert URNs for a specific situation. Section 4.5 states:
finally, a short Albanian auto-callback tone could be indicated
Alert-Info: <urn:alert:service:auto-callback>,
<urn:alert:tone:short>, <urn:alert:tone:al>.
while section 7.3.6 states:
Alert URN Indications from the same group should not be combined.
I could find no definition of what constitutes a "group". The first
thing that comes to mind is "service" vs. "tone", but the above
example violates that. It seems to me that you need some notion of
orthogonal properties in order to define what can/cannot be combined.
It would be good to have more detail about how a recipient should deal
with multiple URNs.
I'm also uncertain of what your intent is regarding top-level vs.
additional indications. As specified, I believe a given "additional
indication" name is always defined with regard to its parent, so that
"short" as used in "normal.short" might mean something entirely
different than "priority.short", or might not be defined for priority
at all.
Yet from the registration text in 7.3.2 it sounds like the intent is
for priority, short, and delayed to be defined for all pbx-tones. If
that is the intent, then I don't think the existing text meets that
intent.
As it has been pointed out, short, long, and delayed are not compatible
with the semantic approach of this draft so I think we should remove
them as they are currently. I need to investigate to see whether they
have been used in the past as stand-ins for a particular service, or
whether we need to define specific tones for them.
Priority, I still think, is useful - we just need to figure out how to
fit it in properly.
I also wonder if the existing hierarchy will work well in practice, or
if some other organization might not work better. For instance, it
might be more convenient to specify ringing.fr with the clear
understanding that if you don't know about ringing.fr you can just
treat it as ringing.
I'm also confused by PBX tones vs. Public telephone tones. In what way
is "normal" different from "ringing"? I would think that PBX tones
would be a superset of common pstn tones.
A nit: in 4.3.2 I would expext the forward to be indicated, if at all,
with a 181 rather than a 180.
Thanks,
Paul
[email protected] wrote:
Hi,
We've re-submitted the Alert-Info URNs draft for DISPATCH
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
-00.txt . (The previous version od the draft was in BLISS and we had a
presentation in BLISS at the last IETF.)
We did some major changes, as suggested on the mailing list, e.g.:
Added: - Description of the interoperability problems for
PBX-services (in
the Introduction chapter) - Requirements for the Alert-Info URNs
mechanism - Alert-Info URNs Indications for country-specific tones
Changed: - Initial IANA Registration mechanism to avoid
combinatorial explosion
of IANA values.
Many thanks for the comments and suggestions,
Laura
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of
[email protected]
Sent: Monday, October 19, 2009 1:00 PM
To: [email protected]
Subject: I-D Action:draft-liess-dispatch-alert-info-urns-00.txt
A New Internet-Draft is available from the on-line Internet-Drafts
directories.
Title : Alert-Info URNs for the Session Initiation
Protocol (SIP)
Author(s) : D. Alexeitsev, et al.
Filename : draft-liess-dispatch-alert-info-urns-00.txt
Pages : 25
Date : 2009-10-19
The Session Initiation Protocol (SIP) supports the capability to
provide a reference to the alternative ringback tone (RBT) for
caller, or ring tone (RT) for callee using the Alert-Info header.
However, the reference addresses only the network resources with
specific rendering properties. There is currently no support for
predefined standard identifiers for ringback tones or semantic
indications without tied rendering. To overcome this limitations and
support new applications a family of the URNs is defined in this
specification.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-liess-dispatch-alert-info-urns
-00.txt
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
dispatch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
dispatch mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dispatch
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
