01-11-2008 05:32 PM - edited 03-15-2019 08:11 AM
Hi,
We are using using a TCL IVR over IP (IPIPGW) for a Calling card Application. It is running on a Cisco 3745 with c3745-ipvoice_ivs-mz.124-11.T4.bin
Everything works perfectly for the first call based on the following call flow:
Calls are SIP-SIP (Inbound SIP and outbound Dialpeer is SIP)
1. caller dials access Number (Inbound Dial-peer voip based) which launches the Service Prepaid (Calling Card TCL).
2. Cisco prompts used for account number.
3. User enters Account Number
4. Cisco verifies Account number and requests Destination number
5. User Enters Destination Number
6. Cisco routes call to the proper outbound Dial-peer and call starts ringing at the destionation number(meanwhile, the caller hears a ringback tone)
7. User on far end answers the call.
8. Both parties talk properly.
The TCL Script is designed so that if the called party hangs up or the initial caller presses the '##' key sequence, the outgoing call is disconnected, and the caller can then dial another destination number.
When the caller presses the "##" sequence, the TCL comes back and requests the next destination number(This also works fine).
However, on this second call once the caller calls the second destination number there is only one way voice.
More details: The Cisco appears to route the call to the proper outbound dial-peer, and the call actually rings at the far end (NO Ringback is heard on the by the caller making the call).
And once connected, only the called party can hear the what the other person is saying. The caller cannot hear anything.
I have confirmed that the issue is not due to any codec mismatch since it happens on both G729 & G711 codecs. We have also tried routing the calls to different outbound dial-peers to confirm that the problem is not on the far end.
By the Way in the TCL Script:
When we are setting up the first call and to bridge the 2 legs we use:
leg setup $destination callInfo leg_incoming
once the user dials "##" to tear down the bridge, we use the following commands:
connection destroy con_all
and then issue
leg disconnect leg_outgoing
Then again we use the
leg setup $destination callInfo leg_incoming
to dial the second destination number and that is when the problem starts to occur.
Below is the show run for the gateway:
Any ideas about what could cause this problem, or something that I need to add to the configuration or TCL script to resolve the issue would be greatly appreciated.
Thank You....
01-13-2008 06:43 AM
Hi,
I do not have a ready solution for your problem, as with TCl/IVR can be difficult to identify the problem sometime. Even more without seeing you script.
Perhaps, there is some step that you should take to ensure the second (and following) setups are good like the first one.
One thing I can suggest, if you look at
http://pbevila.fastmail.fm/public/bcast.tcl
try adding the routine act_generic and the related fsm statement. This will catch any event and you will be able to verify correct flow. There are certain operations that must be done in withing certain events to be successful.
02-21-2008 12:04 PM
The issue was resolved by upgrading to the latest firmware. Thank you for your help.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide