Guys,
I have a problem that just isn't working out in my head so I thought why not put it on here to find out how stupid I really am.
Anyway, I have a virtual MCD at a customer site that talks directly to a SIP Providers SBC for SIP Trunks; everything works as expected.
On this particular site they have a MiVCR and a virtual MBG with TAP Licenses to record the calls of the ACD Group. These ACD phones are pointed to the Public IP Address of the Primary vMBG.
We added a secondary virtual MCD and virtual MBG for Failover capabilities on each of the respective networks. The Primary and Secondary MCDs are on the same network and the Primary and Secondary MBGs are on the same network in the DMZ.
Primary vMCD: 10.1.1.10/20
Secondary vMCD: 10.1.1.110/20
Primary vMBG: 192.200.100.10/24
Secondary vMBG: 192.200.100.110/24
Everything seems to be work just fine except for this one issue.
If the Primary vMBG goes down then all of the ACD and Teleworker phones fail over the Secondary vMBG; works great.
If we make an Inbound call via a DID to any of the non-Teleworker phones we have two-way audio; as expected.
If we make an Inbound call via a DID to any of the ACD or Telework phones then we have one-way audio, Inbound Only, until one of two things happens.
1. They put the call on hold and pick it back up.
2. They transfer the call to another phone; Teleworker or Normal.
If they perform either of the two above steps then the call will have two-way audio.
For the life of me I can't figure out why they are having a problem and where it would reside.
Since there is a time constraint on when we can perform the testing I wasn't able to figure out what to do in the time I had left.
I tried a packet capture at the Secondary vMBG thinking the audio would travel through there, but it doesn't show anything going to the IP Address of the Teleworker/ACD phone we were testing with. I did verify that the phone we were testing with was connected to it, but I guess the Audio doesn't pass through it for this scenario.
I didn't have time to start a TCPDUMP on the Primary vMCD as I though the problem would have been with the Secondary vMBG not sending the audio to the phone.
Has anyone run into this situation before and what can I look at?
We are going to try the test again on Monday morning, but I want to be as prepared as possible. I know that I am going to start a TCPDUMP on the Primary MCD, but can anyone think of anything else to do?
Thanks,
TE
