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

[<[e-mail]>]

Alan,

> I wonder if some of the confusion we are having is because we are not 
> cleanly separating ring tones from ringback tones. 

I fully agree with you.
 
What about defining a 3rd alert-category  "ringback-tone" and register
the country-codes only for this (<urn:alert:ringback-tone:al>)? And
maybe rename the alert-category "tone" in "ring-tone" ?  A "ring-tone"
URN is only sent in INVITE, a "ringback-tone" URN is only sent in a 180
Ringing.  

Or is something wrong with this? 

Thanks a lot
Laura

  


> -----Original Message-----
> From: Alan Johnston [mailto:[e-mail]] 
> Sent: Thursday, October 29, 2009 2:48 PM
> To: Paul Kyzivat
> Cc: Liess, Laura; [e-mail]; 
> [e-mail]; [e-mail]; Jesske, Roland
> Subject: Re: [dispatch] New version for the Alert-Info URNs 
> draft: draft-liess-dispatch-alert-info-urns-00.txt
> 
> 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.ht
> ml  ,  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
> >>>>
> >>
> >
> 
>