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

[Paul Kyzivat <[e-mail]>]

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

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

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

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

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.

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