I did grab a fresh history and packet capture of a new(?) dead call.
sip show history [EMAIL PROTECTED] tranquility*CLI> * SIP Call 1. Rx INVITE / 1 INVITE 2. CancelDestroy 3. TxResp SIP/2.0 / 1 INVITE 4. TxResp SIP/2.0 / 1 INVITE 5. TxResp SIP/2.0 / 1 INVITE 6. TxRespRel SIP/2.0 / 1 INVITE 7. Rx ACK / 1 ACK 8. TxReqRel INVITE / 102 INVITE 9. Rx SIP/2.0 / 102 INVITE 10. CancelDestroy 11. Rx SIP/2.0 / 102 INVITE 12. CancelDestroy 13. Unhold SIP/2.0 14. TxReq ACK / 102 ACK 15. TxReqRel INVITE / 103 INVITE 16. Rx SIP/2.0 / 103 INVITE 17. CancelDestroy 18. Rx BYE / 201 BYE 19. TxResp SIP/2.0 / 201 BYE And the packet capture is attached again.. Matt Hess wrote:
Attached is a pcap of sip packets that pertain to another call similar to the history shown.. it's hard to nail these down as it takes a lot of time, patience and sifting through dumps.Olle E. Johansson wrote: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 _______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users_______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
odd call.pcap
Description: Binary data
begin:vcard fn:Matt Hess n:Hess;Matt org:LiveWire Networks adr;dom:;;4577 Pecos St;Denver;CO;80211 email;internet:[EMAIL PROTECTED] title:Sr. Network Engineer tel;work:303-458-5667 x 106 tel;fax:303-458-5725 x-mozilla-html:FALSE url:http://www.livewirenet.com/ version:2.1 end:vcard
_______________________________________________ --Bandwidth and Colocation sponsored by Easynews.com -- Asterisk-Users mailing list Asterisk-Users@lists.digium.com http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users
