Hi Dale
I do see the logic in providing a hierarchical classification,
allowing some UAs to provide finer-grained information than others.
This isn't necessarily easy to design, though, because you have to pay
attention to how the fall-backs work. E.g., having a high-level
category "service" is useless because you can't report "service" alone
as a condition to the user. But you could have "busy.CCBS-available",
because "busy" is also a state that can be usefully rendered to the
user when "busy.CCBS-available" is specified.
[DA] Do you want to define URNs that are not only applicable to the
Alert-Info header and respectively to the alert phase of the call, also
to the Call-Info Header URNs that can be provided at the terminating
phase of the call as well?
I'm fine with it, that would be a new 'busy' branch:
urn:busy:service:ccbs-availabe or urn:busy:state:ccbs-availabe
and extension of the 'alert' branch with:
urn:alert:service:ccnr-available or urn:busy:state:ccbs-availabe
We just need to agree on the best term for the 'service'/'state' branch.
Greetings,
Denis Alexeitsev
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
