This is both my personal review of this draft [1], and a question with
my WG Chair hat on for both the author and the working group.
First, my question as WG Co-Chair...
This draft has a nice section on how some existing implementations
work, and some descriptions of a couple of different call flows for
different deployment environments and/or sets of user expectations
(for example, whether park orbit identifiers are allocated by the
parking UAC or by the park service and whether those identifiers
need to be human-friendly or not).
Should the goal of this document be to establish a set of call
flows, including what methods are used and how addressing works so
that any implementation using those mechanisms can interoperate with
any other?
If so, if there are alternative flows (as in the existing document),
should it be a goal that the SIP clients and servers can detect
whether or not they are using the same choices? Should there be
identifiers for the choices, and if so where would those identifiers
be used?
If it is not a goal of this document to establish such a set of
flows to be used by future implementations, then what is it?
My personal review of the draft...
This review should be understood in the context of my personal
(individual contributor) answers to the questions above:
- The goal of the draft should be to document a (small) set of
alternative flows that meet the described sets of expectations.
- It should be possible for an implementation, given only a
request or response from its peer, to detect whether or not the
peer is expecting to use the same flow the implementation is
attempting to use.
- There should be a set of labels to identify the alternatives.
These need not (prefereably should not) appear in any SIP
message, but should be availble for example for implementers to
use when creating configurations.
Given the above, I think that the Abstract should be modified to
clearly state the goals (those, or perhaps others); the current text
doesn't set out goals clearly enough that one can tell whether or
not the draft has acheived them.
I think that the draft needs a tighter set of descriptions of what
sets of user experiences it is meant to cover. Then each proposed
flow should reference those descriptions to make clear which flow(s)
are appropriate to which kinds of deployments.
Yes, I know that the old (existing) charter says you're not
allowed to define features, but I think that's silly (and is why
the new proposed charter [2] doesn't say that). If you disagree
with me on this, please start a new thread to discuss that.
The descriptions of the flows need to be tightened up considerably.
They should not rely on any understanding of the flow in RFC 5359
section-2.15 [3], because any new description should be
understandable on its own. I think this draft should itself be a
BCP and normatively Update that RFC, replacing that section [which I
think is somewhat underspecified too).
One thing that both this flow and the 5359 flow do is send the REFER
from the parking UAC to the Park Service, with a Refer-To and
Replaces parameter identifying the call to be parked. Neither spec
(as far as I can find) make clear what address should be used in the
Refer-To header for the party to be parked - an AOR from the To/From
header, or the Contact address? In many situations, one or the
other may not be routable, especially in the absence of the route
set from the dialog. The draft offers the explanation that this
avoids any reliance on parked party to correctly handle an orbit
parameter. Personally, I don't think there's any alternative to
allowing Route header parameters somewhere, and yes, I think that's
a bug in RFC 3261 (yes, I know about gruu, but until everyone does
them they don't solve the problem, and sometimes not even then).
One of the more important difference between the offered flows is
which parties send an 'orbit' parameter in requests and responses.
It seems to me that it should be possible to nail that down so that
the presence or absence of an orbit parameter can be used by each
party to understand the expectations of the other. Granted, in some
cases (such as the parker expects the service to allocate the orbit and
the service needs the parker to do it) this produces only an error -
but at least it could be an error that spells out what the problem
is.
Editorial Nit:
Abstract: "[...] approaches can be Taken, [...]"
'Taken' probably shouldn't be capitalized.
[1] http://tools.ietf.org/html/draft-ietf-bliss-call-park-extension-01
[2]
http://svn.resiprocate.org/rep/ietf-drafts/lawrence/bliss-charter/charter.txt
[3] http://tools.ietf.org/html/rfc5359#section-2.15
_______________________________________________
BLISS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/bliss
