On Tue, 16 Feb 2010, Marcus Hunger wrote:
Hi,
did you see this one: https://issues.asterisk.org/view.php?id=16774 ? It looks
related to your issue.
Oh thanks, I missed that one.
It really looks related. I have added a note.
Thanks,
Armin
Best regards, Marcus
On Fri, Feb 12, 2010 at 12:04 PM, Armin Schindler <[email protected]> wrote:
On Fri, 12 Feb 2010, Armin Schindler wrote:
>>>> I had a look at
>>>> netstat -nuap
>>>> and it shows that a lot of ports are still assigned, even if there
is no
>>>> channel in use.
>>>> But "sip show channels" show a lot of (unused) entries with no
>>>> codec/Format and "Last Message" like INVITE, REGISTER, OPTIONS.
>> REGISTER and OPTIONS allocate no RTP ports, so those are not a
problem. If
>> you have a SIP channel that has a last message being INVITE and still
say
>> you have no calls, you have a problem right there.
>
> I just see these entries with "sip show channels", but cannot tell if
> e.g. the REGISTER listed channels have RTP ports allocated.
> Who can I find out which SIP channel allocated which port?
> Or which SIP channel belongs to the ports I see with 'netstat -nuap'?
I just made a test to confirm:
After a restart of asterisk (to have a clean state with no sip channels
activ and no RTP port allocated), I can confirm that:
- REGISTER and OPTION listed sip channels don't use RTP ports
- after some calls (e.g. SIP to SIP) the RTP ports are freed immediately
(looks like this is the case on hangup before answer).
- after some other calls, the RTP ports are freed after about 20-30 seconds
after hangup.
So basically all is correct.
> I do have a sip channels like
> 172.21.4.114 666 0430c3a638e 00102/00000 0x0 (nothing) No Init:
INVITE
> in 'sip show channels' and they don't go away for a long time.
> Shouldn't there be a timeout to destroy such a channel even if somehow
> the phone was 'disconnected' in during a call?
>
>>> If the channels exists even after 32 seconds after BYE, and BYE was
>>> signaled correctly, I would file a bug report.
It really looks like that there is a case where the sip channel is not
destroyed and that is the cause of the problem.
I will try to reproduce this.
Any ideas?
Armin
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
--
Dipl.-Inf. (FH)
Marcus Hunger - [email protected]
Telefon: +49 (0)211-63 55 55-61
Telefax: +49 (0)211-63 55 55-22
sipgate GmbH - Gladbacher Str. 74 - 40219 Düsseldorf
HRB Düsseldorf 39841 - Geschäftsführer: Thilo Salmon, Tim Mois
Steuernummer: 106 / 5724 / 7147, Umsatzsteuer-ID: DE219349391
www.sipgate.de - www.sipgate.at - www.sipgate.co.uk
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users
