Subject: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Fri, 20 Jan 2012 21:03:25 +0600

Hi 

Greetings!

I am very new to this area. Advance apologies if my ideas sounds completely misaligned.

I found current way of using multiple Alert-Info URNs and Priority Rules a bit difficult to use and implement. I can see that we have 6 fixed alert-categories and the Alert URN Format is 

"URN:alert:" alert-identifier

And format of alert-identifier is

alert-category ":" alert-indication

and alert-indication is a single value.

If we can allow to include multiple value in alert-indication separated by comma (,) and the order of appearance will decide the order of priority for the alert-indication value then I think it will be easy to implement from the device side.

So instead of sending multiple URN like 
URN:alert:source:family 
URN:alert:source:friend
URN:alert:source:internal
URN:alert:source:unclassified

device will send URN as 

URN:alert:source:family,friend,internal,unclassified

Besides, if we disallow or ignore (or latest appearance overrides earlier) multiple appearance of alert-category then it will be more easier to implement.

I have another suggestion regarding the values of alert-category priority. If we make it a number like 0, 1, 10 anything may be between 00 to 99 or 0-9 to make it simple, then I think devices will have the provision to prioritize 2 calls/sessions (in case of call waiting or line busy) easily and devices will be able to implement specific logics for them.

And if we can introduce another alert-category to guide the call/session handle behavoir according to service or priority for the devices e.g. force connect on busy, notify back when free, delivery report (read, delivered, not delivered etc) (as we are handing SIP sessions - the URNs should cover IM and short messages as well may be).

Thanks & Best Regards

JEWEL
Firoze M Zahidur Rahman

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2012 10:43:07 -0500

> URN:alert:source:family,friend,internal,unclassified

In the above you have not included the header. It would really be:

Alert-Info: URN:alert:source:family
Alert-Info: URN:alert:source:friend
Alert-Info: URN:alert:source:internal
Alert-Info: URN:alert:source:unclassified

and your preference would seem to be:

Alert-Info: URN:alert:source:family,friend,internal,unclassified

But the latter cannot work. The key point is that Alert-Info takes URIs 
as arguments (including URNs), which can be separated by commas or as 
separate header fields. Because of that, in your latter case, "friend" 
is syntactically incorrect because it is not a URI.

Aside from that I don't understand why you think what you propose is 
easier to use or implement. (I agree that is uses fewer bytes, but that 
doesn't make it easier.)

	Thanks,
	Paul

> Thanks&  Best Regards
> _______________________________________________
> salud mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/salud
>

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Fri, 20 Jan 2012 22:54:17 +0600

Hi 

Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. As this extension enables UA or devices to choose/implement features as per internal implementation logic - my idea was to make the structure as - all values in single line. So that while implementing device will not have to think about same category multiple times. Even if same category multiple times is allowed - it will completely refresh/overrule earlier appearance.

And the order of appearance wise priority (I think corrent approach is also same, priority is decided by order of appearance of URN in header field) also handles the priority decision making process unchanged.

Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling all values of a category in single URN makes sense.

Thanks & Best Regards

Jewel

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, January 20, 2012 11:43 PM
To: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

        Thanks,
        Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2012 14:49:54 -0500

> Instead of comma(,) we can use dot(.) or slash(/) separated values may be. Or we can find some other way to make it URI compatible. But that can be though/found out if everyone thinks that bundling…

If you look through the salud mail archives you will see that combining 
things into a single URN was proposed and discussed, but we settled on 
what we have now.

	Thanks,
	Paul

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Sat, 21 Jan 2012 10:39:58 +0600

Hi 

It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it.

However, there are couple of things I wanted to highlight in my first mail.

1. URN string format - bundling multiple values (on which I may be wrong as this is already discussed and decided - I will go through the earlier mails from the archive to clarify my understanding)

2. Values of Priority Field - Can we use numbers 0-9 or 00-99

3. Can we have another category to define UA/device reaction/behavior?

Particularly for 2 and 3 the reason I am proposing this is

1. Alert-Info can be present in INVITE and if it is present in Invite then it will be nice to have a mechanism to guide/standardize the handling process/logic of the Alert-Info for the devices receiving Alert-Info

2. As we have multiple URN and URNs defining the service, source, priority etc. I assume the priority is the priority for the session/call. If we implement priority as a number then sorting on the priority number for currently ongoing sessions can be done at the device side - and logics can be implemented like force disconnect for higher priority calls, do not notify for lower priority calls, notify back the user for certain priority calls, divert if priority is less than some specific values. And we can leave it up to the implementation.

With these features I think we will be able to standardize the implementation of Reverse Ring Back Tone, Custom Ringtone/Notification decided by caller, Call Back Notification Services (where caller will be notified whenever the line is free), Handling of Promotional/Low Priority Calls (Voice or Message/SMS Broadcasts) etc.

Thanks & Regards

JEWEL
Firoze M Zahidur Rahman
F  +88 017 13014806, +6 013 6349764
3 +88 02 9882314, +6 03 90581043

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, January 21, 2012 1:50 AM
To: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 20 Jan 2012 23:53:52 -0500

> It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it.

I don't know offhand. The proposal was made by Dale Worley, so look from 
mails from him. It was several months ago, perhaps more than a year.

> 1. URN string format - bundling multiple values (on which I may be wrong as this is already discussed and decided - I will go through the earlier mails from the archive to clarify my understanding)

Already decided - above discussion.

> 2. Values of Priority Field - Can we use numbers 0-9 or 00-99

Keep in mind that the point of this is to guide the rendering of alerts 
to a user. I find it hard to believe that the user will distinguish 10 
or 100 different alert variations based on priority.

There is already a sip Priority header to indicate the priority of the 
message itself.

> 3. Can we have another category to define UA/device reaction/behavior?

I don't understand what you mean.

> 1. Alert-Info can be present in INVITE and if it is present in Invite then it will be nice to have a mechanism to guide/standardize the handling process/logic of the Alert-Info for the devices rece…

That is already provided.

> 2. As we have multiple URN and URNs defining the service, source, priority etc. I assume the priority is the priority for the session/call. If we implement priority as a number then sorting on the…

See above.

	Thanks,
	Paul

> Thanks&  Regards

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Sat, 21 Jan 2012 15:25:21 +0600

Hi

SIP Call priority will not help this case. User will not have to identify different alerts - the UA will have to identify different alerts. And I am thinking about alert notifications like

1. Call Waiting Notifications
2. Disconnect the ongoing call and establish the higher priority call
3. For SMS/IMs - Message Delivered but not read (Like Blackberry Messenger)
4. For SMS/IMs - Message Not Delivered 
5. For SMS/IMs - User is typing a message (Like Blackberry Messenger)
6. For video calls - User has muted his/her mic
7. Presence Services - User Status Changed 
8. Etc.

And all these different types of notifications should have different priority and UA/Device should have its own implementation of handling these alert notifications. And I think all these are targeted for different types of SIP Sessions/Applications. I am not sure if the RFC scope is for Voice Calls only or not.

> I don't understand what you mean.

When we use IM Clients - and someone knocks you - IMs can directly pop up an window with message. Or IM can display a notification that "Mr. X is inviting you for a conversation". So for the same request - the handling of the UA is different. In many case this is set from the UA itself.

Or, if we allow the behaviors like display Customized Picture decided by Caller, Or Play Ringtone (decided by caller) this type of features then I think this additional category will help.

I am not sure if I could make myself clear or I am completely sounding irrelevant. If I am please do point that out. 

Thanks & Regards

Jewel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Saturday, January 21, 2012 10:54 AM
To: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

See above.

	Thanks,
	Paul

---

From: Laura Liess <[email-masked]>
Date: Mon, 23 Jan 2012 15:53:54 +0100

> It will be very nice if you please can refer the discussion date or thread of the multiple value discussion. I am not able to find it.

As Paul already pointed out we already had this discussion, not only once.

The first discussion was in BLISS, back in 2009.  (This draft was
first submitted in BLISS, then moved to DISPATCH, then we got our own
miniWG SALUD. ) In the first versions of the draft in BLISS followed a
similar direction as you propose. See Section 7.3 in
http://tools.ietf.org/id/draft-alexeitsev-bliss-alert-info-urns-02.txt
 .
In http://www.ietf.org/mail-archive/web/bliss/current/msg01027.html
Adam Roach pointed out that we have to register all combinations with
IANA an "If someone adds another semantic dimension, the size of the
registry continues to grow exponentially".

The second discussion on this issue was in SALUD, see  the messages
around  http://www.ietf.org/mail-archive/web/salud/current/msg00038.html
. We call  this issue "multiple URN vs. single URN". Again, we came to
the conclusion that also "single URN" is much more simple to implement
for the receiving UA, we run with it into the problem identified by
Adam, the IANA registry grow exponentially when new values are
registred. With "multiple URNs",  we don't have this problem.

A receiving UA has to be able to deal with combinations of Alert-Info
URNs anyway because  more than one SIP network elements in the message
path (the sending UA, proxies, B2BUAs) may insert Alert-Info URNs.

Kind regards
Laura

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Mon, 23 Jan 2012 21:05:25 +0600

Hi

Thanks a lot for the clarification. I think my proposal and the your discussion point is not same. My proposal was a URNs like

Alert-Info: <URN:alert:service:normal.call-waiting.forward>
Alert-Info: <URN:alert:source:family.friend.internal.unclassified>
Alert-Info: <URN:alert:priority:high.normal> 
etc

Or may be

Alert-Info: <URN:alert:source:family.friend.internal.unclassified>, <URN:alert:service:normal.call-waiting.forward>, <URN:alert:priority:high.normal>

Or something similar. This will help the UA to decide e.g. regarding "service" -priority is normal then call-waiting and finally forward. So UA will try to alert for normal call, if not possible (may be busy in another call) notify for call-waiting or finally notify for forwarding. And the priority for the selection can be determined by the order of appearance.

And I am not sure if this will increase no of IANA registration. The registration can follow

service RFCXXXX
source RFCYYYY

etc.

Best Regards

Jewel

-----Original Message-----
From: Laura Liess [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 8:54 PM
To: Firoze M. Zahidur Rahman
Cc: [email-masked]; Paul Kyzivat; Roland Jesske
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

Kind regards
Laura

---

From: Laura Liess <[email-masked]>
Date: Mon, 23 Jan 2012 16:18:59 +0100

Hi,

During the discussions on this draft, not only in SALUD but also in
BLISS and DISPATCH,  people identified additional possible use cases
which we did not include in the draft. If we try to include every use
case which comes up, we will never get the draft ready (which is now
already 3 years old, first version was back in Feb. 2009).  What we do
whith this draft is to provide the basic mechanism which is
extenssible in any way, see requirement 5, so that people and
organisations can define extenssions, this means, new categories or
values.

We should finish the basic draft as soon as possible. For your use
cases, which seem to me to be quite interesting, I propose you write a
new draft which defines and registers with IANA a new category e. g.
"priority_for_services" or something like that.

Kind regards
Laura

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Mon, 23 Jan 2012 21:29:51 +0600

Hi 

My proposal is for changing the priorities to 0-9 or 00-99 - I mean numbers instead of high, normal and low. I think that will cover the handling of priority. If we don't want the additional category its fine as devices can have their own logic and configuration option to implement that.

Another question - are you completely discontinuing URI support of Alert-Info with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely deployed across many operators may get impacted if we completely remove URI support and will be a significant bottleneck to migrate to SIP. Because in this case the URI is going to be inserted by Switch/Proxy mostly.

Regards

JEWEL
Firoze M Zahidur Rahman

-----Original Message-----
From: Laura Liess [mailto:[email-masked]] 
Sent: Monday, January 23, 2012 9:19 PM
To: Firoze M. Zahidur Rahman
Cc: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

Hi,

Kind regards
Laura

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 23 Jan 2012 11:02:34 -0500

> My proposal is for changing the priorities to 0-9 or 00-99 - I mean numbers instead of high, normal and low. I think that will cover the handling of priority. If we don't want the additional catego…

If you look at the example algorithm that has been proposed, making this 
change would complicate things. If you don't have different handling for 
every distinct priority value, then configuring things to handle ranges 
of priorities equivalently would be messy.

Do you seriously think that there would be separate forms of alerting 
for each of 10 or 100 different priority values?

> Another question - are you completely discontinuing URI support of Alert-Info with this RFC? I think Caller Ring Back Tone (CRBT) - which is widely deployed across many operators may get impacted i…

We aren't discontinuing anything with this draft.
Other uses of Alert-Info, with URIs that are not the form of URN 
specified in this draft, is still possible and unchanged.

However other usage is not well standardized. Presumably its clear that 
when a dereferencable URL is provided, then the intent was that it be 
rendered. But there are great impediments to that usage, and it isn't 
widely supported. And usage with non-dereferencable URIs was never defined.

We do not specify what to do if both our URNs and other URIs are 
included. It was in the past always local policy to decide what to do 
with multiple URIs, and it remains so when there are multiple URIs that 
are not all of the form we specify. I don't think there is anything we 
can usefully add in that case.

	Thanks,
	Paul

> 2012/1/21 Firoze M. Zahidur  Rahman<[email-masked]>:
>> Hi
>>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 23 Jan 2012 15:23:44 -0500

I am just starting to read this thread.  These are my preliminary
responses.

> From: Firoze M. Zahidur  Rahman [[email-masked]]
> 
> I found current way of using multiple Alert-Info URNs and Priority
> Rules a bit difficult to use and implement. I can see that we have 6
> fixed alert-categories and the Alert URN Format is
> 
> If we can allow to include multiple value in alert-indication
> separated by comma (,) and the order of appearance will decide the
> order of priority for the alert-indication value then I think it will
> be easy to implement from the device side.
> 

Overall, there is the architectural choice: (1) use one URN to provide
multiple values (for possibly many categories), or (2) use multiple
URNs, each one of which provides one value for one category.

Note that the implementation effort is the same for either approach,
as the UA must be able to process all the values together to select
its alerting signal.  So the choice is driven by two considerations:
(1) Is the approach compatible with the concept of URN(s) describing
alerting signals?  (2) How difficult is it to describe the
architecture to implementers?

The consensus of the WG is that the "multiple URNs" approach is
preferable because it is architecturally acceptable, and much easier
to describe to implementers.

> Besides, if we disallow or ignore (or latest appearance overrides
> earlier) multiple appearance of alert-category then it will be more
> easier to implement.

The current design is that the *earlier* URN overrides the *later*
URN, which we believe is somewhat more natural.  Of course, the
reverse rule would have no greater or lesser descriptive power.

> URN:alert:source:family,friend,internal,unclassified

the approach in the draft is:

Alert-Info:  urn:alert:source:family, urn:alert:source:friend,
	     urn:alert:source:internal, urn:alert:source:unclassified

which means to alert the call as "family" if possible, and if that is
not possible, then to alert it as "friend" if possible, and if that
is not possible, etc.

> I have another suggestion regarding the values of alert-category
> priority. If we make it a number like 0, 1, 10 anything may be between
> 00 to 99 or 0-9 to make it simple, then I think devices will have the
> provision to prioritize 2 calls/sessions (in case of call waiting or
> line busy) easily and devices will be able to implement specific
> logics for them.

It would be reasonable to specify priorities as numbers.  Effectively,
the current draft provides three values, 1, 2, and 3.

However, we only consider priority as a characteristic affecting how a
call is alerted, not how the UA handles the call.  But I suppose that
the priority could be used for that.

> And if we can introduce another alert-category to guide the
> call/session handle behavoir according to service or priority for the
> devices e.g. force connect on busy, notify back when free, delivery
> report (read, delivered, not delivered etc) (as we are handing SIP
> sessions - the URNs should cover IM and short messages as well may
> be).

The alert URNs are not intended to control how the call is handled,
only its alerting signal.  And alert URNs would not be sufficient for
many handling specifications.  For example, "notify back when free" is
the "call completion on busy subscriber" function, which is much more
complicated to implement in an effective manner than simply attaching
an indication to the INVITE.  (See draft-ietf-bliss-call-completion-14.)

However, alert URNs can be used when initiating IM sessions using MSRP,
as those sessions are set up using SIP INVITE.

In regard to paging IM, using the NOTIFY method, RFC 3428 does not
envision using Alert-Info to specify how the message is announced to
the recipient, but using Alert-Info seems to be a natural extension.

Dale

---

From: "Firoze M. Zahidur Rahman" <[email-masked]>
Date: Tue, 24 Jan 2012 09:21:56 +0600

Hi

>for each of 10 or 100 different priority values?

There are different incidents when users will be required to be notified in a SIP UA/Device e.g Incoming Voice Call Indicatin, IM Request, Incoming Video Call Indication etc. For all these incidents I think users will need different types of notification. The role of priority will come into the picture when you already in a session and another incident comes up e.g. You are in a voice call, another IM invitation comes up, or another IM Request comes up, or may be 2 incidents - one voice call is ringing and and another IM comes or other way round. In such cases I think priority will be able to play a role.

My proposal is primarily change the priority values to numbers instead of high, normal and low. And we can also decide on a range of values to be used without making it widely open to the implementers - may be 10 or 100.

>widely supported. And usage with non-dereferencable URIs was never defined.

Shouldn't this RFC provide a guidance regarding this? As one of the main target of this effort is to standardize the Alert Notification. Standardization of user alert notification on UA/Devices are very much required (you can find so many option to set up the notification/alert tones of smart phones to be set up and every vendor implements it differently). Standardization of Alert Notifications will enable a lot of content based services to be developed around this. [Only the option of having 3 way call and opening up of Media channel after ACM message of SS7 signaling enabled to develop services like Personalized Ring Back Tone which is a very popular service in many operators]. So if alert notifications can be standardized properly this will open up a lot of service opportunities I think.

>can usefully add in that case.

Shouldn't this be covered as part of this work?

Jewel

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Paul Kyzivat
Sent: Monday, January 23, 2012 10:03 PM
To: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

        Thanks,
        Paul

---

From: Laura Liess <[email-masked]>
Date: Tue, 24 Jan 2012 14:41:18 +0100

> Or something similar. This will help the UA to decide e.g. regarding "service" -priority is normal then call-waiting and finally forward. So UA will try to alert for normal call, if not possible (m…
If I understand correctly, in your proposal the rendering for
<URN:alert:service:normal.call-waiting.forward> would depend of the
state of the end device. The rendering for this URN would be the
"normal" when the end device is idle and "call-waiting" or "forward"
when the device is "busy". I am not an expert for URIs/URNs, but I
would say this is not allowed by the definition of the URNs. The RFC
1737 describes the requirements for URNs:

 o Global scope: A URN is a name with global scope which does not
     imply a location.  It has the same meaning everywhere.

   o Global uniqueness: The same URN will never be assigned to two
     different resources.

   o Persistence: It is intended that the lifetime of a URN be
     permanent.  That is, the URN will be globally unique forever, and
     may well be used as a reference to a resource well beyond the
     lifetime of the resource it identifies or of any naming authority
     involved in the assignment of its name.

I think your proposal does not allign with the definition of the URNs.
It can not be that the meaning of a URN depends on the algorithm at
the receiving end device. I am not aware of examples where one URN
contains names with contradictory meanings and using such syntax would
be, if not forbidden, very confusing. I think it would be difficult to
pass this syntax through the IESG review. The syntax we have now was
discussed and reviewed by IETF experts in the past. I am not willing
to change it now into a syntax which may be incorrect.

And I really  don't see why
<URN:alert:service:normal.call-waiting.forward> should be easier to
implement than
 <URN:alert:service:normal> <URN:alert:service:call-waiting>
<URN:alert:service:forward>. The algorithm described in the draft is
not mandatory, it is just an example. You are free to use an algorithm
of your choice.

However, it would make sense for me to consider your use case within
the priority rules in Section 7, because they are mandatory. We
eventually ( if the WG agrees to that) could add following at the end
of the text inside the brackets in the requirement b.: "(because it
does not recognize the URN or the URN's effect is precluded by
preceding URNs   *** or not compatible with the current state of the
end device or explicitely not desired ***  )" . (The new text is
between ***.) Would you agree to that?

Regards
Laura
.

---

From: Laura Liess <[email-masked]>
Date: Tue, 24 Jan 2012 16:23:47 +0100

Hi,
Please see inline.

> My proposal is primarily change the priority values to numbers instead of high, normal and low. And we can also decide on a range of values to be used without making it widely open to the implement…

[LL] The WG deliberately choosed names which are understandable for
humans and not numbers, where the exact meaning must be defined in the
RFC. If you choose numbers for priorities, you have to define if 1 is
the highest or the lowest priority. Many systems only understand three
priorities: normal, low and high. As Paul already said, using more
priorities then this would complicate things for these devices.
So,  I would do not agree to change the current definition for the
priority stuff. But it seems that you have quite nice and interesting
use cases, so it would probably make sense for you to write a new
draft, describe the use cases and define a new category or just
numerical subindications for the current priority indicatios, e.g.
urn:alert:priority:normal:<n>   where n=1...100.

> Shouldn't this RFC provide a guidance regarding this? As one of the main target of this effort is to standardize the Alert Notification. Standardization of user alert notification on UA/Devices are…

[LL]  It was already agreed by the WG that this issue is not in the
scope of this draft, I think it is not in scope for the WG charter.
And we have to finish the basic draft soon, we should have submitted
it to the IESG in August last year.

But this is sure an interesting issue so why don't you go ahead and
submitt a new draft whith the requirements, use cases and whatever
else about this subject?

Kind regards
Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Jan 2012 15:07:39 -0500

The mailing list archive of the most recent discussion of the
"multiple URN vs. single URN" issue starts at 
"Currently known technical issues"
(http://www.ietf.org/mail-archive/web/salud/current/msg00131.html)
in http://www.ietf.org/mail-archive/web/salud/current/maillist.html
and continues through July 2011.

Dale

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Paul Kyzivat [[email-masked]]
Sent: Friday, January 20, 2012 2:49 PM
To: [email-masked]
Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules

On 1/20/12 11:54 AM, Firoze M. Zahidur Rahman wrote:
>
> Its not really usage of lesser no of bytes, the overall idea was to accommodate multiple values in the same URN. [...]

        Thanks,
        Paul

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Jan 2012 15:20:11 -0500

[as individual]

> 1. URN string format - [...]
> 

It would make sense to use numerical priority values.  But it seems
unlikely that there will be any practical difference between more than
the 3 values that are now envisioned.

> 3. Can we have another category to define UA/device reaction/behavior?

This is definitely "out of scope" for the Salud working group -- the
working group is only considering "how calls are alerted to the user".

However, we intend that the URN design be easily extensible in many
ways to accommodate the many alerting alternatives that various
vendors already implement.  So it is possible to define a vendor
extension that is intended to control the callee UA behavior.  And one
can clearly construct a UA that changes how it handles a call based on
the alerting URN.  But standardizing that as a way for the caller to
guide the behavior of the callee is out of scope for this working
group.

You may want to take this idea to the Dispatch working group.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Jan 2012 15:21:23 -0500

> From: [email-masked] [[email-masked]] On Behalf Of Firoze M. Zahidur  Rahman [[email-masked]]
> 

You may want to look at the "resource priority" mechanism (RFC 4412)
to see some of the machinery that SIP has for prioritizing calls.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Jan 2012 15:42:03 -0500

[as individual]

> There are different incidents when users will be required to be
> notified in a SIP UA/Device e.g Incoming Voice Call Indicatin, IM
> Request, Incoming Video Call Indication etc. For all these incidents I
> think users will need different types of notification. The role of
> priority will come into the picture when you already in a session and
> another incident comes up e.g. You are in a voice call, another IM
> invitation comes up, or another IM Request comes up, or may be 2
> incidents - one voice call is ringing and and another IM comes or
> other way round. In such cases I think priority will be able to play a
> role.
> 
> My proposal is primarily change the priority values to numbers instead
> of high, normal and low. And we can also decide on a range of values
> to be used without making it widely open to the implementers - may be
> 10 or 100.

It is true that there may be many different types of notifications,
and the callee UA may want to prioritize them in a particular order.
But it would be very difficult to have the *caller* specify the
priority in a useful way, and we expect the caller, or a device acting
on his behalf, may have provided the Alert-Info.  Worse, we would not
expect every caller creating a video call to use the *same* priority
number when there are 100 values to choose from, so the callee could
not use the priority that the caller specified to decide to handle the
call as Incoming Video Call.

There is some hope that callers will consistently chose from the set
of three values, High, Normal, and Low.

If the question is about a PBX inserting a URN into an incoming INVITE
to control how one of *its* phones handles a call (rather than usage
across the Internet), the PBX can insert an Alert-Info URN with an
appropriate extension category and value.  But that does not need to
be standardized.

> Shouldn't this RFC provide a guidance regarding this? As one of the
> main target of this effort is to standardize the Alert
> Notification.

In theory, RFC 3261 defines using a URI to provide a source for the
alerting signal, and in practice, nobody implements it because it is a
security problem.  The goal of this working group is to provide a set
of standard *meanings* that each device can render as it chooses,
along with extension mechanisms to allow specifying more detailed
meanings, and indications of different ways to alert, without
requiring fetching media via a URI.

> Standardization of user alert notification on UA/Devices
> are very much required (you can find so many option to set up the
> notification/alert tones of smart phones to be set up and every vendor
> implements it differently). Standardization of Alert Notifications
> will enable a lot of content based services to be developed around
> this. [Only the option of having 3 way call and opening up of Media
> channel after ACM message of SS7 signaling enabled to develop services
> like Personalized Ring Back Tone which is a very popular service in
> many operators]. So if alert notifications can be standardized
> properly this will open up a lot of service opportunities I think.

Currently, a UA can provide "early media" that gives a customized
ringback.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 24 Jan 2012 15:44:12 -0500

[as individual]

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

Yes, it makes sense to me that the selection of the alerting signal
may be modified by the current state of the UA:  it could change what
indications it is able to provide, or which of two alternatives is
more preferred.

Dale

---

From: Laura Liess <[email-masked]>
Date: Wed, 25 Jan 2012 16:00:15 +0100

> indications it is able to provide, or which of two alternatives is

Should we add this text as an additional separate requirement instead
of the previously proposed text in the requirement b. within the
brackets?

Laura

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 25 Jan 2012 17:42:29 -0500

> of the previously proposed text in the requirement b. within the

I've got to go over the draft again and remember what I was going to
suggest before I can suggest where I think this change should go.

Dale

Laura