ISDN PRI Cisco 2811 Call Manager - # of Digits recieved

[TODD BERGMAN]

Anyone know how to tell the number of digits recieved from CO to CPE. I do a debug ISDN q931 and see 10 however translation patterns in call manager will only work collecting 4 digits. If I edit the translation pattern to except 10 as displayed in the debug I get error message from provider. Is there another debug command that will show the CO to CPE numbers that callmanager actuall accepts or is there another configuration option somewhere..

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Calling Party Number i = 0x2081, '616XXXXXXX'

Plan:Unknown, Type:National

Called Party Number i = 0xA1, '610XXXXXXX'

Plan:ISDN, Type:National

XX's are hiding actual number

Thanks for your help.

[allan.thomas]

How many significant digits have you configured on the MGCP endpoint, All, 10, or 4?

If you specify 4 digits, then only the last 4 digits from 10 presented reading from right to left are forwarded to CallManager.

If have configured translation patterns to translate 10 digits to 4 to fall within your dial-plan then ensure you have all or 10 digits configured.

Regards

Allan.

[TODD BERGMAN]

Significant digits is set to 4. So based on the debug isdn q931, if I set the endpoint significant digits to 10 or all then I can change my translations to reflect this.

[allan.thomas]

You are correct, the number of digits that you forward into CallManager is dependent on your numbering plan.

For example if you have six digits presented by the telco for a given DDI range then configure your translation patterns such that you translate your six digits to your 4 digit dial-plan.

Lets say you have 20 DDIs 123100-123120, you can configure translations to match 12310X to 650X and 12312X to 651X or simply 1231XX to 65XX.

Regards

Allan.

HTH.

[TODD BERGMAN]

OK I changed significant digits to 10 and changed translation pattern to reflect this change.

My issue:

*Nov 13 02:33:09.808 EST: ISDN Se0/0:23 Q931: RX <- SETUP pd = 8 callref = 0x02

EE

Bearer Capability i = 0x8090A2

Standard = CCITT

Transfer Capability = Speech

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA98381

Exclusive, Channel 1

Calling Party Number i = 0x2183, '616XXXXXXX'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '610XXXXXXX'

Plan:ISDN, Type:National

*Nov 13 02:33:09.860 EST: ISDN Se0/0:23 Q931: TX -> RELEASE_COMP pd = 8 callref

= 0x82EE

Cause i = 0x8081 - Unallocated/unassigned number

[allan.thomas]

This is typical behaviour if there is no pattern match, therefore there is a problem with your translations.

Dialed Number Analyzer will probably confirm. Providing the partition assigned to the translations pattern is within the gateways CSS, and significant digits is 10 the same as your translation pattern there there should be a match unless the transformation is wrong.

Could you provide details of how your 10 digits map to your CCM dial-plan, could you post a translation? and screen of the gateway endpoint?

Regards

Allan.

[TODD BERGMAN]

OK attached are screens of translation pattern for main number and gateway endpoint which has significant digits set to all. The configuration works just fine as long as the translation is 4 digits.

[TODD BERGMAN]

OK what gives. If I change the significant digits to all and then the translation to 10 digits reboot the cluster it works...Any ideas. Any changes I make will not work until I reboot the cluster. What must be refreshed to accept the changes.

[allan.thomas]

Initially try restarting the gateway endpoint, the gateway css will have the partition associated with your translations.

I would not expect you to have to reboot the cluster in order for the changes to take effect.

I would restart only the CallManager service next time, needless to say this should not be necessary. Can you advise what CCM version you are running, and I'll look to see if you running into a known issue.

In the past if you make changes/edit the installed dial-plan file in any way, then in this instance it necessary to restart the CCM service to load the new dial-plan, and also the same is applicable to the DNA.

Regards

Allan.

[TODD BERGMAN]

CM Version 4.1.3sr5d. I messed with it some more and on the gateway I ran "No ccm-manager config" then ccm-manager config and the PRI reregistered this worked. But this is very intrusive. I must have a bug.

One other area that might help us is with this. My configuration consists of 7 locations centralized call manager with subscriber. At the main location I have 3 pri's in a 3825. When the call manager reboots not all pri's come up. Seems an issue with MGCP. The PRI's miss statements under the t1 controllers that tie the timeslots to the service mgcp. If I issue no ccm-manager config and ccm-manager config the pri's will come up just fine. I initially thought that this was isolated to the gateway in the main location but now dealing with this sounds like I have an issue with CM and MGCP communiction with the gateway.

[allan.thomas]

What version of IOS are you running on your MGCP gateway? It should not be necessary to force the ccm-manager config everytime you initate a change within CCM, a reset of the gateway within CCM should be sufficient.

How have you configured your MGCP gateways? with IP address or hostname? Also have you specifically bind MGCP to a loopback or another interface?

Run a 'show ip socket' command, you should be able to identify which ip address port 2427 is associated with, this is your source. Is this address the gateway is registered with in CCM?

Typically MGCP will bind to a loopback, but you may have configured otherwise.

I have come across instances where MGCP which binds to an interface other than a loopback will cause MGCP to bind incorrectly following a restart. The reason is that the interface is not physically up at the time following the restart, and subsequently MGCP binds to a loopback or another address. Consequently although you have specified the FE as the MGCP source, the gateway however regisers with the lo or another address.

This was in 12.4(9)T incidentally.

As a test could you remove the ccm-manager config command and save, then reload the gateway and see if registers after.

Regards

Allan.

[TODD BERGMAN]

Version 12.4(6)XT on my 3825

17 172.20.1.12 2427 172.20.1.2 2427 0 0 211 0

172.20.1.2 is my FE

hostname zeelandvoice

ccm-manager fallback-mgcp

ccm-manager redundant-host 172.20.1.10

ccm-manager mgcp

ccm-manager music-on-hold

ccm-manager config server 172.20.1.12

ccm-manager config

!

mgcp

mgcp call-agent 172.20.1.12 2427 service-type mgcp version 0.1

mgcp dtmf-relay voip codec all mode out-of-band

mgcp rtp unreachable timeout 1000 action notify

mgcp modem passthrough voip mode nse

mgcp package-capability rtp-package

no mgcp package-capability res-package

mgcp package-capability sst-package

no mgcp package-capability fxr-package

mgcp package-capability pre-package

no mgcp timer receive-rtcp

mgcp sdp simple

mgcp fax t38 inhibit

mgcp rtp payload-type g726r16 static

[allan.thomas]

Do you have any other interfaces configured on this gateway other than the FE? The following are some guidelines regarding MGCP Binding:-

If the mgcp bind command is not enabled, the IP layer still provides the best local address.

A warning message will be displayed if any of the following situations occur:

When there are active MGCP calls on the gateway, the mgcp bind command is rejected for both control and media.

If the bind interface is not up as it would be in this case following a restart, then the command is accepted but does not take effect until the interface comes up.

If the IP address is not assigned on the bind interface, the mgcp bind command is accepted but takes effect only after a valid IP address is assigned. During this time, if MGCP calls are up, the mgcp bind command is rejected.

When the bound interface goes down, either because of a manual shutdown on the interface or because of operational failure, the bind activity is disabled on that interface.

When bind is not specifically configured on the gateway as in your case, then the IP address used for sourcing MGCP control and media will be the best available IP address, and this is the issue if you have non routeable interfaces.

If the gateway FE is the only IP interface, then this would selected as the best available IP, which is what is shown in the 'show ip socket' output. The remote source address for MGCP is CCM and the local is the FE IP address.

If there are no other IP addresses then there is no cause for concern, and the fact it it on the same subnet as CCM rules out any issues concerning routing.

The only issue which I can see is that MGCP will be bound to the FE which initially would be down, however apparently this should not be a problem and MGCP will bind once the interface is up.

The question is why you have to force the gateway to download the config, this behaviour suggests an underlying issue in the IOS, I'll look into it.

Have you configured the MGCP endpoint as only zeelandvoice or have you specified the IP of 172.20.1.2? If you have used the hostname, ensure that CCM can resolve it.

Regards

Allan.

[allan.thomas]

Take a look at the following link, I have been doing further digging, and I believe this is a possible match for the symptoms that you describe.

The workaround is to initiate a shut/no shut on the T1 controller or the voice-port is required for the interfaces to register.

According to CCM the gateway is not registered, however the gateway believes that it is. Next time you reload and before you change the controller, check the registration status within CCM and then check the gateway 'show ccm-manager'. Are the both registered, or different states?

http://tools.cisco.com/Support/BugToolKit/search/getBugDetails.do?method=fetchBugDetails&bugId=CSCsh49544&from=summary

12.4(6)XT is certainly an affected version, and is resolved in 12.4(9)T5, 12.4(11)T3

and 12.4(16.10)T.

Regards

Allan.

[TODD BERGMAN]

OK ...Thank you so much for your information much appreciated. You must really have a passion for cisco voice.

When I get another window I will try your recomendations.