[Home]

Summary:ASTERISK-17267: SIP channel not hung up on BYE
Reporter:gb_delti (gb_delti)Labels:
Date Opened:2011-01-21 07:32:50.000-0600Date Closed:2011-06-07 14:05:02
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Channels/chan_sip/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:
Description:I have a SIP peer as a queue member that gets reported as "in use". When I do a "core show channels", the channel does not show up. When I do "sip show channels" the channel shows up like this:

10.3.3.234       3044            3869d2204b9d93e   0x100 (g729)     Rx: BYE

This is the channel info:

* SIP Call
 Curr. trans. direction:  Incoming
 Call-ID:                3869d2204b9d93ef
 Owner channel ID:       SIP/3044-00002ba2
 Our Codec Capability:   270
 Non-Codec Capability (DTMF):   1
 Their Codec Capability:   268
 Joint Codec Capability:   268
 Format:                 0x100 (g729)
 T.38 support            No
 Video support           No
 MaxCallBR:              384 kbps
 Theoretical Address:    10.3.3.234:5060
 Received Address:       10.3.3.234:5060
 SIP Transfer mode:      open
 NAT Support:            RFC3581
 Audio IP:               10.3.1.65 (local)
 Our Tag:                as4d7a7e66
 Their Tag:              3fcbfd73a3
 SIP User agent:         Aastra 55i/2.4.1.37
 Username:               3044
 Peername:               3044
 Original uri:           sip:3044@10.3.3.234:5060
 Caller-ID:              3044
 Need Destroy:           No
 Last Message:           Rx: BYE
 Promiscuous Redir:      No
 Route:                  sip:3044@10.3.3.234:5060;transport=udp
 DTMF Mode:              rfc2833
 SIP Options:            100rel gruu replaces replace timer
 Session-Timer:          Inactive

I have tried to hang up the channel, but it was not found.
Comments:By: Leif Madsen (lmadsen) 2011-01-21 12:34:32.000-0600

This may or may not be related:

https://reviewboard.asterisk.org/r/1077
By: Terry Wilson (twilson) 2011-01-21 13:04:30.000-0600

If having 'sip set debug' turned on doesn't show BYE retransmissions, then it isn't the same issue. It looks like in this case Asterisk received a BYE instead of sent it. There is a transaction timer (sort of) that lasts 64 * t1timer (by default = 64 * 500ms = 32s) that fires to tear down the sip_pvt when retransmissions should end. It could be that this is just correct behavior and that gb_delti just needs to wait the 32 seconds for the transaction to be torn down. They don't necessarily end when the call ends.
By: Leif Madsen (lmadsen) 2011-01-21 13:09:34.000-0600

Ah that sounds right to me. I'm closing this issue.
By: gb_delti (gb_delti) 2011-01-24 02:47:09.000-0600

No, the "in use" status and SIP channel last for hours.
By: Leif Madsen (lmadsen) 2011-01-24 08:40:22.000-0600

We'll need a SIP trace then to show what is going on.
By: gb_delti (gb_delti) 2011-01-24 09:00:33.000-0600

Ok, will do that. The error is not reproducible but crops up from time to time, so it can take while until I can post it here. "SIP trace" means the SIP traffic between * and the phone, right?
By: Leif Madsen (lmadsen) 2011-01-24 14:58:15.000-0600

Yes it does.
By: Leif Madsen (lmadsen) 2011-02-18 14:07:23.000-0600

Ping?
By: gb_delti (gb_delti) 2011-02-21 02:49:00.000-0600

The issue still exists. It occured once again, while we had no SIP log. We now we are logging but waiting for the error to occur ...
By: Leif Madsen (lmadsen) 2011-04-14 09:34:04

Closing issue for now. Please reopen when you have the appropriate information.