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 L.Liess at telekom.de 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 explosionof IANA values. Many thanks for the comments and suggestions, Laura-----Original Message-----From: i-d-announce-bounces at ietf.org [mailto:i-d-announce-bounces at ietf.org] On Behalf Of Internet-Drafts at ietf.org Sent: Monday, October 19, 2009 1:00 PM To: i-d-announce at ietf.org 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 dispatch at ietf.org https://www.ietf.org/mailman/listinfo/dispatch_______________________________________________ dispatch mailing list dispatch at ietf.org https://www.ietf.org/mailman/listinfo/dispatch