Thank you for your reply and the link to the proceedings. I guess you refer to the following paragraph from the minutes:
"Another question: suppose the UAC receives a BYE after a crash and reboot. This will have an apparently new Call-Id, but a familiar tag. Should the response be 200 OK or 481? Jonathan suggested that the UAC issue a 200 OK to ensure that the call is cleared. Christian Huitema [[email protected]] said to use 481 -- admit you don't know about the call and let the far end recover. Adam Roach [[email protected]] cited a need to distinguish methods in choosing the response. The basic concern is that 481 doesn't necessarily clear the call. Jonathan argued that, based on the principle of transaction independence, a 481 response on a re-INVITE fails that transaction but not the complete call. Despite this argument, the general view was that 481 means the call is dead. Jonathan's concern was that we are breaking a general model: call state shouldn't be determined by 400-class response. However this interpretation of 481 has already been implemented. The final consensus: 481 means the call is dead." The last sentence seems pretty clear and I would interpret this as not having to send a BYE from the UAC but just to clean up the dialog/call state locally. Since the proceedings are from 2000, I'm however concerned that this particular consensus was again overturned for RFC3261 (which is from 2002). Are there any more recent official statements on this matter? If not, could someone think of a possible issue when the dialog is just cleaned up locally without sending a BYE afterwards? Best regards, Peter On Tue, Mar 1, 2011 at 1:23 PM, Brett Tate <[email protected]> wrote: > > Did I just misread the RFC and the dialog can just be cleaned > > up locally or is the UAC nevertheless supposed to send a BYE, > > cleaning up the dialog when the BYE transaction finally > > terminates? > > The following is from RFC 3261 section 12.2.1.2: > > "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. A UAC SHOULD also terminate a dialog if > no response at all is received for the request (the client > transaction would inform the TU about the timeout.) > > For INVITE initiated dialogs, terminating the dialog consists of > sending a BYE." > > > For those interested, the 481 topic was discussed within IETF 49 SIP > working group: > http://www.ietf.org/proceedings/49/ > > > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
