Hi, [CHH]I am not sure we can solve this on the implementors list, so maybe it should be moved elsewhere. I have discussed my "view" with one of the 3261 editors, and he seems to agree with me, but it seems that this is more than a pure implementation issue.
>>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. [CHH] Both of my assumptions are, as I said, also based on previous discussions. I do agree that the text is a little unclear. >>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. [CHH] Yes, "based on this specification", because "this specification" (RFC3261, that is) does not define reliable provisional responses, PRACK, UPDATE etc. But, just because you DO have provisional responses, and may send the offer/answer in one of those, RFC3261 still says that the UAS MUST NOT generate subsequent offers in any responses to the initial INVITE. I haven't found any text in any specification that would change that. >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. [CHH] It may not say so, but at least my understanding is that is how it works. I also think that the offer/answers should be handled in the same transaction. Now, in the case the offer is received in 18x and the answer is sent in PRACK, that is not true, or if the offer is received in 200 and the answer is sent in ACK, but in all other cases. >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) > <-------------- [CHH] I do not agree that this would be allowed. >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.) [CHH] Before choosing one of your options, I think the existing rules should be clarified. When it comes to PRACK, I personally think they shouldn't be used for offer/answer exchanges, because there are some problems which have been discussed before (for example, how do you reject an offer in a PRACK, since you must reply with 200 OK if the PRACK otherwise is ok). I do understand why it's allowed, to save network traffic, but still... >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 [CHH] So far I agree :) >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 [CHH] No problems so far :) >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 [CHH] I guess I'm fine with this one too. I'll have to draw some flows to verify, but it looks ok :) > 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.) [CHH] This is where we seem to disagree (iii is fine, though). > 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. [CHH] It is allowed to send offer2 in the PRACK, but not offer3, offer4 etc. >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. [CHH] Instead of defining use-cases of rules that it seems like we can't agree on it think the rules should first be clarified :) Regards, Christer Holmberg Ericsson Finland _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
