26 jun 2013 kl. 14:32 skrev Brett Tate <br...@broadsoft.com>: > 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? > I have had a lot of discusisons about this and in Asterisk we ended up answering 200 OK to all in-dialog OPTIONs without bothering with the r-URI. It's messy.
Thank you for your summary below, Brett. /O > 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 _______________________________________________ Sip-implementors mailing list Sip-implementors@lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
