CCME Transfer and conferencing problem.

[Ayodeji Okanlawon]

Guys,

I have an interesting problem on CCME 7.1.

There are 2 sites. One is CCME 7.1(remote) and the other CM7.1.3.(HQ)

Users dial between site over the PSTN. A 4 digit extension is dialled whihc is then xlated using the full DDI of the number.

The problem is this, each time a user attempts to trasfer a call to the head office (CCM) using the 4 digit extension (which is xlated to the full DDI), the xfer fails.

When an adhoc conference is also attempted, it fails "cannot complete conference".

When both scenarios are attempted using the full DDI, which does not go through the xlation pattern it works succesfully. Which meant tha my proble is with the xlation pattern

here is my dial-peer for the 4 digit number

dial-peer voice 9998 voip
incoming called-number .

dial-peer voice 100 voip
translation-profile outgoing Marlow
destination-pattern 3[147]..
session target ipv4:172.16.7.20

Do I need to enable some form of supplemenatry service on this dial-peer. ??

[Steven Holl · Accepted solution]

When both scenarios are attempted using the full DDI, which does not go 
through the xlation pattern it works succesfully. Which meant tha my 
proble is with the xlation pattern

That scenario may be working if the full DID number routes the call out a local PSTN circuit.  That changes the call topology enough for it to potentially work.  I'd take that test with a grain of salt.  Dial-peer/xlation issues wouldn't cause 'Cannot complete conference' on the phone.

First, since you are going to CM, make sure you have h450.2 (call transfer) and h450.3 (diversion) disabled on CME, since IOS enabled it by defaulyt but CM doesn't support it.  Also, enable ECS since that's how CM renegotiates media streams on hold/resume/transfer scenarios.  Do these and retest before continuing:

voice service voip

no supp h450.2

no supp h450.3

h323

  emptycapability

Assuming it is the CME phone hitting transfer/conference: how are you configured for conferencing on CME?  HW or SW?  Can you post:

sh run | s sccp|tele|ccm|dsp|voice

sh sccp

sh voice dsp group all

Note that conferences across the WAN will fail if you are using SW conferencing because that only supports g711.  If you want to use g729, you'll need to configure hardware ad-hoc conferencing and put g729 under the dspfarm profile.  Consult the CME Administration Guide for a sample config on that.  You may want to try configuring peers 9998 and 100 for 'codec g711ulaw' just to see if your tests work when using g711ulaw, though.

Also, it isn't causing this issue, but (for best practices and proper configuration) you're missing a DTMF relay configuration and you likely want to disable VAD, too; add:

dial-peer voice 9998 voip
  no vad

dtmf-relay h245-alpha

dial-peer voice 100 voip
no vad

dtmf-relay h245-alpha

If you still have issues, post that output I requested, and collect the following for a failure:

debug voip ccapi inout

debug sccp all

debug cch323 all

debug h225 asn1

debug h245 asn1

Collect via:

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

[CHRIS KAM]

Steven,

Thanks for posting this!!!  I was having an issue with Conferencing on CME 7.1 and could not figure it out.  I added the no supp 450.2 and no supp 450.3 commands and now everything works for me.

Thanks!!

[Ayodeji Okanlawon]

Steve,

Thanks for your reply. Today I got a chance to work on this. I added the configs you suggested, but we keep getting cannnot complete conference. I was not able to take the debugs you ask for. I will do tomorrow and post them.

I will send the full CCMe config tomorrow and yes its software conferencing. I am not doing this over the WAN.

The scenario is this..CCME>>PSTN>CCM

So the call to CCM goes over the PSTN.

[Ayodeji Okanlawon]

Steve,

It finally worked. When I looked at the logs, I saw that it was trying to use G.729 for the conferencing. Since I am using software conferencing, I changed it to G.711. what I do not get is this..I do not see any cause in the logs showing that it was codec issue. It just says cause=16. Just for learning purposes, can you help me look through the logs and let me know where I could have spotted the codec was causing the issue.

I did configure voice-class codec with g.711 and g.729. I thought this will enable codec negotiation if G.729 is not supported, obviuosly this was not the case.

Th call details:

Calling number :(4119) full ANI:01612723119

called number: 07967464902

Conference to number:  (3733) xlated to 01628403733

[Steven Holl]

The first disconnect for the call is here:

362794: Nov 17 09:16:47.287: //119552/19809424AE74/CCAPI/cc_api_call_disconnected:
--More--                              Cause Value=16, Interface=0x49DB09AC, Call Id=119552

Leg 119552 is the CME leg.  You see cause value 16 on that leg because the conference not completing isn't the cause of the disconnect--it is just displaying an error on the phone at that point.  The user is hanging up after they see that message, which is the true disconnect of the call.

You would need to look at ephone detail and SCCP debugs to see the logic for the codec causing the conference bridge to not allocate if you wanted to see debugs pointing to it being the codec issue.