Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - dilkie

Pages: 1 ... 18 19 [20] 21 22
286
Mitel Software Applications / Re: MBG SIP Test bad address in to header
« on: March 29, 2014, 08:19:26 AM »
Your friend is right. You appear to be running MBG in "server-gateway" mode without a public address on the WAN side.. which isn't going to work, that's the ip address MBG is telling everyone on the internet how to "reach me".

Use a supported network configuration, S-G, with a proper internet connection. Or DMZ mode in a proper 3-port DMZ.

287
Mitel Software Applications / Re: MBG SIP Test bad address in to header
« on: March 28, 2014, 08:24:57 AM »
Do you have anything modifying SIP messages in the path? Other than MBG, that is.

"Client edge router" sounds suspicious...

288
Mitel Software Applications / Re: Cluster MBG and one way audio
« on: March 27, 2014, 01:55:04 PM »
internal calls.

okay, I assume set to set... are both sets on the same site or are these calls from the site to another set connected directly to the mcd?

289
Mitel Software Applications / Re: Cluster MBG and one way audio
« on: March 27, 2014, 12:18:49 PM »
document the date/time and DN of a incident, grab the tug.log file for that period and send it in to PS. They'll have an answer for you.

I doubt it's a weighing thing, unless one of the MBG's has internet reachability issues.

This confuses me "It's only a problem with calls to the desk of phones local to the MBG"... I'm not sure what you mean.

290
Mitel Software Applications / Re: TW to MPBG Part Number?
« on: March 19, 2014, 08:35:03 AM »
You're probably right, I can never keep track of them... I vote for "Mitel 6010"... that was the best name.

291
Mitel Software Applications / Re: TW to MPBG Part Number?
« on: March 17, 2014, 12:43:59 PM »
Well.. it's isn't a "multi protocol border gateway" , it's just a "Mitel Border Gateway" MBG... which is now a "MiCollab Border Gateway" MBG...

292
Mitel Software Applications / Re: TW to MPBG Part Number?
« on: March 17, 2014, 10:14:53 AM »
I don't think there was an upgrade part number... you should be able to upgrade without one. Just install upgrade msl to be able see the newer blades.

293
Mitel Software Applications / Re: MBG and SIP
« on: February 21, 2014, 07:12:30 AM »
does a packet trace show the options working between mcd and mbg? That's where it sounds like your problem is, mbg thinks mcd is down.

294
Mitel Software Applications / Re: Split DNS
« on: December 23, 2013, 07:27:47 PM »
are you sure it's a good idea to expose your customer to the security risks associated with what you are attempting? The design Mitel has is for a reason, it isn't just cobbled together.

295
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 13, 2013, 06:49:29 AM »
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.

296
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 07, 2013, 09:59:07 AM »
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.

297
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 07, 2013, 09:02:12 AM »
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.

298
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 07, 2013, 06:53:06 AM »
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).

299
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 07, 2013, 05:57:13 AM »
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.



300
Mitel Software Applications / Re: Mitel Teleworker One Way Audio
« on: November 06, 2013, 05:10:27 PM »
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.

Pages: 1 ... 18 19 [20] 21 22