08-19-2010 07:40 AM - edited 03-16-2019 12:21 AM
Hello,
Is there any way to make a BACD call or Auto attendant to call with G729?
I've tested a B-ACD over a H323 call with CUCME and CUCM.
The B-ACD is on the CUCME.
h323 to H323 is allowed
transcoder is enabled
The B-ACD works fine internaly.
But when it works with the CUCM, the call is droped on the CUCM.
Case :
The operator is into the CUCM 4.2
The B-ACD is on the CUCME 7.1
1. When pres 0 to the operator, then the call is transfered to the operator on the CUCM.
2. When the operator transfer the call to the right enduser, i hear nothing, and after the call is droped.
Call and region between these equipements are in G729.
What can be the reason.
regards,
Antra
Solved! Go to Solution.
08-23-2010 08:01 AM
It sounds like you are running B-ACD with CUCM. B-ACD is intended for integration to a CME ephone hunt-group on the local router. B-ACD across an H323 trunk to CUCM agents is not going to be a supported solution since you can't pass agent states to queue calls across an H323 trunk to CUCM.
In theory, I suppose just sending to the operator would be fine if that's a remote extension on CUCM. Maybe. Not sure what would happen if the operator is on the phone and another call comes in, since again, call states aren't going to be passed across the trunk.
Regarding 1-way audio, though. Bring the call up and look at the negotiated media address. See if RTP packets are being received, and work backwards in the media path until you find root cause of the 1-way audio issue.
Make sure your transcoder has the correct CM version configured in the 'sccp ccm' statement. Make sure the interface SCCP is running on is routeable to both the BACD box and the operator's IP phone network. To invoke the transcoder, you need to make sure that the transocder is registered to the device where the codec mismatch occurs (which could be CUCM or CME depending on how things are configured). I don't understand your topology enough at the moment to tell if the codec mismatch is occurring on the CME or the CUCM point. If your peers on CME which point to CUCM has codec g711ulaw, then the mismatch occurs at CUCM and the xcoder should be registered there. If your peers have g729 pointing to CUCM, and only your loopback peer to CUCM is 711, the mismatch occurs at CME and the transcoder needs to be registered to CME.
-Steve
08-19-2010 07:56 AM
I have this message in my CUCME (BACD)
Aug 19 14:54:31.568: %IP-3-DESTHOST: src=10.71.4.2, dst=0.0.0.0, NULL desthost -Process= "VOIP_RTCP", ipl= 0, pid= 308, -Traceback= 0x418B162C 0x41FD331C 0x41FD4334 0x41FD491C
Aug 19 14:54:34.364: %IP-3-DESTHOST: src=10.71.4.2, dst=0.0.0.0, NULL desthost -Process= "VOIP_RTCP", ipl= 0, pid= 308, -Traceback= 0x418B162C 0x41FD331C 0x41FD4334 0x41FD491C
08-19-2010 08:45 AM
Try upgrading IOS.
08-19-2010 10:47 PM
Thank you,
It is the best way, because the I'm using the c2800nm-advipservicesk9-mz.124-22.YB.bin.
Also if the operator is on the CUCME, There is no problem from the B-ACD or the AutoAttendant in the CUE.
But if the call goes directly to the CUCM, then the problem appears.
So the only solutions are :
1- Or upgrade IOS
2- Or Register all operators in the CUCME and after they make transfert to the CUCM.
08-23-2010 06:05 AM
Hi,
I've changed the IOS to 12.4.24 T2, it works at 50%.
Because the XCODE in the CUCM4.2 doesn't works very well.
From My CUCME-B-ACD the call works fine, and I can transfert the call to the CUCM4.2
My voice is heard in CUCM side but I cannot hear the CUCM4.2 user voice.
So I want to know how to change the prompts to G729. Is it still user the .au extension?
Best regards,
Antra
08-19-2010 10:48 AM
Is the transcoder getting invoked for the call (ensure you aren't using voice-class codecs on your inbound and outbound peers)? Does 'sh sccp con' show the call legs? Because if you don't invoke a transcoder, you need the prompts to be recorded in a g.729 format.
08-23-2010 06:21 AM
Your email is a little unclear. You say "My voice is heard in CUCM side but I cannot hear the CUCM4.2 user voice." Is this when the agent is connected? If that's the case, you have a traditional 1-way audio issue that needs to be troubleshot, and the prompts are not the issue.
If you aren't able to hear the prompt, then it could be a codec formatting issue. This link will guide you if you need to convert prompts to g729:
Note that if you configure BACD for g729 prompts, you will have to set ALL calls to BACD up as g729. You can't mix and match g711 and g729.
-Steve
08-23-2010 07:40 AM
Yes
I experience a one way voice.
I explain :
The voice Gateway is in G711u with the The B-ACD (tcl-script)-router : communication is in G711
The-B-ACD Router is in G729 with the CUCM4.2 : communication is in G729 (region,...)
The same voice Gateway is in G729 with the CUCM4.2 : communication is in G729 (region...)
There are XCoder and MTP in the voice Gateway and the B-ACD Router. I can hear MoH.
IP Connectivities are OK and there is no firewall
When the call arrives in the voice gateway, it is forwarded to the AutoAttendant
When the caller press 0, the call is forwarded to the CUCM4.2. The B-ACD MoH is played until the operator doesn't take the call.
==> caller is heard, but the called number (operator) is not heard by the caller.
PS : The CUCM4.2 have XCoder and MTP, but it seems be not working when I monitor with the RTMT.
XCoder and MTP are registerd in the CUCM4.2 but I cannot hear MoH.
Any helps other than upgrading the CUCM to 8.
regards,
Antra
08-23-2010 08:01 AM
It sounds like you are running B-ACD with CUCM. B-ACD is intended for integration to a CME ephone hunt-group on the local router. B-ACD across an H323 trunk to CUCM agents is not going to be a supported solution since you can't pass agent states to queue calls across an H323 trunk to CUCM.
In theory, I suppose just sending to the operator would be fine if that's a remote extension on CUCM. Maybe. Not sure what would happen if the operator is on the phone and another call comes in, since again, call states aren't going to be passed across the trunk.
Regarding 1-way audio, though. Bring the call up and look at the negotiated media address. See if RTP packets are being received, and work backwards in the media path until you find root cause of the 1-way audio issue.
Make sure your transcoder has the correct CM version configured in the 'sccp ccm' statement. Make sure the interface SCCP is running on is routeable to both the BACD box and the operator's IP phone network. To invoke the transcoder, you need to make sure that the transocder is registered to the device where the codec mismatch occurs (which could be CUCM or CME depending on how things are configured). I don't understand your topology enough at the moment to tell if the codec mismatch is occurring on the CME or the CUCM point. If your peers on CME which point to CUCM has codec g711ulaw, then the mismatch occurs at CUCM and the xcoder should be registered there. If your peers have g729 pointing to CUCM, and only your loopback peer to CUCM is 711, the mismatch occurs at CME and the transcoder needs to be registered to CME.
-Steve
08-23-2010 08:06 AM
If you get this output, it may shed some light, as well.
* Get these debugs:
debug voip ccapi inout
debug h225 asn1
debug h224 asn1
debug ip tcp trans
* Once call us up to operator, get multiple outputs of:
sh sccp conn
sh call active voice br
sh voip rtp conn
* Collect debugs with following method:
Router(config)# service sequence
Router(config)# service timestamps debug datetime msec
Router(config)# logging buffered 10000000 7
Router(config)# no logging con
Router(config)# no logging mon
Router(config)# voice iec syslog
Router# term len 0
Router# sh logg
* Note the original calling number, operator extension, and IP address of the operator phone which is answering the call.
08-23-2010 11:53 PM
Thank you,
You're right.
The sccp ccm in the CCM voicegateway is 3.1.
But when I've tried to change it, I don't see the CCM version 4.2.
3.0 Select CCM 3.0 version or above
3.1 Select CCM 3.1 version or above
3.2 Select CCM 3.2 version or above
3.3 Select CCM 3.3 version or above
4.0 Select CCM 4.0 version or above
4.1 Select CCM 4.1 version or above
5.0.1 Select CCM 5.0.1 version or above
6.0 Select CCM 6.0 version or above
7.0+ Select CCM 7.0 version or above
My CCM is v4.2. As I know CCM4.2 is like CCM 5 .
So which version is good for this sccp ccm 4.1 or 5.0.1
I'll try with 4.1
Regards,
Antra
08-24-2010 06:19 AM
4.1 will be fine.
Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: