Hi,
If I implement UA, I would not send the UPDATE request with an offer
unless PRACK transaction is completed.
but other ua may send these UPDATE request. Then my ua should do something.
I think that offer-answer draft would discribe it.
I want to confirm which scenario is appropriate, and which one is illegal.
my comment inline.
Regards,
Shinji
Paul Kyzivat <[EMAIL PROTECTED]>
>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?
Yes.
>Would you then expect to be able to send yet another offer in the PRACK???
No, I think following PRACK must not include offer.
> 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.
I agree. B may send 4xx(maybe 491) for UPDATE. But is following
sequences illegal ?
A B
| |
|ini-INVITE (offer0) |
|------------------------------>|
| |
| 1xx-rel (answer0)|
|<------------------------------|
| |
|UPDATE (offer1) |
|==============================>|
| |
|PRACK(no offer) |
|------------------------------>|
| |
| answer1 (2xx-UPD)|
|<==============================|
| |
or crossing case
A B
| |
|ini-INVITE (offer0) |
|------------------------------>|
| |
| 1xx-rel (answer0)|
|<------------------------------|
| |
|PRACK(no offer) |
|--------------\ /============>|
| \/ |
|offer1(UPD) /\ |
|==============/ \------------>|
| |
| answer1 (2xx-UPD)|
|<==============================|
| |
| 500(PRACK)|
|<------------------------------|
| |
|PRACK(no offer) |
|------------------------------>| incremented CSeq
| |
| |
>> 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.
Yes, I agree. A should not send this UPDATE, but if B receive it,
B must do something. BCP I think is following,
A B
| |
|re-INV (no offer) |
|------------------------------>| --+
| | |
|offer1(UPD) | |
|==============================>| | The 1st reliable response
| | |
| answer1 (2xx-UPD)| |
|<==============================| |
| | |
| offer2| |
| (1xx-rel/2xx)| |
|<------------------------------| <-+ Wait until answer1
| |
| answer2 (PRACK/ACK) |
|------------------------------>|
| |
or crossing case
A B
| |
|re-INV (no offer) |
|------------------------------>| --+
| offer2 | |
|offer1(UPD) (1xx-rel/2xx)| |
|============\ /===============| <-+ The 1st reliable response
| \/ |
| /\ |
|<===========/ \==============>|
| |
| 491(UPD)|
|<------------------------------|
| |
| answer2 (PRACK/ACK) |
Wait until 491 |------------------------------>|
| |
>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
_______________________________________________
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
