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

From: "Fairlie-Cuninghame, Robert" <[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.

P.S. I'm going to be away for the next couple of weeks (good duck and cover
tactic :-)

_______________________________________________
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: Thu, 23 Aug 2001 06:56:54 -0700

Perhaps defining a SIP header value (valid in 1xx & 2xx INVITE responses)
that simply states that the SDP is a counter offer is the best approach.
This separates the handling of these issues from the early-media issues ?

Content-Disposition seems like a logical place to do this ? For instance
define a new token name to supplement the existing "session" disposition and
use it with a "handling=required" disposition value. 

Comments/thoughts?

Robert.

> -----Original Message-----
> From: Fairlie-Cuninghame, Robert [mailto:[email-masked]]
> Sent: Saturday, August 11, 2001 8:52 AM
> To: [email-masked]'
> Cc: [email-masked]'
> Subject: [Sip] Weakness in SIP offer/answer model.
> 
> 
>