Subject: [Sip] Draft-manyfolksl: Precondition Negotiation Issues

From: "Alan O'Neill" <[email-masked]>
Date: Sun, 11 Nov 2001 08:37:47 -0500

Working Group / Authors.

I am concerned about the signalling examples and a lack of clarity in the
draft regarding the interpretation of preconditions signalling that need to
be addressed. Apologies for both the lateness and verbosity of this and
related contributions.

1. Lead Role Negotiation

I believe the SDP negotiation results in the agreement at both ends of the
session preconditions and the required confirmation signalling. However, I
do not believe that it always provides a common view of who is responsible
for trying to meeting each precondition first (ie establishing lead roles).

I think that the examples as they stand can lead to both ends attempting to
book the same resources (without additional information) but this may be due
to a bad interpretation of the mechanisms so please advise if I am missing 
something.

My understanding is as follows.

With a sendrecv precondition, B should not continue with the session until
resources exist from B to A and from A to B. Confirms are needed so that if
B fails to meet all preconditions then A can then try to meet them if it is
capable, before sending the final confirmation (COMET) to B (or a CANCEL). 

Now in the single media example, B and A start trying to meet the
preconditions in parallel following the PRACK/200ok exchange. In particular,
B starts trying to meet the preconditions before receiving the COMET from A.
Now if A and B have overlapping capabilities in terms of meeting
preconditions then by progressing in parallel it is possible for both hosts
to
book the same resources from opposite ends. Strict adherence to the protocol
would suggest that B should not start trying to meet preconditions until it
receives the COMET, but this leads to significantly extended call set-up
delay
due to the two phases of RSVP operating in parallel. This may justify the
risk of duplicate precondition satisfaction. Now in the specific case of
each host having the same unidirectional capability, duplicate booking is
not possible.
However, I don't believe that B and A can always exchange that information
and if for example they both have sendrecv capabilities then duplication can
occur. Is this information obtained elsewhere or have I missed something ?

In more detail...

A requests are not clear about what it wishes from B in meeting
preconditions. The request can only be taken to mean that A wishes B to help
book these resources if a confirm was requested. Effectively it says to B
that it should book what it can and then tell A. A will then try to book the
rest and then tell B. This is mandated by the draft in that B must request
confirm if A requests a confirm. Who is booking which resources is only
clarified as B makes its attempt and then sends the COMET to A, and then A
makes its attempt at the remaining preconditions and then sends the COMET to
B. 

B reponses are also not clear about who is booking which resources. They can
only be taken to mean that B wishes A to help to book these resources and is
why a confirm was included (if A didn't mandate it by issuing a confirm
itself). It effectively causes A to book what it can and then for B to book
the rest. 

I assume therefore that the confirm / COMET mechanism is being used to order
potentially competing attempts at booking the same resources in which case B
cannot start RSVP in the draft signalling examples at the same time as A.

Only when A sends the COMET and signals a failure in the recv direction
should B try to book resources. If we do not maintain this order then we
risk multiple attempts to book the same resources. This ordering though
leads to a delay in starting the reservation at B though extending call
set-up times.

Ambiguity about who books the resources could be avoided if we assume that A
inteprets that it must only attempt to install resources for preconditions
that B omitted but that A requested. However, this contradicts the draft
because it would mean that the preconditions contained in B SDP responses
are those that B is prepared to meet and not those for the session. 

All of this (if correct) begs a very important question though. Lots of SDP
preconditions signalling occurs but not until the exchange of COMETs and
after booking some resources, does either endpoint know if the precondition
is actually possible to meet, given each others basic capabilities. This
seems very unfortunate and potentially expensive...If the SDP preconditions
signalling could be redesigned so that the lead roles were always clear then
it would be possible for all of the preconditions to be attempted in
parallel. The COMETs would then communicate progress and only the occasional
failed preconditions re-attempted at the other end.

2. Response Interpretation in the absence of a confirm from A

Some ambiguities wrt lead roles could be reduced through a subtle
interpretation of the confirm messaging. The case of the B response is
analysed in the table below assuming a sendrecv precondition was requested
by A.

B response 	Could imply
recv		that B wishes only a recv precondition and B can book recv
send		that B wishes only a send precondition and B can book send
recv c	that B wishes only a recv precondition and B can't book recv
send c	that B wishes only a send precondition and B can't book send

	If A assumes that a confirm means that B can't meet the precondition
then A could for example issue a CANCEL if B 	asks for a confirm for a
precondition that A cannot meet. 

	If A assumes that the confirm means that B is capable but would
prefer A to book these resources then B can still 	book them if it
must. 

The correct interpretation would seem to be latter and that A sends the
COMET and B then responds with the 580 error if it can't meet the remaining
preconditions. This needs to be clearly addressed in the draft.

B response 	Could imply
sendrecv	that B agrees a sendrecv precondition and B can book both.
sendrecv	that B agrees a sendrecv precondition and B can book only
one direction.
sendrecv c	that B agrees a sendrecv precondition and B can't book one
direction.
sendrecv c	that B agrees a sendrecv precondition and B can't book
either

	If we look specifically at the sendrecv case. If B agrees to
sendrecv and asks for a confirm it cannot tell A which 	direction it cannot
meet. If A is capable of doing either then A might only try one direction
and then forward to B 	in the hope that B can do the other half. Clearly
this is problematic because A could guess wrong and ask B to do
something it is not capable of (rather than what it might fail at which is
clearly ok). 

Therefore A must try to meet both preconditions and this should be stated in
the draft. This ensures an opportunity for a valid call is not missed.

Solutions to some of these issues are contained in the e-mail titled "Lead
Role Negotiation".
 
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 [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip