I don't see it as an "UPDATE race condition". There are legitimate sequences (arising from 100rel, UPDATE, pre-conditions, early session disposition etc.) in which, following conclusion of the original offer-answer exchange when the answer is sent in a reliable provisional response, further offer-answer exchanges can occur (using PRACK or UPDATE). These can occur before the 200 response to INVITE. Thus repeating the original SDP answer in the 200 response to INVITE is history - it has been overtaken by subsequent offers and answers. At best it will be ignored, but at worst it will lead to confusion, e.g., the UAC and UAS getting out of step with which SDP version from the UAS is to be used. And why should the UAS even have to store the original SDP answer it sent, if it has been overtaken by subsequent SDPs?
Of course, one can question the wisdom behind some of these mechanisms, some of which have not seen much deployment. But they are there, and unless we deprecate them, we change the offer-answer rules at our peril. John > -----Original Message----- > From: Dean Willis [mailto:[EMAIL PROTECTED] > Sent: 22 November 2007 05:21 > To: Robert Sparks > Cc: Sanjay Sinha (sanjsinh); sip List; Paul Kyzivat > Subject: Re: [Sip] SIPit21: SDP in a 200OK when using 100rel > > > On Nov 21, 2007, at 10:57 PM, Robert Sparks wrote: > > > There can be several UPDATEs with their associated 200-UPDATES > > before the 200-INVITE. > > Remember that UPDATE is a nonINVITE transaction and there may be a > > _long_ time between the UPDATE and the 200-INVITE. > > > > Paul drew the arrow backwards for the 200-UPDATE though - did that > > mislead you? > > > > Ah, yes, I read that Alice had sent a second conflicting offer in > UPDATE. > > However, even with this directionality, the answer in the > INVITE-200, > if present, would have to be a copy of the answer in the 183. This > doesn't create any error I can see, it just illustrates the UPDATE > race condition that would have existed even had there not been an > answer in the 183. Early media, early session, and UPDATE were all > bad ideas (probably all because of forking and PSTN interactions) > IMHO, and I'm pretty sure reliable provisionals are on that list too. > > > >>> > >>> Alice Bob > >>> | INVITE offer1 | > >>> |----------------->| > >>> | 183 answer1 | > >>> |<-----------------| > >>> | PRACK | > >>> |----------------->| > >>> | 200 PRACK | > >>> |<-----------------| > >>> | UPDATE offer2 | > >>> |<-----------------| > >>> | 200 UP answer2 | > >>> |<-----------------| > >>> | 200 IN SDP? | > >>> |<-----------------| > >>> > >>> Now what should be in the 200 for the invite? > >>> > >>> Its better to do what is already required - send no SDP in the > >>> 200 for the invite. > >> > > -- > Dean > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
