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. One can achieve the same thing without such a tweak. Then, 3.c.i and 4.a.1 SHOULD NOT, or hopefully MUST NOT, be used. 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. Regards, Takuya > > > Christer Holmberg (JO/LMF) wrote: > > Hi, > > > > Chapter 5 in RFC 3262 says: > > > > "If the UAC receives a reliable provisional response with an offer > > (this would occur if the UAC sent an INVITE without an offer, in > > which case the first reliable provisional response will contain the > > offer), it MUST generate an answer in the PRACK." > > > > To me this sounds like you can only receive an offer in a reliable response (which > > also must be the FIRST reliable response, said in the same chapter). > > I don't follow your logic. The above says that if the UAC didn't send an > offer with the invite, then the first reliable provisional (if any) will > contain an offer. It doesn't say more than that. (But see below.) > > > The chapter also says: > > > > "If the INVITE contained an offer, the UAS MAY generate an answer in a > > reliable provisional response (assuming these are supported by the > > UAC)." > > > > To me this sounds that only an answer to the offer in the INVITE request can be > > sent in the reliable response. > > Again, I don't see where you get the "only" part of your conclusion. > > > No, the text doesn't forbid other usage, and I do think it could be more clear, > > but at least what I've just written is my understanding of the text and previous discussions. > > > > Also, which I asked earlier, IF you're allowed to send new offers in provisional > > responses, what happens if I have sent you a new offer before that, which you yet haven't received when sending me your offer (ie we have a race condition). I can't send a 490 response to your provisional response, so do I have to accept your offer and ASSUME that you will reject my offer (which I sent in a request, eg UPDATE)? > > That was discussed earlier. I think proper resolution is defined. > > Subsequently, Bharrat, Shaun wrote: > > Also RFC 3261 page 80 > > > > o Once the UAS has sent or received an answer to the initial > > offer, it MUST NOT generate subsequent offers in any responses > > to the initial INVITE. > > This is more compelling. But you omitted the last sentence of that > paragraph: > > This means that a UAS based on this > specification alone can never generate subsequent offers until > completion of the initial transaction. > > This does still seem to introduce a somewhat arbitrary limitation on how > multiple offer/answers may be exchanged. (Note that it *doesn't* say > that answers to subsequent offers cannot be sent in subsequent answers > to the initial INVITE. > > So this would still permit: > > INVITE w/offer > ---------------> > 183 > <-------------- > PRACK > ---------------> > 200 (PRACK) w/answer > <-------------- > UPDATE w/offer > ---------------> > 200 (UPDATE) > <-------------- > 183 w/answer > <-------------- > PRACK > ---------------> > 200 (PRACK) > <-------------- > > I've been looking at these rules for where offers and answers can > appear, and I can't make any sense of them in terms of an algorithm for > how an endpoint can plan how to accomplish the things it needs to do, if > that involves more than a single offer/answer exchange. The existing > rules don't make things simpler, they only make them harder. And, it > seems that the rules are sufficiently complex that they are likely to be > implemented in non-interoperable ways. > > I think there are two ways to improve the situation: > > 1) tighten up the rules still further, providing very limited > ways of exchanging multiple offers/answers. > > 2) loosen up the rules, so that an offer or answer can be exchanged > in any related and reliable message in the dialog as long as the > recipient of an offer is left with an option for sending an answer. > > I prefer (2). I think some of the existing rules are pretty restrictive. > For instance the rule that requires an offer in the first reliable > provisional if there was none in the invite is causing some implementors > a lot of grief. And it doesn't really help the other side, because it > must be prepared to wait until the 2xx when 100rel isn't supported. > Similarly, requiring an answer in the prack when there is an offer in a > reliable provisional, or requiring an answer in the prack response when > there in an offer in the prack, can be a pain to comply with. (The other > side may need some time to prepare the answer.) > > Paul > > 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. > > Single offer/answer cycle: > > 1) normal (3261 only) invite > a) offer in invite > i) answer must be in 2xx > ii) answer may be duplicated in 1xx > iii) no subsequent offer/answer possible > until after ack > b) offer not in invite > i) offer must be in 2xx > ii) answer must be in ack > > 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. > > Could go on from here, figuring out where the 2nd answer can appear, > where a 3rd offer can appear, etc. This gets combinatorially more > difficult, because the rules for where things can go are pretty arbitrary. > > _______________________________________________ > 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
