Subject: [Sip] Draft-manyfolks: Lead Role Negotiation

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

Working group/ Authors,

I believe it is necessary for the preconditions negotiation to attempt to
agree both the session preconditions and which end is the lead role for each
precondition. This would speed up the progression of sessions and yet still
avoid duplication.

One way to achieve the identification of the lead roles is to use separate
precondition lines for each direction-tag (generally avoid sendrecv), and
then intelligently use the confirmation-tag as shown in the following table.

SDP preconditions
A requests	B responds			Response Meaning wrt SDP
from B to A
A leaves decisions to B by avoiding confirm in requests. 
send, recv	recv, send			Both agree sendrecv, B will
do everything. A knows progress from 580 or 180
send, recv	recv, send c		Both agree sendrecv. B will do
Brecv, A can attempt Bsend and then confirm back
send, recv	recv c, send		Both agree sendrecv. B will do
Bsend, A can attempt Brecv and then confirm back
send, recv	recv c,send c		A can attempt both Bsend and Brecv
first and should report back to B
If A can't do the lead role assigned by B then it can be more specific or
CANCEL call

A adds its preferences by including confirm in request and B agrees
send c, recv	recv, send c	A tells B that A will do Bsend, B should do
Brecv. B confirms to A, then A to B.
send, recv c	recv c, send	A tells B that A will do Brecv, B should do
Bsend. B confirms to A, then A to B.
send c, recv c	recv c, send c	A tells B to do both and B happy. B then
confirms to A. Then A confirms to B.
If B can't do the lead role assigned by A then it can be more specific or
return a 580.

A adds its preferences but B corrects them. 
send c, recv	recv c, send c	A tells B to do Brecv but B can't. A tries
both and then confirms to B.
send, recv c	recv c, send c	A tells B to do Bsend but B can't. A tries
both and then confirms to B.
send c, recv c	recv, send 		A tells B to do both but B can't. A
tries both and confirms to B (B didn't request it!)
If A can't do the lead role assumed by B then it can be more specific or
CANCEL the call.

	Note that the strangeness of the confirm processing in the last line
whereby B gets a confirm that wasn't asked for. This is required to
differentiate it from the case where A includes send c, recv c and B replies
with recv c, send c...

	Note that the table doesn't make it clear what each end is
ultimately capable of, only what that end is prepared to do regarding lead
roles (first attempts). This is addressed in a later e-mail titled
"Capability Exchange".

	Note that in the case that the confirm status of both send and recv
direction-tags is the same then it may still be useful to use the combined
"sendrecv confirm" direction-tag and confirmation-tag.
		
	Note that the use of a combined sendrecv direction tag with a single
strength tag does not cover the case where the strength-tag (mandatory,
optional, success, failure) is different for send and recv directions as
might be common in non VoIP applications.

	Note that the separation of the sendrecv direction-tag then enables
COMET (confirmation) messaging for each direction to be decoupled whereby a
UAC/UAS could signal an inability to attempt/provide one direction of
security or QoS in advance of the completion of the other direction-tag that
it is able to attempt. This enables the peer to either quickly start and
attempt to meet that precondition itself, or failing that to quickly CANCEL
the call. In addition, this separation enables the sender to request a
confirmation for only one of the directions, and in fact to be specific
about which direction-tag it seeks a confirmation on. 

	Note that this split direction-tag is also used during Capability
Exchange.

Using split direction-tags, and the clarifying confirms in this table, we
have greatly increased the ability of the SDP preconditions protocol to
agree lead roles and to be direction specific about confirms. We still need
the same amount of COMET signalling with the change from combined sendrecv
direction-tags because each end still needs to know what happened at the
other end. Specifically, this is necessary to signal precondition failures
from the lead role end for that precondition, so that the other end can
attempt that precondition if capable.

The benefit though is that both ends can start meeting preconditions must
quicker and be informed of direction specific results much earlier. This is
because both ends have agreed on lead roles and can therefore proceed in
parallel. This avoids the risk of precondition duplication when their roles
aren't clear yet they still try to proceed in parallel instead of waiting
for the COMET from the other end.  If they instead proceed in series and
wait for the COMET then the cost is then the  additional call set-up delay. 

Regards,  Alan.

----------------------------------------------------------------
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