[Asterisk-Dev] SIP channels not cleared

[Olle E. Johansson]

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