Hi Brett, I went through that part it says that the dialog shold not be destroyed unless it is the last usage of this dialog,but in case of a non-invite subscription ,the subscription itself is the last and the only usage so,will the subscription not be terminated?
Thanks and regards, Shamik Saha Project Engineer Voice Protocols Cell : +91-9886704155 -----Original Message----- From: Brett Tate [mailto:br...@broadsoft.com] Sent: Thursday, April 16, 2009 8:33 PM To: Shamik Saha (WT01 - Telecom Equipment) Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? The RFC ambiguity is discussed within RFC 5057; search for 481. The most relevant text is within section 5.1 note 8 concerning 481. > -----Original Message----- > From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com] > Sent: Thursday, April 16, 2009 10:58 AM > To: attila.si...@vegastream.com > Cc: pkyzi...@cisco.com; Brett Tate; > sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > But section 12 of RFC3261 says that if a 481 response is received > within a dialogue then the dialoue will be terminated > > " If the response for a request within a dialog is a 481 > (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC > SHOULD terminate the dialog." > > So essentially the subscription state at the subscriber end will also > be removed. > > 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 8:12 PM > To: Shamik Saha (WT01 - Telecom Equipment); pkyzi...@cisco.com > Cc: br...@broadsoft.com; sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > > >>Will a 481 response in such a sceanrio terminate the subscription at > the subscriber`s end? > > if it is a 481 BYE response, no. > if it is a 481 SUBSCRIBE response, yes - the subscription usage (and > the dialog - assumming only one usage) would get destroyed - the > subscription would have to get destroyed too. A new subscription > could be created after (if required). > > > > > -----Original Message----- > From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com] > Sent: 16 April 2009 15:34 > To: pkyzi...@cisco.com > Cc: br...@broadsoft.com; Attila Sipos; > sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > One more thing, > > What will be the case with a subscrption which is not part of a invite > transaction. > > Will a 481 response in such a sceanrio terminate the subscription at > the subscriber`s end? > > Thanks and regards, > > Shamik Saha > Project Engineer > Voice Protocols > Cell : +91-9886704155 > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzi...@cisco.com] > Sent: Thursday, April 16, 2009 7:36 PM > To: Shamik Saha (WT01 - Telecom Equipment) > Cc: br...@broadsoft.com; attila.si...@vegastream.com; > sip-implementors@lists.cs.columbia.edu > Subject: Re: [Sip-implementors] BYE after SUBSCRIBE? > > > > shamik.s...@wipro.com wrote: > > Hi Brett, > > > > In section 4 it is said that > > > > " Dialogs come into existence along with their first usage. Dialogs > > terminate when their last usage is destroyed. The messages that > > create and destroy usages vary per usage. This section provides a > > high-level categorization of those messages. The section does not > > attempt to explore the REGISTER pseudo-dialog." > > > > So since the invite transaction creates this dialog so this will be > > the first and the founding usage of this dialogue. > > > > When we send the subscription request and gets back the 200OK the > > subscribe usage is created which is the second usage within the > > initial invite dialogue. > > > > > > > > So when we get a 481 in response to a BYE it will only terminate the > > usage associated with that BYE transaction. > > true > > > Which in our case will be the subscription usage. > > Brett already responded to you about this. > There is no single indicator in a request of which usage it belongs to. > That must be determined contextually: > - certain methods are tied to a particular usage: > . BYE, INFO, UPDATE, (re)INVITE are always part of INVITE usage > - some methods could be part of more than one usage. > additional info from the message determines which one: > . SUBSCRIBE, NOTIFY, PUBLISH are always part of a usage > determined by the event type and id > > So, the BYE is part of the INVITE usage if there is one, and is in > error if there is none. > > If we had a dialog with both INVITE and SUBSCRIBE usages, and then > there can easily be cases in which both ends attempt to terminate the > INVITE by sending BYE. In that case one of them will probably be getting a 481. > > And that should not harm the SUBSCRIBE usage. > > (See RFC 5407 - race-examples.) > > > However if the INVITE usage is destroyed after the esatblishment of > > the subscription usage then the subscription usage will be the last > > usage and its termination will terminate the dialog. > > That is true > > > Otherwise,the initial INVITE transaction will be unaffected. > > > > It is said that 481 terminate the usage > > > > "Destroys Usage The error destroys the usage, but not the dialog. > > Any other usages sharing this dialog are not affected." > > > > So I think since INVITE usage is the dialog creating usage, > > yes > > > which is not > > related to the BYE message it will be un-affected. > > no > > > Please let me know if my thoughts are wrong. > > done. > > Thanks, > Paul > > > Thanks and regards, > > > > Shamik Saha > > Project Engineer > > Voice Protocols > > Cell : +91-9886704155 > > > > -----Original Message----- > > From: Brett Tate [mailto:br...@broadsoft.com] > > Sent: Thursday, April 16, 2009 6:56 PM > > To: Shamik Saha (WT01 - Telecom Equipment) > > Cc: sip-implementors@lists.cs.columbia.edu > > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > > > Shamik, > > > > Please reread section 4 concerning the distinction between INVITE > > usage and SUBSCRIBE usage. > > > > Per tables 1 and 2, BYE 481 applies to the INVITE usage. > > > > -brett > > > >> -----Original Message----- > >> From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > >> implementors-boun...@lists.cs.columbia.edu] On Behalf Of > >> shamik.s...@wipro.com > >> Sent: Thursday, April 16, 2009 9:12 AM > >> To: attila.si...@vegastream.com > >> Cc: sip-implementors@lists.cs.columbia.edu > >> Subject: Re: [Sip-implementors] BYE after SUBSCRIBE? > >> > >> But in RFC 5057 page 9,it is said that a 481 will terminate the > >> SUBSCRIPTION usage but the INVITE usage dialogue within which the > >> subscription is established will be un-affected. > > > > > > 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 > > > > 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
