Teleworker No Audio

[warlockcode]

Hi

I have this issue with my Teleworker phones having no audio at all when you call through the public trunk to an external device.
However, there is audio both ways if you call from a TW set to another TW set, or from an internal ext to a TW set. There is also audio both ways when you call from internal ext to the public trunk.

My setup consists of a MiCollab server, MiVoice Business and MiBoarder Gateway. Both my MiVOice and Micollab sits in the same LAN, while MBG sitting in the DMZ with basically all the ports in the Engineering guideline opened. I have both MBG in a cluster (MiCollab and vMBG).
I have standard UCCv3 user licenses which provides me with the TW licenses.

TNA says that all ports are fine, externally and internally.

No alarms on the controllers or Micollab, but I get "loss of rx stream from IS for 5008ms" on my vMBG server.

Not sure what is causing this, any help is appreciated.

Thanks.



The freedom to make your own mistakes is all you ever need to succeed.

 

[techymitel]

Have you added the MBG and MiVB's subnets to each other as trusted or local networks?

techymitel

 

[Billz66]

what sort of public trunks are they ?

if they are sip , you need to make sure that the MBG can access the SIP server directly .

only signalling is proxied via the MCD , the voice will stream direct from the MBG to the SIP server address

If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....

 

[LoopyLou]

Your internal phones are ok. You can call IP sets or other teleworkers which would suggest no issues hitting the subnets containing phones. Follow Billz66 advice for SIP but if PRI follow techyMitel i.e make sure the subnet with the MCD is defined as a local network. Sounds like you have done that for the subnet with internal phones.

You can't duct tape stupid.

 

[warlockcode]

Lets start from the top:

techymitel - yes all networks is trusted on both servers.

Billz66 - SIP is actually terminated directly to the MiVoice (MCD) and not via MBG as voice network sits within the Telco's MPLS network. Will this change your statement on proxy, or should I still get the MBG (DMZ) to see the SIP server?

LoopyLou - it's SIP, as above terminates directly on MCD and not MBG.

The freedom to make your own mistakes is all you ever need to succeed.

 

[Billz66]

no it wont you will need to make sure that the MBG can route to the sip server or the voice wont have a path to the sip server



If I never did anything I'd never done before , I'd never do anything.....

and due to an endless stream of MiCollab , MiCC issues
Life would be simpler If only they tested products properly before releasing them .....

 

[warlockcode]

Just ran a traceroute from MBG to SIP end - Trace came out successful.
I am running out of ideas now.

The freedom to make your own mistakes is all you ever need to succeed.

 

[warlockcode]

Running TNA again, port 6800 appears to be closed.
Could this be the reason?

The freedom to make your own mistakes is all you ever need to succeed.

 

[GZgidnick]

Can you provide some IP addressing so we can get understanding of your Network Topology?

To me this sounds as an RTP issue.
The stream is getting lost.

Your signaling works fine which is good.

Now, before being able to provide more specific answer, you will need to let us know of your addressing and setup.

 

[warlockcode]

Sorry for the late reply guys,

My setup is straight forward -

MiCollab - LAN Mode (10.123.16.12/24)
MBG - DMZ Mode (192.168.10.20/24)
MiVB - LAN (10.123.16.20/24)

Firewall - Cisco ASA (Client managed)
- 3 x Interfaces (LAN, DMZ, WAN)

MBG IP is in NAT with Public IP which is used by TW.
SIP is connected directly to MiVB (no need for MBG as this is all in Telco WAN - MPLS Network)









The freedom to make your own mistakes is all you ever need to succeed.

 

[jpruder]

Since the Sip is straight to the MCD, in the MBG do you have the ip address of the provider as a local network going out via the same path as the MCD?

 

[warlockcode]

@jpruder -

Are you suggesting adding the public IP (SIP GW Address) to the trusted network and then pointing it to go out the the DMZ gateway?

The freedom to make your own mistakes is all you ever need to succeed.

 

[jpruder]

Yes

 

[bribob]

"MBG IP is in NAT with Public IP which is used by TW."

Confirm this please: all outbound traffic from the MBG in DMZ to the SIP GW via MPLS WAN is being NAT'd on the way out? To the Public IP which TW sets are connecting to? Internet is delivered via MPLS as well?

If you were to capture the SIP packets on both the MCD and ASA showing the SDP exchange during call setup (specifically Connection Information), I would bte that the MCD is replying to the SIP GW with a 'c' value of 192.168.10.20. Does the MPLS provider know about 192.168.10.0/24?

My ASA experience is limited, try and put an outbound rule before the 0.0.0.0 (which NATs to public IP) which will NOT NAT from 192.168.10.20 to <SIP GW IP>. Your MPLS provider will have to know how to route to 192.168.10.0/24



Terminating SIP trunks to an MBG (Proxy) can make firewall rules less of a headache as you only have to allow the SIP gateway to talk to a single device within your network. SIP and RTP all stream to the MBG Proxy first before going to TW/MCD/sets/VM/anywhere... Any chance you could have the SIP trunk terminate to the MBG in DMZ first? There is a cost associated with this, MBG SIP Proxy licenses: 1/channel


-b

 

[warlockcode]

@jpruder - tried this mate, didn't seem to work.

@bribob - confirming that all outbound traffic from MBG in DMZ to the SIP GW via MPLS is being NAT'd on the way out. Internet is on different link (not on same link as SIP).

I have requested changes to made on the ASA as advised.

Will update when tested.

The freedom to make your own mistakes is all you ever need to succeed.

 

[warlockcode]

looking through some past post danMirez actually stumbled on the same issue
thread1329-1615787



The freedom to make your own mistakes is all you ever need to succeed.