Subject: [Sip] Re: Weakness in SIP offer/answer model

From: William Marshall <[email-masked]>
Date: Fri, 24 Aug 2001 09:59:57 -0400 (EDT)

The offer/counter-offer/answer model also appears in the manyfolks draft.
The specific case where it is essential is when the UAS reduces the
preconditions requested by the UAC - the UAC needs a mechanism to
drop a media stream from the session if the UAS will not agree to
all of the preconditions for it.  So an SDP is included in the PRACK
in this case.

There are at least two other situations where the offer/counter-offer/
answer model is a big improvement.

If the UAC and UAS both support a large number of codecs, but with very
few in common, it may take a while to find one in common.  If the UAC
sends an initial SDP with a single codec, which is not supported by UAS,
the session would fail and the UAC would have to re-try with a different
codec.  This is true even if the UAS responds with an alternative in
its answer SDP.  The three-way handshake allows the UAC to insert _all_
of its supported codecs in the initial SDP, the UAS to indicate those
it supports as well, and the UAC to then pick one of the common ones.
Single round-trip codec negotiation, and minimal impact on post-dial-delay.

The second situation relates to billing (that awful B-word).  If the
originating client will be paying for the session, he/she should have
some control over the choice of codec out of the common pool.  While it
is certainly possible for a nasty UAS to thwart this (i.e. for a
telemarketer call, I only support the $$$$/sec media streams), the
final choice of media streams properly belongs to the UAC.

Bill Marshall
[email-masked]

-----original message-----
From: "Fairlie-Cuninghame, Robert" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Date: Sat, 11 Aug 2001 00:51:42 -0700

I perceive a strong weakness in the current SIP offer/answer model.

The problem pertains to the fact that the callee has no way of indicating
its media profile requirements. Consider the situation: 

A sends INVITE B with
m=audio 5454 RTP/AVP 0
m=video 4444 RTP/AVP 31

However the server only supports (or requires for this call) a different
profile, eg RTP/SAVP or some other transport profile (RTP/AVP-USCTP or TLS
or something). 

There is no way that the callee has to communicate this information to the
caller. This will be needed for proper deployment of SRTP on servers and a
great many other things.

- You cannot accept the call by setting the port to zero and then sending a
re-INVITE as you cannot be sure that the client supports this profile.
Answering calls successfully when you really don't have the ability to
communicate is something that we want to avoid at all costs (dead handset
syndrome). 

- It cannot be communicated in SIP headers as this is a layer violation (and
just bad design). You are trying to use the session protocol to signal he
required SDP transport paths.

- You could send a 4xx error with an SDP indicate the appropriate offer that
the caller should make to be successful. The requires more messages, longer
call setup times and new parsing & analysis logic of the SDP on the client
side. I don't like it.

I have a proposal: I think what we need is to allow a
offer/counter-offer/answer model. Now this sounds very familiar ->
Jonathan's new Early Media model! SDP in INVITE, callee instead sends
counter-offer in reliable provisional response, to which the caller either
accepts or rejects with the SDP in PRACK. When the 200 OK is eventually sent
by the callee it is in answer to the SDP in the PRACK (rather than original
INVITE).

I would like to see this generalized such that it can also be used with
local ringback (rather than removed as some have requested). 

Once again, I see this functionality as _absolutely_ crucial to the proper
deployment of SRTP and other SDP transport profiles. This also apples to the
situation where the callee needs to know whether the caller supports a
certain SDP capability (for instance, support for a particular SDP
attributes) - another very, very important case.

Please suggest something else if you don't like this scheme. 

[Jonathan proposed an alternate solution in the open issues section of his
early media draft:

	  .... We would then need a token in the 1xx somewhere
        which says "I ignored your offer of SDP in the INVITE, this
        2xx is an offer, not an answer". This token, perhaps a
        require token, would be present in the original 1xx but not
        1xx in response to re-INVITEs. We could apply this to
        INVITE/2xx/ACK as well.

We should try to make any scheme consistent and as long as it works I am not
bothered.]

Regards,

Robert.

_______________________________________________
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

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 24 Aug 2001 16:25:03 -0700

Hi William,

Good comments.

One nit thought, I think we should avoid using the term  "three-way
handshake" with respect to offer/counter-offer/answer. These words have
certain connotations that may confuse people. Although _notionally_ it may
in some way form a three way handshake (because the counter-offer may be
formed based on the original offer), algorithmically the
offer/counter-offer/answer is still a simple two-way handshake. The offer is
completely replaced by the counter-offer. A three way handshake could also
suggest that some confirmation of the answer is made by the receiver which
is also not algorithmically true at the SDP layer.

Not completely wrong but confusing I think.

Regards,

Robert.

> -----Original Message-----
> From: William Marshall [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 7:00 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Weakness in SIP offer/answer model
> 
>

---

From: "Fairlie-Cuninghame, Robert" <[email-masked]>
Date: Fri, 24 Aug 2001 19:05:21 -0700

Hi William,

I just reread your post and came to the conclusion that we fell into the
confusion I was talking about. It appears to me you _are_ talking about a
true three-way handshake which is quite different to the
offer/counter-offer/answer .... more like a offer/answer/refined-answer.
This is a different discussion and needs to be separated. I might add that
it has been previously proposed and rejected on the list.

In the offer/counter-offer/answer model we are maintaining the _exact_
semantics of the basic SIP two-way offer/answer model described in bis. The
offer and counter-offer are not algorithmically related at all - in fact
this is where the real usefulness of the model is achieved. [Eg Caller
offers RTP/AVP, callee counter-offers RTP/SAVP; or caller offers one
bidirectional unicast stream, callee counter offers one unidirectional
multicast stream and one-unidirectional unicast stream]

If caller and callee have non-overlapping requirements/capabilities then you
do not want to establish the session initially. Codec refinement can occur
using re-INVITE but you want to ensure that the two UA's can communicate in
_some_ manner before establishment. 

I hope this clarifies things.

Robert.

> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Friday, August 24, 2001 4:25 PM
> To: 'William Marshall'; [email-masked]
> Cc: [email-masked]
> Subject: [Sip] RE: Weakness in SIP offer/answer model
> 
> 
> Hi William,
> 
> Good comments.
>