Shinji,
I realize I haven't responded to your earlier o/a question.
You have obviously been looking deeply into this subject, and I haven't
had time to give a studied answer.
The collection of RFCs that touch on offer/answer don't fit together
perfectly. It takes a lot of "reading tea leaves" to put it all together
and make sense of it. For the most part it has been concluded that only
certain usages are valid, because the others lead to inconsistent
results or violate some aspect of one or more of the RFCs. There was an
extended discussion of all this on the mailing list some years ago,
which then faded into folklore. We later realized that such folklore
needed to be formally recorded, which is what led to the offeranswer draft.
The end result is that if you simply look at one RFC, such as 3311, and
construct flows that are consistent with it, then you are likely to come
up with some that aren't workable for some reason not stated in 3311.
OKUMURA Shinji wrote:
> Hi,
>
> I have any questions about sending offer by UPDATE request.
>
> RFC3311/5.1 Sending an UPDATE says,
>
> The rules for inclusion of offers and answers in SIP messages as
> defined in Section 13.2.1 of RFC 3261 still apply. These rules exist
> to guarantee a consistent view of the session state. This means
> that, for the caller:
>
> o If the UPDATE is being sent before completion of the initial
> INVITE transaction, and the initial INVITE contained an offer,
> the UPDATE can contain an offer if the callee generated an
> answer in a reliable provisional response, and the caller has
> received answers to any other offers it sent in either PRACK or
> UPDATE, and has generated answers for any offers it received in
> an UPDATE from the callee.
>
> o If the UPDATE is being sent before completion of the initial
> INVITE transaction, and the initial INVITE did not contain an
> offer, the UPDATE can contain an offer if the callee generated
> an offer in a reliable provisional response, and the UAC
> generated an answer in the corresponding PRACK. Of course, it
> can't send an UPDATE if it has not received answers to any
> other offers it sent in either PRACK or UPDATE, or has not
> generated answers for any other offers it received in an UPDATE
> from the callee.
>
> o If the UPDATE is being sent after the completion of the initial
> INVITE transaction, it cannot contain an offer if the caller
> has generated or received offers in a re-INVITE or UPDATE which
> have not been answered.
>
> According to the description above, The following scenarios seem
> to be allowed.(before sending PRACK)
>
> A B
> | |
> |ini-INVITE (offer0) |
> |------------------------------>|
> | |
> | 1xx-rel (answer0)|
> |<------------------------------|
> | |
> |UPDATE (offer1) |
> |==============================>|
> | |
>
> A B
> | |
> |re-INVITE (offer0) |
> |------------------------------>|
> | |
> | 1xx-rel (answer0)|
> |<------------------------------|
> | |
> |UPDATE (offer1) |
> |==============================>|
> | |
Your point in the above is that the UPDATE is being sent prior to the
PRACK, right?
Would you then expect to be able to send yet another offer in the PRACK???
From B's perspective there is the possibility that there was a PRACK
and it was lost or delayed. This then gets very complex to interpret.
IMO this is at least a very bad idea.
>
> A B
> | |
> |re-INVITE (no offer) |
> |------------------------------>|
> | |
> |UPDATE (offer1) |
> |==============================>|
> | |
This clearly can't work. B will be working on generating an offer, so
this is just inviting a complex glare condition.
So this is certainly a bad practice, if not illegal.
I don't have time right now to dig into all your other cases. But let me
wrap up for now this way:
The best way we found to resolve all of these alternatives in the o/a
draft was to reformulate by giving just the patterns that are known to
be valid. Others, that might seem to be valid according to one of the
RFCs, are to be avoided.
In retrospect, it would have been better for the RFCs to have been much
more explicit and constraining.
Thanks,
Paul
> and for the callee:
>
> o If the UPDATE is being sent before the completion of the INVITE
> transaction, and the initial INVITE contained an offer, the
> UPDATE cannot be sent with an offer unless the callee has
> generated an answer in a reliable provisional response, has
> received a PRACK for that reliable provisional response, has
> not received any requests (PRACK or UPDATE) with offers that it
> has not answered, and has not sent any UPDATE requests
> containing offers that have not been answered.
>
> o If the UPDATE is being sent before completion of the INVITE
> transaction, and the initial INVITE did not contain an offer,
> the UPDATE cannot be sent with an offer unless the callee has
> sent an offer in a reliable provisional response, received an
> answer in a PRACK, and has not received any UPDATE requests
> with offers that it has not answered, and has not sent any
> UPDATE requests containing offers that have not been answered.
>
> o If the UPDATE is being sent after the completion of the initial
> INVITE transaction, it cannot be sent with an offer if the
> callee has generated or received offers in a re-INVITE or
> UPDATE which have not been answered.
>
> According to the description above, The following scenarios seem
> to be allowed.(before receiving PRACK)
>
> A B
> | |
> | re-INVITE (offer0)|
> |<------------------------------|
> | |
> |1xx-rel (answer0) |
> |------------------------------>|
> | |
> |UPDATE (offer1) |
> |==============================>|
> | |
>
> A B
> | |
> | re-INV (no offer)|
> |<------------------------------|
> | |
> |UPDATE (offer1) |
> |==============================>|
> | |
>
> Is my understanding correct?
> Some scenarios seem to be allowed only for re-INVITE.
> is this what the author intended?
> If not, which is not intended scenario?
>
> Regards,
> Shinji
> _______________________________________________
> Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping
> This list is for NEW development of the application of SIP
> Use [EMAIL PROTECTED] for questions on current sip
> Use [email protected] for new developments of core SIP
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
