|Summary:||ASTERISK-17267: SIP channel not hung up on BYE|
|Date Opened:||2011-01-21 07:32:50.000-0600||Date Closed:||2011-06-07 14:05:02|
|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
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/18.104.22.168
Original uri: sip:email@example.com:5060
Need Destroy: No
Last Message: Rx: BYE
Promiscuous Redir: No
DTMF Mode: rfc2833
SIP Options: 100rel gruu replaces replace timer
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:
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
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.