We are running Asterisk 11.19 in an Amazon EC2 instance and it works well for us overall. We use ConfBridge for internal meetings. My dialplan does not provide any access to the conference rooms from an outside line. My EC2 instance is behind a firewall with holes open for the fewer than ten total SIP phones that use the PBX at all.
During conference calls, we occasionally have a completely unrelated phone call barge into our room. It usually sounds like we originated a call, that is, some automated attendant suddenly starts listing their company hours and menu options. Occasionally a human answers. Once, when we got a human, we had a brief conversation with her, indicating that the audio is live both ways.
The interruption is pretty consistently short, perhaps 20 seconds and not more than 30 seconds.
Naturally, all the standard call progress logs show that nothing happened. Our asterisk did not log any call activity other than the participants dialing in to our confbridge in the first place.
Is there anything I can do short of logging every single RTP packet to figure out what is really happening here?
Use the command confbridge list to list conference bridges and participants. and makes sure that all are legitime participants, Also make sure full log is enable on your logger.conf file, if this is asterisk issue the answer it is on you logs files
confbridge list showed me that I had two zombie participants. Both were connections via our SIP trunk provider to POTS numbers, which had long since hung up.
From that list and core show channels I was able to isolate call IDs that I could locate in my CDR logs, which showed that the zombies were probably lingering for six months.
At that point, confbridge kick was able to kill the zombies.
So the much deeper question is how those zombies happened in the first place. It does appear that their presence in some sort of undead state could explain how audio was getting in to a private PBX through a firewall at all.
I haven’t tested it enough to know for sure, but early indications are that the barge in problem may be solved. Now I just need to figure out what to look for in the log files to notice the problem sooner.
The dialplan is very simple. No outside lines have access to dial in to the ConfBridge, and I’ve only configured a single conference room entered via a single internal extension.
I’ve solved the immediate problem thanks to ambiorixg12.
If the BYE was lost and never received from the PSTN provider it is possible for the call to have remained up in Asterisk. As well since it’s in a ConfBridge Asterisk will continue to send media to the PSTN provider gateway. If the PSTN provider gateway has NAT functionality it will likely switch where it sends media, causing the current call using that RTP port on the gateway to suddenly start sending it to you.
Is there some way to detect this sort of zombie sooner?
Shouldn’t some part of Asterisk have noticed that the call is effectively dead and dropped it, perhaps with caution and logging something?
For that matter, shouldn’t my trunk provider have noticed something odd and complained? I’m certainly hoping that these zombies weren’t on the clock on my metered connection!
I can’t find any fingerprints of the zombie in /var/log/asterisk/messages, at least not around the date when the SIP channels were first set up.
Asterisk has mechanisms you can enable in sip.conf to try to detect dead calls. Session timers is one where a SIP message is sent and if no response is received then the call is terminated. RTP timeout is another where if RTP is not received for a period of time then the call is terminated.
Thanks, I’ve turned session timers on in my SIP configuration. Googling around doesn’t seem to indicate there are any obvious pitfalls to be found there, and seems to indicate that the idea of a session timer is fairly mature.
To get rid of the last few stale mystery objects in the SIP channel, I restarted Asterisk, and a test call seems to indicate that a session timer was turned on for a channel originating in my Grandstream phones. So that will likely prevent future abandoned SIP channels.