Mikael Magnusson wrote: > On Thu, Aug 18, 2005 at 10:50:42PM -0500, Kevin P. Fleming wrote: > >>Chee Foong wrote: >> >>>But I still dont understand why asterisk response to the BYE with OK since >>>it is not permited at the stage and leave the channels hanging. >> >>You are correct, Asterisk's response doesn't make much sense. However, >>there is no 'logical' response to a SIP endpoint that is violating the >>spec; the response is 'undefined' which means it could be anything. > > > I think Asterisk should respond with 481 (Call/Transaction Does Not Exist) > as defined in RFC 3261 Section 15.1.2: > > A UAS first processes the BYE request according to the general UAS > processing described in Section 8.2. A UAS core receiving a BYE > request checks if it matches an existing dialog. If the BYE does not > match an existing dialog, the UAS core SHOULD generate a 481 > (Call/Transaction Does Not Exist) response and pass that to the > server transaction. > I do not agree. We have a transaction. See section 15:
The caller’s UA MAY send a BYE for either confirmed or early dialogs, and the callee’s UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. 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 -------- Caller may send BYE on early dialog. Surprise, surprise to me. Callee MUST NOT. So we should accept this bye, send 487 on the invite and give up this dialog. /O _______________________________________________ Asterisk-Dev mailing list [email protected] http://lists.digium.com/mailman/listinfo/asterisk-dev To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
