Hi Iñaki, On Fri, Mar 19, 2010 at 1:37 PM, Iñaki Baz Castillo <[email protected]> wrote: > 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. > --------------------------------------- >
To me, that means a local 408 will be generated, thus the rules of 12.2.1.2 should apply from now on, and the UAC should send a BYE. > > > > 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. > I think they complement each other. This is: you could get a 408/481 back from the server, or you could timeout yourself, and generate a local 408, which has the same effect as it was received from the other side IMHO, so you'd act the same, that is, send a BYE. That's my 2 cents :) Kind regards, -- /Saúl http://saghul.net | http://sipdoc.net _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
