|Summary:||ASTERISK-09567: Interoffice IAX2 trunk kills VoipStreet trunk|
|Reporter:||William Smith (wpns)||Labels:|
|Date Opened:||2007-06-01 20:08:22||Date Closed:||2011-06-07 14:02:39|
|Environment:||Attachments:||( 0) VoipStreet.zip|
( 1) VoipStreet-with-interoffice-verbosity9.log
|Description:||After adding an interoffice IAX2 trunk, my VoipStreet IAX2 trunk stops working. Errors range from incoming calls being rejected for failure to negotiate codecs, to incoming calls being routed back out the trunk, and coming back in again, creating many channels.|
It's repeatable, deleting the interoffice trunk make everything start working again.
Strangely, I don't have this problem with my Vitelity IAX trunks.
****** ADDITIONAL INFORMATION ******
TrixBox 2.2, FreePBX 2.2.1, all modules up to date.
The 'offending' trunk runs across my VPN:
And then a different name and different IP address on the other side. Each of the trunks works fine independently, but together they trash the VoipStreet trunk.
The VoipStreet trunk looks like:
|Comments:||By: Joshua C. Colp (jcolp) 2007-06-04 06:51:26|
Can you please provide console output with this and also an iax2 debug or two of failures? Without these there isn't much we can do.
By: William Smith (wpns) 2007-06-04 07:59:55
I've uploaded voipstreet.zip, with the functional (no interoffice trunk) and unsuccessful (with interoffice trunk) logs with:
set debug 9
turned on. As you can see, the incoming call gets immediately routed back out hy default outbound trunk (vitel-outbound) and then comes back in on VoipStreet. Rinse Lather repeat.
Is there some lower-level debug I can turn on? I'm not sure these logs show _why_ the call is routed back out the outbound trunk when the interoffice trunk exists...
By: Joshua C. Colp (jcolp) 2007-06-04 08:07:17
The verbose needs to be turned up to see the dialplan logic that is executing... I suspect that is the issue.
By: William Smith (wpns) 2007-06-04 08:22:47
OK, there's one with verbosity 9
By: Joshua C. Colp (jcolp) 2007-06-04 08:28:25
From the last output it looks like this is a Trixbox configuration issue.
By: William Smith (wpns) 2007-06-06 09:11:29
Apparently it used to happen with Asterisk@Home as well, what configuration file would I look in to try to find the logic that's getting corrupted?
By: Joshua C. Colp (jcolp) 2007-06-06 09:14:47
Trixbox/Asterisk@Home both use/used AMP, the web portal, which generates the dialplan logic to handle calls. This is output in extensions.conf but if you start mucking with that stuff directly it could get overwritten.
By: Joshua C. Colp (jcolp) 2007-06-12 11:11:47
Determined to be a Trixbox issue. If you have further information indicating it is an internal Asterisk issue please reopen with the info. Thanks.