B-ACD with G729

Answered Question
Aug 19th, 2010
User Badges:

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

Correct Answer by Steven Holl about 6 years 11 months ago

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

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (6 ratings)
Loading.
iantra123 Thu, 08/19/2010 - 07:56
User Badges:

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

paolo bevilacqua Thu, 08/19/2010 - 08:45
User Badges:
  • Super Gold, 25000 points or more
  • Hall of Fame,

    Founding Member

Try upgrading IOS.

iantra123 Thu, 08/19/2010 - 22:47
User Badges:

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.

iantra123 Mon, 08/23/2010 - 06:05
User Badges:

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

Steven Holl Thu, 08/19/2010 - 10:48
User Badges:
  • Cisco Employee,

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.

Steven Holl Mon, 08/23/2010 - 06:21
User Badges:
  • Cisco Employee,

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:

http://www.cisco.com/en/US/prod/collateral/voicesw/custcosw/ps5693/ps1846/solution_overview_c22-524728_ps3651_Product_Solution_Overview.html


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

iantra123 Mon, 08/23/2010 - 07:40
User Badges:

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

Correct Answer
Steven Holl Mon, 08/23/2010 - 08:01
User Badges:
  • Cisco Employee,

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

Steven Holl Mon, 08/23/2010 - 08:06
User Badges:
  • Cisco Employee,

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.

iantra123 Mon, 08/23/2010 - 23:53
User Badges:

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

Actions

This Discussion