Re: [Sip] UPDATE with offer
OKUMURA Shinji <[email protected]>
| Newsgroups | gmane.ietf.sipping,gmane.ietf.sip |
|---|---|
| Message-ID | <[email protected]> |
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 _______________________________________________ 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