ISE write-up for: draft-worley-alert-info-fsm-08
Abstract:
'The "alert" namespace of uniform resource names (URNs) can be used in
the Alert-Info header field of Session Initiation Protocol (SIP)
requests and responses to inform a VoIP telephone (user agent) of the
characteristics of the call that the user agent has originated or
terminated. Based on the URNs in the Alert-Info header field, the
user agent must select the best available signal to present to its
user to indicate the characteristics of the call. This document
describes a method by which a user agent's designer can, based on the
user agent's signals and their meanings, construct a finite state
machine (FSM) to process the URNs to select a signal in a way that
obeys the restrictions given in the definition of the "alert" URN
namespace. In many situations, the resulting FSM is simpler and
faster than the selection algorithm described in [RFC7462].'
This draft has no IANA Considerations.
The draft is a follow-on to RFC 7462, which was the sole output of the
Salud WG. (https://www.ietf.org/wg/concluded/salud.html). It's
author posted a "call for discussion" on the mailing lists of the
"parent" WGs, Dispatch and Sipcore, but got no responses.
It was reviewed for me by Rifaat Shekh-Yusef, Gonzalo Camarillo and Eric Burger.
The authors have made the changes suggested by the reviewers, as well as those
requested by the ISE.
- - - - -
Rifaat Shekh-Yusef's review
I have review the document and exchanged few emails with the author to
provide him with some feedback and ask some clarification questions.
The author has already updated the document based on my feedback, and he is
planning on submitting another version to address few more comments.
The document is trying to address the general use case where there are
*multiple
URNs* and the *order of URNs matters* and affects the resulting signal.
Some of these use cases are too complex or the URNs are expected to change
frequently, which makes it very difficult for a person to build the FSM
manually.
The author also provided some open source code to allow the user to use
that code to build the FSM, which looks like a very useful tool.
While the document seems to be too complex for the simple use cases,
overall, this seems like a very useful document to address the general,
complex, and dynamic use cases.
- - - - -
Gonzalo Camarillo's review
The fact that it was so difficult for you to find reviewers may be an
indication of the industry's lack of interest in what the draft
proposes. The draft proposes an internal optimization over the algorithm
described in the original RFC. So, this is not a protocol specification;
it is actually closer to an implementation guideline. I am not sure
whether or not you publish a lot of those in your publication stream or
whether they are in or out of scope.
The draft touches upon the fact that the proposal is better than the
algorithm in the original RFC, but could have done a better job
quantifying the benefits in the context of different use cases. How much
faster or simpler is it? It is also worthwhile noting that very
complicated uses of Alert-Info do not have much practical value since
not many systems will support a large number of distinct ways of
alerting a user. Having too many different tone combinations would make
it complicated for humans on understand all their different meanings.
I have not analyzed, for lack of time, whether the algorithm described
in the draft yields correct results or whether its performance is better
than the algorithm described in the original RFC. Nevertheless, since
you said you got a detailed review, I guess the reviewer checked that.
- - - - -
Eric Burger's review
This document does not conflict with existing main-line IETF work, is well
written, and should work. It provides guidance for a practical implementation
of an existing RFC, which is a valuable contribution from the ISE track.
Literally the only nit I found is the text for the example on page 36 does not
seem to be correct. I think the sense should be reversed:
Call-waiting can be signaled in conjunction with country XA but not in
conjunction with country XB as the UA does not have the facility to present the
call waiting alerts for country XB.
- - - - -