For what it worth, sipcore has been discussing OPTIONS lately concerning issues when used in-dialog and outside of dialog. OPTIONS will be discussed at the IETF meeting.
The following is a link to one of the threads: http://www.ietf.org/mail-archive/web/sipcore/current/msg02020.html Concerning in-dialog usage of OPTIONS, timeouts, 408, 481, and etcetera, RFC 5057 attempts to clarify things. > -----Original Message----- > From: sip-implementors-boun...@lists.cs.columbia.edu [mailto:sip- > implementors-boun...@lists.cs.columbia.edu] On Behalf Of Iñaki Baz > Castillo > Sent: Friday, March 19, 2010 8:38 AM > To: sip-implementors@lists.cs.columbia.edu > Subject: [Sip-implementors] RFC 3261: section 12.2.1.2 VS section 11 > > Hi, let me redefine a question I already did: > > > - A client initiates a SIP UDP call with a server. The call is > correctly established. > > - After the INVITE transaction the client sends an in-dialog OPTIONS > to check the dialog status. > > - Due to a SIP stack bug, the server ignores the in-dialog OPTIONS (no > response is given but the dialog and RTP remains active in both > directions). > > - The client retransmits the OPTIONS until a transaction timeout > occurs (32 seconds). At this point the client decides to stop sending > RTP but doesn's send a BYE. > > - The call remains active in the server until a RTP timeout occurs > (i.e. after 1 minute without receiving RTP from the client). Then the > server sends a BYE and receives 481 because the client closed, > internally, the call. > > - Client's CDR shows a call of 32 seconds (until the OPTIONS > transaction failed due to timeout). > > - The server's CDR shows a call of 92 seconds (the initial 32 plus 60 > seconds until RTP timeout raises). > > > > > Server side argument: The client should send a BYE after it detects > the in-dialog OPTIONS timeout by following RFC 3261 section 12.2.1.2 > (the BYE is mandatory): > > --------------------------------------- > 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. > --------------------------------------- > > > > Client side argument: A failing OPTIONS means that the server is > unreachable so it doesn't make sense to send a BYE (taken such > argument from RFC 3261 section 11): > > --------------------------------------- > As is the case for general UA behavior, the transaction layer can > return a timeout error if the OPTIONS yields no response. This may > indicate that the target is unreachable and hence unavailable. > --------------------------------------- > > > > > I'm pretty sure that section 12.2.1.2 (server side argument) has > preference over section 11, this is, an in-dialog failed transaction > (due to timeout) must force the client sending a BYE to terminate the > call. Such BYE could arrive to the server or not (in case there are > network problems or the server is down), but it must try to send such > BYE. > > However I would like to hear your opinnions about this issue, along > with any other reference justifying one of both arguments. > > > Thanks a lot and best regards. > > > -- > Iñaki Baz Castillo > <i...@aliax.net> > > _______________________________________________ > 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
