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. 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. How UPDATE is used for offer/answer is defined in RFC 3311. - offer/answer is UPDATE/2xx(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. Regards, Takuya > 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 -------- 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
