Mitel Forums - The Unofficial Source
Mitel Forums => Mitel Software Applications => Topic started by: jf1221 on November 05, 2013, 10:32:38 PM
-
Mitel Border Gateway and Cisco ASA.
I have a MBG in the DMZ of the ASA.
The MBG is nat'd from its external public ip address to the internal DMZ address.
I have opened ports according to mitel spec, the teleworker handsets authenticate and shows connected in the vMBG. The problem is i can only receive one way audio i.e. the teleworker cannot hear the internal or external LAN phone but the internal LAN phone can hear the teleworker audio just fine. I even put the telework phone on hold and the hold music could be heard just fine on cell phones and LAN lines.
I suspect it is the way my vMBG gateway is set up. I am not sure how the call flow should go if a teleworker calls 7 digits to make an external call. My firewall does not show any errors and I have correct NAT statements, ACLs, and SIP awareness disabled. I have ran the TNA, traces, looked at logs I cannot figure this out for the life of me. Please help.
Teleworker DMZ IP 192.168.30.150
Teleworker outside external IP 209.33.141.4 static NAT to 192.168.30.150
ICP 3300 10.21.67.153
static (DMZ,outside) 209.33.141.4 192.168.30.150 netmask 255.255.255.255
static (inside,DMZ) 10.21.0.0 10.21.0.0 netmask 255.255.0.0
-
is this a minet phone or a sip phone?
-
it's a Minet phone...well mitel 5340, so it should be minet, correct? How can i verify?
-
yes, that's minet... if it's a "mitel 5xxx something-or-other" then it's minet and that is good, they have less issues than sip.
Can you grab tug.log and post it somewhere?
We're going to look at the OPEN_RX OPEN_TX (and ACK) messages to see where MBG is telling folks to stream.
-
change the ext to .log
-
this is a log from my event log, as well...
MBG one-way audio 08:00:0F:65:CF:D8 Major Wed 06 Nov 2013 15:00:15 CST loss of rx stream from IS for 5020ms
-
the event log is just reporting that after 5 seconds of waiting, no rtp was received from the "icpside, IS", the "other" end of the call from the set's perspective.
looking in your tug log, you have a routing or f/w issue on the inside... here's the details.
okay,
you're setup in DMZ mode, public address is 209.33.141.4
2013-11-05 00:00:00.248591000 rtp_icpside_override_address=209.33.141.4
2013-11-05 00:00:00.248591000 rtp_setside_override_address=209.33.141.4
2013-11-05 00:00:00.248591000 rtp_setside_bind_address=192.168.30.150
2013-11-05 00:00:00.248591000 rtp_icpside_bind_address=192.168.30.150
this all looks good, we sub in our public address for the private ones, and add crypto
2013-11-05 08:51:57.222595000 28284 OPEN_TX_STREAM: 12.68.242.163:6929 - 10.21.67.153
2013-11-05 08:51:57.222595000 28284 sysToken:124747887 sysStrmID:0 strmCodec:RTP_CODEC_G711_U(1)
2013-11-05 08:51:57.222595000 28284 dst addr:10.250.0.13:20048 strmFrameSizeInMS:20
2013-11-05 08:51:57.222595000 28284 TxFlags:0x0000 SrtpCipher: 0 SrtpRekey:0
we create new socket pairs.
2013-11-05 08:51:57.223907000 28284 SS0: Rtp endpoint: id=725, socket=48, overrode bound address; from=192.168.30.150:30740, to=209.33.141.4:30740
2013-11-05 08:51:57.224019000 28284 SS0: Rtp endpoint, id=725, created socket, fd=48, address=209.33.141.4:30740
2013-11-05 08:51:57.224098000 28284 SS0: Rtp endpoint, id=725, created socket, fd=48, address=209.33.141.4:30740
2013-11-05 08:51:57.224501000 28284 IS0: Rtp endpoint: id=726, socket=49, overrode bound address; from=192.168.30.150:30742, to=209.33.141.4:30742
2013-11-05 08:51:57.224577000 28284 IS0: Rtp endpoint, id=726, created socket, fd=49, address=209.33.141.4:30742
2013-11-05 08:51:57.224650000 28284 IS0: Rtp endpoint, id=726, created socket, fd=49, address=209.33.141.4:30742
2013-11-05 08:51:57.225913000 28284 **OPEN_TX_STREAM:
2013-11-05 08:51:57.225913000 28284 sysToken:124747887 sysStrmID:0 strmCodec:RTP_CODEC_G711_U(1)
2013-11-05 08:51:57.225913000 28284 dst addr:209.33.141.4:30740 strmFrameSizeInMS:20
2013-11-05 08:51:57.225913000 28284 TxFlags:0x0005 SrtpCipher: 5 SrtpRekey:0
2013-11-05 08:51:57.232126000 28284 OPEN_RX_STREAM: 12.68.242.163:6929 - 10.21.67.153
2013-11-05 08:51:57.232126000 28284 sysToken:107962480 sysStrmID:1 strmCodec:RTP_CODEC_G711_U(1) isMulticast:0
2013-11-05 08:51:57.232126000 28284 src addr:0.0.0.0:0 multicast addr:0.0.0.0:0 strmFrameSizeInMS:20
2013-11-05 08:51:57.232126000 28284 RxFlags:0x10000 SrtpCipher: 0 SrtpRekey:0
2013-11-05 08:51:57.232428000 28284 **OPEN_RX_STREAM:
2013-11-05 08:51:57.232428000 28284 sysToken:107962480 sysStrmID:1 strmCodec:RTP_CODEC_G711_U(1) isMulticast:0
2013-11-05 08:51:57.232428000 28284 src addr:209.33.141.4:30740 multicast addr:0.0.0.0:0 strmFrameSizeInMS:20
2013-11-05 08:51:57.232428000 28284 RxFlags:0x8005 SrtpCipher: 5 SrtpRekey:0
2013-11-05 08:51:57.253409000 28284 OPEN_TX_STREAM_ACK: 12.68.242.163:6929 - 10.21.67.153 (response time: 27)
2013-11-05 08:51:57.253409000 28284 reqStatus:0 sysToken:124747887 txConnectionID:0
2013-11-05 08:51:57.253409000 28284 Tx addr:192.168.1.122:50032
2013-11-05 08:51:57.253409000 28284 TxFlags:0x0005 SrtpCipher: 5 SrtpRekey:0
2013-11-05 08:51:57.254467000 28284 **OPEN_TX_STREAM_ACK: (response time: 27)
2013-11-05 08:51:57.254467000 28284 reqStatus:0 sysToken:124747887 txConnectionID:0
2013-11-05 08:51:57.254467000 28284 Tx addr:209.33.141.4:30742
set sends a NAT keepalive packet to open pinhole, good
2013-11-05 08:51:57.266391000 28284 SS0: NAT keepalive (sock=48) from:12.68.242.163:50032
2013-11-05 08:51:57.276715000 28284 OPEN_RX_STREAM_ACK: 12.68.242.163:6929 - 10.21.67.153 (response time: 44)
2013-11-05 08:51:57.276715000 28284 reqStatus:0 sysToken:107962480 connectionID:0
2013-11-05 08:51:57.276715000 28284 Rx addr:192.168.1.122:50032
2013-11-05 08:51:57.276715000 28284 RxFlags:0x0005 SrtpCipher: 5 SrtpRekey:0
receive rtp from set
2013-11-05 08:51:57.310515000 28284 SS0: RX RTP (sock=48) from: 12.68.242.163:50032
2013-11-05 08:51:57.310515000 28284 Codec: RTP_CODEC_G711_U , PT: 0 , M: 0, SeqNum: 0, TS: 1732761920, SSRC: 1154623393, rtpLen: 160
send to where mcd told us to send.
2013-11-05 08:51:57.338564000 28284 IS0: TX RTP (sock=49) to: 10.250.0.13:20048
2013-11-05 08:51:57.338564000 28284 Codec: RTP_CODEC_G711_U , PT: 0 , M: 0, SeqNum: 0, TS: 1732761920, SSRC: 1154623393, rtpLen: 160
no rtp received from icpside (inside), should have received rtp from 10.250.0.13:20048
okay... so because we're in a DMZ, we 'told' the mcd to tell the other end of the call, 10.250.0.13, to send to 209.33.141.4:30740
things to check.
from 10.250.0.13, is there a route to the internet, can he reach 209.33.141.4?
On your f/w, port range 209.33.141.4:20000-31000 forwarded to mbg in dmz, at least from the internet side, because we are receiving rtp from the set.
Is this f/w also the default interent gateway for 10.250.0.13?
What rule do you have for internal (lan) to 209.33.141.4? It should just be a straight mapping to the mbg, 192.168.30.150.
-
it might help to run TNA from same network as the other end of the call, 10.250.0.x, check that the rtp starting and ending ports are reachable (have checks).
-
It used to be that you could not run a TW server in server/gateway mode in a DMZ if you were NATing the external IP address.
Because you'd only get one way audio.
Has this changed?
Ralph
-
this server isn't running in SG mode. It's configured in DMZ mode, and I assume it's sitting in a proper 3-port f/w's DMZ... otherwise you'll get one-way audio.
-
If it's in server mode then I'd have to agree it's either
1) A routing problem in the voice network
2) Firewall blocking ports
One way to possibly test this is to set your laptop to the IP of of TW server, remove the TW server, plug in your laptop and run the TNA software against the 3300. I'd also have the firewall set up to be able to ping the 3300 from the TW server.
Also make a note here regarding the firewall. The firewall will need to allow connections to the entire voice network - not just the 3300.
Ralph
-
Like I said earlier, simply run TNA on the internal network, pointed at MBG's public address. It should come up clean, the same as TNA run from the internet.
-
So 10.250.0.13 is the providers SIP proxy server (windstream) we have a an MPLS set up into their cloud. I know they can ping and signal the DMZ address 192.168.30.150...yes, the firewall would be the default gateway for all my internet traffic. I don't know how i would get them (winstream) to be able to route their traffic to the internet. I will check... in the meantime please look at my configs from the cisco asa firewall and the TNA results. all look good to me.
-
Ah... see. you completely failed to mention the call was over a sip trunk. For that, I smack you.
Call mitel support, your problem is too complex to resolve here.
-
So the real issue you are seeking an answer to is that your teleworker phones get one way audio when using a SIP trunk?
-
I know this topic is very old but I came across this problem today and wanted to share my experience.
We have MBG as Server/Gateway and MCD with SIP Trunks via MPLS to our provider.
I was experiencing one-way audio on external calls via Teleworkers.
I found I had to add the provider's IP Address into the local networks on the MAS/MBG to create a static route via the MPLS link.