This has also been reposted to the NZ local VoIP User Group, I'm pretty desperate to get this sorted :-/ TelstraClear is the local ADSL provider, 2talk is the ITSP. I've got other customers with both 2talk & TelstraClear, none of whom have reported any issues, so it appears to be local to this customer. Greetings all, We've got a bit of an issue with an install I'm just finishing up. Things have been great with the transition over to SIP, they have a dedicated ADSL connection with a Draytek DV120 through Telstraclear. Upload speed is around 850kbps, download is around 4500kbps, and the line appears reliable because through this whole time I've had an ssh connection running while trying to remotely diagnose it and I can see the Asterisk console streaming past when the calls drop. Asterisk shows: [root@sip ~]# asterisk -rvvvvv Asterisk 188.8.131.52, Copyright (C) 1999 - 2008 Digium, Inc. and others. Created by Mark Spencer <firstname.lastname@example.org> Asterisk comes with ABSOLUTELY NO WARRANTY; type 'core show warranty' for details. This is free software, with components licensed under the GNU General Public License version 2 and other licenses; you are welcome to redistribute it under certain conditions. Type 'core show license' for details. ========================================================================= == Parsing '/etc/asterisk/asterisk.conf': Found == Parsing '/etc/asterisk/extconfig.conf': Found Connected to Asterisk 184.108.40.206 currently running on sip (pid = 6906) Verbosity was 3 and is now 5 -- SIP/2talk-00c97e80 answered SIP/700-c80009d0 -- Remote UNIX connection -- Remote UNIX connection disconnected -- Executing [h@macro-dialout-trunk:1] Macro("SIP/700-c80009d0", "hangupcall|") in new stack -- Executing [s@macro-hangupcall:1] GotoIf("SIP/700-c80009d0", "1?skiprg") in new stack -- Goto (macro-hangupcall,s,4) -- Executing [s@macro-hangupcall:4] GotoIf("SIP/700-c80009d0", "1?skipblkvm") in new stack -- Goto (macro-hangupcall,s,7) -- Executing [s@macro-hangupcall:7] GotoIf("SIP/700-c80009d0", "1?theend") in new stack -- Goto (macro-hangupcall,s,9) -- Executing [s@macro-hangupcall:9] Hangup("SIP/700-c80009d0", "") in new stack == Spawn extension (macro-hangupcall, s, 9) exited non-zero on 'SIP/700-c80009d0' in macro 'hangupcall' == Spawn h extension (macro-dialout-trunk, h, 1) exited non-zero on 'SIP/700-c80009d0' == Spawn extension (macro-dialout-trunk, s, 19) exited non-zero on 'SIP/700-c80009d0' in macro 'dialout-trunk' == Spawn extension (from-internal, 021405552, 4) exited non-zero on 'SIP/700-c80009d0' Extension Changed 700[ext-local] new state Idle for Notify User 700 sip*CLI> What happens is their Snom phones (Apparently it also happens on their Linksys SPA942's too) just go silent, and the party at the other end hears "Call disconnected" tones, like when the other party has hung up. Initially I'd suspect it's an issue with the internet / 2talk, but it happens when I call in through ISDN and go straight through to an Ext too, using the Patton SN4554 box. This were going real smooth until this afternoon where it's got progressively worse, to the point where calls hang up every few minutes, but not on a regular timing. They've got a mix of Snom 320's, Snom 360's, Linksys SPA942 and Linksys SPA2102. The also have the SN4554 and a couple of SIP trunks to their provided 2talk. The box is running Elastix-1.6 on an Intel D510MO board, CPU is at 22c degrees and the motherboard is 41c. Inbound is primarily through ISDN using the SN4554. Outbound is through SIP through 2talk over the ADSL link, however I can also dial-in through SIP as the inbound routes are setup. I've checked in the phones and I don't believe they're trying to do any form of an update either, be it firmware or configuration. The customers gone home for the night, but I can get in and do an echo test to see... however I've just been on the line now for 20 minutes and it's not dropped my call. Usually it'd happen within a couple of mins at most. Yesterday they apparently had 2 dropped calls (Potentially unrelated?). Today, it started happening this afternoon, and we're not sure why, but they've had a few dozen (test calls) and a several real calls drop. Thankfully it wasn't a busy day on the phones today. I'm open to suggestions / thoughts / comments Cheers Chill.