2010/3/12 Saúl Ibarra <[email protected]>: > Hi Iñaki, > > On Fri, Mar 12, 2010 at 5:39 PM, Iñaki Baz Castillo <[email protected]> wrote: >> Well A could generate a BYE with a very high CSeq (at least greater >> than the failed OPTIONS) and send it to B2BUA but it's, for sure, not >> required at all. >> >> My question is: could somebody please point me to the exact point in >> RFC 3261 in which this is explained? I need it to document a failure >> in a SIP device. I have no doubt about that the above is 100% correct >> (A is not required to send such BYE), but I have to document it and >> cannot find the exact specification in RFC 3261. >> >> Any reference in RFC 3261 please? Thanks a lot. >> > > Humm, maybe you do need to send that BYE: > > Sec. 12.2.1.2: > "The UAC will receive responses to the request from the transaction > layer. If the client transaction returns a timeout, this is treated > as a 408 (Request Timeout) response." > ... > "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." > > So from what I understand here, that OPTIONS which hasn't been > answered will generate a local 408, so you should terminate the dialog > with a BYE. I recently came into this with the case of re-INVITEs: > imagine user A starts an audio session with user B and then user A > decides to add video (re-INVITE) .If user B is away from his computer > with a wireless headset and can't answer the re-INVITE, user A should > send a BYE. :-S
Opsss, so A is required to send a BYE even if the remote endpoint didn't reply to an in-dialog request?? I was wrong then! Thanks a lot (also to Thomas Gelf for confirming it). -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
