[Sip] Still issues with preconditions

["Alan O'Neill" <A.ONeill@flarion.com>]

Version 3 of the manyfolks-resources draft has appeared but there still
appear to me to be a number of issues with this document. I have tried to
raise / resolve issues with the authors of the draft but have so far not had
any response. 

In summary;

i)	The strength-tag appears overloaded in attempting to carry both
requirement (Mandatory/Optional) and progress (Success/Failure) information.
This prevents a node with precondition resources already in place (existing
resources in call waiting / dimensioned diff-serv QoS) from including the
Success progress in an Invite which in the general case would lead to very
fast and efficient call set-up. In the case of incapability, the caller
could signal the inability to meet a precondition direction itself with a
Failure which would enable the callee to immediately and quickly detect
impossible preconditions when merged with its own incapabilities. The
limitation of the overloaded strength-tag could be avoided by using an
additional result-tag in each precondition to signal progress separately
from the requirement in the strength-tag.

ii)	The draft is clear on the negotiation phases of the precondition
signalling and how direction-tags in requests, responses and COMETs are
related. However, it is not at all clear how end nodes actually work out how
to respond to offered preconditions and how they work out which resources
each end should attempt to meet, especially regarding whether preconditions
must/may/must not be attempted in parallel or in series at the caller and
callee. This ambiguity is clearly a barrier to the production of multiple
interworking implementations and leads to inefficient call set-up and
cleardown, as well as the danger of each end trying to book the same
resources.


I'll use a brief and specific example in an attempt to get some discussion
on the second issue which is maybe less obvious than the first...

In the first example in the draft, the caller requests a sendrecv resource
precondition and includes a confirmation request. The callee cannot tell if
the caller is able or wishes to meet either send or recv direction in the
sendrecv precondition, only that it wishes to be informed of progress. The
callee responds with sendrecv confirm but the caller cannot glean any
information from the inclusion of the confirm by the callee. This is because
the callee confirmation request is mandated in the draft in response to the
caller confirmation request. The only information exchanged (that I can
glean from the draft) so far is that the callee, in accepting the sendrecv
precondition, is informing the caller that it can contribute in some way to
meeting the sendrecv precondition.

The caller now sends a PRACK and repeats the precondition it sent in the
Invite. At this point, the example says that both the caller and callee can
in parallel start booking resources to meet the sendrecv precondition but
this opens up the possibility of problems because neither end has actually
agreed with the other end on which of the precondition directions it is
going to attempt (ie lead roles in meeting preconditions). The model only
works if both ends have the same unidirectional reservation capability (send
only or recv only) such that non-overlapping resources are booked. If both
ends can book both directions (sendrecv) then full duplication is possible
(double the resources). If both ends have opposite capabilities (caller
send/recv and callee recv/send) then one direction will get double the
resources and the other will have no resources booked. The double / missing
resources will always be detected by the caller because the callee COMET
will include success/failure separately for each direction so that the
caller can recover, but clearly the caller can only then change its
reservation status because no mechanism exists to get the callee to do so.
The existance of duplicate reservations is clearly unfortunate and could be
avoided if the preconditions negotiation was explicit about agreeing which
resources each end should attempt to reserve.

I hope one of the authors will be kind enough to help me with this....

Regards,  Alan O'Neill

----------------------------------------------------------------
Notice Regarding Intellectual Property Rights

Flarion's submissions will conform with RFC 2026.  Flarion may seek patent
protection on some or all of the technical information submitted by its
employees in connection with the IETF's standards process.  If part(s) of a
submission by Flarion is (are) included in a standard and Flarion owns
patent(s) and/or pending patent application(s) that are essential to
implementation of such included part(s) in said standard, Flarion is
prepared to grant a license on fair, reasonable, reciprocal (license back)
and non-discriminatory terms on such included part(s).


_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip