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

["Mark Watson" <[e-mail]>]

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



----- Original Message -----
From: Jonathan Rosenberg <[e-mail]>
To: Fairlie-Cuninghame, Robert <[e-mail]>
Cc: <[e-mail]>
Sent: Wednesday, December 19, 2001 8:47 PM
Subject: [Sip] Re: SDP Offer/Counter-offer/Answer


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


_______________________________________________
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