[Asterisk-Users] sip rfc bye violated?

[Matt Hess]

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 at 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
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: svi error.pcap
Type: application/octet-stream
Size: 6793 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20051018/87c43246/svierror.obj
-------------- next part --------------
A non-text attachment was scrubbed...
Name: mhess.vcf
Type: text/x-vcard
Size: 288 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20051018/87c43246/mhess.vcf