Yes that will be fine for de-bugging purposes but the UAC will never come to know what cuased the problem and try to overcome it on its own,because the application will not try to parse the reason header and take subsequent action based on it.
It will never come to know that which part of the message is forbidden.So it cannot retry ommiting that part. Is the reason for not allowing BYE for subscription termination is its inability to specify the package name for which it is intended? Or is there something else also? Thanks and regards, Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 -----Original Message----- From: Attila Sipos [mailto:attila.si...@vegastream.com] Sent: Thursday, April 16, 2009 4:05 PM To: Shamik Saha (WT01 - Telecom Equipment) Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? As we can see from your discussion, it seems that 405 is awkward to use and can lead to confusion. I think I still favour 403 Forbidden. To make it more helpful, one could add a Reason header: Reason: SIP ;cause=403 ;text="Method Not Allowed for Subscription Dialog" Thanks for your responses. Regards, Attila -----Original Message----- From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com] Sent: 16 April 2009 11:15 To: Attila Sipos Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? Now we can think of two scenarios, 1)A subscription within a Invite tansaction. 2)A subscription outside a invite transaction. In the second scenario,sending a 405 without including BYE in allowed methods will not be a problem,since we do not want to use a BYE within a subscription dialogue. In case we need to start a invite transaction then we can send another message with BYE included in the allowed header. However in the first scenario,we cannot send a 405 with BYE not included in the Allowed header field as this will confuse the invite transaction. A 403 will be fine but it will not allow the UAC to debug the error. One solution I can think of is sending a 486 busy here with a retry-after field set equal to the subscription interval, This will ensure that the UAC does not re-transmit the BYE within this period,and at the expiration of the timer the notifier will anyway send out a subscription temination. But then this is a crooked and dis-graceful way. I cannot think of any other solution which will be both graceful and effective. Another solution as I mentioned in my first mail will be to send a 481 and to terminate the transaction at the notifier end to stop transmission of the subscription termination. Let me know your thoughts. Thanks and regards, Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 -----Original Message----- From: Attila Sipos [mailto:attila.si...@vegastream.com] Sent: Thursday, April 16, 2009 3:14 PM To: Shamik Saha (WT01 - Telecom Equipment) Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? Thanks for the responses. Shamik, I undestand your reasoning - but what would be the contents of the Allowed header in the 405 response? And if the Allowed header only lists SUBSCRIBE, wouldn't it imply that that INVITE, BYE, etc aren't supported? So, it could confuse something receiving that response. Or if the Allowed header listed all methods as usual, it wouldn't help work out the problem and would be in contradiction to the meaning of the 405 response. Maybe "403 Forbidden" would be better though it doesn't help work out why the request went wrong. It does seem to be a more accurate reason than 405. 21.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. Regards, Attila -----Original Message----- From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com] Sent: 16 April 2009 08:37 To: Attila Sipos Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? A problem with 481 can be that the subscriber receiving 481 will consider the dialog as terminated,but the notifier will retain the dialog state. Eventually the notifier will terminate the dialog on timeout and send a subscription terminated message to the subsciber. The subsciber on receiving this message will try to match a existing subscirption which it will nt find as the subscirption has already being terminated on its end and so it will send a 481 subscription does not exist. Thus this scenario will lead to a dis-graceful subscription termination with extra messaging overhead. One solution can be the notifier terminating the dialog at its end also before sending the 481 response,so that it need not send any more subscription terminated message,but still that will be a dis-graceful termination,other than that I think 405 is still a good option. Thanks and regards, Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 -----Original Message----- From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip-implementors-boun...@lists.cs.columbia.edu] On Behalf Of Attila Sipos Sent: Thursday, April 16, 2009 12:25 PM To: sip-implementors@lists.cs.columbia.edu Subject: [Sip-implementors] BYE after SUBSCRIBE? As we know, when a new SUBSCRIBE occurs, it creates a dialog. But what should one do when a BYE is received on a SUBSCRIBE dialog? I don't think "405 Method Not Allowed" is right but maybe "481"? I can't believe that BYE should clear the dialog because, IMO, BYE is only valid for INVITE-created dialogs. Regards, Attila _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu 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 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 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 Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
