The initial query by Attila was that what will be the behavior of a notifier when a subscriber sends a BYE request within a existing subscription,so we had two scenarios for that 1)A subscribe within a invite transaction. for that the behavoir got cleared. 2)A subscription outside of a invite transaction. So my query was regarding that BYE which will be sent by a subscriber for a non-invite transaction. If in this scenario the notifier sends a 481 response,the subscription and the subsequent dialog will be terminated in the subscriber,however the subscription will exist at the notifier which on timer timeout will send subscription terminated,on the receipt of which the subsciber will send a 481 subscription does not exists. Am I right in this regard?
________________________________ From: Brett Tate [mailto:br...@broadsoft.com] Sent: Thu 4/16/2009 8:59 PM To: Shamik Saha (WT01 - Telecom Equipment) Cc: sip-implementors@lists.cs.columbia.edu Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? Concerning your quote of RFC 3261 481 text, I'm not sure if you are asking about SUBSCRIBE/NOTIFY 481 or BYE 481 impacts upon dialog and/or associate usage. If you are asking about SUBSCRIBE/NOTIFY 481 and there is no INVITE usage, yes the 481 also impacts the dialog since no more usages. If you are asking about BYE 481 while there is still a SUBSCRIBE usage, no it doesn't impact the dialog (beyond what may happen to other implementations not interpreting 481 per RFC 5057). The following is the snippet discussing 481 ambiguity associate RFC 3261 and multiple dialog usages. (8) 481 Call/Transaction Does Not Exist: This response indicates that the peer has lost its copy of the dialog usage state. The dialog itself should not be destroyed unless this was the last usage. The effects of a 481 on a dialog and its usages are the most ambiguous of any final response. There are implementations that have chosen the meaning recommended here, and others that destroy the entire dialog without regard to the number of outstanding usages. Going forward with this clarification will allow those deployed implementations that assumed only the usage was destroyed to work with a wider number of implementations. Existing implementations that destroy all other usages in the dialog will continue to function as they do now, except that peers following the recommendation will attempt to do things with the other usages and this element will return 481s for each of them until they are all gone. However, the necessary clarification to RFC 3261 needs to make it very clear that the ability to terminate usages independently from the overall dialog using a 481 is not justification for designing new applications that count on multiple usages in a dialog. > -----Original Message----- > From: shamik.s...@wipro.com [mailto:shamik.s...@wipro.com] > Sent: Thursday, April 16, 2009 11:12 AM > To: Brett Tate > Cc: sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] BYE after SUBSCRIBE? > > 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. 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
