I haven't read carefully through your e-mail but maybe this draft will answer some of your questions (if not, it will, at least, give you extra guidance)...
http://tools.ietf.org/html/draft-ietf-sipping-sip-offeranswer-08 Regards, Attila -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of OKUMURA Shinji Sent: 10 September 2008 11:04 To: [email protected]; [EMAIL PROTECTED] Subject: [Sipping] UPDATE with offer 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) | |==============================>| | | A B | | |re-INVITE (no offer) | |------------------------------>| | | |UPDATE (offer1) | |==============================>| | | 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
