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

["Firoze M. Zahidur Rahman" <[e-mail]>]

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
F  [phone], [phone]
3 [phone], [phone]


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

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



2012/1/21 Firoze M. Zahidur  Rahman <[e-mail]>:
> 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.
>
>>> 3. Can we have another category to define UA/device reaction/behavior?
>> 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: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: Saturday, January 21, 2012 10:54 AM
> To: [e-mail]
> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules
>
> On 1/20/12 11:39 PM, Firoze M. Zahidur Rahman wrote:
>> 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.
>
> 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.
>
>> 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)
>
> 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.
>
>> 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
>
> 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 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.
>
> See above.
>
>        Thanks,
>        Paul
>
>> 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  [phone], [phone]
>> 3 [phone], [phone]
>>
>>
>> -----Original Message-----
>> From: [e-mail] [mailto:[e-mail]] On Behalf Of Paul Kyzivat
>> Sent: Saturday, January 21, 2012 1:50 AM
>> To: [e-mail]
>> 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:
>>> 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.
>>
>> 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
>>
>>> Thanks&   Best Regards
>>>
>>> Jewel
>>>
>>> ________________________________________
>>> From: [e-mail] [[e-mail]] On Behalf Of Paul Kyzivat [[e-mail]]
>>> Sent: Friday, January 20, 2012 11:43 PM
>>> To: [e-mail]
>>> Subject: Re: [salud] Call Priority and Combinations of Alert-Info URNs and Priority Rules
>>>
>>> On 1/20/12 10:03 AM, Firoze M. Zahidur Rahman wrote:
>>>> 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
>>>
>>> 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
>>>
>>>
>>>> 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
>>>>
>>>> _______________________________________________
>>>> salud mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/salud
>>>>
>>>
>>> _______________________________________________
>>> salud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/salud
>>> _______________________________________________
>>> salud mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/salud
>>>
>>
>> _______________________________________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/salud
>> _______________________________________________
>> salud mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/salud
>>
>
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud
> _______________________________________________
> salud mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/salud