Subject: Re: [salud] Interpreting a series of URNs

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 26 Sep 2011 15:12:27 -0400

[as individual]

I'm finally getting back to thinking about this question.  I think it's the last
major issue we have to deal with.

Dale

---

From: Laura Liess <[email-masked]>
Date: Wed, 28 Sep 2011 11:45:06 +0200

Dale,

> major issue we have to deal with.

[LL] I think yes, if we adopt multiple URNs and the rules you proposed
in your algorithm.
Initially, we had 3 issues : 1) Single versus multiple URNs,  2)
Combinations of URNs and 3) Priority rules. These issues belong
together.

Back to your algorithm and our mail exchange from  9 to 22 of August:
Your algorithm works fine and has essential benefits.  The only
problem which we identified then was that after ruling out the signals
that are incompatible with the received URNs, we have more than one
remaining signals.

What do you think about continuing with the algorithm as follows:
For the set of remaining signals, the device checks if there are two
or more signals left which are not compatible with each other (in our
case, the example from your mail
http://www.ietf.org/mail-archive/web/salud/current/msg00150.html,
these are "signal-low" and "signal-high").  It discards all signals in
this group. (This means that for rendering proprieties (e.g.
"priority") for which the device did not receive any URN telling him
what to render, it takes the default.)  If, after this process, there
is no signal left, the device renders the default/normal rendering. If
there is only one signal left, the device renders this signal. If
there are more then one signals left, we have to deal with signals
which describe different proprieties of the signal. In this case, the
device should have internal rules about how to render this
combination, either (a) combined signal(s), or priorities or both.
(E.g. if  "signal-external"  and "signal-high" remain, the device may
render a combination of both or choose one of them.)  If the device
does not have any rules, it chooses one randomly.

Thanks a lot
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 28 Sep 2011 16:33:29 -0400

[as individual]

> From: Laura Liess [[email-masked]]
> 

I'm working on a sorting rule that might fix this problem.
I'll compare what it does to your examples here and
write it up.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 28 Sep 2011 17:02:15 -0400

[as individual]

I'm starting to work through this message and its relationship to
rendering algorithms.  Here's the first section.

> [LL] I see another advantage, from the point of view of the network:
> Proxies will want to overwrite Alert-Info URNs in certain situations.
> E.g. carriers don't want
> their customers to be bothered by SPIT INVITEs with <urn:alert:priority:high>,
> so they need a mean to tell the end device not to play the signal. If
> only one urn per category is allowed, the only thing the proxy can do
> is to find out if <urn:alert:priority:high> or a child of it is
> present and delete or overwrite it.
> However, if the call is a call between two units of the same
> enterprise with the VoIP traffic traversing the carrier network, the
> caller and the callee may not want  <urn:alert:priority:high> to be
> overwritten by the carrier. This is not possible with the rules
> described above without a lot of provisioning at the carrier, which is
> probably not posible at all in practice.
> With your algorithm principle, the carrier only needs to add
> <urn:alert:priority:normal > at the beginning of the urn-chain. The
> end device will have both URNs,  <urn:alert:priority:normal > and
> <urn:alert:priority:high >, in that order. Most end devices would
> eliminate devices
> <urn:alert:priority:high >. Enterprise devices, which will recognise
> the sender as beeing from the own enterprise, could keep and render
> it. The algoritm is great and gives us a lot of flexibility.

I think this situation can be handled even more simply.  We have to
assume (as you say in the last sentence) that the enterprise PBXs can
recognize when a call comes from another unit of the same enterprise
(and can thus be trusted).  If the call does *not* come from the
enterprise, the PBX can prepend <urn:alert:priority:normal>, which
will suppress the effect of any priority specification in the incoming
call.

BTW, how do the priority signaling levels interact with the Priority
header?

Dale