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 ack2) 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/offerMultiple 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 UPDATE4) 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
