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

From: <[email-masked]>
Date: Mon, 19 Oct 2009 14:38:54 +0200

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: [email-masked]
[mailto:[email-masked]] On Behalf Of
[email-masked]
Sent: Monday, October 19, 2009 1:00 PM
To: [email-masked]
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.

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 19 Oct 2009 16:44:03 -0400

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

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.

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 would be good to have more detail about how a recipient should deal 
with multiple URNs.

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.

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.

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.

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.

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

	Thanks,
	Paul

[email-masked] wrote:
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch
>

---

From: "Elwell, John" <[email-masked]>
Date: Tue, 20 Oct 2009 09:41:04 +0200

(I have removed the BLISS cross-post, by the way).

I agree with the points Paul makes. In addition, I am concerned about some of the values:

1. In 4.3.8, the value "short" is defined. This seems to have nothing to do with the meaning of a tone, but the way it is rendered. So in one locale, a short form of ring tone might denote low priority, say, whereas in another locale it might mean urgent, yet in a third locale it might mean some form of recall. Also, if my device renders tones visually, does displaying the alert icon or message only for a short period make sense? Finally, what does "short" mean to an automaton?

2. Given that Alert-Info is defined only for use in an INVITE request or a 180 response, how would values such as "busy", "intrusion" and "record" be used?

John

> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Paul Kyzivat
> Sent: 19 October 2009 21:44
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Subject: Re: [BLISS] [dispatch] New version for the 
> Alert-Info URNs draft: draft-liess-dispatch-alert-info-urns-00.txt
> 
> BLISS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/bliss
>

---

From: <[email-masked]>
Date: Wed, 21 Oct 2009 16:26:15 +0200

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.

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

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

	> 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 

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.  

	> different than "priority.short", or might not be defined for 

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.   

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

	> that if you don't know about ringing.fr you can just treat it 

See above comments. 

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

	> 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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 21 Oct 2009 21:06:48 -0400

responses inline

> used in the current version of the draft. 

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

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

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

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

> country specific ringing tones, country specific busy tones and country

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.

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

> home, I may want the pbx ringing tone to be different from the ringing

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.

> 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

---

From: <[email-masked]>
Date: Sun, 25 Oct 2009 18:06:00 +0100

Hi John,

Thank you very much for reading the draft and for the comments. 

Please  see answers inline:

	> From: Elwell, John [mailto:[email-masked]]

	> Sent: Tuesday, October 20, 2009 9:41 AM
	> To: Paul Kyzivat; Liess, Laura
	> Cc: [email-masked]; Jesske, Roland; [email-masked]
	> Subject: RE: [BLISS] [dispatch] New version for the 
	> Alert-Info URNs
draft:draft-liess-dispatch-alert-info-urns-00.txt
	> 1. In 4.3.8, the value "short" is defined. This seems to have 
	> nothing to do with the meaning of a tone, but the way it is 
	> rendered. So in one locale, a short form of ring tone might 
	> denote low priority, say, whereas in another locale it might 
	> mean urgent, yet in a third locale it might mean some form of 
	> recall. Also, if my device renders tones visually, does 
	> displaying the alert icon or message only for a short period 
	> make sense? Finally, what does "short" mean to an automaton?

I am not very familiar with PBXs, this is Alan's part, but my
understanding is that the PBX tones URNs are inserted by the local PBX
system (Proxy, Application server, maybe a UA directly connected to the
PBX) and rendered  by one UE of the same enterprise, so that, in
generally, there is a common understanding about the meaning of "short".
Maybe we could add a description about how itshould be used? 

> 
> 2. Given that Alert-Info is defined only for use in an INVITE 
> request or a 180 response, how would values such as "busy", 
> "intrusion" and "record" be used?

This is true. I just did not think about it when I wrote this part. We
should define only country ringing tones. 

Thanks a lot
Laura

---

From: "Elwell, John" <[email-masked]>
Date: Mon, 26 Oct 2009 08:40:50 +0100

> From: [email-masked] [mailto:[email-masked]] 
> Sent: 25 October 2009 17:06
> To: Elwell, John; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> [email-masked]
> Alert-Info URNs draft:draft-liess-dispatch-alert-info-urns-00.txt
> 
> 
> Hi John,
> 
[JRE] I agree it could be used in this way, but I thought the whole point of the draft was to define semantic names for ring tones, not names that suggest a particular means of rendering.

John

> > > > 	Filename        : 
> draft-liess-dispatch-alert-info-urns-00.txt
> > > > 	Pages           : 25
> > > > 	Date            : 2009-10-19
> > > >

---

From: <[email-masked]>
Date: Wed, 28 Oct 2009 10:22:46 +0100

You are right that discrete items and multiple URNs are much more
complex than the original hierarchical URNs. Multiple URNs add a lot of
new problems.
But do you see other possibility to solve Adam's issue? In principle, we
do not have the problem with the URN which we want to define in the
current draft, if we drop chapter 4.2 and only define the ringback tones
as country-specific. As John pointed out we can not send Alert-Info in a
busy-response anyway. 
Maybe we can restrict the IANA registration to Alert URNs which we know
people intend to implement? This will probably reduce the number
considerably, but the theoretical problem remains. 
I will take this as an open issue for the dispatch meeting slides. I
hope Adam will be there because it was his proposal to use combinations
of discrete items rather than hierarchy. I am open for both and also for
a new proposal. 

Additional comments inline.

> from one or the other of those. I don't really desire any 

The scenario  you describe is also valid for me. I think it depends on
the job they are doing if people using a PBX wants to know a call is
internal or external. Call centres, sales people have other needs than
we have and as far as I know customers often require these features from
PBX-systems. I think Alan added this stuff to the draft because it is
required by Avaya's customers. 

> least ringback should be french.

I don't see the contradiction here:  external is inserted by the
PBX-system in the INVITE to my phone if the caller is external. How
could  my phone decide if the caller is external or internal?
If I call someone in France the French phone (or ist proxy) may insert
the Alert-Info URN for france into the 180 ringing response. 
These are for me two different scenarions. Or maybe I did not understand
you correctly?

I should probably change wording in the draft and use ringback instead
of ringing in connection with country tones. The current text is often
quite confusing.   

> in a position to perform that role. But in any case it is a nit.

It's true, only a statefull proxy is able to insert this URN if it is
send in 180 ringing. 
But this is the scenario for which this particular A-I URN is defined. 

The caller's UA renders a ringback 
tone when it receives the 180, not earlier. The URN should tell the the
caller's UA to render 
a specific ringback *instead* of the ringback used for not forwarded
calls. 
In principle the 181 tells the caller's UA that the call has been
forwarded and the UA may decide, 
independent from the proxy, to notity the caller about this. 

But this was my personal opinion and this one of Alan's use cases. 
I am not sure he follows the discussion, so let me check with him. 

Thank you
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2009 10:10:01 -0400

[email-masked] wrote:
> But do you see other possibility to solve Adam's issue?

Perhaps its a messy problem any way you cut it.

My main concern is not with going this way, but that if this way is 
taken then it be made very clear how the various combinations are to be 
interpreted by the recipient. There ought to be some obvious algorithm 
to get from any valid combination to something to render.

> In principle, we

If it makes sense, I wouldn't exclude the possibility of extending the 
use of Alert-Info to additional messages.

> considerably, but the theoretical problem remains. 

AFAIK there is no reason why all the URNs have to be drawn from the same 
URN scheme. Some other organization can define their own URNs and start 
using them.

But that works more easily if the Alert-Info URNs are mutually 
exclusive, so the recipient just chooses one it understands and renders 
that.

But I guess it can still work in the multi-dimensional approach. Each 
URN that is understood must imply the values of one or more of those 
dimensions.

> These are for me two different scenarions. Or maybe I did not understand

I don't think it is a contradiction or a problem.
But it affects the use cases. And it introduces the potential need for 
some added policy decisions about what to honor and what not to honor. 
In some cases a pbx acting on behalf of its phone users may want to 
replace an incoming Alert-Info, or add to it. And those 
replacements/additions may or may not be influenced by what was in the 
incoming Alert-Info. Its an environment rich with possibilities.
I think its at least worth pointing out.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Oct 2009 11:36:01 -0500

> URN that is understood must imply the values of one or more of those

this is starting to sound like multipart/related and multipart/alternative.

Perhaps we are barking up the wrong tree, and alerts should be body
parts selected by a new content-disposition?

--
dean

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 28 Oct 2009 13:34:28 -0400

> parts selected by a new content-disposition?

Did you imply a smiley on this message?

On the off chance that you did not, its important that it be possible 
for intermediaries to add the Alert-Info, which pretty much excludes 
using body parts.

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Wed, 28 Oct 2009 19:54:11 -0500

On Oct 28, 2009, at 12:34 PM, Paul Kyzivat wrote:

> On the off chance that you did not, its important that it be  
> possible for intermediaries to add the Alert-Info, which pretty much  
> excludes using body parts.

Not if the intermediaries are B2BUAs.  I'm wondering about alert-info  
and authentication. Perhaps anything that can change the alerting  
model really OUGHT to be a B2BUA and capable of re-authenticating the  
request.

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2009 09:05:14 -0400

Dean Willis wrote:
> and authentication. Perhaps anything that can change the alerting model 
> really OUGHT to be a B2BUA and capable of re-authenticating the request.

My philosophy has always been that a UA must be very careful about 
trusting Alert-Info unless it is in an environment where something it 
trusts is doing screening for it.

The URN approach helps with this, because then the UA is only using the 
URN as a key into a database of of alerts that the UA is willing to 
render. But even so, some care is required. For instance, the "internal" 
vs. "external" ring choice would not be very effective if an arbitrary 
caller could decide whether it was internal or external. If that 
decision isn't made by the UA itself, then it needs to be made by 
something it trusts.

That doesn't *necessarily* mean that the screening server must be a 
B2BUA. It could be a proxy if used in a controlled topology. The "sip 
pbx" implementations I'm familiar with *are* B2BUAs, but I think some 
are not.

Also, even without trust, some info inserted by intermediaries might be 
acceptable to a UA. For instance, a proxy in front of the callee might 
insert an Alert-Info in the 180 indicating that the call was coming from 
France, proposing a French ringback tone. The caller, if it is capable 
of understanding that, may be willing to render it that way even though 
it doesn't know the callee or have any particular trust in it.

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Thu, 29 Oct 2009 08:47:42 -0500

Paul,

Thanks for your comments on the draft.  See mine below.

Thanks,
Alan

Paul Kyzivat wrote:
>>     >     > This seems to be shaping up well. I think the 
>> requirements are
>> quite     > clear now.
>>
>> right direction :-).       >     > I don't fully understand what is 
>> intended regarding
>> combination of     > multiple alert URNs for a specific situation. 
>> Section 4.5
>> states:
> 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 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.
>>

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

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

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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 29 Oct 2009 08:53:34 -0500

Paul,

One comment below.

Thanks,
Alan

Paul Kyzivat wrote:
> 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.
>
> different than "priority.short", or might not be defined for priority 
> at all.
>
> 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.

As it has been pointed out, short, long, and delayed are not compatible 
with the semantic approach of this draft so I think we should remove 
them as they are currently.  I need to investigate to see whether they 
have been used in the past as stand-ins for a particular service, or 
whether we need to define specific tones for them.

Priority, I still think, is useful - we just need to figure out how to 
fit it in properly.

> 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.
>
> is "normal" different from "ringing"? I would think that PBX tones 
> would be a superset of common pstn tones.
>

---

From: Francois AUDET <[email-masked]>
Date: Thu, 29 Oct 2009 06:58:36 -0700

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 <[email-masked]> wrote:

>>> right direction :-).       >     > I don't fully understand what  
>>> is intended regarding
>>>    >     > >    finally, a short Albanian auto-callback tone could  
>>> be
>>> indicated
>>>    >     > >    Alert URN Indications from the same group should  
>>> not be
>>> combined.
>>>
>>>
>>>
>> So, maybe that is the confusion. I didn't understand that from  
>> reading the text.
>>
>> 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.
>>
>>> 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
>> 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.
>>>
>>> "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
>> 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.
>>
>>> "additional     > indication" name is always defined with regard  
>>> to its parent,
>> 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.
>>>
>>> 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.
>>>
>>> tones. In     > what way     > is "normal" different from  
>>> "ringing"? I would think that PBX     > tones would     > be a  
>>> superset of common pstn tones.
>>>
> 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.
>
>>
>> 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.
>>>
>> 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
>>>>
>>>>> the Introduction chapter)   - Requirements for the Alert-Info  
>>>>> URNs mechanism   - Alert-Info URNs Indications for country- 
>>>>> specific tones

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 29 Oct 2009 11:11:54 -0400

> Urn:tones.alerting.Albanian

Yeah, that had occurred to me.

But I think Adam's point was that you can find other orderings that make 
more sense in other contexts:

URN:tones.alerting.Albanian.short vs. URN:tones.alerting.short.Albanian

It may actually be the case that a combination of a hierarchy for some 
things, and independent values (dimensions) for other things might work 
out. But I'm just thinking out loud.

	Thanks,
	Paul

---

From: <[email-masked]>
Date: Fri, 30 Oct 2009 16:34:51 +0100

Alan,

> 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

> From: Alan Johnston [mailto:[email-masked]] 
> Sent: Thursday, October 29, 2009 2:48 PM
> To: Paul Kyzivat
> Cc: Liess, Laura; [email-masked]; 
> [email-masked]; [email-masked]; Jesske, Roland
> Subject: Re: [dispatch] New version for the Alert-Info URNs 
> draft: draft-liess-dispatch-alert-info-urns-00.txt
> 
> Paul,
> 
> >>     >     > >    finally, a short Albanian auto-callback 
> tone could be
> >> indicated
> >>     >     > >    Alert URN Indications from the same group 
> should not be
> >> combined.
> >>
> >>
> >>
> renderings 
> "ringing"?