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

[Laura Liess <[e-mail]>]

2012/1/21 Firoze M. Zahidur  Rahman <[e-mail]>:
> 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.

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









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