In message <[EMAIL PROTECTED]> "RE: [Sip-implementors] Few doubts in Offer/Answer in sip protocol" ""Arunachalam Venkatraman" <[EMAIL PROTECTED]>" wrote:
> This is a good way to summarize the issues. > > With respect to your statement below - > "In the case that offer2 is in the first reliable provisional response or > ACK, " > I am not sure that it makes sense to send an offer in a ACK. I believe taht > only an answer may be sent in an ACK. I don't know that if this is stated > anywhere, however. > Oh, I made a mistake here. I wanted to say that "In the case that offer2 is in the first reliable provisional response or 2xx," not ACK. Maybe, just saying "in the first reliable response" was enough. Thank you for pointing this out. Regards, Takuya > I think you also make a valid point about > "if there is a rule that INVITE, even w/o SDP, must not be sent if pending > offer exists. > I am not sure whether it is clearly stated." > > It would appear that "making an offer/ seeking an offer" should be > considered with the same sequencing rules and restrictions. > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Takuya > Sawada > Sent: Sunday, January 25, 2004 6:35 PM > To: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Sip-implementors] Few doubts in sip protocol > > > Hi, Paul, > > Let me summarize my view of "restrictions" defined in the current SIP RFCs. > * Probably I think I may share the same view with Christer in most parts. > > Offer/Answer exchange described in RFC 3264 is independent from > higher layer protocol. > Higher layer protocol provides means to exchange offer/answer > and this needs to provide means for resolving "glare" situation > as described in the last paragraph in RFC 3264. > > [How to provide means to exchange offer/answer in SIP] > > <RFC 3261> > RFC 3261 provides the following two ways to exchange offer/answer; > - INVITE/2xx > - 2xx/ACK > See the page 80 in RFC 3261. > > <RFC 3262> > RFC 3262 provides the additional three ways to exchange offer/answer; > Note that here "1xx" is a reliable provisional response to INVITE. > - INVITE/1xx ... a first reliable 1xx with SDP. (may not be the first 1xx) > - 1xx/PRACK ... Only when INVITE w/o SDP, 1xx must be the first reliable > response. > - PRACK/2xx(PRACK) ... Only after a completion of INVITE/1xx or 1xx/PRACK. > See chapter 5 in RFC 3262. > > <RFC 3311> > RFC 3311 provides an additional way to exchange; > - UPDATE/2xx(UPDATE) > Only when after any offer/answer exchange defined in RFC 3261 and RFC 3262 > has completed and no offer/answer exchange in progress. > See section 5.1, 5.2 in RFC 3311. > > Currently, as far as I understand, no other ways are not defined in any > RFCs. > Assuming this is correct, let me clarify how to resolve "glare" cases. > * I can not imagine how to resolve "glare" if other offer/answer exchanges > are possible beyond my assumption here. > > [How to resolve "glare" condition] > One reason why the usage of a SIP method to exchange offer/answer > needs to be carefully restricted in RFCs is that UA must detect mis-ordered > message delivery and must avoid confusion. > In RFC 3264, "it MUST NOT generate a new offer if it has > received an offer which it has not yet answered or rejected. > it MUST NOT generate a new offer if it has generated a > prior offer for which it has not yet received an answer or a rejection." > So now there seems to be two possible message crossing case > to be considered assuming that the above rules are guaranteed. > > Case1 > A B > |offer1 | > |--------------->| > | answer1| > |<-----\ /-------| > | X offer2| > |<-----/ \-------| > > Case2 > A B > |offer1 offer2| > |------\ /-------| > | X | > |<-----/ \------>| > > Case1: > Assuming that offer/answer exchange follows the restrictions I described > above, A can know an SDP in offer2 is not an answer to offer1. > Then offer2 must be rejected with a 500 with Retry-After, when > offer2 is UPDATE. And I assume that it can apply to reINVITE, > which may not be stated clearly. > I am not sure that when this happens when offer2 is in PRACK. > But probably 500 with Retry-After will also apply, even it results in > delay for reliabile transfer mechanism for provisional response. > In the case that offer2 is in the first reliable provisional response > or ACK, it seems to me that it never happens, if there is a rule that > INVITE, even w/o SDP, must not be sent if pending offer exists. > I am not sure whether it is clearly stated. > > Case2: > Assuming that offer/answer exchange follows the restrictions I described > above, A can know an SDP in offer2 is not an answer to offer1. > Then offer2 must be rejected with a 491, if it is UPDATE or (re)INVITE. > In the case that offer2 is in PRACK, it may be accepted with 200 or > may be rejected with 491. 491 may be adequate for offer/answer but it may > delay the completion of a reliable response transfer mechanism or, in > worst case, may result in failure to complete SIP transaction because > there is no clear retry rule when PRACK is rejected with 491. > When RFC 3262 was defined, there were no UPDATE, therefore offer in PRACK > never collides with other offers from the other side. I guess this is why > there is no rule in RFC 3262 when PRACK offer collides with UPDATE offer. > (It is safe to use UPDATE instead of PRACK when UPDATE is supported) > Anyway, because there is no PRACK against PRACK collision in the current > RFCs, the other side is always expected to send 491. > There is no possibility that offer2 is in the first reliable response or > ACK. > Because A must not send new offer when it send INVITE w/o offer. > > Is this a correct summary? > > More comments inline with [TS]. > > > Takuya, > > > > RFC 3312 introduces situations in which multiple offer/answer exchanges > > are required before a single INVITE transaction can complete. Of course > > multiple transactions are involved because PRACK and/or UPDATE are used > > to achieve part of the exchange, but the INVITE transaction can't finish > > until they are done. > > > > This is at least one case in which offers and answers are spread across > > transactions in complex ways. > > > [TS] In my reading so far, there is the only one case which offer/answer is > across transaction, that is offer in the first reliable provisional response > of INVITE and answer is in PRACK. There is no other case that an offer is in > a transaction and an answer is in another transaction. > I agree with that any number of offer/answer exchanges can occur during > one INVITE transaction. > > > There are also cases independent of 3312 where there is a need to send a > > subsequent offer/answer before an invite transaction completes. For > > instance, this is one of the techniques for dealing with port conflicts > > introduced as a result of forking. > > > [TS] Yes. I did not disagree with that an offer in UPDATE request can > be used before the completion of INVITE transaction. > > > Once an invite transaction has completed, including one or more > > offer/answer pairs, additional offer/answer cycles can be initiated > > using either reINVITE or UPDATE. > > > > In the case of reINVITE, I believe there is a requirement that one or > > more offer/answer cycles be completed before it can succeed. And if it > > fails, the changed tentatively imparted by all of those offer/answer > > cycles are to be rolled back. > > > > The case of UPDATE is a little less clear. If there is no invite > > transaction in progress, and an offer is sent in an UPDATE, and the > > update is rejected, it must be the case that the dialog state remains as > > it was before the update. If there is no invite in progress and an > > UPDATE is sent without an offer, there seems to be no prohibition > > against sending an offer in the update response. In that case, the > > answerer would have no way to refuse the offer and retain the dialog as > > it is. The only option the answerer would have is to send another UPDATE > > containing the answer. I doubt this is intended behavior, but it isn't > > prohibited. > > > [TS] This is the point I can not agree. I can not find any description that > UPDATE response can contain an offer in RFC 3311. IMO, this means UPDATE > response > can not have any offer. SIP RFCs define restrictions to utilize RFC 3264 > model. > UAs can not do any offer/answer exchange which is not defined clearly in any > RFCs. > > > More below. > > > > Paul > > > > Takuya Sawada wrote: > > > Hi, > > > > > > In my understanding, > > > > > > - Once previous offer/answer completes each side can issue new offer. > > > - INVITE request contains the offer, and the first reliable 1xx response > > > which contains answer, offer/answer for the INVITE transaction > completes. > > > - UPDATE transaction and PRACK transaction can exchange offer/answer. > > > - Therefore, once the reliable 1xx response which contains answer is > received, > > > caller can start offer/answer with PRACK or UPDATE or any new method. > > > And once the reliable 1xx response which contains answer is sent, > > > callee can start offer/answer with UPDATE. > > > > > > > > >>P.S. For those with the patience, below I have tried to enumerate all > > >>the offer/answer cases thru the 2nd offer. It is pretty painful. > > >> > > > > > > <snip> > > > > > >>2) invite with 100rel > > >> a) offer in invite > > >> Possible places for answer: > > >> i) answer in first reliable 1xx > > >> ii) answer in subsequent reliable 1xx > > >> iii) answer in 2xx > > >> b) offer not in invite > > >> offer must be in first reliable 1xx > > >> answer must be in PRACK to 1xx w/offer > > >> > > >>Multiple offer/answer cycle prior to completion of invite. > > >>Can only happen in subcases of (2) above. > > >>It requires use of UPDATE in some cases. > > >> > > >>3) original offerer sends 2nd offer > > >> a) following 2.a.i or 2.a.i.i: > > >> Possible places for 2nd offer: > > >> i) offer2 in PRACK of answer1 > > >> ii) offer2 in PRACK of some subsequent 1xx > > >> iii) offer2 in UPDATE > > >> b) following 2.a.iii: > > >> No 2nd offer possible until after completion of invite. > > >> c) following 2.b: > > >> i) offer2 in 2xx to PRACK w/answer1 > > >> ii) offer2 in UPDATE > > >> > > >>4) original answerer sends 2nd offer: > > >> Not clear if this is intended to be legal at all prior to > > >> completion of invite. It appears existing text permits > > >> as follows: > > >> a) following 2.a.i or 2.a.ii: > > >> Possible places for 2nd offer: > > >> i) offer2 in 2xx to prack of answer1. > > >> ii) offer2 in subsequent reliable 1xx > > >> following the one carrying answer1. > > >> iii) offer2 in UPDATE following answer1. > > >> (No reason to prefer this to other possibilities.) > > >> b) following 2.a.iii: > > >> No 2nd offer possible until after completion of invite. > > >> c) following 2b: > > >> i) if another reliable 1xx is received, > > >> could send offer2 in the PRACK. > > >> (but can't count on this happening.) > > >> ii) offer2 in UPDATE after sending answer1. > > > > > > > > > I do not think offer/answer exchange beyond the SIP transaction > > > is possible. I am not sure it is prohibited somewhere in RFC, but > > > even if it is not prohibited explicitly, one should not assumed > > > that is possible. > > > > Following the principle of being conservative in what you send and > > liberal in what you receive, I want to assume that I might receive > > anything that isn't prohibited, and do something reasonable with it. > > > [TS] I love this principle. IMO, if I receive an SDP which I do not expect > to receive in RFC, one possible solution is that I will accept SIP message > and ignore the SDP. Content-Disposition header's handling parameter > should be checked, though. > Anyway, here I do not know what is something reasonable to do with it. > > > I would be willing to be conservative in initiating this stuff if I > > could figure out what that is. Given the current state of > > underspecification I don't know that I will draw the same conclusion > > than anyone else will. > > > [TS] There seems to be some uderspecification in RFCs. But I want to > confirm the following; > RFCs only state where and when an offer and an answer can appear. > If RFCs do not state "it can", then it MUST NOT contain offer/answer. > Because RFCs define "restrictions" where and when offer/answer > exchange can occur. > First I think we should reach a consensus with this point. > > > > One can achieve the same thing without such a > > > tweak. > > > > Not sure what you are referring to here, or whether it is negated in > > your subsequent posting. See above for a number of things that must be > > possible. > > > > > Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. > > > > If we can codify a clear, and complete, set of rules for where offers > > and answers can appear, that provides full functionality, and it > > excludes these cases, then fine. > > > > In the case of 4.a.1, removing it causes no loss of functionality, so I > > am inclined to agree. It might ultimately result in exchanging more > > messages, but the number is probably insignificant. > > > > In the case of 3.c.1, removing it requires that both sides support > > UPDATE. So its removal may remove functionality in the case where one > > side or the other doesn't support UPDATE. This may or may not be > > significant. > > > [TS] As you said, UPDATE can solve the problem. > You can use extensions when it wants the functionality that the base > specifications can not provide. This is what the extensions are. > > > > Anyway for INVITE transaction, as explained in my previous mail, > > > it is clear in RFC 3261 to me that one INVITE transaction can > > > include only one offer/answer exchange. > > > > > > Then 4.a.ii is not permitted. > > > > I think I identified cases above where this is needed. > > > [TS] The reason I think it is not permitted is, as Christer pointed our, > that RFC 3261 does not permit and any other RFCs do not override it. > > > Takuya Sawada wrote: > > > Hi, > > > > > > > > >>I do not think offer/answer exchange beyond the SIP transaction > > >>is possible. I am not sure it is prohibited somewhere in RFC, but > > >>even if it is not prohibited explicitly, one should not assumed > > >>that is possible. One can achieve the same thing without such a > > >>tweak. > > > > > > > > > I am not exactly correct here. > > > When an offer is in INVITE reliable provisonal response and > > > an answer is in PRACK offer/answer exchange is beyond one > > > transaction. > > > What I want to say is that how offer/answer is used in a certain > > > method is explicitly scoped in each RFC which defines the method. > > > > The trouble with these is that they were written in a certain order. As > > each was written, a broadening of thinking seems to have occurred. This > > is reflected in each, but not necessarily fully reflected in the earlier > > specs. > > > [TS] I may agree with this. At least this makes it difficult to understand > and share the same view among all. Actually, there seems to be a little > ambiguity with PRACK and UPDATE collision case as I pointed > out in this mail, etc. > > > > How PRACK is used for offer/answer is defined in RFC 3262. > > > There seems to be only two cases: > > > - offer/answer is reliable 1xx(INVITE)/PRACK > > > - offer/answer is PRACK/2xx(PRACK) > > > only after INVITE's offer/answer exchange complete. > > > > I agree that this seems pretty well locked down as it relates to 3261. > > These lock downs of course do apply to the things that came later. But > > they seem at least awkward and arbitrary in some cases. > > > > > How UPDATE is used for offer/answer is defined in RFC 3311. > > > - offer/answer is UPDATE/2xx(UPDATE) > > > > Here I disagree. I looked pretty closely at this, and I don't see *any* > > normative language for how offer/answer is used with it. There is a > > bunch of non-normative language which appears to simply restate > > implications of 3261 and 3264 in the presence of update. > > > [TS] Again, this is the point I can not agree. I agree with that there is > no normative language to prohibit offer in the response of UPDATE > like "2xx response to UPDATE MUST NOT contain offer". > Actually, response can have an SDP even if UPDATE does not have > an offer SDP. But an SDP can be neither an offer nor an answer > unless clear semantics are defined in any RFCs. I can not find > any usage or semantics to use offer/answer exchange beyond > one UPDATE transaction. > IMO, SDP in a 2xx of UPDATE when an UPDATE request w/o > offer is neither an offer nor an answer like SDP in INFO is > neither an offer nor an answer. > > > > How INVITE is used for offer/answer is defined in RFC 3261. > > > - offer/answer is INVITE/non-failure reliable response > > > - offer/answer is the first non-failure first > > response/acknowlegement for the response > > > , which is 2xx(INVITE)/ACK in RFC 3261 and 1xx(INVITE)/PRACK in > > RFC 3262. > > > * Note that the second or later SDP in INVITE non-failure response > > > is not an offer. It is nothing. > > > > > > There is no other way than explicitly defined in any RFC, IMO. > > > > I believe you are right that nothing more is explicitly defined. > > But 3264 is pretty general and broad. It is not prescriptive in how > > offers and answers are transmitted. > > [TS] Yes. Therefore, RFC 3264 requires restrictions on how > to exchange offer/answer in higher layer protocol. > > > And while the other RFCs may not > > explicitly specify other ways, there are other ways that aren't > > explicitly prohibited. In general with sip, things that aren't > > explicitly prohibited are permitted. > > > [TS] Yes. Any SIP messages can contain SDP at any moment. > But without semantics, it is neither an offer nor an answer. > > > I just want to get this nailed down, so I know how to build a stack that > > can both handle every valid case thrown at it, and that can initiate all > > the needed functionality. > > > > I am thinking that maybe somebody (probably me) needs to write a best > > practices document that pulls this all together, specifying all the ways > > that offer/answer can be used. Following that, I think it will be > > advisable to tighten up one or more of the RFCs in places where things > > haven't been prohibited but should be. > > > [TS] The guideline document that you are proposing can be useful. > Collecting all the possible collision cases, recommending UPDATE > offer rather than PRACK offer if UPDATE is supported and no need > to reduce the number of messages, enumerating Warning header code > examples to be included when offer is rejected with 488, etc. > > Regards, > Takuya > > > Paul > > > > _______________________________________________ > > Sip-implementors mailing list > > [EMAIL PROTECTED] > > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > > -------- > Takuya Sawada > KDDI Corporation (KDDI) > Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku > Tokyo 102-8460, Japan > Tel: +81-3-6678-2997 > Fax: +81-3-6678-0285 > [EMAIL PROTECTED] > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > -------- Takuya Sawada KDDI Corporation (KDDI) Garden Air Tower, 3-10-10 Iidabashi Chiyoda-ku Tokyo 102-8460, Japan Tel: +81-3-6678-2997 Fax: +81-3-6678-0285 [EMAIL PROTECTED] _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
