Re: [dispatch] [BLISS] New version for the Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt

["Elwell, John" <[e-mail]>]

 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> Sent: 25 October 2009 17:06
> To: Elwell, John; [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]; 
> [e-mail]
> Subject: RE: [BLISS] [dispatch] New version for the 
> Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt
> 
> 
> Hi John,
> 
> Thank you very much for reading the draft and for the comments. 
> 
> Please  see answers inline:
> 
> 	> -----Original Message-----
> 	> From: Elwell, John [mailto:[e-mail]]
> 
> 	> Sent: Tuesday, October 20, 2009 9:41 AM
> 	> To: Paul Kyzivat; Liess, Laura
> 	> Cc: [e-mail]; Jesske, Roland; [e-mail]
> 	> Subject: RE: [BLISS] [dispatch] New version for the 
> 	> Alert-Info URNs
> draft:draft-liess-dispatch-alert-info-urns-00.txt
> 	> 
> 	> (I have removed the BLISS cross-post, by the way).
> 	> 
> 	> I agree with the points Paul makes. In addition, I am 
> 	> concerned about some of the values:
> 	> 
> 	> 1. In 4.3.8, the value "short" is defined. This seems to have 
> 	> nothing to do with the meaning of a tone, but the way it is 
> 	> rendered. So in one locale, a short form of ring tone might 
> 	> denote low priority, say, whereas in another locale it might 
> 	> mean urgent, yet in a third locale it might mean some form of 
> 	> recall. Also, if my device renders tones visually, does 
> 	> displaying the alert icon or message only for a short period 
> 	> make sense? Finally, what does "short" mean to an automaton?
> 
> I am not very familiar with PBXs, this is Alan's part, but my
> understanding is that the PBX tones URNs are inserted by the local PBX
> system (Proxy, Application server, maybe a UA directly 
> connected to the
> PBX) and rendered  by one UE of the same enterprise, so that, in
> generally, there is a common understanding about the meaning 
> of "short".
> Maybe we could add a description about how itshould be used? 
[JRE] I agree it could be used in this way, but I thought the whole point of the draft was to define semantic names for ring tones, not names that suggest a particular means of rendering.

John

> 
> 
> > 
> > 2. Given that Alert-Info is defined only for use in an INVITE 
> > request or a 180 response, how would values such as "busy", 
> > "intrusion" and "record" be used?
> 
> This is true. I just did not think about it when I wrote this part. We
> should define only country ringing tones. 
> 
> Thanks a lot
> Laura
> 
> 
> > 
> > John
> > 
> >  
> > 
> > > -----Original Message-----
> > > From: [e-mail] [mailto:[e-mail]] 
> > > On Behalf Of Paul Kyzivat
> > > Sent: 19 October 2009 21:44
> > > To: [e-mail]
> > > Cc: [e-mail]; [e-mail]; [e-mail]; 
> > > [e-mail]
> > > Subject: Re: [BLISS] [dispatch] New version for the 
> > > Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt
> > > 
> > > 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.
> > > 
> > > 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
> > > 
> > > [e-mail] 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: [e-mail]
> > > > [mailto:[e-mail]] On Behalf Of
> > > > [e-mail]
> > > > Sent: Monday, October 19, 2009 1:00 PM
> > > > To: [e-mail]
> > > > 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
> > > > [e-mail]
> > > > https://www.ietf.org/mailman/listinfo/dispatch
> > > > 
> > > _______________________________________________
> > > BLISS mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/bliss
> > > 
> > 
>