* You are viewing Posts Tagged ‘hangup’

What Would Cause A Drop Between Two Asterisk Systems?

We have an asterisk frontend terminating all our SIP phones to, and an asterisk backend with a wildcard PRI card in it connecting to the PTSN. The frontend handles 99% of dialplan logic and just hands off anything outgoing to the backend via IAX2, which dials out on one of the open channels.

Lately we’ve been getting a disconnected calls. Keeping the consoles running it doesn’t seem to be the PRI initiating the hangups, as I’ll when I see hangups intiiated on the backend / PRI side:

— Span 2: Channel 0/21 got hangup request, cause 16

Instead, I’m seeing

== Spawn extension (outbound, (dialed #), 3) exited non-zero on ‘IAX2/asterisk-frontend2-603′
— Hungup ‘IAX2/asterisk-frontend2-603′

Which indicates the frontend initiated a hangup. But on the frontend I’m seeing auto fallthroughs to the h extension, which only happens if the hangup is initiated from the backend:

— Auto fallthrough, channel ‘SIP/phone1-00000167′ status is ‘ANSWER’
(h extension stuff follows)

If that side was initiating the hangup, I’d just see a jump to the h extension, with no auto fallthrough. So it looks like there may be a communication interruption between the front and backends.

The problem is this happens intermittently, so I can’t reproduce it reliably. I’ve held open a call for 30+ minutes and not run into the problem, while someone’s been on a call for 7 minutes and this happens. It doesn’t seem feasible to constantly run IAX2 debugs from the console on any open call – does anyone have suggestions on how to troubleshoot this? Weirdly enough, this only seems to happen when users dial into conference bridges (not local) such as WebEx and GoToMeeting, but that might just be because of the length of those calls.

Will tweaking things like the IAX2 jitter buffer help? The two systems are barely four hops apart with an average of .2 ms ping times between them on a very resilient network (two of those hops are through core transports). I’ve never seen ping loss between them, even when running ping tests for hours during heavy call volume periods. The loads on the machines are minimal – never seen the load go above .10 during normal operation. But it does seem like something between them is making them drop calls.

hose

Hacked By Microsoft?

This morning someone tried to make sip call through my Asterisk. My server just drop these calls and record them in CDR with IP address:

2012-11-28 06:30:51 SIP/216… 1000 “1000″ <1000> hangup
999011972592249388 ANSWERED 00:01 Hacker: 168.63.67.239
2. 2012-11-28 06:30:49 SIP/216… 1000 “1000″ <1000> Hangup
88011972592249388 ANSWERED 00:01 Hacker: 168.63.67.239
3. 2012-11-28 06:30:46 SIP/216… 1000 “1000″ <1000> Answer
99011972592249388 ANSWERED 00:02
4. 2012-11-28 06:30:43 SIP/216… 1000 “1000″ <1000> Answer
1011972592249388 ANSWERED 00:02
5. 2012-11-28 06:30:39 SIP/216… 1000 “1000″ <1000> Hangup
2011972592249388 ANSWERED 00:00 Hacker: 168.63.67.239
6. 2012-11-28 06:30:33 SIP/216… 1000 “1000″ <1000> Hangup
7011972592249388 ANSWERED 00:01 Hacker: 168.63.67.239
7. 2012-11-28 06:30:30 SIP/216… 1000 “1000″ <1000> Answer
8011972592249388 ANSWERED 00:03
8. 2012-11-28 06:30:27 SIP/216… 1000 “1000″ <1000> Hangup
9011972592249388 ANSWERED 00:06 Hacker: 168.63.67.239
9. 2012-11-28 06:30:25 SIP/216… 1000 “1000″ <1000> Answer
011972592249388 ANSWERED 00:07

Now I noticed something interesting: The hacker’s IP address: 168.63.67.239

whois gave me:
NetRange: 168.61.0.0 – 168.63.255.255
CIDR: 168.61.0.0/16, 168.62.0.0/15
OriginAS:
NetName: MSFT-EP
NetHandle: NET-168-61-0-0-1
Parent: NET-168-0-0-0-0
NetType: Direct Assignment RegDate: 2011-06-22
Updated: 2012-10-16
Ref: http://whois.arin.net/rest/net/NET-168-61-0-0-1

OrgName: Microsoft Corp OrgId: MSFT-Z
Address: One Microsoft Way City: Redmond StateProv: WA
PostalCode: 98052
Country: US
RegDate: 2011-06-22
Updated: 2011-06-22
Ref: http://whois.arin.net/rest/org/MSFT-Z


hmmmmmmm…. Did I just hacked by Micro$oft?

Gao

Simultaneous Caller/callee Hangup; Hangup Extensions Execute Only Once; Unable To Determine If Destination Channel Up

Hello

This is a question regarding whether there’s any way within hangup extensions to determine whether the caller or callee leg (or both) of a bridged call has hung up. The test case I have is running under Asterisk 1.8.17.0, but the behaviour is observed in 1.8.18.0 (and also
1.6.2.18).

Within the dialplan, the Dial() application with the “F” flag, so that once the caller hangs up, the dialplan jumps to a new priority which enables the called party to enter some digits which describe the outcome of the call. Also, the “g” flag is used to attempt to continue execution of the dialplan if the called party hangs up.

Minimally, the dialplan is covered by the following:

[test]
exten => _1000,1,Set(_CALLER_HUNGUP

Question On Softhangup

How do I use softhangup through the AMI interface?

I am using 1.4.43. Will softhangup hangup a DAHDI channel?

I have found that “Action: Hangup” does not hangup a DAHDI channel only sip.

Thanks,

jerry

Alsa Channel

I have had a case where after a hangup on the Alsa CHANNEL asterisk still thinks the line or call is active.

I have:

rtptimeout`
rtpholdtimeout`
rtpkeepalive`

in my sip.conf file to help with this but it had no effect.

How can I ensure a session HANGS up and is not stale????

Is there a way for the next incoming call to VERIFY that console/ALSA
channel is still valid. I dont want to hangup a real connection – I want to give a busy tone for sure.

But if the session is not valid I need it gone.

How can I do that. I am using 1.4.43

Jerry

UDP Miss A Hangup On SIP

Is it possible to miss a UDP SIP packet to hangup a call?
Using 1.4.43 I had a call from on Asterisk box (server) to a low end client (chan_alsa) not hangup.

Could this be due to missed UDP SIP packet to hangup?

Is there anyway for a client asterisk (chan_alsa again) to monitor the connection and if the channel is not there to hangup?

Thanks,

Jerry