Agents login to ipcommunicators at side B location and ipcommunicators register to side B subcriber 2. Side B is connected to Side A over WAN i.e, callmanager cluster is distributed over WAN between side A and side B.
Customer calls a tollfree number and lands in side B voice gateway. Welcome prompt is played from CVP B server and when customer opts for agent transfer
call gets transferred to agents at side B thru callmanager subscriber 2. We dont have any issues at side B.
The issue is, when the subscriber 1 or callmanager publisher at side A is switched on, we get a one way audio i.e, caller can hear agent talking but agent does not hear the caller, caller's voice is echoed back to him.
All switch ports and all servers are full duplex and we are able to ping all servers at both locations. When we switch off side A callmanager publisher and subscriber 1 the call flow is fine. Effectively side B seems to run fine but when side A (callmanager publisher and subscriber 1) is switched on we have this one way audio problem.
Both call servers have static route pointing to side B callmanager subscriber 2.
I don't know what the problem is yet, so let me ask a couple more questions.
1. Call comes in on VGB.
2. First preference dial peer activates and sends the call to CVPB
3. A static route on CVPB sends the VRU label back to VGB.
This implies that CVPB has only one static route for the transfer label - and it points to VGB. Is this correct?
Do you likewise have CVPA configured with a single static route to VGA? The problem with this is that should the first preference dial peer fail because CVPB is down, the second preference dial peer will send the call to CVPA. If it just has a static route to VGA, the vru leg will run on VGA and now you have an RTP stream between the ingress gateway VGB and the VXML gateway VGA. Undesirable.
Again, if you have two static routes in CVPB for the transfer label one pointing to VGB and one pointing to VGB, every other call will be sent to VGA to run the vru leg.
Send To Originator resolves this problem and the VRU leg will always run on the ingress gateway. You probably want this.
Sometime later, an agent becomes available and the agent extension label is returned to CVPB. It looks at the static routes and there is one, and it only goes to SUBB. What if SUBB is down? Don't you want to have a pair of static routes going to SUBB and SUBA?
On the PG configuration, do you have the JTAPI gwy on PGA pointing to SUBA and the CTI Manager process is running there? Similarly, does the JTAPI gwy on PGB point to SUBB and the CTI Manager process is also running on that Subscriber?
1.Correct, CVPB has one static route pointing to VG. VG is available only in sideB location, theres no VG in sideA location.
2.CVPA has a static route pointing to VG at sideB.
3.One static route pointing to SUBB from both callservers CVPA and CVPB. Actually I wanted to add another route pointing to SUBA, but as explained whenever i start SUBA we have one way audio issue hence I thougt I would remove this route as of now pointing to SUBA.
4.Yes, sideA PIM pointing to SUBA and sideB PIM pointing to SUBB. Failover is also fine. CTI Manager processes are running in all three nodes (PUBA,SUBA,SUBB)
I see. You actually had that in your first post - the fact that you only have one gateway, and it's located at side B. This is your lab system, right?
You don't need CTI Manager on the Pub. A small point.
It seems like you have the bases covered. I don't know what your problem is, but I have certainly had my share of one way audio problems. You need to look at some logs or something. If it's too hard, you should ask TAC for help.
SIP traces provide key information in troubleshooting SIP Trunks, SIP
endpoints and other SIP related issues. Even though these traces are in
clear text, these texts can be gibberish unless you understand fully
what they mean. This document attempts to br...
Please find the attached HTML document, download and open it on your PC.
This provides an easy to use form where you simply answer a few
questions and it will render the proper jabber-config.xml file for you
to copy/paste. There is built in logic to verif...
CUCM Database Replication is an area in which Cisco customers and
partners have asked for more in-depth training in being able to properly
assess a replication problem and potentially resolve an issue without
involving TAC. This document discusses the bas...