Re: [Sip] Re: SDP Offer/Counter-offer/Answer

Christer Holmberg <christer.holmberg@lmf.ericsson.se> Thu, 20 December 2001 13:24 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06933 for <sip-archive@odin.ietf.org>; Thu, 20 Dec 2001 08:24:38 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id IAA08074 for sip-archive@odin.ietf.org; Thu, 20 Dec 2001 08:24:41 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07683; Thu, 20 Dec 2001 08:07:22 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id IAA07652 for <sip@optimus.ietf.org>; Thu, 20 Dec 2001 08:07:19 -0500 (EST)
Received: from albatross-ext.wise.edt.ericsson.se (albatross-ext.wise.edt.ericsson.se [194.237.142.116]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06787 for <sip@ietf.org>; Thu, 20 Dec 2001 08:07:15 -0500 (EST)
Received: from fogerty.lmf.ericsson.se (fogerty.lmf.ericsson.se [131.160.11.6]) by albatross.wise.edt.ericsson.se (8.11.0/8.11.0/WIREfire-1.3) with ESMTP id fBKD76J27752; Thu, 20 Dec 2001 14:07:06 +0100 (MET)
Received: from lmf.ericsson.se (3O46G00K6Q7QPRF.lmf.ericsson.se [131.160.30.116]) by fogerty.lmf.ericsson.se (8.12.1/8.12.1/lmf.8.12.1.jcs) with ESMTP id fBKD75hO019080; Thu, 20 Dec 2001 15:07:05 +0200 (EET)
Message-ID: <3C21E278.184EC9A9@lmf.ericsson.se>
Date: Thu, 20 Dec 2001 15:07:04 +0200
From: Christer Holmberg <christer.holmberg@lmf.ericsson.se>
X-Mailer: Mozilla 4.61 [en] (WinNT; I)
X-Accept-Language: en
MIME-Version: 1.0
To: Jonathan Rosenberg <jdrosen@dynamicsoft.com>
CC: "Fairlie-Cuninghame, Robert" <rfairlie@nuera.com>, sip@ietf.org
Subject: Re: [Sip] Re: SDP Offer/Counter-offer/Answer
References: <3C20FCEC.3010505@dynamicsoft.com>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
Sender: sip-admin@ietf.org
Errors-To: sip-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: Session Initiation Protocol <sip.ietf.org>
X-BeenThere: sip@ietf.org
Content-Transfer-Encoding: 7bit

Hi,

Some comments.

>I don't have answers yet for the failure cases. Its not clear to me
>whether these need to be handled in the SDP or in SIP, or whether we
>truly need atomicity in the failure cases or not, and so on.
> 
>So, my proposal would be that IFF a three-way handshake is truly needed,
>it be accomplished by collapsing a four-way O/A exchange into three by
>making the middle two messages the same, AND furhter specifying that the
>recipient of the initial offer MUST NOT send any media based on
>information in the initial offer.

I think the UAC can indicate, EVEN if it uses three-way handshake (I
will use "3whs"...), IF it accepts media after the first OFFER message
(the initial INVITE) or not (the default value would be "DO NOT SEND
MEDIA", to make sure a UAS NOT supporting 3whs doesn't start sending
media...)

I think we could use the same indicator that we would also later use to
indicate if we accept early media (offered in the OFFER/ANSWER message)
or not.

eg.

------------- OFFER (early-media:no) ----->

<----- ANSWER/OFFER (early-media-offer) ---

------------ ANSWER (early-media:yes) ---->

<............ early media .................

or

------------- OFFER (early-media:yes) ----->

<............ early media .................

<----- ANSWER/OFFER -----------------------

------------ ANSWER ---------------------->


NOTE: This "early-media" indicator is NOT the same we would use to
indicate if we support 3whs in the first place!


>With this definition, we can then consider what additional data needs to
>be sent in order to properly do this in SIP. My proposal would, in fact,
>require the initial offer from the uac to be marked in some way that
>indicates that its an offer which is expecting a counter-offer. This is
>needed since the uac needs to know whether to expect media on the
>ports/addresses/codecs in the initial message.
>Similarly, the counter-offer needs to be marked as such in order for the
>uac to know it needs to generate an answer.
> 
>One of the things I was worried about in explicitly labeling SDP as
>offer/answer/counter-offer was 3pcc. I was worried that SDP which one
>entity provided as an offer was used by the controller as an answer in
>another flow. Interestingly, looking through draft-rosenberg-sip-3pcc,
>only ONE of the flows there does this - flow 2. Its also interesting to
>note that this flow is NOT RECOMMENDED because it doesn't generally
>work, and indeed, the reason it doesn't generally work is that its using
>an answer from one element as an offer to another!
> 
>Soooo, I do think it makes sense to be explicit. The requirements we
>have are:
> 
>1. label something as offer/answer/both
>2. somehow indicate that a 3way handshake is supported when the initial
>offer is made
>3. somehow indicat that a 3way handshake is required when the initial
>offer is made

Would 2) really work with proxies? The UAS can indicate if it supports
3whs or not, but what about intermediate proxies needing the SDP (eg for
MIDCOM)? If they don't support the 3whs they will ASSUME the SDP in the
first OFFER message (the initial INVITE) is valid for the session, even
if will be updated later in the ANSWER message send by the UAC. If it's
only about codecs etc it may not be a big deal, but it would cause
problems if eg the media port is changed in the update...

Including a Proxy-Require is not a good solution, because there may be
only one-of-XXX proxies that really need to understand the 3whs. I also
brought up this issue ealier, in a thread about the proxy support for
the "Caller privacy" extension.

Also, if the UAC won't include the port in the OFFER message, I don't
think it can use the Supported header, because the UAS MUST support the
mechanism to be able to update the port later.

------------- OFFER (m=audio - 0 8) ----->   //Note the '-' sign for the
port!

<------------ ANSWER/OFFER ---------------

------------ ANSWER (m=audio 20000 0 8) ->   //Note that the media port
is now set!


Another question is: what if the UAS(!) doesn't know which port to use
until it receives the ANSWER message? If the ANSWER/OFFER message is a
provisional response, and the ANSWER message a PRACK/UPDATE request, the
UAS could include the final port in the 200 OK. Then we would have a
kind of 4-way handshake, however...

Regards,

Christer Holmberg
Ericsson Finland

_______________________________________________
Sip mailing list  http://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip