答复: PRACK 481 (was RE: 答复: Re: 答复: Re: PRACK: Change MUST requirement to include SDP offer in first reliable provisional response)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




Hi,

Yes. But I did not mean automatically.

The process of termination of session should obey RFC3261.

IMO, BYE is *recommended*. Cancel would terminate other forking branch.

How to do it is just complementarity of RFC3262, not overthrow of it.
And I am not sure that really we need to give out a detail process for behaviour of violation of *MUST NOT*.

Gao




Brett Tate <brett@xxxxxxxxxxxxx>
发件人:  sipping-bounces@xxxxxxxx

2009-04-08 19:17

收件人
"sipping@xxxxxxxx" <sipping@xxxxxxxx>
抄送
主题
[Sipping] PRACK 481  (was RE:  答复: Re: 答复: Re:  PRACK: Change MUST requirement to include SDP offer in first reliable provisional response)





> 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


--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
_______________________________________________
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

[Index of Archives]     [IETF Announce]     [IETF Discussion]     [Linux SCSI]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [XFree86]     [Big List of Linux Books]

  Powered by Linux