CM interaction with H.323 Gateway issue ???

[renzil]

Hi ,

I have created a route pattern 9.24XXXXXX pointing to my H.323 gateway. Following are the two dial-peer created on my H.323 gateway

dial-peer voice 100 voip

preference 1

destination-pattern 5...

voice-class h323 15

session target ipv4:10.1.1.5 ( CallManager )

dtmf-relay h245-alphanumeric

!

dial-peer voice 4 pots ( To PSTN )

destination-pattern 9........

port 0/1/0

prefix 9

But when my IP Phone dials a local no i.e 924XXXXXX, I get a recorded message from my CM saying the call cannot go through...

Following is the debug

cc_api_call_setup_ind_common:

cisco-username=5002

----- ccCallInfo IE subfields -----

cisco-ani=5002

cisco-anitype=0

cisco-aniplan=0

cisco-anipi=0

cisco-anisi=1

dest=24709281

cisco-desttype=0

cisco-destplan=0

cisco-rdn=

cisco-rdntype=-1

cisco-rdnplan=-1

cisco-rdnpi=-1

cisco-rdnsi=-1

cisco-redirectreason=-1

Mar 11 19:08:33.481: //-1/006ADD2B0600/CCAPI/cc_api_call_setup_ind_common:

Interface=0x44F20020, Call Info(

Calling Number=5002(TON=Unknown, NPI=Unknown, Screening=User, Passed, Present

ation=Allowed),

Called Number=24709281(TON=Unknown, NPI=Unknown),

Calling Translated=FALSE, Subsriber Type Str=Unknown, FinalDestinationFlag=TR

UE,

Incoming Dial-peer=100, Progress Indication=NULL(0), Calling IE Present=TRUE,

Source Trkgrp Route Label=, Target Trkgrp Route Label=, CLID Transparent=FALS

E), Call Id=56

Mar 11 19:08:33.481: //-1/006ADD2B0600/CCAPI/ccCheckClipClir:

In: Calling Number=5002(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pre

sentation=Allowed)

Mar 11 19:08:33.481: //-1/006ADD2B0600/CCAPI/ccCheckClipClir:

Out: Calling Number=5002(TON=Unknown, NPI=Unknown, Screening=User, Passed, Pr

esentation=Allowed)

Mar 11 19:08:33.481: //56/006ADD2B0600/CCAPI/cc_api_call_setup_ind_common:

Set Up Event Sent;

Call Info(Calling Number=5002(TON=Unknown, NPI=Unknown, Screening=User, Passe

d, Presentation=Allowed),

Called Number=24709281(TON=Unknown, NPI=Unknown))

Mar 11 19:08:33.481: //56/006ADD2B0600/CCAPI/cc_process_call_setup_ind:

Event=0x4509D970

Mar 11 19:08:33.481: //56/006ADD2B0600/CCAPI/ccCallSetContext:

Context=0x445470B4

Mar 11 19:08:33.485: //56/006ADD2B0600/CCAPI/cc_process_call_setup_ind:

>>>>CCAPI handed cid 56 with tag 100 to app "Default"

Mar 11 19:08:33.485: //56/006ADD2B0600/CCAPI/ccCallProceeding:

Progress Indication=NULL(0)

Mar 11 19:08:33.485: //56/006ADD2B0600/CCAPI/ccCallDisconnect:

Cause Value=1, Tag=0x0, Call Entry(Previous Disconnect Cause=0, Disconnect Ca

use=0)

Mar 11 19:08:33.485: //56/006ADD2B0600/CCAPI/ccCallDisconnect:

Cause Value=1, Call Entry(Responsed=TRUE, Cause Value=1)

Mar 11 19:08:33.485: //56/006ADD2B0600/CCAPI/cc_api_get_transfer_info:

Transfer Number Is Null

Mar 11 19:08:33.493: //56/006ADD2B0600/CCAPI/cc_api_call_disconnect_done:

Disposition=0, Interface=0x460D4FF0, Tag=0x0, Call Id=56,

Call Entry(Disconnect Cause=1, Voice Class Cause Code=0, Retry Count=0)

Mar 11 19:08:33.493: //56/006ADD2B0600/CCAPI/cc_api_call_disconnect_done:

Call Disconnect Event Sent

Where am I going wrong ????

Rgds

Renzil

[jm9393]

Your CallManager is stripping the 9. Remove the period from your route pattern to send the 9 to the h323 gateway.

[allan.thomas]

Could you clarify whether your local number you are dialling should be 8 or 9 digits ?

From your config the terminating router will strip the digit 9 from the called number and then append the 9 back to the front of the remaining digits due to the prefix command. So the the actual number dialed will still be 924709281.

[maharris · Accepted solution]

Yes, but the pots peer pattern starts with a 9, so if the number does not show up from the CallManager routing with a 9 to start, it will not match the peer, and the call won't go out.

Mary Beth

[allan.thomas]

This is exactly why clarification is required as to whether local dialling requires 8 or 9 digits. If CallManager is not stripping predot in the first instance, then the dial-peer does match the destination pattern.

However, as I have highlighted previously, the terminating gateway will strip 9 leaving 24........, which will be append again with 9 by the prefix command, and dialled number will be 924........

[maharris]

Yes, you are right - but it looked from the debug ccapi that it was stripping the 9. It would sure be nice if you didn't have to also worry about how many digits you were really supposed to be sending, with so many different dial plans out there!

Mary Beth

[renzil]

Thanks guys for all that input,

Problem solved. I configured the route pattern as 924XXXXXX then the pots dial-peer as follows

dial-peer voice 4 pots

destination-pattern 9........

port 0/1/0

I needed to have an 8 digits dial plan as its applicable here in Oman.

Rgds

Renzil