2011/7/26 Leo Leo <[email protected]>: > This makes no sense to me: > > > > Wrong. BYE can be used to terminate a *specific* dialog (answered or > not answered yet). > > Because... > > > RFC 3261 > > From section 9.1: > If the original > request has generated a final response, the CANCEL SHOULD NOT be > sent, as it is an effective no-op, since CANCEL has no effect on > requests that have already generated a final response.
This just says that a CANCEL must not be sent if there is already a final response. If a INVITE creates paralell forking in a proxy and there are N early-dialogs, then the UAC can send a BYE to any of them. > From section 15: > > However, the callee’s UA MUST NOT send a BYE on a confirmed dialog > until it has received an ACK for its 2xx response or until the server > transaction times out. (...) This is speaking about *confirmed* dialogs and BYE sent from the callee to caller. It has nothing to do with the case I'm describing. > Typically, when the user hangs up, it indicates a desire to > terminate the attempt to establish a session, and to terminate any > sessions already created. For the caller’s UA, this would imply a > CANCEL request if the initial INVITE has not generated a final > response, and a BYE to all confirmed dialogs after a final > response. It does not say that a BYE cannot be sent for an early-dialog. Leo, I'm ***sure*** (and it's not the first time I investigate or discuss about it) that a UAC can send a BYE to terminate an early-dialog, just in case there is route-set and remote-target for such early-dialog (if not, that is not an early-dialog yet). Please re-check section 15. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
