|
|
Joined: Mar 2013
Posts: 22
Member
|
Member
Joined: Mar 2013
Posts: 22 |
So here is one that has me boggled. I have a client with two systems, an OS7400 in one city and an OS7100 in another city. They are connected over a VPN tunnel. Currently they have VOIP connecting to the OS7400 (set to private/public). I have the SPLink setup and MMC838 set to point to the OS7100 since they are on very different subnets. I can make calls as such:
OS7400 Digital to OS7100 OS7400 Digital to VOIP OS7100 Digital to OS7400 VOIP to OS7400 VOIP to OS7100 VOIP to VOIP
I cannot get the OS7100 Digital sets to dial successfully to the VOIP. It seems to just go to voicemail. They can leave, the person get the voicemail, and then call back, but this isn't very efficient. Being that it is on the VPN, there shouldn't be any ports blocked over it. Does anyone have any ideas as to what I can look at? I feel like we are missing *one* setting. It's just frustrating that we are on the last leg of this. Any help is greatly appreciated.
|
|
|
Visit Atcom to get started with your new business VoIP phone system ASAP
Turn up is quick, painless, and can often be done same day.
Let us show you how to do VoIP right, resulting in crystal clear call quality and easy-to-use features that make everyone happy!
Proudly serving Canada from coast to coast.
|
|
|
Joined: Feb 2011
Posts: 11
Member
|
Member
Joined: Feb 2011
Posts: 11 |
Hi,
Did you enable VPN on the officeserv (5.14.3)
|
|
|
|
Joined: Jan 2005
Posts: 340
Member
|
Member
Joined: Jan 2005
Posts: 340 |
You need to incorporate the whole network in 838. For Example - If site A is 192.168.3.xxx and Site B is 192.168.4.xxx then in mmc838 you need to enter 192.168.255.255 in the field. You also might have to set the private w public to private only.
Last edited by Ironhedz; 03/18/13 08:59 PM.
|
|
|
|
Joined: Jun 2006
Posts: 3,004 Likes: 4
Moderator-Samsung
|
Moderator-Samsung
Joined: Jun 2006
Posts: 3,004 Likes: 4 |
Mmc838 is only required when you have private with public turned on, and have both public and private ip traffic (eg sip trunks via public, and spnet or ip phones on a different subnet (such as via vpn or private ip (mpls))
Setting private only negates the need for mmc838
|
|
|
|
Joined: Mar 2013
Posts: 22
Member
|
Member
Joined: Mar 2013
Posts: 22 |
We have to have Private w/ Public on the OS7400 site since they have outside VOIP phones. Setting it to Private only kills that.
From what I understood, I need to only put in the phone system & MGI IPs in MMC838, not the whole subnet. Why would I do a subnet?
I will look a the VPN setting and see what we have there. Thanks for the idea.
I appreciate all the input on this.
|
|
|
|
Joined: Mar 2013
Posts: 22
Member
|
Member
Joined: Mar 2013
Posts: 22 |
Vimponia> Unfortunately 5.14.3 didn't seem to have anything that was related to the issue.
Yesterday, we figured out the OS7100 to VOIP calling issue. We needed to add a 32** to Ring Plan B in 3.2.3. That took care of it.
Unfortunately, now I get to tackle why the DIDs assigned in 3.2.3 to the VOIP extensions do not ring to them. Instead they ring to the receptionist at the OS7400 location (which is what the VOIPs are based off). AWe have the DIDs listed in 3.2.3 pointing to the VOIP extensions for Ring Plan 1-6. It is formatted the same as all the DIDs pointing to Digital extensions which work without issue.
I turned ON the DID Error Tone in 5.14.4, which confirmed when I dialed the DID that it came up as unavailable, which is why it was ringing to the receptionist. However, if it is in 3.2.3, it shouldn't come up as undefined.
I saw references in the Programming Manual that said if DID Error Tone was off, that it would ring the operator group if it wasn't found in 5.15.8. All extensions are listed in there the same way.
I have gone through the manual searching for anything DID related, and cannot find what I must be missing. Any ideas on this? Thanks in advance for any help you can offer on this.
|
|
|
|
Joined: Mar 2013
Posts: 22
Member
|
Member
Joined: Mar 2013
Posts: 22 |
I just realized that I never gave a follow-up on this. It turns out that the carrier wasnt passing all 7 digits, only 4. That's why anything that wasn't DID to ext similar didn't work. Once they changed it and set it to pass all 7 digits, everything worked perfectly.
Thanks for all input on this.
|
|
|
Forums84
Topics94,512
Posts639,933
Members49,844
|
Most Online5,661 May 23rd, 2018
|
|
0 members (),
109
guests, and
36
robots. |
Key:
Admin,
Global Mod,
Mod
|
|
|
|
|