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

[<[e-mail]>]

Paul, 

Thank you very much for taking the time to look and comment the draft.
After the changes we did shortly before the submission deadline, there
are some inconsistecies and open items. We are aware of some of them and
probably there are some we are not aware of. For the problems we are
aware of, there are alternative solutions. In some cases, we did not
have a clear opinion which way to go and we would like to hear others
opinions.


Please find comments inline: 

	> 
	> This seems to be shaping up well. I think the requirements are
quite 
	> clear now.

It's good to hear that we have achieved at least a smal stepp in the
right direction :-).   
	> 
	> 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.



To avoid the combinatorial explosion of IANA values as Adam pointed out
in his comment
http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html  ,  we
decided to abandon the usage of sub-indications for  the use cases we
have in the draft and to register only discrete tokens as top-level
registrations.  (With county-specidfic ring and busy tones, we almost
got the problem Adam talked about.) The sub-indications are no longer
used in the current version of the draft. 

We thougt about changing the template in chapter 3 from 

                alert-indication = top-level *("." sub-indication)
        top-level        = let-dig [ *25let-dig-hyp let-dig ]
        sub-indication   = let-dig [ *let-dig-hyp let-dig ]

to just
		   alert-indication= let-dig [ *let-dig-hyp let-dig ]

But we are not sure if everyone would agree with this, so we would like
to have feedback from the WG on this issue.  
 

There is an inconcistency concerning the alert indications "priority",
"short" and "delayed": In chapter 4, they are now  top-level indications
in the alert-category "service", therefore in the same group eith
"auto-callback".     In chapter 7 there is a dedicated group for them
"Additional Indications for PBX-tones" in the "tones" alert-category.
We must have to decide which alternative to take. If we decide for the
chapter 4 alternative, we must change either the combination rule or the
example you complained about. 


	> 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's true, it's quite impossible to guess from the text what I meant
here. A group consists of the indications in one sub-chapter 7.3.1 to
7.3.5. I just looked for a way to avoid combinations of contradictory
URNs, e.g.   that <urn:alert:tone:internal> is combined with
<urn:alert:tone:external>   or  <urn:alert:tone:us> is combined with
<urn:alert:tone:de> .   If we agree that this kind of groups makes sense
and we keep it, some definition needs to be added.  But maybe there are
better proposals in the WG about how to avoid combinations of
contradictory indications?
 
	> 
	> It would be good to have more detail about how a recipient 
	> should deal 
	> with multiple URNs.

Yes. But I think we need to work in steps:
   -First we need to see if we have an aggreement on the new proposal
about registering discrete tokens ("internal" and "priority"  instead of
"internal.priority"). 
   -If this OK, we have to decide if we changed the template otr not. 
   -We need, I think,  some rules to avoid combinations of URNs which
are obviously contradictory.  

	> 
	> 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.

We changed this in this version, see
http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html .  If
we do not agree on this change, we need another mean to avoid
combinatorial explosion and the same time still being able to send
country specific ringing tones, country specific busy tones and country
specific whatever tones.   

 
	> 
	> 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.

This should be achieved by sending  two URNs, one from the group 7.3.1.
"Indications for PBX-tones"  and the second from the group 7.3.2.
"Additional Indications for PBX-tones" e.g.  <urn:alert:tone:internal>
and   <urn:alert:tone:short>.  

	> 
	> 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.

See above comments. 


	> 
	> 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.

I think  a PBX has ist own tones for normal, internal and external
ringing, different from those of the public network. 
I would keep the two worlds disjunct. E.g. , I have a sip handy which is
attached sometimes to the pbx and sometimes to my public carrier at
home, I may want the pbx ringing tone to be different from the ringing
tone at home. 
   


	> 
	> A nit: in 4.3.2 I would expext the forward to be indicated, 
	> if at all, 
	> with a 181 rather than a 180.

My understanding is that the URN should be transmitted in the 180
ringing after the forwarded call has reached ist final destination and
the phone is ringing at the UE, not in the 181 sent by the forwarding
proxy when it decides to to forward the call. Also the RFC 3261 only
allows Alert-Info in 180 responses. Or did I miss something here?

Thanks a lot
Laura

> 
> 	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
> > 
>