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


Attachment: svi error.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

Reply via email to