We have two servers, one at each of our plants. We had direct inter-company route via IAX for the longest time. The IAX is not working currently due to some other routing issues, so we started just using the normal trunk and lines to communicate between plants. Our Dial plans are as follows
SITE A
ToSiteB -> IAX : pattern 1XX
ToTDS -> SIP : everything else normal outbound
SITE B
ToSiteA -> IAX : pattern 3XX
ToNextiva -> SIP : everything else normal outbound
When site A outbounds through ToTDS using site B’s external number and dials an extension all is well. when site B outbounds through ToNextiva using site A’s external number this is where things get wierd.
Say I am calling…
from B to A and I want extension 331 I will get 333
from B to A and I want extension 342 I will get 334
See the pattern? First two digits dialed are added to the 3XX pattern and last digit is ignored. This does not happen calling through external lines from A to B only from B to A. Deleting the Outbound route for B to A with the 3XX pattern in it solved the issue.
Thing is once I have already outbound through one route in these cases I hit site A’s IVR dialing from site B how can in the middle of that call another route and pattern take over?
Would you like the log from the receiving side or the calling side or both? I’m honestly not sure which one is causing me fits. I feel like Site B is the one since calling Site A from my cell phone works just fine.
So we are having trouble reproducing it. Here is what I’m told by site B. It’s happens frequently but not always. when it does it ringing will start after only punching 2 numbers. When it works it won’t start ringing until after all 3 ext digits are pressed. I will try to capture it in the act later again.
Seems to be all at Site B. We are using Yealink SIP-T38G at both sites. Site B was installed about a year after our site. I believe they have a newer firmware at the least. Not 100 percent on that. We have a Site to Site VPN so my phone is direct attached over the local IP to their phone system and I cannot reproduce the issue. However they can about 80% of the time accross multiple phones. They have not indicated if it happens calling other peoples phone systems. Only trying to call us since we dropped the IAX link between the two systems has it been brought up… but you know how these things go with users
So new info has been brought to light. Supposedly there are other people external to Site A and B, just a John Doe, that also have had this happen. So that would mean it’s something at Site A for sure. I still can’t reproduce it by force no matter how much i try. I am on latest version of FreePBX but on 11.xx of Asterisk. Should I on the fly switch to Asterisk 13 and see what happens?
@wciit
it’s highly unlikely that as switch to Asterisk will make any difference on your issue. What you describe is either a dialplan problem, or a user config issue.
I’ll go out on a limb and say that it’s highly unlikely to be a dialpan/FreePBX problem and almost certainly a user problem. I am not saying we are immune to issues in this area, it’s just our experience that almost all issues like this related to outbound calls ‘bleeding’ into the wrong outbound route end up being configuration confusion given that the Outbound Routing and Outbound Trunk configuration is one of the most confusing aspects of FreePBX to most people.
The areas where we have seen bugs of bleeding over in the past, related to Outbound Route rules that included CallerID pattern matching as part of the outbound route, coupled with multiple trunk failover, and the inclusion of alternative outbound routes that had the same based pattern and no CallerID matching. In other words, highly ‘complex’ and very rare configurations, and those have since been fixed (a long time ago). I believe there were also some corner cases that presented themselves coupled with the Extension Routing module that were also fixed. So … it’s very possible there are still some extreme corner case bugs lurking in that part of the dialplan for highly unusual configurations, it does not sound likely that your case is one of them.
A detailed log trace, with the possibility of manually adding some Noop() calls within the auto-generated dialplan, would probably help to trace if the calls is doing what you think it should be doing and if not, then you can try to decide if it’s a mis-understanding in the configuration or an apparent bug.
@p_lindheimer I should update the title it’s been discovered that we are having a different issue than Outbound from Site B but rather these are inbound calls routing wrong at the IVR coming into Site A. I would have thought maybe something outbound related from site B when i thought it was just our two building’s now i’m told it’s other people as well coming into us so.
John Doe -> TDS -> IVR -> 331 (punched) gets 333
Site B -> TDS -> IVR -> 316 (punched) gets 331
again the above doesn’t always happen but it’s not exclusive to just my Site B like i originally thought it’s inbound calls hitting our system at Site A. Our IVR is pretty simple. A day and night time condition. and only one level deep.
@plindheimer I’m getting reports that the issue is not occurring anymore. The only thing I have done is run updates (which as of the last week have been heavy) and disabled IVRPro. I noticed IVRPro was unsigned, but commercial and enabled. I am not licensed for it. uninstalled and re-downloaded it just re-enabled unsigned so i disabled it again. I will keep an eye out but so far so good.
