Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Question about IPOffice 3
- Thread starter Cgull
- Start date
ITfromZX81
Programmer
Hi Peter,
From a networking perspective, this doesn't follow. There are VPN connections from the branch offices to the main office. The IPO data is sent through the VPN connections.
For a call to go from branch to branch, it's gotta go this way:
branch ----> main office ----> branch
This is simply because this is the way the network is setup. Branch to branch data HAS to go through the main office. Maybe it can be done the way you suggest, but this is not how it is setup right now. Our VPN routers(which are not Avaya IPOs) are setup this way, as this is how I was told to set them up.
I also know that there is nothing on the IPOs in the branch offices that direct them to attempt anything other than sending outside calls to the main office. There is nothing in their configs to re-route calls to a branch office to that branch office directly. It all gets pointed to the main office, which then puts the call through to the branch office.
(this also jives with a problem we had a few weeks ago when nobody could call out from the main office using extension numbers to branch offices. The branch offices could still call the main office but they could not call other branch offices. It turned out it was a configuration issue on the vpn routers which would not permit outgoing data from the IPO in the main office to go to the IPOs in the branch offices).
Maybe this explains some of our issues. Perhaps it should be setup to have vpn connections directly between branch offices, but the company installing the Avaya system asked me to set it up this way.
Thanks for your input.
- Mike
From a networking perspective, this doesn't follow. There are VPN connections from the branch offices to the main office. The IPO data is sent through the VPN connections.
For a call to go from branch to branch, it's gotta go this way:
branch ----> main office ----> branch
This is simply because this is the way the network is setup. Branch to branch data HAS to go through the main office. Maybe it can be done the way you suggest, but this is not how it is setup right now. Our VPN routers(which are not Avaya IPOs) are setup this way, as this is how I was told to set them up.
I also know that there is nothing on the IPOs in the branch offices that direct them to attempt anything other than sending outside calls to the main office. There is nothing in their configs to re-route calls to a branch office to that branch office directly. It all gets pointed to the main office, which then puts the call through to the branch office.
(this also jives with a problem we had a few weeks ago when nobody could call out from the main office using extension numbers to branch offices. The branch offices could still call the main office but they could not call other branch offices. It turned out it was a configuration issue on the vpn routers which would not permit outgoing data from the IPO in the main office to go to the IPOs in the branch offices).
Maybe this explains some of our issues. Perhaps it should be setup to have vpn connections directly between branch offices, but the company installing the Avaya system asked me to set it up this way.
Thanks for your input.
- Mike
I take it form the example that you are routeing calls as follows
Branch 1 - Main - Branch 2
in this case if you have Direct media path enabled you should only be using a VCM channel @ Branch 1 & Branch 2 NOT Main.
Both Mine & Peters Earlier Comments believed the calls to be Branch 1 - Main - Branch 1, in which case the link is dropped as soon as the call returns to branch 1
Branch 1 - Main - Branch 2
in this case if you have Direct media path enabled you should only be using a VCM channel @ Branch 1 & Branch 2 NOT Main.
Both Mine & Peters Earlier Comments believed the calls to be Branch 1 - Main - Branch 1, in which case the link is dropped as soon as the call returns to branch 1
ITfromZX81
Programmer
Hi IPGuru,
I was addressing the question about a call going from one branch to a second branch - at least some bandwidth HAS to be taken up since the data itself that makes up the call is routed through the main office, if the call is going from one branch to another seperate branch.
I understand what you guys are saying - if the call is routed back to the originating office, the IPO is designed to drop the routing to the main office and switchover to the caller just being routed in the branch office only. [I don't think this is going to work with calls going from one branch to a seperate branch.]
However, in practice the quality drops like a rock if a client calls a branch office, the call is forwarded to the main office and the call is transfered back to the same branch office. It improves dramatically if the call is not forwarded but just answered in the branch office only.
Therefore either a) it doesn't work the way it is supposed to or b) there is something wrong with the way it is setup or the way calls are transferred.
Maybe something is misconfigured?
Thanks again,
Mike
I was addressing the question about a call going from one branch to a second branch - at least some bandwidth HAS to be taken up since the data itself that makes up the call is routed through the main office, if the call is going from one branch to another seperate branch.
I understand what you guys are saying - if the call is routed back to the originating office, the IPO is designed to drop the routing to the main office and switchover to the caller just being routed in the branch office only. [I don't think this is going to work with calls going from one branch to a seperate branch.]
However, in practice the quality drops like a rock if a client calls a branch office, the call is forwarded to the main office and the call is transfered back to the same branch office. It improves dramatically if the call is not forwarded but just answered in the branch office only.
Therefore either a) it doesn't work the way it is supposed to or b) there is something wrong with the way it is setup or the way calls are transferred.
Maybe something is misconfigured?
Thanks again,
Mike
Mike did you try setting all your codecs the same? Ie if WAN bandwidth limitations force you to use g.729 for WAN voip traffic then set your ip hardphones to use g.729 also.
Out of curiousity why are you routing branch-branch trafic through your HQ vpn box? Seems to me that all that would accomplish is to bog down the connection at your HQ. I'll be the first to admit I'm not a data expert (having come up through the voice side of the convergence equation), but to my way of thinking it makes sense to create secondary tunnels between the branch's vpn boxes, especially with lots of inter-branch traffic.
Peter
Out of curiousity why are you routing branch-branch trafic through your HQ vpn box? Seems to me that all that would accomplish is to bog down the connection at your HQ. I'll be the first to admit I'm not a data expert (having come up through the voice side of the convergence equation), but to my way of thinking it makes sense to create secondary tunnels between the branch's vpn boxes, especially with lots of inter-branch traffic.
Peter
ITfromZX81
Programmer
Hi Peter,
I haven't tried setting the codecs, I want to check with the outfit that installed them.
The reason I'm routing all the branch-branch traffic through the main office is because the company which installed the Avaya system indicated that this way should work fine(it was how or vpns were setup originally, as data between branches was something that pretty much never happened - it all went back and forth to the main office).
I can quite easily setup secondary tunnels to each branch as long as the IPOs are setup to figure this out(I would assume they would just need to know the routes to the extensions).
I agree with you totally - I think the current setup would bog things down. I'm coming from a network background and I'm learning IPO as I go along. Therefore, my take on the problem is from a networking perspective.
Thanks for your input. Everyone on this site is very helpful. I will let you know how it goes.
- Mike
I haven't tried setting the codecs, I want to check with the outfit that installed them.
The reason I'm routing all the branch-branch traffic through the main office is because the company which installed the Avaya system indicated that this way should work fine(it was how or vpns were setup originally, as data between branches was something that pretty much never happened - it all went back and forth to the main office).
I can quite easily setup secondary tunnels to each branch as long as the IPOs are setup to figure this out(I would assume they would just need to know the routes to the extensions).
I agree with you totally - I think the current setup would bog things down. I'm coming from a network background and I'm learning IPO as I go along. Therefore, my take on the problem is from a networking perspective.
Thanks for your input. Everyone on this site is very helpful. I will let you know how it goes.
- Mike
TheMitelGuy
IS-IT--Management
- - - PETER - - -
I'm here in Ontario as well. I was wondering with that company that had DSL between the two IP Offices, do they EVER have bad quality voice? Or is it good 99.999% of the time?
Thanks
Neil
I'm here in Ontario as well. I was wondering with that company that had DSL between the two IP Offices, do they EVER have bad quality voice? Or is it good 99.999% of the time?
Thanks
Neil
ITfromZX81
Programmer
Hello all,
Peter,
I have not been able to change codecs on the phones yet(the company doing this stuff for us is taking forever to get back to me on this issue).
One thing I noticed in looking at the system is that in the branch office IPO and in the main office IPO, in the settings for the connections to each other(ie - the settings in one office IPO under the IP Line that connects to the other office)
- in the VOIP tab, Allow Direct Media Path is NOT checked.
Should it be? The only place this is checked on the system is for the individual IP Phones. It is never checked for the connections the IP Office devices have to each other.
What exactly does the setting Allow Direct Media Path do?
Thanks all in advance,
Mike
Peter,
I have not been able to change codecs on the phones yet(the company doing this stuff for us is taking forever to get back to me on this issue).
One thing I noticed in looking at the system is that in the branch office IPO and in the main office IPO, in the settings for the connections to each other(ie - the settings in one office IPO under the IP Line that connects to the other office)
- in the VOIP tab, Allow Direct Media Path is NOT checked.
Should it be? The only place this is checked on the system is for the individual IP Phones. It is never checked for the connections the IP Office devices have to each other.
What exactly does the setting Allow Direct Media Path do?
Thanks all in advance,
Mike
Mike,
It is correct for your network setup. Only check it after you setup secondary VPN tunnels directly between each branch. What it does is, after call setup is complete, allow the voice packets to travel directly between the endpoints instead of routing all traffic through the IPO at your main branch.
On that note you'll also need additional voip lines at each location. Ie. instead of one line (say 90) from branch A to HQ, you'll need to add 91 for branch B, 92 for Branch C, etc. and then repeat that at the other branches. Once all this is in place (secondary VPN tunnels, direct voip lines between all sites) you can tick the allow direct media path and you should put less demands on your IPO's.
I still say your biggest improvement will be to standardise all your codecs.
Peter
It is correct for your network setup. Only check it after you setup secondary VPN tunnels directly between each branch. What it does is, after call setup is complete, allow the voice packets to travel directly between the endpoints instead of routing all traffic through the IPO at your main branch.
On that note you'll also need additional voip lines at each location. Ie. instead of one line (say 90) from branch A to HQ, you'll need to add 91 for branch B, 92 for Branch C, etc. and then repeat that at the other branches. Once all this is in place (secondary VPN tunnels, direct voip lines between all sites) you can tick the allow direct media path and you should put less demands on your IPO's.
I still say your biggest improvement will be to standardise all your codecs.
Peter
ITfromZX81
Programmer
Hi guys,
I just had an evening work session with our supplier and we are ironing things out.
Here is what we did(at my suggestion from your suggestions):
I setup vpn tunnels directly between branch offices to bypass the main office when calls go branch-branch.
All IPOs in branch offices setup to route calls correctly to branch offices.
All IPOs and all IP phones set to Direct Media Path - note: when I did this, the anti-tromboning or anti-hairpinning or whatever you want to call it seemed to start working - it did not work before this. After I did this calls that came into a branch office, got transferred to the main office and then transferred back to the original branch office were very noticibly clearer when I got transferred back to the branch. All staff agree it is like night and day.
All IPOs and all IP phones set codecs to 729a
All of this has helped quite a bit with the quality of most calls.
The only weird thing I can report is that at one point I reset(using RESET on the phone keypad) my own phone to figure out an issue with a phone at a remote office, and then I only had one way calls(other party could not hear me but I could hear them). I had to turn off direct media path on my phone only and it fixed the problem - the weird part is that this phone worked fine with this setting on up to the point I reset the phone). One other phone in our organization had to have direct media path turned off as well(this is out of about 40 total IP phones).
Anyway, things are much improved. Thanks to everyone for their input - I really don't know if this would have been done if I hadn't pushed our provider to do it, and I would not have known to push if it wasn't for your help.
Does anyone have suggestions for QoS settings for VOIP? Do I just set tcp port 1719 to have priority?
Thanks again.
- Mike
I just had an evening work session with our supplier and we are ironing things out.
Here is what we did(at my suggestion from your suggestions):
I setup vpn tunnels directly between branch offices to bypass the main office when calls go branch-branch.
All IPOs in branch offices setup to route calls correctly to branch offices.
All IPOs and all IP phones set to Direct Media Path - note: when I did this, the anti-tromboning or anti-hairpinning or whatever you want to call it seemed to start working - it did not work before this. After I did this calls that came into a branch office, got transferred to the main office and then transferred back to the original branch office were very noticibly clearer when I got transferred back to the branch. All staff agree it is like night and day.
All IPOs and all IP phones set codecs to 729a
All of this has helped quite a bit with the quality of most calls.
The only weird thing I can report is that at one point I reset(using RESET on the phone keypad) my own phone to figure out an issue with a phone at a remote office, and then I only had one way calls(other party could not hear me but I could hear them). I had to turn off direct media path on my phone only and it fixed the problem - the weird part is that this phone worked fine with this setting on up to the point I reset the phone). One other phone in our organization had to have direct media path turned off as well(this is out of about 40 total IP phones).
Anyway, things are much improved. Thanks to everyone for their input - I really don't know if this would have been done if I hadn't pushed our provider to do it, and I would not have known to push if it wasn't for your help.
Does anyone have suggestions for QoS settings for VOIP? Do I just set tcp port 1719 to have priority?
Thanks again.
- Mike
Great news, Mike. Glad it is vastly improved. That is weird indeed on the two IP hardphones - are you sure they are running the latest firmware?
On QoS - no 1719 is only used for call setup. You have two methods of implementing QoS. Layer 3 - the TOS field on all voice packets is set to DSCP 46 (by default). Tell your switches to give that TOS priority. Also, Layer 4 - all RTP/UDP traffic is sent within UDP port range 49152-53247.
Peter
On QoS - no 1719 is only used for call setup. You have two methods of implementing QoS. Layer 3 - the TOS field on all voice packets is set to DSCP 46 (by default). Tell your switches to give that TOS priority. Also, Layer 4 - all RTP/UDP traffic is sent within UDP port range 49152-53247.
Peter
ITfromZX81
Programmer
Hi Peter,
Any simple way I can tell if the phones are running the latest firmware?
- Mike
Any simple way I can tell if the phones are running the latest firmware?
- Mike
ITfromZX81
Programmer
Hello again guys,
Well, I set QoS to the ports Morrack suggested, and this improved things greatly. I do get a bit of echoing if there is high bandwidth use, but other than that, it works really well now. Calls no longer go to pieces when a print job goes from the main office to a branch office.
I still have the problem with not being able to use Direct Media Path on a few phones, but that's something I can live with for now.
Thanks to everyone for all their help, especially Peter. I wish you were the guy who installed this stuff!! =)
- Mike
Well, I set QoS to the ports Morrack suggested, and this improved things greatly. I do get a bit of echoing if there is high bandwidth use, but other than that, it works really well now. Calls no longer go to pieces when a print job goes from the main office to a branch office.
I still have the problem with not being able to use Direct Media Path on a few phones, but that's something I can live with for now.
Thanks to everyone for all their help, especially Peter. I wish you were the guy who installed this stuff!! =)
- Mike
- Status