Hi, I found another point to be corrected.
I wrote in the description on Case2 collision; "There is no possibility that offer2 is in the first reliable response or ACK." I wanted to say "There is no possibility that offer2 is in the first provisional reliable response or 2xx." I know the previous one is not wrong, but the fact that there is no possibility in ACK is crystal clear to me and is needless to say that. Regards, Takuya > > 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 -------- 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
