Hi oa-lovers, I have two proposals. |2.2. Rejection of an Offer | (snip) | Alternatively the UA may terminate the | dialog and send an error response to the INVITE request I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------- Alternatively the UA may send an error response to the (re)INVITE request to terminate the dialog or to roll back the offer-answer status before sending reINVITE request. In this case UAS should not continue to retransmit the unacknowledged reliable provisional response, UAC should not continue to retransmit a PRACK request. ------------------------------------------------------------------- |2.2. Rejection of an Offer | (snip) | (While it may be tempting to respond with a 488 response in this | case, that is not recommended, because it does not acknowledge the | response.) 488 response to PRACK is still tempting for (hopefully not only) me. "UAS may respond 488 and UAC should send again PRACK without offer." I think it doesn't violate the current normative definition, the process is more effective than always-200OK with a meaningless SDP. I propose the alternative text for the above-mentioned one. ------------------------------------------------------------------- The 488 response is another proposed solution, UAS may respond with a 488 response and then UAC should send again a PRACK request without an offer. ------------------------------------------------------------------- By way of caution, I do not deny "always-200OK". Regards, Shinji >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. 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.) 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 sip-implementors@xxxxxxxxxxxxxxx for questions on current sip >Use sip@xxxxxxxx for new developments of core SIP _______________________________________________ Sipping mailing list https://www.ietf.org/mailman/listinfo/sipping This list is for NEW development of the application of SIP Use sip-implementors@xxxxxxxxxxxxxxx for questions on current sip Use sip@xxxxxxxx for new developments of core SIP
