[asterisk-users] SIP RTP ports not released when channel is hung up

Armin Schindler armin at melware.de
Tue Feb 16 08:36:36 CST 2010


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 <armin at melware.de> 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 - hunger at sipgate.de
> 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
> 
>


More information about the asterisk-users mailing list