Cisco Support Community
cancel
Showing results for 
Search instead for 
Did you mean: 
Announcements

Welcome to Cisco Support Community. We would love to have your feedback.

For an introduction to the new site, click here. And see here for current known issues.

New Member

Second call Disconnect Cause=47 Strange Issue

Hi

I have a critical strange Issue in my VoIP network.

we have ISR 4351/K9 Router with ISO isr4300-universalk9.03.16.05.S.155-3.S5-ext.SPA.bin

we have CUCM 11.5 an we are using E1 line

the problem is 1st call is successfully establised but when we dial any other number from another ext. it gives buzy tone or disconnected.

 

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions

Re: Second call Disconnect Cause=47 Strange Issue

Hi There,

 

Failed calls happen when the HW-TRANS device is allocated instead of the HW-MTP device. When the calls try and connect when the HW-TRANS device is used, we get an error (in the failed call section below).

 

WORKING CALL - Resource Allocation:

27616400.004 |05:12:15.100 |AppInfo  |MediaResourceCdpc(5330)::sendMtpAllocateRequestToDevice MtpResource=HW-MTP Cepn=ec22edcc-adc9-e399-491b-cf2fe909fb5b

FAILED CALL - Resource Allocation:

27618027.004 |05:13:21.598 |AppInfo  |MediaResourceCdpc(5333)::sendMtpAllocateRequestToDevice MtpResource=HW-TRANS Cepn=03197a90-af35-9059-575b-b4f6ddb966a4
.... SOME OUTPUT OMMITED ...

27618198.001 |05:13:21.613 |AppInfo |StationInit: (0147068) OpenReceiveChannelAck Status=1 (Error: Endpoint failed to open receive channel), IpAddr=IpAddr.type:1 ipAddr:0x00000000000000000000000000000000(::), Port=0, PartyID=33570955

 

Since your HW-MTP and HW-TRANS are in the same MRG, CUCM is load balancing between them for calls made through your H.323 GW which has MTP required enabled. This is why some calls work, and some calls fail (I think this may be related to the fact that your HW-TRANS has passthrough enabled, but I am not 100% sure).

 

Can you first try removing HW-TRANS from the MRG which is assigned to the MRGL on the H.323 GW? You could also move the HW-TRANS resource to a new MRG which sits below the MRG which contains the HW-MTP inside of the MRGL.

This should correct your issue.

Please let us know if this helps!


*** Please mark answers as helpful and/or correct if appropriate.

11 REPLIES

Re: Second call Disconnect Cause=47 Strange Issue

Hi There,

 

I started taking a look through the debugs, but you have a lot of output and no descriptions of which call is which.

 

On first glance it looks like it could be a codec issue. I see some cause code 47 messages in there, which usually indicate you have an issue requiring a transcoder, and there is no transcoder available.

 

It would be a lot easier if you could do the following:
1. Attach a copy of the running configuration of the VGW (remove sensitive info first)
2. Whenever you attach debugs for a test call, list the following info for each call:
   a. Start Time
   b. Called Number
   c. Calling Number
   d. Result of the call (failed or good)
3. Grab the following debugs for a working a failed call:
   a. debug h225 asn1
   b. debug h245 asn1
   c. debug voip ccapi inout

 

Also, please configure "voice iec syslog" in your VGW running-config if you don't already have it. It can generate very useful output in troubleshooting scenarios.

 

New Member

Re: Second call Disconnect Cause=47 Strange Issue

Hi Jonathan

Thank you for your reply please find the attached output of the commands that you have requested

1st call. from 531 to 050648xxx fine

2nd call from 521 to 055421xxx gives busy tone but recieve missed call on mobile.

our telephone line is E1 DID/DOD.

Re: Second call Disconnect Cause=47 Strange Issue

Hi There,

 

Thanks for sending those debugs.

I compared the 2 calls, Call A (Working - 050648xxx), to Call B (Non-Working 055421xxx).

 

Here is the comparison between the 2 calls:

  1.  Both calls send a nearly idencical H.323 SETUP message from CUCM to the VGW. Nothing of concern here.

  2. Both calls progress through the H.323 call setup process in the same manner up until the Terminal Capability Set (TCS) exchange phase (where CUCM and the VGW exchange media capabilities (codecs)).

  3. In both call A and call B the TCS sent from the VGW to CUCM is identical, the VGW offers g711Ulaw64k as the codec. This makes sense since your inbound VoIP dial-peer forces the g711u codec.

  4. CUCM then responds with it's TCS back to the VGW. Here is where the first main difference lies.
    1. In Call A the TCS from CUCM to the VGW only lists g711Ulaw64k as a capability.
    2. In Call B the TCS from CUCM to the VGW lists: g729, g729wAnnexB, g711Ulaw64k, g711Alaw64k, g729AnnexA, g729AnnexAwAnnexB

  5. The next step for both calls is the Open Logical Channel (OLC) step. Messages are exchanged between CUCM and the VGW which state the codec chosen from the list of capabilities.

  6. In both Call A and Call B, the VGW and CUCM agree on g711Ulaw64k in the OLC messages.

  7. The next step is for the VGW and CUCM to send each other the Open Logical Channel Acknowledgement message to confirm the setup of the RTP and RTCP streams (IP address and port number)
    1. Call A OLC Ack Exchange
      1. VGW Sends OLC Ack to CUCM with RTP and RTCP IP address set to the VGW IP address (normal)
      2. CUCM Sends OLC Ack to VGW with RTP and RTCP IP address set to the VGW IP address. This indicates that there is a Transcoder or MTP allocated to the call which exists on this VGW.
    2. Call B OLC Ack Exchange
      1. VGW Sends OLC Ack to CUCM with RTP and RTCP IP address set to the VGW IP address (Normal)
      2. CUCM Sends a closeLogicalChannel message to the GW 7ms later.
      3. The call is released.

Based on this I would suggest you check the following:

  1. Check the region assigned to the calling phone and the region assigned to the gateway in CUCM.
    1. What is the maximum audio bitrate assigned between these regions (codec)?
    2. If the answer to the above question is G.729, you could try changing it to G711uand testing again.

 

If you checked that the region configuration is good and calls still fail, we will need to review the CM trace from UCM in addition to a fresh set of VGW logs in order to continue troubleshooting.

 



 

New Member

Re: Second call Disconnect Cause=47 Strange Issue

HI Jonathan,

I really appreciate your effort to analyze debug logs.

It seems that we are using correct region codec. I have attached more detail of CUCM config.

 

Re: Second call Disconnect Cause=47 Strange Issue

Hi There,

Thanks for posting those screenshots!

It looks like you have defined the codec max bitrate within the regions (HQ_REG to HQ_REG and Default to Default), but there is no region relationship defined between HQ_REG and Default. This means that calls between HQ_REG and Default will use G.729 by default.

Since the H.323 GW has the "MTP Required" tickbox selected, a media resource will need to be pinned to every call through that H.323 GW. I suspect that some of your media resources (MTPs or Transcoders) are in the default device pool, which would cause them to be in the default region.

Things I would look at next:
1. Check the devicepool/region assigned to your media resources (MTP and Transcoders) to see if they would be in the "Default" Region.
2. Would you be able to define the max audio bit rate between the HQ_REG and Default region to use 64Kbps (G711)?


Highlighted
New Member

Re: Second call Disconnect Cause=47 Strange Issue

Hi Jonathan,

all ip phones (caller) and gateway are in the same device pool (same region) and none of the devices are using the default region on their setting.

Re: Second call Disconnect Cause=47 Strange Issue

Hi there,

 

Yes, but can you confirm which location the media resources are located?

Can you post a screenshot of "Media Resources > Transcoder" and "Media Resources > Media Termination Point"?

 

In order to continue troubleshooting past this point, you would need to post the CM trace for the working/failed call.

New Member

Re: Second call Disconnect Cause=47 Strange Issue

Hi Jonathan,

Find the attached required logs

https://drive.google.com/open?id=0B5PZdkvYVavpTFpnNTQ1NFhYanM

Re: Second call Disconnect Cause=47 Strange Issue

Hi There,

 

Failed calls happen when the HW-TRANS device is allocated instead of the HW-MTP device. When the calls try and connect when the HW-TRANS device is used, we get an error (in the failed call section below).

 

WORKING CALL - Resource Allocation:

27616400.004 |05:12:15.100 |AppInfo  |MediaResourceCdpc(5330)::sendMtpAllocateRequestToDevice MtpResource=HW-MTP Cepn=ec22edcc-adc9-e399-491b-cf2fe909fb5b

FAILED CALL - Resource Allocation:

27618027.004 |05:13:21.598 |AppInfo  |MediaResourceCdpc(5333)::sendMtpAllocateRequestToDevice MtpResource=HW-TRANS Cepn=03197a90-af35-9059-575b-b4f6ddb966a4
.... SOME OUTPUT OMMITED ...

27618198.001 |05:13:21.613 |AppInfo |StationInit: (0147068) OpenReceiveChannelAck Status=1 (Error: Endpoint failed to open receive channel), IpAddr=IpAddr.type:1 ipAddr:0x00000000000000000000000000000000(::), Port=0, PartyID=33570955

 

Since your HW-MTP and HW-TRANS are in the same MRG, CUCM is load balancing between them for calls made through your H.323 GW which has MTP required enabled. This is why some calls work, and some calls fail (I think this may be related to the fact that your HW-TRANS has passthrough enabled, but I am not 100% sure).

 

Can you first try removing HW-TRANS from the MRG which is assigned to the MRGL on the H.323 GW? You could also move the HW-TRANS resource to a new MRG which sits below the MRG which contains the HW-MTP inside of the MRGL.

This should correct your issue.

Please let us know if this helps!


*** Please mark answers as helpful and/or correct if appropriate.

New Member

Re: Second call Disconnect Cause=47 Strange Issue

Hi Jonathan,

you really did a great job. all calls are working fine i have attached the screen shot changes that we made.from the router we could not remove pass-through command so we disable dspfarm profile 1 and created new profile.

Thanks man.

 

Re: Second call Disconnect Cause=47 Strange Issue

That is good news, thanks for following up with the results!

634
Views
10
Helpful
11
Replies
CreatePlease login to create content