Showing results for 
Search instead for 
Did you mean: 

TEHO does not work


We have 3 sites locate in London, Melbourne and New York respectively.


VG - 2911 running c2900-universalk9-mz.SPA.151-4.M5.bin

Call flow as bleow:

9971 ----sip-----CUCM -----trunk---- GW ---- PSTN----- ITSP

If Melbourne user call USA it will use TEHO to New York VG for outgoing calls, vice versa.

So does for London and USA.

Recently we suspected that TEHO is not working as expected (I assume it never work properly). User get fast busytone after inter digit timeout straight away. I have done the DNA and it shows call flow is correct and should work.

I have attached the DNA output,  isdn q931 debug and CCM trace for failed call.

calling number - 61386725433 (will be translated to other number on VG)

called number - 17193252949

The isdn debug does not tell too much info.

CCM trace looks like it's CUCM send disconnection message to VG to terminate the call.

Any ideas?

Rising star

Hello Fei,

The CUCM disconnects the calls with "reason q.850 cause=47" meaning there is not enough media resource to complete the call. It seems Codec issue. Kindly check the region settings between 'REG-USANYC'  and 'REG-AUVICMEL'

79794959.011 |15:53:50.239 |AppInfo  |DET-MediaManager-(81230)::preCheckCapabilities, region1=REG-USANYC, region2=REG-AUVICMEL, Pty1 capCount=5 (Cap,ptime)= (4,30) (258,0) (257,30) (259,30) (261,30), Pty2 capCount=6 (Cap,ptime)= (4,20) (2,20) (11,20) (12,20) (6,20) (86,20)

79794959.015 |15:53:50.239 |AppInfo  |RegionsServer: applyCodecFilterIfNeeded - no codecs remained after filtering so restored original 0 caps

79794959.016 |15:53:50.239 |AppInfo  |DET-MediaManager-(81230)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(8), filtered A[capCount=0 (Cap,ptime)=], B[capCount=2 (Cap,ptime)= (11,20) (12,20)] allowMTP=0 numXcoderRequired=1 xcodingSide=1

79794967.003 |15:53:50.240 |AppInfo  |MediaTerminationPointControl(107)::waiting_AllocateMtpResourceReq - (not an error) DeviceCap Mismatch

79794967.026 |15:53:50.241 |AppInfo  |MediaTerminationPointControl(107)::SendMTPResourceErrToSender - ERROR  AllocateMtpResourceReq failed -- Ci=49707060, errBitset=0x3

79794968.001 |15:53:50.241 |AppInfo  |MediaResourceCdpc(50984)::resource_rsvp_AllocateMtpResourceErr Device=TRN-USANYC-01 deviceCapIntersec=256

79794968.003 |15:53:50.241 |AppInfo  |MediaResourceCdpc(50984)::adjustDeviceTblXcoder - No enough available resource

79794994.001 |15:53:50.243 |AppInfo  |StationD(21332): StationCtiD-CcDisconnReq onBehalf=Media Cause=47

Please check if the transcoders are registered properly and available in MRGL.

//Suresh Please rate all the useful posts.

Your RTP flow looks like this. Note an MTP device was invoiked because you are using EO.

ip phone------->MTP------->gateway

The inbound dial-peer on the gateway is set to use g711ulaw

From the logs,,,this is the 183 session progress we get back from the gateway to cucm.on the outbound leg of the call

79796878.002 |15:54:28.626 |AppInfo  |SIPTcp - wait_SdlReadRsp: Incoming SIP TCP message from on port 5060 index 13504 with 1058 bytes:


SIP/2.0 183 Session Progress

Via: SIP/2.0/TCP;branch=z9hG4bK22936757af1347

From: "Jaryd Anning" <61386725433>;tag=16794848~2580bb60-ed88-451a-be78-42a8a117e39f-49707070

To: <>;tag=CFC1EA3C-99C

Date: Thu, 24 Oct 2013 04:49:57 GMT

Call-ID: 5ad70900-2681a803-107008-c0c12ac@

CSeq: 101 INVITE


Allow-Events: telephone-event

Remote-Party-ID: <17193252949>;party=called;screen=no;privacy=off

Contact: <>

Supported: sdp-anat

Server: Cisco-SIPGateway/IOS-12.x

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 250


o=CiscoSystemsSIP-GW-UserAgent 1271 8975 IN IP4

s=SIP Call

c=IN IP4

t=0 0

m=audio 26442 RTP/AVP 0 101

c=IN IP4

a=rtpmap:0 PCMU/8000------------------------------Here you can see the codec on the dial-peer is g711

a=rtpmap:101 telephone-event/8000

a=fmtp:101 0-16


The region between the MTP device that has been selected for the call and the gateway is set to use shown from this log..

79796915.011 |15:54:28.628 |AppInfo  |DET-MediaManager-(81231)::preCheckCapabilities, region1=REG-USANYC, region2=REG-AUVICMEL

Hence cucm determines that a xcoder is required..

79796915.016 |15:54:28.628 |AppInfo  |DET-MediaManager-(81231)::preCheckCapabilities, caps mismatch! Xcoder Reqd. kbps(8)

CUCM tries to allocate a xcoder but coundlt find any tsuitable one.

I suggest you change the inbound dial-peer on your gateway to advertise both g729 and g711 codecs using voice class codec

voice class-codec 1

codec preference 1 g729

codec preference 2 g711alaw

codec preference 3 g711ulaw

You should then remove the codec on the dialpeer and apply the voice class codec. This will remove the need for a xcoder

dial-peer voice xx voip

no codec g711ulaw

voice class-codec 1

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Hi aokanlawon

The voice class codec original configured as below and assigned to all voip dial peer in sh run.txt file attached.

voice class codec 1

codec preference 1 g729r8

codec preference 2 g711alaw

codec preference 3 g711ulaw




Hi sureshsub2

I have checked xcoder configuration, xcoder are registered with CUCM sub and it's included in MRGL assigned to trunk.

The region settings between REG-USANYC'  and 'REG-AUVICMEL are using g729.





Can we do a quick test. Since you are doing EO on your CUBE there is no need for you to do EO on CUCM. Can you disable EO on your CUCM so we can remove the need for the MTP as this is introducing unneccesary complexity. This way we will have RTP stream flowing directly between the IP phone and the NYC gateway.

Another solution is to configure the region between your MTP (REG-USANYC) and REG-AUVICMEL as G711. This is because your MTP is configured for g711ulaw, but the region between it and the gateway is set to g729..

Let me know which option you had like to try...Once you have made the changes please collect the ff logs from the NYC gateway

1. debug ccsip messages

2. debug voip ccapi inout

3. cucm SDL logs

Can you also include the cucm logs for the test call. Just the

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

What is EO?


EO stands for early offer. This is a term used in SIP signalling where the SDP (media capabilities) are exchanged with the INVITE. In delayed offer this is exchanged during the 200 OK answer phase

Please rate all useful posts

"opportunity is a haughty goddess who waste no time with those who are unprepared"

Please rate all useful posts

Hi aokanlawon

Issue seems resolve by itself from last few days. We have not make any change at all.

Regarding your suggest, we have not able to take it as EO is configured for another purpose - EO over ISDN call.

But something really strange. I noticed that when IOS MTP is UP and register with CUCM, TEHO stop working. But as soon as IOS MTP become unregistered, TEHO start working.

I have attached ccm trace for both scenario. Since I cannot reproduce issue, i was unable to capture debug on VG for failed but able to provide succeed one.  20131108.rar

Final called number as 17193252949.

I have a question, since we do have all 711 and 729 codec has been configured in Xcoder, do we still need MTP invoke for call setup? When MTP invoke?


Hi Fei,

As Deji mentioned, is it possible for you to change the codec to G711 between the regions REG-USANYC and REG-AUVICMEL and check the behaviour?

//Suresh Please rate all the useful posts.
Content for Community-Ad