Matt Hess wrote:> I have this in sip show history for a particular channel marked as dead
> (should be removed) in sip show channels:
>
> 1. TxReqRel INVITE / 102 INVITE
> 2. Rx SIP/2.0 / 102 INVITE
> 3. CancelDestroy
> 4. Rx SIP/2.0 / 102 INVITE
> 5. CancelDestroy
> 6. Unhold SIP/2.0
> 7. Rx SIP/2.0 / 102 INVITE
> 8. CancelDestroy
> 9. Unhold SIP/2.0
> 10. Rx SIP/2.0 / 102 INVITE
> 11. CancelDestroy
> 12. Unhold SIP/2.0
> 13. TxReq ACK / 102 ACK
> 14. TxReqRel INVITE / 103 INVITE
> 15. Rx SIP/2.0 / 103 INVITE
> 16. CancelDestroy
> 17. Rx SIP/2.0 / 103 INVITE
> 18. CancelDestroy
> 19. Unhold SIP/2.0
> 20. TxReq ACK / 103 ACK
> 21. TxReqRel INVITE / 104 INVITE
> 22. Rx BYE / 302 BYE
> 23. TxResp SIP/2.0 / 302 BYE
> 24. Rx SIP/2.0 / 104 INVITE
> 25. CancelDestroy
>
> Why is asterisk allowing an invite after receiving a bye on a particular
> session/channel? From what I've read.. a bye should be the termination
> of the session/channel and therefore it should be hungup and removed..
> yet it is not.
>
> I am using cvs head from 2005-10-08 00:00 .. I can't use the latest cvs
> head as it's rather ugly with sip right now.. especially on
> refer/redirect/reinvites.. but that will be left for a different topic.
>
> I believe from looking at things that the sip gateway involved with the
> sip session is re-using a particular call identifier immediately after
> it believes that call from before is gone.. (possibly a bug on the
> vendor side as far as that goes) but regardless of whether the vendor is
> immediately re-using a session id or not should not matter as the fact
> seems to be that asterisk allows this situation to happen when (from
> what I've been reading) it should not. Does anyone have any comments or
> thoughts on this?
This history does not show the details on what Asterisk does. It seems
like Asterisk transmits an INVITE, then gets a BYE and after the BYE get
a response to the INVITE... Please provide a full SIP log so I see how
we react to the response of the INVITE...
/O