CUCM to H323 Dial Peer not working

[Salvo_Phl]

Hi All,

I have a customer with a remote site located in India. I have configured an H323 Gateway on the CUCM.

Incomming calls work perfectly.

When I attempt to make an outgoing call, I receive a fast busy tone.

This is the outbound dialpeer:

dial-peer voice 10 pots

description National Calls

destination-pattern .T

port 0/2/0:15 - (The PRI port is up and operational as I can receive calls)

IND-SR-RTR01#sh controllers e1

E1 0/2/0 is up.

  Applique type is Channelized E1 - balanced

  No alarms detected.

  alarm-trigger is not set

  Version info Firmware: 20100222, FPGA: 13, spm_count = 0

  Framing is CRC4, Line Code is HDB3, Clock Source is Line.

The correct dialpeer is being reached:

IND-SR-RTR01#debug  voice dialpeer all

voip dialpeer all debugging is on

<output ommited>

Nov 30 12:18:36.952: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:

   Result=SUCCESS(0)

   List of Matched Outgoing Dial-peer(s):

     1: Dial-peer Tag=10Nov 30 12:18:36.952: //-1/xxxxxxxxxxxx/DPM/dpMatchPeersMoreArg:
   Result=SUCCESS(0)
   List of Matched Outgoing Dial-peer(s):
     1: Dial-peer Tag=10

The result of a debug h225 asn1 is:

IND-SR-RTR01#debug h225 asn1
H.225 ASN1 Messages debugging is on
IND-SR-RTR01#
Nov 30 12:25:10.214: H225.0 INCOMING ENCODE BUFFER::= 20B0060008914A00050201803733401F0030003400300030000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000022C0B50000120F436973636F43616C6C4D616E61676572003100010480C9B94C438B000097A0950F2161ED2600AF02AC14221A00D50D80000700AC14010B06B811000097A0950F2161ED2600AF02AC14221A010001000100010010A001000F0140B5000012088144000400010300
Nov 30 12:25:10.214:
Nov 30 12:25:10.214: H225.0 INCOMING PDU ::=

value H323_UserInformation ::=
    {
      h323-uu-pdu
      {
        h323-message-body setup :
        {
          protocolIdentifier { 0 0 8 2250 0 5 }
          sourceAddress
          {
            dialedDigits : "0400",
            h323-ID : {"0400..."}
          }
          sourceInfo
          {
            vendor
            {
              vendor
              {
                t35CountryCode 181
                t35Extension 0
                manufacturerCode 18
              }
              productId '436973636F43616C6C4D616E61676572'H
              versionId '31'H
            }
            terminal
            {
            }
            mc FALSE
            undefinedNode FALSE
          }
          destinationAddress
          {
            dialedDigits : "9686191058"
          }
          activeMC FALSE
          conferenceID '0097A0950F2161ED2600AF02AC14221A'H
          conferenceGoal create : NULL
          callType pointToPoint : NULL
          sourceCallSignalAddress ipAddress :
          {
            ip 'AC14010B'H
            port 1720
          }
          callIdentifier
          {
            guid '0097A0950F2161ED2600AF02AC14221A'H
          }
          mediaWaitForConnect FALSE
          canOverlapSend FALSE
          multipleCalls FALSE
          maintainConnection FALSE
        }
        h245Tunneling FALSE
        nonStandardControl
        {

          {
            nonStandardIdentifier h221NonStandard :
            {
              t35CountryCode 181
              t35Extension 0
              manufacturerCode 18
            }
            data '8144000400010300'H
          }
        }
      }
    }

Nov 30 12:25:10.214: H225 NONSTD INCOMING ENCODE BUFFER::= 8144000400010300
Nov 30 12:25:10.214:
Nov 30 12:25:10.214: H225 NONSTD INCOMING PDU ::=

value H323_UU_NonStdInfo ::=
    {
      callMgrParam
      {
        interclusterVersion 3
        enterpriseID {}
      }
    }

Nov 30 12:25:10.218: H225.0 OUTGOING PDU ::=

value H323_UserInformation ::=
    {
      h323-uu-pdu
      {
        h323-message-body releaseComplete :
        {
          protocolIdentifier { 0 0 8 2250 0 4 }
          callIdentifier
          {
            guid '0097A0950F2161ED2600AF02AC14221A'H
          }
        }
        h245Tunneling FALSE
      }
    }

Nov 30 12:25:10.218: H225.0 OUTGOING ENCODE BUFFER::= 2580060008914A0004110011000097A0950F2161ED2600AF02AC14221A10800100
Nov 30 12:25:10.218:

If anyone can assist as to what the problem can be, that would be greatly apprecieated.

I have attached the current router config with the relavant lines in it.

Thanks in advance.

Phil

[acampbell]

Phil,

Looking at the dial peer 10

dial-peer voice 10 pots

description National Calls

destination-pattern .T

This will forward all digits including the 9

Try changing to

dial-peer voice 10 pots

description National Calls

destination-pattern 9T

Regards

Alex

[Salvo_Phl]

Hey Alex,

The 9 is actually part of the full number that needs to be dialed, so it is not a preceeding digit needed to access the PSTN.

Thanks,

Philip.

[acampbell]

Hi,

Can you provide the output from

debug isdn q931

For the failed call.

Rgeards

Alex

[david-lima]

Hi Phillip, I suggest to configure the *h323-gateway voip bind srcaddr IP ADDRESS* under the interface that is registered as H323 GW in your Callmanager.

hth

David

[Salvo_Phl]

Hi Alex,

No output displayed from debug isdn q931, but there is output from debug h225 asn1 as specified above.

Hi David,

I have added that command but still no joy.

Thanks all for the help with all so far...

Phil

[boris.kudr]

try adding "no digit-strip" into the dial-peer 10 and post debug output if call fails.

debug isdn q931

debug isdn q921

deb voice ccapi inout

deb h225 as

deb h245 as

[acampbell]

Phil,

Looking at the H225 trace I dont think we are matching an inbound dial peer from VOIP

The IP address is sourced from AC14010B(HEX) = 172.20.1.11

Can you add this dial peer (Just for testing)

!

dial-peer voice 101 voip

preference 2

incoming called-number .

destination-pattern 0...$

session target ipv4:172.20.1.11

voice-class h323 1

dtmf-relay h245-alphanumeric

!

Try another call

Regards

Alex

[Salvo_Phl]

Hi All,

Thanks for all of the replies.. I managed to sort out the problem with the help of TAC. Below are the details.

1. First problem was as suggested by Alex, there was no inbound dial peer to match the incomming VOIP leg form the CallManager. This was the Dial-Peer configured :

dial-peer voice 99 voip

session target ipv4:172.20.1.10

incoming called-number .

voice-class h323 1

dtmf-relay h245-alphanumeric

2. Secondly, the service provider in India required the calls to be passed in ascending order from channel #1 and not the default descending order from Channel #31. The following command was added:

interface Serial0/2/0:15

isdn bchan-number-order ascending

3. Lastly , there has been a new feature added to the newer IOS versions for Toll Fraud prevention that requires IP addresses of incomming VOIP calls (SIP or H323) to be trusted. It is enabled by default and is disabled with:

voice service voip

no ip address trusted authenticate

Thanks again.

Phil