Hi Paul, Concerning PRACK 488 text within draft-ietf-sipping-sip-offeranswer, I don't have a strong opinion as long as RFC 3262 is adequate to avoid interoperability problems upon sending/receiving PRACK 481. If needed to avoid interoperability problems, the draft should indicate that UAS should avoid sending PRACK 481 if receives PRACK resubmit with higher cseq (and appropriate content modifications) attempting to obtain a PRACK 2xx after UAS sent prior PRACK 488. Concerning resubmitting PRACK because of 488, the draft should highlight that a 481 may be received by UAC; it should highlight that the 481 is potentially because of prior PRACK satisfying the UAS instead of the dialog usage being unknown. Concerning RFC 5057, I'd like the errata for section 5.1 note 8 to discuss PRACK 481 applying to transaction (similar to CANCEL) instead of usage. However my comment is mainly for interoperability reasons since RFC 5057 is informational (i.e. it did not update RFC 3262). > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@xxxxxxxxx] > Sent: Wednesday, April 08, 2009 8:12 AM > To: Brett Tate > Cc: sipping@xxxxxxxx > Subject: Re: PRACK 481 (was RE: 答复: Re: 答复: Re: PRACK: Change > MUST requirement to include SDP offer in first reliable provisional > response) > > Brett, > > That's a good point. What would you like to see done about it? > > Thanks, > Paul > > Brett Tate wrote: > >> Considering UAC, it can judge from the 4xx to terminate > >> the session (such as 481), or send a new PRACK. > > > > The PRACK 481 should not automatically terminate the dialog usage. > > > > Since avoiding the sending of PRACK 481 (after sending PRACK 488 and > similar failure responses) is an open issue within draft-ietf-sipping-sip- > offeranswer-10 section 6.1, I thought that I'd mention the RFC 3262 text > and potentially missing RFC 5057 text concerning PRACK 481. > > > > RFC 3262 section 3 indicates to send PRACK 481 similar to sending CANCEL > 481. The 481 should not automatically terminate the usage since the UAS > is not necessarily indicating that the dialog does not exist. > > > > "If a PRACK request is received by the UA core that does not match any > unacknowledged reliable provisional response, the UAS MUST respond to the > PRACK with a 481 response." > > > > Unfortunately RFC 5057 section 5.1 note 8 only appears to discuss the > special consideration for CANCEL instead of also discussing PRACK. > > > > "The 481 response to a CANCEL request has to be treated differently. > For CANCEL, a 481 means the UAS can't find a matching transaction. A 481 > response to a CANCEL affects only the CANCEL transaction. The usage > associated with the INVITE is not affected." > > > > _______________________________________________ > > 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/sippingThis list is for NEW development of the application of SIPUse sip-implementors@xxxxxxxxxxxxxxx for questions on current sipUse sip@xxxxxxxx for new developments of core SIP
