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

[Alan Johnston <[e-mail]>]

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