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

[Paul Kyzivat <[e-mail]>]

responses inline

[e-mail] wrote:
> 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. 

So, maybe that is the confusion. I didn't understand that from reading 
the text.

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

I don't know yet. The alternative is apparently to have multiple URNs 
and interpret the combination. I'm having difficulty imagining how that 
would work. I have always assumed that in the end a URN would be "looked 
up" locally by the UA and resolved to *something* that it could render.

I will keep an open mind, but I'll need a better explanation of how 
multiple URNs are to be combined into *something* that can be looked up.

> 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 seems like what you must be doing is replacing a hierarchy with an 
N-dimensional matrix which is sparsely populated. That seems harder to 
deal with.

> 	> 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 don't think that works. I can't evaluate whether the approach works 
without a practical understanding of how it could be used. In the end I 
have to render *something*. And I have to choose what that is. While 
hierarchical names present a class of problems, its at least clear how 
to resolve them to something I have.

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

I understand Adam's issue. I just don't (yet) understand how/if the 
alternative works.

It seems that what you propose is a multidimensional space, where every 
point in that space is potentially rendered uniquely. But in practice 
values will often be supplied for some but not all of the dimensions. In 
that case we end up specifying some "slice" of the array. I guess in 
this case you could look to see what you would render for each point in 
the slice. If those are all identical, then you are in good shape. But 
if they are not, then what? Do you pick one of the points? That amounts 
to choosing a default value for each unspecified dimension. Is that the 
right answer?

I also understand that this approach works great if all the renderings 
are audio, and each of the dimensions is an input to a synthesizer 
algorithm. But that pretty much only works for audio. If you have to 
render in user friendly text, or in flashes of light then it isn't going 
to work very well. Nor does it work for audio if you want to use unique 
sound clips for some or all of the cases.

> 	> 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 have a sip pbx phone on my desk. I don't have any distinction for 
internal vs. external, and have no clue how "normal" would be different 
from one or the other of those. I don't really desire any distinction on 
any of those terms.

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

I don't really have any objection to a bunch of "names" for extra 
arbitrary ring types. The real issue is deciding when to use one or 
another. Is the assumption here that these will typically be inserted by 
some agent acting on behalf of the phone acting on them, rather than 
being inserted by "the other" party? IOW, *my* pbx decides that an 
incoming call from you is "internal" or "external" and inserts a 
suitable value by its policy, rather than *your* phone deciding the call 
is internal or external and inserting the value that I then render.

It seems like you might have both models in mind. On one hand *my* pbx 
is deciding if the call to me is internal or external, but the other end 
is indicating it is a French phone rather than a US phone and so at 
least ringback should be french.

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

I checked, and you are right that A-I isn't allowed in 181. Sorry about 
that. But it seems like a mistake to me.

The behavior you describe requires there to be a stateful agent in the 
network that is aware this has happened. In general there may be nothing 
in a position to perform that role. But in any case it is a nit.

	Thanks,
	Paul

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