Mitel Forums - The Unofficial Source
Mitel Forums => Mitel MiVoice Business/MCD/3300 => Topic started by: cchaney on November 23, 2012, 02:22:36 AM
-
Hey all -- thanks in advanced for even reading the post.
We just ordered a few SIP trunks from Bandwidth and have our vendor configuring the trunks with our 3300 PBX.
Up to this point, we are still having issues with one way audio -- they can hear us, we cannot hear them. Test calls are usually placed from my teleworker phone and captures have been done using port mirroring and Wireshark.
Our PBX is NAT'ed behind a Cisco ASA security appliance, which is SIP aware. From what I can see, it looks like our firewall is properly handling the translations/etc to/from Bandwidth's SIP proxy.
Bandwidth is reporting a ‘Not Acceptable’ from the PBX, from what they have said.
VoIP Flow:
|Time | 10.1.2.2 | 68.xxx.xxx.xxx |
| | | 216.82.xxx.xxx |
|0.000000000| INVITE | | |SIP From: "C.User" <sip:+281xxxxxxx@10.1.2.2 To:<sip:+1281xxxxxxx@216.82.xxx.xxx
| |(5060) ------------------> (5060) | |
|0.000449000| | INVITE | |SIP Request
| | |(5060) <------------------ (5060) |
|0.097827000| | 100 Giving a try |SIP Status
| | |(5060) ------------------> (5060) |
|0.097941000| 100 Giving a try | |SIP Status
| |(5060) <------------------ (5060) | |
|4.205087000| | 183 Session Progress |SIP Status
| | |(5060) ------------------> (5060) |
|4.205356000| 183 Session Progress | |SIP Status
| |(5060) <------------------ (5060) | |
|19.623845000| | 200 OK SDP (g711U telephone-eventRTPType-101) |SIP Status
| | |(5060) ------------------> (5060) |
|19.624424000| 200 OK SDP (g711U telephone-eventRTPType-101) | |SIP Status
| |(5060) <------------------ (5060) | |
|19.672179000| ACK SDP (g711U telephone-eventRTPType-101) | |SIP Request
| |(5060) ------------------> (5060) | |
|19.672840000| | ACK SDP (g711U telephone-eventRTPType-101) |SIP Request
| | |(5060) <------------------ (5060) |
|26.235692000| BYE | | |SIP Request
| |(5060) ------------------> (5060) | |
|26.236031000| | BYE | |SIP Request
| | |(5060) <------------------ (5060) |
|26.346427000| | 200 OK | |SIP Status
| | |(5060) ------------------> (5060) |
|26.346695000| 200 OK | | |SIP Status
| |(5060) <------------------ (5060) | |
Here is the trace from Bandwidth support:
U 2012/11/06 20:32:48.834529 68.xxx.xxx.xxx:5060 -> 216.82.xxx.xxx:5060
SIP/2.0 406 Not Acceptable.
Via: SIP/2.0/UDP 216.82.xxx.xxx;branch=z9hG4bKb2b.d003737.0,SIP/2.0/UDP 67.231.xxx.xxx;branch=z9hG4bKb2b.5dbb3216.3,SIP/2.0/UDP 192.168.37.68:5060;branch=z9hG4bK0bB86c148cbb1cb7710.
Record-Route: <sip:216.82.xxx.xxx;lr;ftag=gK0b07b3aa>,<sip:67.231.xxx.xxx;lr=on;ftag=gK0b07b3aa>.
Warning: 399 10.1.2.2 "19H Reject".
From: <sip:+1919xxxxxxx@192.168.37.68;isup-oli=0>;tag=gK0b07b3aa.
To: <sip:+1281xxxxxxx@67.231.xxx.xxx>;tag=0_2240970064-98773126.
Call-ID: 1863043143_16435119@192.168.37.68.
CSeq: 17638 INVITE.
Contact: <sip:68.xxx.xxx.xxx>.
Server: Mitel-3300-ICP 11.0.1.26.
Content-Length: 0.
Happy Thanksgiving!
-
Removing the teleworkers as a problem, do calls work just from a local hand set on site?
-
Going to have a user do a test call today and make sure a capture is taken during the same time -- I'm remote to that office so I'm reliant on my TW.
-
I wouldn't be surprised if it is just the teleworkers from what you have described. It would probably be a routing issue on the MBA server. Some static routes would fix it if that is the case.
-
Ok so verified -- local users are able to call out using the SIP trunk but TW phones still not able to (remote party can hear, calling party cannot hear) -- and each time I can, I get the 'major alarms' from the MBG showing one way audio.
Could you give me an example of the static route configuration for the MGA/MBG that would allow this to work?
So happy you have me on the right path!
-
And FYI, the MBG is setup using the Gateway mode profile
-
I wonder if its your router (at teh TW end causing the problem. SIP awareness can be a real problem area. Try turning it off locally and see if that makes any difference.
-
And FYI, the MBG is setup using the Gateway mode profile
Yep, guessed this to be the case. You need to add the address range for the sip provider to your local LAN list on the mbg , and tell it to go via the ASA. It will probably be trying to go via the MBG wan interface at the moment.
I'm on my iPad at the moment so can't look up the details, but I do remember seeing an interop doc on MOL the other day that has the ip range info in it.
-
Sorry I just noticed my earlier posts said MBA rather than MBG, as the iPad was doing auto correct.
-
Thanks for the details.. will play around with it and see since don't have access to MOL.
-
Tried a couple ways without success. If you have a chance to review the interop MOL and post the items, that would be greatly appreciated.
Would the MAS have to be rebooted to apply these changes or should they work after applying?
And didn't mention previously, but this is a physical MAS and not virtual.
-
Yep no worries, I will have a look in the morning when I get in to the office, it's Sunday night here now, so can't be bothered getting the laptop out, enjoying the cricket and a beer too much!
You can't have a virtual mas in gw mode anyway, so all good.
-
ok, can you do a trace route from the shell of the MBG server to 216.82.224.202 and see if it goes via the public interface of the MBG, or via the ASA?
As a side note, I noticed that the call that you had in your original post was running uncompressed. It might pay to have it compressed unless there is a large amount of bandwidth at each end of the connection.
-
Whenever I SSH into the MAS, I get the 'server console' -- how can I drop down to a regular bash to be able to traceroute/etc?
-
login as root rather than admin. Same password.
-
Yea, I should have known that :D
Yes, does look like a tracert is pushing it out the MBG WAN interface and not via the ASA.
-
ok cool, try adding that IP address with a subnet mask of 255.255.255.255 to the local LAN's list, either through the shell or via the web interface.
-
Added that route, 216.82.224.202 going out 10.1.2.1 (ASA gateway address) and it added the route to the eth0 interface (LAN .. which is configured as 10.1.2.10 for MAS and 10.1.2.2 for MCD .. eth1 is the WAN, going directly to the ISP, bypassing the ASA).
Doing a tracert still puts it out the WAN interface (looks like its using the default gw route to go out still) -- goes directly through ISP and not through ASA.
When I try to add the route to the eth1 interface, it fails due to 'Network is unreachable':
[root@mascgy ~]# route add -net 216.82.224.202 netmask 255.255.255.255 gw 10.1.2.1 dev eth1
SIOCADDRT: Network is unreachable
[root@mascgy ~]# route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
216.82.224.202 10.1.2.1 255.255.255.255 UGH 0 0 0 eth0
10.1.2.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
68.179.0.0 0.0.0.0 255.255.224.0 U 0 0 0 eth1
10.1.0.0 10.1.2.1 255.255.0.0 UG 0 0 0 eth0
0.0.0.0 68.179.x.xx 0.0.0.0 UG 0 0 0 eth1
[root@mascgy ~]# ip route
216.82.224.202 via 10.1.2.1 dev eth0
10.1.2.0/24 dev eth0 proto kernel scope link src 10.1.2.10
68.179.0.0/19 dev eth1 proto kernel scope link src 68.179.x.xx
10.1.0.0/16 via 10.1.2.1 dev eth0
default via 68.179.x.xx dev eth1
Would I need to be changing the default gw on the MAS to be pointing to the ASA (10.1.2.1) instead of the WAN gw?
-
You can do it this way via the route command, but the supported way is to add it via local networks. Try it through that and see if it makes a difference to it accepting it.
-
I added the route via the Local Networks on the web page, which added it to eth0 -- I was just trying to manually add it to eth1 using the route command
-
There isn't a routing table for each interface, there is one routing table for the system, so it didn't add it for eth0 as such, but for the whole system.
I assume that the 10.1.2.1 address is the interface on the ASA for that vlan, or is it another router?
Can you paste an output from the trace route?
-
When you look at the 'route -n' and 'ip route' commands issued, you can see the route says 'use iface eth0' -- so that is where I was getting the 'adding it to eth0' LAN interface
And yes, 10.1.2.1 is the interface of the voice VLAN on the ASA.
[root@mascgy ~]# tracert 216.82.224.202
traceroute to 216.82.224.202 (216.82.224.202), 30 hops max, 40 byte packets
1 static-68-179-x-xx.ptr.terago.net (68.179.x.xx) 1.663 ms 1.853 ms 2.118 ms
2 10.64.9.29 (10.64.9.29) 3.790 ms 3.797 ms 3.872 ms
3 static-67-226-180-150.ptr.terago.net (67.226.180.150) 16.661 ms 16.668 ms 16.662 ms
4 static-67-226-180-141.ptr.terago.net (67.226.180.141) 16.517 ms 16.522 ms 16.615 ms
5 static-67-226-180-102.ptr.terago.net (67.226.180.102) 16.282 ms 16.288 ms 16.407 ms
6 static-67-226-180-54.ptr.terago.net (67.226.180.54) 19.911 ms 19.732 ms 19.718 ms
7 te3-2.207.ccr01.sea02.atlas.cogentco.com (38.104.124.129) 224.434 ms 153.129 ms 153.072 ms
8 te2-8.ccr01.sea01.atlas.cogentco.com (154.54.85.177) 127.776 ms 127.776 ms 127.827 ms
9 te0-0-0-7.ccr21.slc01.atlas.cogentco.com (154.54.29.221) 42.027 ms 42.031 ms 42.022 ms
10 te9-1.ccr01.den01.atlas.cogentco.com (154.54.87.17) 251.644 ms te2-1.ccr02.den01.atlas.cogentco.com (154.54.87.21) 96.912 ms te3-3.ccr02.den01.atlas.cogentco.com (154.54.3.13) 96.975 ms
11 te0-3-0-7.ccr21.mci01.atlas.cogentco.com (154.54.87.86) 63.934 ms te0-3-0-7.ccr22.mci01.atlas.cogentco.com (154.54.87.94) 63.675 ms 63.607 ms
12 te0-7-0-33.ccr22.ord01.atlas.cogentco.com (154.54.30.102) 76.496 ms te0-4-0-3.ccr21.ord01.atlas.cogentco.com (154.54.6.157) 75.842 ms te0-7-0-33.ccr22.ord01.atlas.cogentco.com (154.54.30.102) 75.497 ms
13 te0-0-0-15.ccr22.jfk02.atlas.cogentco.com (154.54.43.109) 95.192 ms te0-1-0-4.ccr22.jfk02.atlas.cogentco.com (154.54.43.101) 95.082 ms te0-7-0-15.ccr21.jfk02.atlas.cogentco.com (154.54.43.97) 95.093 ms
14 te0-6-0-0.ccr21.jfk04.atlas.cogentco.com (154.54.47.22) 95.258 ms te0-6-0-2.ccr21.jfk04.atlas.cogentco.com (154.54.47.26) 94.896 ms te0-1-0-0.ccr21.jfk04.atlas.cogentco.com (154.54.47.18) 94.980 ms
15 38.104.72.254 (38.104.72.254) 95.059 ms 94.848 ms 95.209 ms
16 67.231.9.222 (67.231.9.222) 94.655 ms 94.653 ms 94.616 ms
17 67.231.9.212 (67.231.9.212) 95.367 ms 95.219 ms 95.205 ms
18 67.231.9.202 (67.231.9.202) 95.867 ms 95.514 ms 95.482 ms
19 sp-udp01.iad.bandwidth.com (216.82.224.202) 95.087 ms 95.191 ms 95.279 ms
[root@mascgy ~]#
-
Would you mind posting the config guide for Bandwidth? From the SIP compatibility sheet, looks like 08-4940-00030 is the config guide and it does say teleworker compatible.
I've seen a few other guides out there for other providers but just want to review our setup (especially anything dealing with the MBG).
-
Not sure how but for a brief moment earlier, when doing a tracert to the Bandwidth SIP Proxy, it looked to be going out the right path -- tested a TW call and had two way audio (TW from one of the corporate offices, which have a VPN tunnel between them, but still hooks up via the MBG public IP).
Went back to the shell a moment or two later, did a tracert, this time back out eth1 (WAN) interface. No more two way audio.
I also called Bandwidth and had them also add the public address for the MBG (instead of just the PABX), in case that would help.
-
Hmm interesting. Might pay to do another tcpdump from the MBG box to see if anything has changed now with the responses from Bandwidth.
Will find the interop doc for you shortly.
-
Thanks -- will need to do some tcpdumps on the MBG itself -- most of my captures have been from my switch and port mirroring the inside/outside interface of the ASA
Any good suggestions on tcpdumps to filter out what we are looking for? And I'm guessing I should be dumping eth1 (WAN) and not eth0 (LAN) since I'm already seeing the eth0/LAN traffic from my port mirroring capture...
And just to clarify, when I tested the call from an internal TW phone (as mentioned earlier, has VPN between the sites but connected to MBG WAN address) and go two way audio, it was because I called a number that was in one of my other divisions.. I still only get one way audio for other external calls (and also from my external TW phone at home to the same number tested above, the other division).
I am planning on rebooting the MAS/MBG later today -- sometimes when adding static routes in linux you have to restart the networking.. not sure if that is part of the web GUI when adding new routes (and referring to the Bandwidth 255.255.255.255 route pointing to the ASA).
-
Ah ok yep that makes sense that internal calls work fine, but calls to bandwidth are the issue.
Reboot can't hurt, but shouldn't be needed! :) Let us know how you go!
-
Sorry should have been more clear -- too much going on =\
The internal call was from my office TW device to an external AT&T number, via the Bandwidth Trunk. The AT&T number is being forwarded to a DID where the PABX is installed (same one with SIP trunk configuration). That DID then rings the headset for the remote worker (also part of the VPN corporate network).
Going through the interop guide now -- thanks a bunch!
-
Hmm ok, an interesting loop! :)
I'd suggest keeping it simple whilst trying to troubleshoot and just call your mobile as a test, as creating a loop could have added issues and lead you off on a different path rather than focusing on a normal call scenario.
-
Agreed -- I jumped the gun and didn't realize I was even calling that number.. and then all of a sudden got two way audio.. at first was like BINGO, but then realized why it worked :D