Re: New Version Notificationfordraft-ietf-sipping-sip-offeranswer-12
Paul Kyzivat <[email protected]> Thu, 11 Mar 2010 08:45:46 -0500
| Newsgroups | gmane.ietf.sipping |
|---|---|
| Message-ID | <[email protected]> |
Shinji, I have had a lot of difficulty weaving the various suggestions into the overall document. If you would like to see changes like this, can I ask a favor of you - could you also please propose the specific text changes that are necessary to complete the integration into the document? Thanks, Paul OKUMURA Shinji wrote: > Hi all, > > I study RFC3311 again, so I change my comment. > >> For 4.2 I disagree that 3311 forbids the sending >> of an UPDATE while awaiting a prack. (It probably should have been, but >> I don't see that it is.) > > I agree. This forbode is not clear. > In initial INVITE transaction, RFC3311 forbids this UPDATE. > But for reINVITE, RFC3311 say little. > >> 4.1. Message Crossing Case Handling > > I revise the table 3. > > | M1 | M3 | M2 | Action of A | Action of B | > |(offer1)|(answer1) |(offer2) | | | > +--------+----------+---------+---------------------+----------------------------+ > | UPDATE | 2xx-UPD | UPDATE | | | > | | +---------| 491 response for M2 | | > | | | INVITE | | | > | | +---------+---------------------+ | > | | | 1xx-INV | should not send | | > | | +---------+ Mx until M3 in 4a, | | > | | | 2xx-INV | M1 until My in 4b | | > +--------+----------+---------+---------------------+ | > | PRACK | 2xx-PRA | UPDATE | | | > +--------+----------+---------+ | | > | 2xx-INV| ACK | UPDATE | 491 response for M2 | | > | | +---------+ | | > | | | INVITE | | | > +--------+----------+---------+ +----------------------------+ > | 1xx-rel| PRACK | UPDATE | | should not send UPDATE | > +--------+----------+---------+ | until ACK/PRACK transaction| > | INVITE | 1xx-rel | UPDATE* | | is completed. | > | |----------+---------+ | | > | | 2xx-INV | UPDATE* | | (*:invalid for init-INVITE)| > +--------+----------+---------+---------------------+----------------------------+ > >> 4.2. Glare Case Handling > > I propose that the following Figures and Table are added in this section. > > A B > | | > | re-INV (offer0)| > |<------------------------------| > | | > | 1xx-rel (answer0) | > |------------------------------>| --+ > | | | Acknowledge > | offer1(UPD) offer2(PRA)| | > |============\ /===============| <-+ > | \/ | > | /\ | > |<===========/ \==============>| > | | > | 491 (UPD)| > |<------------------------------| > | | > > A B > | | > |re-INV (no offer) | > |------------------------------>| --+ > | offer2 | | > |offer1(UPD) (1xx-rel/2xx)| | > |============\ /===============| <-+ The 1st reliable response > | \/ | > | /\ | > |<===========/ \==============>| > | | > | 491 (UPD)| > |<------------------------------| > | | > > A B > | | > |offer1(UPD) | > |===========\ | > | \ | > |re-INV \ | > |--------------\--------------->| --+ > |(no offer) \ offer2 | | > | \ (1xx-rel/2xx)| | > |<================\=============| <-+ The 1st reliable response > | \ | > | \ | > | \=========>| > | | > | 491 (UPD)| > |<------------------------------| > | | > > | offer1 | offer2 | Action of A | Action of B | > +----------+----------+----------------------------+----------------------------+ > | | reINVITE | | | > | reINVITE +----------+ | | > | | UPDATE | 491 response for the offer2| | > +----------+----------+ | | > | | UPDATE | | | > | +----------+----------------------------+ 491 response for the offer1| > | | 1xx-rel | should not send UPDATE | | > | UPDATE +----------+ until ACK/PRACK transaction| | > | | 2xx-INV | is completed | | > + +----------+ | | > | | PRACK * | (*:invalid for init-INVITE)| | > +----------+----------+----------------------------+----------------------------+ > > Regards, > Shinji > >> Hi Paul, >> >>> I just submitted draft-ietf-sipping-sip-offeranswer-12.txt. >>> >>> It addresses comments received re -11 from Okumura Shinji, Brett Tate, >>> Gao Yang, and Keith Drage. >>> >>> Shinji had a number of comments regarding sections 4.1 and 4.2. I tried >>> to fit them in, not literally, but hopefully in spirit. >> Thank you for your work. >> >>> I had better >>> luck with section 4.1. For 4.2 I disagree that 3311 forbids the sending >>> of an UPDATE while awaiting a prack. (It probably should have been, but >>> I don't see that it is.) >> A B >> | | >> | INV (offer0)| >> |<------------------------------| >> | | >> | 1xx-rel (answer0) | >> |------------------------------>| --+ >> | | | Acknowledge >> | offer1(UPD) offer2(PRA)| | >> |============\ /===============| <-+ >> | \/ | >> | /\ | >> |<===========/ \==============>| >> | | >> >> [OS]>I think that the offer1 is a protocol violation as PRACK case in 4.1. >> [OS]>Probably RFC3311(UPDATE) prohibits this operation. >> >> RFC3311/Page 5 >> 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. >> >> At the time of sending the UPDATE, UA A(callee) has NOT received >> a PRACK for that reliable provisional response. According to the >> above description, the UPDATE cannot be sent with an offer. >> >> Regards, >> Shinji >> >>> Ultimately I couldn't figure out how to make >>> the comments on that section work. Modulo the parts I agreed with the >>> existing text has equivalent meaning, so I left it unchanged. >>> >>> Brett pointed out that Retry-After cannot be used with 491. I have >>> removed any suggestion that it should be. >>> >>> Gao wanted more emphasis on avoiding cases where it might be necessary >>> to fail a prack. I have reworded things to make that more explicit and >>> removed suggestions to use 491 as a response to prack. >>> >>> Keith objected to normative language in the suggestions that Gao made. I >>> have avoided using normative language. >>> >>> Please review this carefully - its always possible that subtle issues >>> could have crept in. >>> >>> Thanks, >>> Paul >>> >>> IETF I-D Submission Tool wrote: >>>> A new version of I-D, draft-ietf-sipping-sip-offeranswer-12.txt >>>> has been successfuly submitted by Paul Kyzivat and posted to >>>> the IETF repository. >>>> >>>> Filename: draft-ietf-sipping-sip-offeranswer >>>> Revision: 12 >>>> Title: SIP (Session Initiation Protocol) Usage of the Offer/Answer Model >>>> Creation_date: 2010-03-08 >>>> WG ID: sipping >>>> Number_of_pages: 22 >>>> >>>> Abstract: >>>> The Session Initiation Protocol (SIP) utilizes the offer/answer model >>>> to establish and update multimedia sessions using the Session >>>> Description Protocol (SDP). The description of the offer/answer >>>> model in SIP is dispersed across multiple RFCs. This document >>>> summarizes all the current usages of the offer/answer model in SIP >>>> communication. >>>> >>>> The IETF Secretariat. > _______________________________________________ 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