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

[Jonathan Rosenberg <[e-mail]>]

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
[e-mail]                 FAX: [phone]
http://www.jdrosen.net                  PH:  [phone]
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 [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip