[Asterisk-Users] sip rfc bye violated?

[Matt Hess]

I should have mentioned that I can't do a full sip log.. with several 
calls a second whipping through this system it's almost impossible to 
weed out the info for the proper call.. and usually I don't see the dead 
channel until well after the fact.

I did grab a fresh history and packet capture of a new(?) dead call.

sip show history 96327948 at SVIGateway
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 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
>>
>>
> _______________________________________________
> --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: odd call.pcap
Type: application/octet-stream
Size: 7270 bytes
Desc: not available
Url : http://lists.digium.com/pipermail/asterisk-users/attachments/20051018/33b78800/oddcall.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/33b78800/mhess.vcf