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

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 19 Dec 2001 15:47:40 -0500

There are LOTS of issues here. Let us take them one step at a time. The 
group has a habit of jumping right into headers or parameters or bodies 
or whatever without understanding the scope of the problem or the 
semantics involved.

First off, I think its important to define a sufficient list of concrete 
problems that require a three-way exchange, so that we don't go too far 
down this path if its not really needed. Some of the ones Robert has 
offered include:

   a. early media (need to be able to refuse/modify an early media stream)
   b. having the uas add SRTP to its counter-offer when not made in the 
offer

Others I could think of:

   c. in the case of forking, if there are multiple 200 OK, each will go 
to the same port/ip on the caller. This will require knowing 
cname<->dialog mappings to sort out. THe alternative is to use a 
three-way exchange that allows a separate port for each uas

Now, let me explain why Robert's (b) is NOT an issue as defined. What is 
special about SRTP? What if the uas wants to use a new codec not offered 
by the uac? Or an additional media stream? They can always be added 
later on through a re-invite. This leads us to the question of the day: 
under what conditions is a three way handshake needed, as opposed to 
simply doing a re-invite once the call is up? The answer to this 
question is critical in determining required semantics.

I would posit that the three way handshake would be needed for those 
cases where we require atomicity, AND the offerer does not have 
sufficient information to exchange all the data in the initial offer.

As an example, consider my problem (c). The UAC wants to make a call, 
but can't offer a port until it knows who its talking to, as there will 
be a separate port for each uas. Thus, the initial offer cannot contain 
sufficient information for the exhcange. Furthermore, we don't want to 
simply do a re-invite after the 2xx, since we'll end up with this 
transitional period where we can't easily associate media with the 
dialogs it was established through. This introduces the atomicity 
requirement. In this case, the atomicity requirement is not that strong; 
I could argue that the few seconds between the 200 OK and the re-invite 
are not so important - you're not losing any media, you just can't 
associate it with the specific dialog.

Robert's SRTP example is one where its not clear to me that atomicity is 
important.

OK, now onto the second point. How do we accomplish the three-way 
handshake? I had initially proposed that the counter-offer was nothing 
more than a valid answer to the initial offer, plus a new offer. More 
concretely, we could accomplish a three way handshake by starting with 
the basic four-way handshake:

----------> OFFER
ANSWER<------
OFFER<-------
----------->ANSWER

and then making the middle two the SAME SDP, passed in one message:

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

The semantics would then be: the uac processes the second message FIRST 
as an answer, and THEN as an offer, generating an answer to that. This 
would allow us to do a three-way exchange without specifying any 
additional semantics. This exchange has the very nice property that it 
supports complete subsetting, so that the SDP in message 2 is a subset 
(subset of codecs, of media streams, of directions) of message 1, and 
message 3 is a subset of 2.

However, on further cogitation, I realized this doesn't work. It doesn't 
work since its missing the fundamental atomicity property. The uac, for 
example, needs to be prepared to receive with the codecs in the offer 
(the first messae), even though there will later be another SDP updating 
that information (the third message). Thus, the information provided in 
the initial offer has to be valid and usable in its own right, and based 
on the defined semantics above, the uas could even send using that media 
before receiving message 3. That would violate atomicity.

Thus, to fully specify a three-way handshake, we need to add one 
additional bit - the uas MUST NOT ever send media using the initial 
offer, it MUST wait for the third message (the answer). This introduces 
the required atomicity, and maintains the subsetting property.

Another fun issue is handling error cases. We have the ability today to 
"reject" an offer when there is no overlap in any of the media. If the 
offer is in an INVITE, thats easily done (488 or whatever it is). If the 
offer is in a 2xx, its harder - you still need to include a valid answer 
in the ack, and then BYE later on. That doesn't work for re-invites, 
which is why we have another open issue, which is trying to ensure that 
the offer in a 2xx to a re-invite w/o SDP is always acceptable. Not sure 
how to do that, or if its even possible. Now, how to do that in a 
three-pass model is more complex, since presumably we can "reject" at 
any point and need to back off to the original sdp beforehand (the 
atomicity requirement).

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.

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

I would argue that Content-Disposition is right for (1), and 
Require/Supported for (2) and (3).

OK, there is a lot to digest and comment on in here. Additional thoughts 
are welcome.

-Jonathan R.

Fairlie-Cuninghame, Robert wrote:

> Hello,
> 
> I'm not sure whether this is more suited to the MMUSIC list (as there is a
> answer-offer discussion ensuing presently), however I believe this is more
> related to the use of the SDP offer-answer model than its specification.
> [draft-rosenberg-mmusic-sdp-offer-answer-00.txt]
> 
> Just a recap: the SDP offer/counter-offer/answer model is where Peer A makes
> an offer in the INVITE, that Peer B has decides to make a counter-offer back
> to A (in 183 or 200 OK) which A then sends an answers (in PRACK or ACK). 
> 
> We are seeing the offer/counter-offer/answer model becoming more widely
> used: it is used in the manyfolks resource reservation, it is used in the
> early media proposal and it is required in the 3GPP requirements document.
> Also when SRTP becomes more prevalent, it will be useful in that instance. 
> An example of its use with SRTP: A calls B. A offers RTP/AVP in the INVITE
> but B requires the use of SRTP/AVP profile, so B counter-offers with
> SRTP/AVP in the 200 OK. A either answers in ACK or sends empty SDP and
> rejects call. 
> 
> My aim is not to change the answer-offer model (everything is still always
> an offer or answer), early media or resource reservation; my aim merely to
> make what is happening EXPLICIT rather than assumed, that is, make it
> explicit with an SDP is an answer or a counter-offer. Explicit protocol are
> just about always better than implicit (IETF mantra right).
> 
> My proposal (which I made earlier in the year): whenever a response
> (provisional or final) contains an SDP counter-offer then this fact is
> EXPLICITly indicated in the Content-Disposition header. 
> 
> For instance: Content-Disposition=newoffer;handling=required
> 
> I propose that this Content-Disposition token is added to the next SIP
> draft. 
> 
> Comments?
> 
> Regards,
> 
> Robert.
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
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: "Mark Watson" <[email-masked]>
Date: Thu, 20 Dec 2001 11:11:55 -0000

Jonathan,

Sounds reasonable to me, except the very last part.

We split out the offer/answer model from SIP and input it into mmusic
because it has broader application - i.e. anywhere that you need to use SDP
in this request/response type of way.

Now we have a requirement to make the offer/answer+offer/answer semantics
explicit, but you are suggesting solutions to that which only work for SIP.

Shouldn't this indication be clear from the SDP itself (either implicit or
explicit) ? Alternatively, I guess we could state this requirement in the
offer/answer draft as a requirement on 'whatever is used to carry the SDP'.

Interestingly, ITU-T SG11 in Q.1990 defines a new SDP attribute for almost
exactly this purpose.

Regards...Mark

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 20 Dec 2001 15:07:04 +0200

Hi,

Some comments.

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

>3. somehow indicat that a 3way handshake is required when the initial

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