Subject: [Sip] Draft-manyfolks: Capability Exchange

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

Working Group / Authors,

The Lead role modifications enable the requestor and receiver to agree to
both the preconditions for the session as well as the lead roles in meeting
those preconditions, independently for each direction-tag. The capability
exchange modifications are then intended to enable the endpoints to in
addition exchange what they are capable of in regard to the meeting of
preconditions.

The primary change is to remove the overloading of the strength-tag which is
presently used for both mandatory/optional requirements, as well as ongoing
success/failure 'results' communication within COMETs. This overloading
prevents the early exchange of 'results' because a Success/failure value
would overwrite the mandatory/optional information that must be maintained
for the precondition negotiation.

A new result-tag is therefore defined that is optional in preconditions
negotiation but mandatory in COMETs. The result-tag can therefore be missing
<blank>, Success, Failure or Wait. The stength-tag is left as
mandatory/optional. The use of the result-tag can recreate all the functions
in the existing draft and especially the rigorous requirements of VoIP. In
addition however, an endpoint (requestor/responder) can now include
result-tag information during the negotiation phase, without loss of stength
information, which for now we will consider in the context of capability
exchange.

For example, we can now discriminate between the case where an endpoint is
incapable of meeting a precondition (whether due to technical, commercial or
any other constraints) and when an endpoint is capable of meeting it
eventually, but wishes first to offer it to the other party.

Therefore,

	When an endpoint is incapable then it should immediately include a
Failure in the result-tag against that direction-tag.
	When an endpoint is capable then it can leave the result-tag <blank>
and the confirm signalling tricks from lead role negotiation can be used to
negotiate the lead role within capable options.

The immediate benefit is that sessions that will inevitably fail, due to
incompatible session requirements and host capabilities (whether security or
QoS related), can be quickly identified, cancelled and/or modified early in
the session signalling process. In addition, the ability to exchange
result-tags early in the SDP negotiation can be used for sessions and
commercial models that require/support early precondition completion and to
reduce both the number of SIP messages and the session set-up times.
Premature precondition attempts need to be handled carefully though given
the interaction with SDP 3 way negotiation regarding media types and codecs,
as well as with SIP callee location identification and lead role
negotiation. This will be further discussed in the forthcoming draft.

For example,

	When an endpoint has a desire to meet a precondition itself and does
not wish to negotiate the lead role then the precondition can optionally be
started early, especially when starting early has low costs associated with
it.
 	When such an endpoint has sufficient preconfigured QoS resources for
the session then the result-tag can immediately be set to Success. One
example here is Call Waiting where the called party already has signalled
resources in place. Another example is dimensioned QoS or when a node has an
existing security association.
	When the endpoint has a low cost and/or slow QoS signalling
capability then the result-tag can be set to Wait to indicate that the
precondition is being attempted and the result will be communicated later.
The Wait signal is designed to prevent duplicate premature precondition
attempts during the negotiation phase. Starting early with a slow signalling
mechanism (and risking subsequent changes) may be better in the general case
than causing all sessions to have extended set-up times
	When an endpoint that previously sent a Wait gets a definitive
result then this can be further communiated in the next set-up message from
that endpoint.
	Early Success and Wait signalling (with subsequent success)
potentially avoids the need for COMET signals in many sessions because all
preconditions can be met on the INVITE (response is then a 180), on the
PRACK (following a 183) as well as on the normal COMET. This dramatically
reduces the signalling cost and set-up delays of simple sessions.
	Early Failure and Wait (with subsequent failure) potentially enables
unsupported sessions to be idendified, changed or Cancelled on 183 or 200ok
to the PRACK rather than having to progress to COMET signalling.
	Wait signalling with a quick failure also enables the lead role to
be passed to the other end way before the COMET signals and therefore agin
speds up either session set-up or session modification and Cancellation.

A full description of result-tag processing and the interactions between
this, lead role negotiation and SDP three way negotiation will be better
covered in the forthcoming draft. The modified SDP preconditions BNF is
below.

Summary of new SDP Preconditions BNF

Specifically, the preconditions attributes now become (changes from section
5.1 of draft)

   The formatting of the qos and the security attribute in the Session
Description 
   Protocol (SDP)[3] is then described by the following BNF: 
 
		qos-attribute    	= "a=qos:" strength-tag SP
direction-tag [SP result-tag]
				 [SP confirmation-tag]
				 
		sec-attribute    	= "a=secure:" SP strength-tag SP
direction-tag [SP result-tag]
				 [SP confirmation-tag]

strength-tag     	= ("mandatory" | "optional")

direction-tag    	= ("send" | "recv")				can
be sendrecv if all else equal...

result-tag		= ("success" | "failure" | "Wait")		can
be missing
 
      confirmation-tag = "confirm"
can be missing

In summary, I believe the combination of

	Splitting the sendrecv tag into two direction-tags (two SDP lines)
	Modifying confirm processing to identify lead roles
	Removing the overloading of the stength-tag by adding a result-tag
	Modifying preconditions processing to support premature attempts

greatly widens the applicability of the model to preconfigured/dimensioned
QoS, reduces the amount of messaging, reduces session set-up times and
quickly eliminates aimless signalling towards impossible session
preconditions. This I believe is achieved without compromising the VoIP /
host RSVP requirements behind the existing draft, without modifying
substantially the mechanisms of the existing draft, and without adding
significant complexity in situations where it is not required. Once the
direction-tags are split and the result-tag added, all other mechanisms are
essentially optional and backwards compatible with the existing draft.  
	
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