Thanks for the responses. As per RFC 3326, BYE may have Reason Header.
---- Initially, the Reason header field defined here appears to be most useful for BYE and CANCEL requests, but it can appear in any request within a dialog, in any CANCEL request and in any response whose status code explicitly allows the presence of this header field. ---- We have a requirement wherein we need to have Reason Header for BYE. Since the status code was 200 (INVITE -- 200 OK; but no ACK), I was unsure what to add in the Reason Header field for BYE. The examples which were given were for CANCEL request. I was thinking to add Reason Header for BYE in similar lines. Regards, Sunil -----Original Message----- From: Avasarala Ranjit-A20990 [mailto:[email protected]] Sent: Wednesday, January 20, 2010 5:25 PM To: Sunil Bhagat (WT01 - Telecom Equipment); [email protected] Subject: RE: [Sip-implementors] Reason Header in BYE Hi I do not think you can put reason header in BYE request unless you want to convey some additional information to the server while terminating a call normally. For e.g. in I-D http://cidr-report.org/ietf/idref/draft-avasarala-sipping-reason-header- dynamic-icb/ the reason header in BYE is used to block a particular identity from further calling. And the reasons you mentioned actually do not make sense for BYE, but for other requests like CANCEL or responses like 4xx. Regards Ranjit -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Wednesday, January 20, 2010 5:02 PM To: [email protected] Subject: [Sip-implementors] Reason Header in BYE Hi All, I have a doubt regarding Reason Header in BYE request. We can have the different Reason Header in BYE request depending on the call state. Some of the examples are given below: Reason: SIP ;cause=600 ;text="Busy Everywhere" Reason: SIP ;cause=580 ;text="Precondition Failure" Reason: SIP ;cause=200 ;text="Call Completed Elsewhere" My doubt is - what should be the Reason Header if BYE is sent after server transaction times out waiting for ACK? 13.3.1.4 The INVITE is Accepted If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. 15 Terminating a Session However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. In this case, can we have something like the following in BYE request? - Reason: SIP ;cause=200 ;text="Call Completed Normally" Would this be wrong as it is not a normal call termination? Regards, Sunil Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors Please do not print this email unless it is absolutely necessary. The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
