My review of this draft (wearing individual contributor hat)...
Section 4.3:
The draft references an expired I-D (elwell-bliss-dnd). I suggest
that you either remove the reference, or add the required material
somewhere in this document. (Personally, I think the truth of the
assertion that there is not standardized response to indicate DND is
apparent, but I suspect that others would disagree).
Section 4.4, second paragraph:
The draft says:
Where there is forking proxy between the entity performing ACH and
the calling UA, information may be lost because of the
Heterogeneous Error Response Forking Problem (HERFP).
While many readers may believe that they understand what HERFP is, I
don't think it's appropriate to either assume that they all believe
the same thing, or leave the uninitiated in the dark. I suggest
either finding an existing description appropriate to reference,
adding an appendix to include one, or replacing this shortcut with
some short description of what happens.
Section 4.4, third paragraph:
This paragraph make some assumptions about how forwarding is
implemented that I believe are not universal. It may or may not be
true that a UA receives no information when a request is retargeted
(even provisional responses provide some information, as might the
use of History-Info). When redirection is used, the the calling UA
may or may not see any 3xx response, depending on whether or not
there is a forking proxy between the requester and the UAS returning
the 3xx.
Section 4.6, first paragraph:
The draft says:
If ACH is performed at the proxy, the user needs a means to configure
the proxy with the required rules. There is no SIP means of doing
this, but a number of mechanisms can perform the basis for this task,
e.g.:
that last sentence would be better made both active and
conditional... something like
There is no standard mechanism in SIP to configure ACH rules in a
proxy, but implementations might provide non-standard mechanisms
such as:
Section 4.6, page 9 second paragraph:
The draft says:
Related to this is the means by which a UA (and hence the user) can
discover how the proxy is configured. Most of the mechanisms listed
above are applicable, and also a SIP SUBSCRIBE/NOTIFY mechanism could
be used. The survey indicated that only a minority of proxies
provided support in this respect.
Again, making this conditional would be clearer, and it should also
be more specific - what's of interest is how the proxy is configured
with respect to ACH. With respect to the survey result, again being
more explicit would be clearer.
Related to this is the means by which a UA (and hence the user)
can discover what ACH rules a proxy is currently using. Most of
the mechanisms listed above might be used, and it might also be
possible to define a SIP SUBSCRIBE/NOTIFY mechanism. The survey
indicated that only a minority of proxies provided ...
The '...' is left to you, since it's not clear to me what it is the
survey indicated (do only a minority of proxies provide any way at
all of figuring out what will happen to a call? seems unlikely).
Section 5 (Discussion):
This section is pretty good, but misses one issue with implementing
ACH in UAs that I think is important, that being the security of
responses from UAs. Unless the connection to a UA is authenticated
either with TLS (rare, especially on the last hop) or through Digest
authentication (whose integrity protections are not strong enough),
the response from a UA might be modified by an attacker. Even if
the signalling can, by some means, be secured there remains the
problem that a UA might be physically compromised (I step into your
office while you're momentarily away, and change the ACH in your
phone). In general, ACH in a central system is more easily secured
and changes more easily audited.
Section 6.5:
The draft says:
In view what is specified in [RFC3261] for 6xx response codes and
with some, but not all existing practice, it is safest to regard 6xx
response codes as impacting all branches of a forked INVITE request.
In what sense is this 'safest'? Perhaps if your motivation is to
have some 'pure' implementation of a literalist interpretation of
3261, but if you want a phone system people are happy with then I
think not. In my experience, some phones return 6xx codes for local
rejection, and users complain bitterly if the call is not then sent
to voicemail or some other reasonable action is taken; they rarely
seem to mean "disconnect this caller with extreme prejudice".
Section 6.6:
The draft says:
General methods for configuring proxies (including synchronization of
multiple proxies serving a domain) are considered outside the scope
of BLISS work.
Even if true (and I'm not sure it is), I don't think that statement
adds anything to the document, and will make little sense in an
archival document when no one remembers what BLISS was.
Section 7.1:
I don't know that the two normative (MUST) statements here actually
make any sense in practice, and in any event they are not very
specific.
What does a UA having 'all ACH features turned off' really mean?
Never return a 3xx response? Never return a 486 busy response?
Disable the 'Do Not Disturb' button? Don't give the user the option
to reject a call?
Similarly, what does it mean that a proxy must 'operate when ACH is
provided by the registered UA'? That the proxy cannot implement any
redirection or retargeting? If so, then the assertion that this
'typically would be the default configuration' is certainly not true
of any system I've encountered.
Section 7.2 says:
o Response code 487 for silent rejection/local. This is the same
response code that would be used if a proxy were to issue a CANCEL
request.
That's a new (to me, at least) usage that does not seem to me to be
within the meaning given to it by 3261:
The request was terminated by a BYE or CANCEL request. This response
is never returned for a CANCEL request itself.
It would not surprise me if a UAS (either the originator of the
INVITE or some intermediate system) would not expect to see a 487
when it had not sent either a BYE or a CANCEL.
In practice, I think that the only way to really have a 'silent'
rejection (which I define as a rejection that the caller cannot tell
is a rejection) is to simply not send any final response at all,
just as though I just let the phone ring until it stopped on its
own. I've encountered SIP phones that did it this way - a silent
rejection on the phone UI suppressed the local call indication, but
did not send any final response at all, leaving the caller to time
out the early dialog. This approach is mentioned in section 6.3.1,
and I think that would be better advice to give for this case.
As for global rejection, I think that UAs should never issue 6xx
responses unless it is absolutely clear to the user that what they
are doing is disconnecting the caller completely and preventing any
ACH in any upstream system. In practice, no UA can really know
that, so a 6xx response is alway ambiguous (in my proxy, we've just
changed them so they are handled as local rejections with no effect
on subsequent ACH by the proxy).
Nit: don't use the term 'SPIT' without defining it.
Sections 7.3 and 7.4:
These don't have any content now, and it's not clear (given the
discussion earlier in this draft) that there's much of anything to
say. Hopefully we can get the effort to specify mechanisms for this
done, but it would seem to me to be out of scope for this draft.
Section 9 (Security considerations):
I'm not sure that I agree that there are no security considerations
as the draft stands now. If the final version of this draft
actually recommends that 6xx responses (which are difficult or
impossible to authenticate in most systems). See the discussion
above of the security implications of response authentication.
Multiple Sections:
There are a number of references to the SIPPING config framework as
a possible means of doing various things. One such example is in
section 6, page 12, second bullet:
o Configure the UA and proxy independently. The SIP configuration
framework [I-D.ietf-sipping-config-framework] is one possible
means of configuring the UA.
In fact, I don't believe that I-D specifies anything remotely like a
means to configure any ACH behavior in the UA. At this point, I
know of no standard means of configuring UA behavior for ACH (or
anything else), certainly not in any IETF document.
I think that all those references need to be examined to see whether
or not they are actually supported by
I-D.ietf-sipping-config-framework as it exists today.
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
