DIDs on the same SIP can't call each other - do you have this problem?
-
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
@Dashrender said in DIDs on the same SIP can't call each other - do you have this problem?:
Furthermore, my Mitel vendor tells me that the inability to call ourself is something that Cox specifically disables.
How? how could Cox possibly have that power?
uh, it's their network? now should they be excersing that power? that's another matter.
I'm currently waiting on a call back.
-
If you think of DIDs like IP addresses, because they are similar, your phone switch is a router. It knows what goes where and can send things out to the ISP or route them internally first. In this case, your internal addresses are getting sent out to the default gateway but the default gateway doesn't know how to handle them and the routing is failing. But the real problem is that the default gateway knows that the call is coming FROM the address in question so that it doesn't hairpin the call is not entirely crazy. That the "router" is sending the call to the outside when it is an inside call... that is the crazy part.
-
Of course, putting this dialing pattern in place does present another issue - or should I say change of trouble shooting.
In the past, we'd pick up our own phone and call ourselves to see if our numbers were working - well now that simply won't work. Testing will be required to come from other sources, cell phones, landlines, etc.
-
@Dashrender said in DIDs on the same SIP can't call each other - do you have this problem?:
Of course, putting this dialing pattern in place does present another issue - or should I say change of trouble shooting.
In the past, we'd pick up our own phone and call ourselves to see if our numbers were working - well now that simply won't work. Testing will be required to come from other sources, cell phones, landlines, etc.
If you want internal calls to hairpin only for testing, then yes, that is true. But it is an odd use case.
-
Also, you typically do not test from internal phones to test because if there is an issue with call routing, you would not see it.
-
What brought this to my attention earlier today was that when my staff need to reach a doctor, they just - wait for it - page them (with the phone number they are at). In today's case, the person getting the page was inside our facility, picked up the phone and tried to dial the 10 digit number - and it failed.
We can't change this workflow of paging with 10 digit numbers because we have no clue where the doc might be.
-
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
If you think of DIDs like IP addresses, because they are similar, your phone switch is a router. It knows what goes where and can send things out to the ISP or route them internally first. In this case, your internal addresses are getting sent out to the default gateway but the default gateway doesn't know how to handle them and the routing is failing. But the real problem is that the default gateway knows that the call is coming FROM the address in question so that it doesn't hairpin the call is not entirely crazy. That the "router" is sending the call to the outside when it is an inside call... that is the crazy part.
AGREED! but that's how was setup for TDM, so what the heck do I know?
-
@Dashrender said in DIDs on the same SIP can't call each other - do you have this problem?:
What brought this to my attention earlier today was that when my staff need to reach a doctor, they just - wait for it - page them (with the phone number they are at). In today's case, the person getting the page was inside our facility, picked up the phone and tried to dial the 10 digit number - and it failed.
We can't change this workflow of paging with 10 digit numbers because we have no clue where the doc might be.
So the issue is that the docs can't get back to the person paging them? The page works, but there isn't a reliable way to respond?
-
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
@Dashrender said in DIDs on the same SIP can't call each other - do you have this problem?:
What brought this to my attention earlier today was that when my staff need to reach a doctor, they just - wait for it - page them (with the phone number they are at). In today's case, the person getting the page was inside our facility, picked up the phone and tried to dial the 10 digit number - and it failed.
We can't change this workflow of paging with 10 digit numbers because we have no clue where the doc might be.
So the issue is that the docs can't get back to the person paging them? The page works, but there isn't a reliable way to respond?
Exactly.
-
@Dashrender said in DIDs on the same SIP can't call each other - do you have this problem?:
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
If you think of DIDs like IP addresses, because they are similar, your phone switch is a router. It knows what goes where and can send things out to the ISP or route them internally first. In this case, your internal addresses are getting sent out to the default gateway but the default gateway doesn't know how to handle them and the routing is failing. But the real problem is that the default gateway knows that the call is coming FROM the address in question so that it doesn't hairpin the call is not entirely crazy. That the "router" is sending the call to the outside when it is an inside call... that is the crazy part.
AGREED! but that's how was setup for TDM, so what the heck do I know?
Ask the people who chose a proprietary PBX and Cox locked in SIP lines, they are the ones that made this choice, it's their call as to what to do now, right? It's not your problem.
-
If you had normal (not ISP locked in) SIP lines and/or an open source PBX (or any number of apparently better proprietary ones) this would not be an issue. It's mind boggling that this is an issue as it is. But someone made some decisions here and this is the result of those. No idea why someone made them, but they did. Let them know the results of their decisions and ask them how they want to handle it.
-
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
If you had normal (not ISP locked in) SIP lines and/or an open source PBX (or any number of apparently better proprietary ones) this would not be an issue. It's mind boggling that this is an issue as it is. But someone made some decisions here and this is the result of those. No idea why someone made them, but they did. Let them know the results of their decisions and ask them how they want to handle it.
It is a Cox provided SIP trunk. So of course they can do this if they want. It is 100% their network. I am willing to bet that a Cox SIP trunk has no such restriction though. It is highly unlikely that Cox has a completely separate switch for SIP service compared to PRI service, and you did not have this problem when the same numbers came in over the Cox PRI.
The problem is more likely bad routing on the Mitel side.
-
@JaredBusch said in DIDs on the same SIP can't call each other - do you have this problem?:
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
If you had normal (not ISP locked in) SIP lines and/or an open source PBX (or any number of apparently better proprietary ones) this would not be an issue. It's mind boggling that this is an issue as it is. But someone made some decisions here and this is the result of those. No idea why someone made them, but they did. Let them know the results of their decisions and ask them how they want to handle it.
It is a Cox provided SIP trunk. So of course they can do this if they want. It is 100% their network. I am willing to bet that a Cox SIP trunk has no such restriction though. It is highly unlikely that Cox has a completely separate switch for SIP service compared to PRI service, and you did not have this problem when the same numbers came in over the Cox PRI.
The problem is more likely bad routing on the Mitel side.
I'd agree here, I simply don't believe that either Cox or Mitel actually are this bad. This is one bad consultant avoiding admitting that he doesn't know how to set up a Mitel PBX.
-
@JaredBusch said in DIDs on the same SIP can't call each other - do you have this problem?:
@scottalanmiller said in DIDs on the same SIP can't call each other - do you have this problem?:
If you had normal (not ISP locked in) SIP lines and/or an open source PBX (or any number of apparently better proprietary ones) this would not be an issue. It's mind boggling that this is an issue as it is. But someone made some decisions here and this is the result of those. No idea why someone made them, but they did. Let them know the results of their decisions and ask them how they want to handle it.
It is a Cox provided SIP trunk. So of course they can do this if they want. It is 100% their network. I am willing to bet that a Cox SIP trunk has no such restriction though. It is highly unlikely that Cox has a completely separate switch for SIP service compared to PRI service, and you did not have this problem when the same numbers came in over the Cox PRI.
The problem is more likely bad routing on the Mitel side.
Agreed. I've seen Translation patterns that are two vague cause issues like this (sometimes even causing loops not stop in and out of the SIP trunks).
We have a translation pattern for the DIDs to just translate to the internal extensions, Simple and saves money.
-
The problem(s) are solved. and they were several.
- hairpin calling didn't work
- outside callers on Cox's network (and perhaps any network) couldn't call in reliably, this resulted in different results for different networks, some people got fast busies, other got, this number is not in service (that message was horribly wrong, but is the fault of either bad encoding or poor error matching with the carrier).
The problem as it was explained to me.
The Edgemarc provided by Cox had a problem and was hanging calls. We requested 23 channels, and they've provisioned us for 30 to handle over flow. When they looked they found 27 "active" calls but couldn't tell if they were real calls or if the edgemarc was simply frozen on those channels.
The reset those 27 channels, did other tweaking and now EVERYTHING works. Hairpin calling works, and calls are coming into the system. of course, we're not under load, so only time will tell if it's fixed.
Additionally they noted that the Edgmarc has what they called old firmware on it. They are going to bring out a replacement Edgemarc tomorrow with updated firmware and swap them out. The new firmware is something they have been deploying for at least a month, but wheren't sure how long and currently there are no reported errors with it.
Holy shit this was stressful day!
-
OK talking about hairpinning - When I mentioned to Cox that Mitel vendor said that Cox prevents hairpinning, he had no idea what I/vendor was talking about.
In my situation though, the lack of hairpinning was a result of a malfunctioning Edgemarc, not the Mitel 5000.
But I did inquire about having the Mitel 5000 do the hairpinning internally.
They said that they couldn't do it in a way that was completely transparent to end users.
I don't know why, but this MItel 5000, like many other commercial systems requires an 8 (9 seems more common) to get an outside line. So we have the following scenerio:
Doc gets page 402-555-5555, when they are in our offices they would dial 8-402-555-5555. Because of that 8, they are telling me that they can't do any additional routing other than that the call will be sent to an outside line.
They proposed two solutions.
- On the Mitel, create a routing rule for 7, like 8, but that the system knows that the call will be routed internally, then train the the staff to page the providers with #402-555-5555 so the provider will know by the # that this is a call from our office, and if they are in our office they need to call 7-402-555-5555 instead of starting with 8.
this is pretty complex and easy to forget - not a great solution
- create a dedicated DID for them to call in on. Now staff would page 402-555-1111 (the new dedicated number) and the phone system would prompt them for what extension they want to dial.
So the page would like like this 402-555-1111#1234
In this case, when the provider sees the extension, they know it's ours and when inside, they would be trained to dial only the extension.
While still not awesome, this would be a much better solution.
-
so you can't have doctors call an extension? they can't dial a 4 digit extension?
-
@KyleCaminita said in DIDs on the same SIP can't call each other - do you have this problem?:
so you can't have doctors call an extension? they can't dial a 4 digit extension?
Of course they can - but sending a 4 digit extension to a pager when they are the hospital - the doc has no idea who sent that - was it hospital 1-5 or their own office? that's why the phone number has worked great for 20 years.
and was maddening when I learned it MIGHT not be possible anymore. -
No sure why they can't do translation rules, Cisco can still do this. The problem is if you "live" dial by picking up the headset first the system usually will assume you want the PSTN
-
@Jason said in DIDs on the same SIP can't call each other - do you have this problem?:
No sure why they can't do translation rules, Cisco can still do this. The problem is if you "live" dial by picking up the headset first the system usually will assume you want the PSTN
I think pressing the 8 is the same as live dialing, that's why they can't intercept it.
