IPIPGW TCL One Way Voice

Unanswered Question
Jan 11th, 2008


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....

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Paolo Bevilacqua Sun, 01/13/2008 - 06:43


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


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.

ajaytschand Thu, 02/21/2008 - 12:04

The issue was resolved by upgrading to the latest firmware. Thank you for your help.


This Discussion