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.
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.
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.
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.
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.
> 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.
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.
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.
> 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.
> 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. 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.
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.
Paul
_______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
