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

[Francois AUDET <[e-mail]>]

What about reverting the tree order, so that you put the country id  
last, so you can ignore it if you don't care?

Urn:tones.alerting.Albanian





On Oct 29, 2009, at 6:47, Alan Johnston <[e-mail]> wrote:

> Paul,
>
> Thanks for your comments on the draft.  See mine below.
>
> Thanks,
> Alan
>
>
> Paul Kyzivat wrote:
>> 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.
>>
>
> Perhaps, or perhaps not.  Remember that this is just a suggestion,  
> rather than a command about a ring or ringback.  It is perfectly  
> reasonable for UAs to simply ignore the Alert-Info.  So, the sparse  
> scenario, where a server puts in as much information as possible,  
> possibly via multiple URNs, and the UA uses the ones it knows and  
> ignores the rest.
>
>>>    > 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.
>
> Remember, the use case for normal is driven by shared appearances -  
> we want to insert an appearance number parameter into the Alert-Info  
> but we do not want to convey any particular Alert, so we use normal  
> as a no-op.
>
>>
>>> 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.
>
> I wonder if some of the confusion we are having is because we are  
> not cleanly separating ring tones from ringback tones.  I'm going to  
> think a bit how we would structure this if we had separate  
> registries or trees for these.  For instance, the country  
> specification would only make sense for ringback tones.  Also,  
> things like priority would only apply to ring tones, etc.
>
>>
>>
>> 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.
>>
>
> Right, this is mixing ring tone and ringback tone in your example,  
> so while this seems confusing, there is no actual confusion in  
> practice.
>
>>>    > 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
>>>>>
>>>
>>
>
> _______________________________________________
> dispatch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dispatch