Hi, If they are use OPTIONS to determine call/subscription/dialog state...
Does anyone know what response they are expecting to receive when there is no dialog usage? Does anyone know the RFC snippet indicating what should be sent and how the UAC should act upon receiving the response? Thanks, Brett > -----Original Message----- > From: Tarun2 Gupta [mailto:tarun2.gu...@aricent.com] > Sent: Wednesday, June 26, 2013 7:12 AM > To: Brett Tate; sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] SIP messages exchange to maintain a > session > > Brett > > I agree that OPTIONS is not a recommended way, however I believe that > it is still being used by many end points (may be due to ease of > implementation). > > Regards > Tarun Gupta > Aricent > > > -----Original Message----- > From: Brett Tate [mailto:br...@broadsoft.com] > Sent: Wednesday, June 26, 2013 4:26 PM > To: Tarun2 Gupta; sip-implementors@lists.cs.columbia.edu > Subject: RE: [Sip-implementors] SIP messages exchange to maintain a > session > > I do not recommend attempting to use OPTIONS to determine call/dialog > state. > > RFC 3261 is ambiguous concerning if a 481 should ever be sent for > OPTIONS. Similarly RFC 5057 clarifies that OPTIONS is not part of > dialog usage; thus a 481 has no impact/meaning. There isn't another > OPTIONS response to clearly indicate that the related dialog is > unknown/terminated (and destroy the entire dialog). > > RFC 3261 section 11.2: > > "An OPTIONS request received within a dialog generates a 200 (OK) > response that is identical to one constructed outside a dialog and > does not have any impact on the dialog." > > RFC 3261 section 12.2.2: > > "Requests that do not change in any way the state of a dialog may be > received within a dialog (for example, an OPTIONS request). They are > processed as if they had been received outside the dialog." > > RFC 5057 section > > "OPTIONS does not belong to any usage. Only those failures discussed > in Section 5.1 and Section 5.2 that destroy entire dialogs will have > any effect on the usages sharing the dialog with a failed OPTIONS > request." _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
