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

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 27 Jan 2004 11:55:18 +0100

Hi,

I pretty much agree on Takuya's "summary too". However, my understanding is still that you can only send an SDP in a PRACK once (either 18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by Takuya). After that, before the INVITE transactions has completed, you'll have to use UPDATE.

Regards,

Christer Holmberg
Ericsson Finland

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: 26. tammikuuta 2004 18:43
> To: Takuya Sawada
> Cc: Christer Holmberg (JO/LMF); [email-masked]
> Subject: Need to clarify rules for offer/answer usage in sip
> 
> 
> 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

---

From: "arunvenk" <[email-masked]>
Date: Tue, 27 Jan 2004 08:03:13 -0600

Christer
You state that " you can only send an SDP in a PRACK once".
If you have more than one rel prov response and the most recent one
arrives without an offer and there is no incomplete offer/answer at that
time, a new offer could be sent in the PRACK, I would think.
Venkat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Christer Holmberg (JO/LMF)
Sent: Tuesday, January 27, 2004 4:55 AM
To: 'Paul Kyzivat'; Takuya Sawada
Cc: [email-masked]
Subject: [Sipping] RE: Need to clarify rules for offer/answer usage in
sip

Hi,

I pretty much agree on Takuya's "summary too". However, my understanding
is still that you can only send an SDP in a PRACK once (either
18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by
Takuya). After that, before the INVITE transactions has completed,
you'll have to use UPDATE.

Regards,

Christer Holmberg
Ericsson Finland

---

From: Takuya Sawada <[email-masked]>
Date: Wed, 28 Jan 2004 11:24:51 +0900

Hi,
> 
> Hi,
> 
> I pretty much agree on Takuya's "summary too". However, my understanding is still that you can only send 
an SDP in a PRACK once (either 18x(offer)/PRACK(answer) or PRACK(offer)/200(answer), as described by Takuya).
 After that, before the INVITE transactions has completed, you'll have to use UPDATE.
In my understanding, you can send PRACK(offer)/200(answer) cycles after the first offer/answer
exchange completes and until INVITE transaction completes.
But if both ends can support UPDATE, I recommend to use UPDATE
for offer/answer cycles rather than PRACK.

Drawbacks of PRACK are;
- If PRACK is rejected due to the offer in PRACK, it would delay the reliable mechanism.
- If it wants to send offer in PRACK, it ahs to wait for the reliable response.

The advantage of PRACK over UPDATE is just saving one message cycle.

But I am not sure I can say it "must" use UPDATE.

Regards,
Takuya

--------
Takuya Sawada
KDDI Corporation (KDDI)