Subject: [Sipping] Need to clarify rules for offer/answer usage in sip

From: Paul Kyzivat <[email-masked]>
Date: Mon, 26 Jan 2004 11:42:53 -0500

Takuya,

You make good points. I think you have convinced me of how this all 
needs to work. I believe we are also both in agreement that the 
necessary behavior is currently underspecified in the RFCs.

I think a useful next step would be to hear from the authors of the RFCs 
in question, and hopefully obtain their concurrence. Then we can discuss 
the best way to formalize this. I am moving this to the sipping list and 
changing the title in order to pick up those authors, some of which 
don't normally watch sip-implementors.

	Paul

Takuya Sawada wrote:
> 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-masked]
>>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-masked]
> 

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP