Mitel Teleworker One Way Audio

[jf1221]

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

[dilkie]

is this a minet phone or a sip phone?

[jf1221]

 it's a Minet phone...well mitel 5340, so it should be minet, correct? How can i verify?

[dilkie]

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.

[jf1221]

change the ext to .log

[jf1221]

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

[dilkie]

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.

[dilkie]

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).

[ralph]

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

[dilkie]

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.

[ralph]

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

[dilkie]

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.

[jf1221]

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.

[dilkie]

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.

[LoopyLou]

So the real issue you are seeking an answer to is that your teleworker phones get one way audio when using a SIP trunk?