cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3010
Views
4
Helpful
10
Replies

isdn overlap-receiving issues

jerold.baker
Level 1
Level 1

Hey all,

I am having an issue with overlap receiving on a MGCP/CallManager controlled PRI in Milano Italy. The gateway is a 3825 running 12.4(15)T7. The teleco is sending 8 digits total and I am getting 7 followed by the final digit sometime later. The D channel is configured as follows. Increasing the T302 timer seems to have not effect.

interface Serial0/0/1:15

no ip address

encapsulation hdlc

isdn switch-type primary-net5

isdn overlap-receiving T302 12000

isdn incoming-voice voice

isdn bind-l3 ccm-manager

isdn bchan-number-order ascending

no cdp enable

The CallManager version is 6.0(1). The gateway is setup to get 5 significant digits. These patterns are in the gateways CSS.

XXXXX

46997

24691

4[67]XXX

46999

When an incomplete call setup comes in the CallManager attempts to match the last 5 of 7 instead of 8 and the call gets rejected with this error.

Cause i = 0x8081 - Unallocated/unassigned number

10 Replies 10

What do you see in your debug isdn q931 - 7 or 8 digits?

on the failed calls I see 7, on the good I see all eight. The teleco says that we are disconnecting the call before they finish sending.

ISDN PRI sends digts enblock by default, so how can you disconnects before call finished?

not always

Just some data for you to consider:

This call should have came in as 26124691 and this is what came:

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA18385

Preferred, Channel 5

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '261294777'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '2612469'

Plan:ISDN, Type:National

.Jul 30 10:48:31.309 CET: ISDN Se0/0/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x8400

Cause i = 0x8081 - Unallocated/unassigned number

This call should have been 261246981 and it came in like this

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1838A

Preferred, Channel 10

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2181, '296543483'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '26124698'

Plan:ISDN, Type:National

.Jul 30 10:49:13.469 CET: ISDN Se0/0/1:15 Q931: TX -> RELEASE_COMP pd = 8 callref = 0x9000

Cause i = 0x8081 - Unallocated/unassigned number

Hi,

Follow this thread it will fix this issue for you. I just had the same issue in Italy.

I see how this would work with a H.323 gateway and I have the Overlap command in. I think the issue may be in that fact that this is a call manager controled gateway (MGCP). We are disconnecting the call before we have a chance to receive the final digit.

I currently have the same issue in two countries Germany and Italy and have resolved it. I am using H323 instead of mgcp but the most important thing is to setup your dialpeer using the " T " so it waits for the last digit to turn up. Also, on your translation rules, do match as far as the most significant digit. For example, if the extension number is 567 and the carrier is presenting 34567, match and strip the 34 only and have your dialpeer as 3T...

rule 1 /^345/ /5/

dial-peer voice 1003 voip

destination-pattern 3T

progress_ind setup enable 3

voice-class h323 1

session target ipv4:10.8.101.10

dtmf-relay h245-signal h245-alphanumeric

codec g711ulaw

Hey everyone thanks for all the help. I seem to have solved it myself. It was much the same as the H.323 issue above, except CallManager had a route for any 5 digit pattern so when an incomplete call came in the last five would match that pattern and there would be no DN to match so we got the error above.

What I did was to make all the digits (9) that the teleco was sending significant. Once that was in I set up some translation patterns for the gateway to read that would trim it back down to where I needed it. In short this made callmanager not have a match until it received 9 digits. Now it waits for the rest of the digits before making a routing decision.

here is what the layer 3 looks like now.

.Jul 30 16:49:33.973 CET: ISDN Se0/0/1:15 Q931: RX <- SETUP pd = 8 callref = 0x5900

Bearer Capability i = 0x9090A3

Standard = CCITT

Transfer Capability = 3.1kHz Audio

Transfer Mode = Circuit

Transfer Rate = 64 kbit/s

Channel ID i = 0xA1838F

Preferred, Channel 15

Progress Ind i = 0x8083 - Origination address is non-ISDN

Calling Party Number i = 0x2183, '261293812'

Plan:ISDN, Type:National

Called Party Number i = 0xA1, '2612469'

Plan:ISDN, Type:National

.Jul 30 16:49:33.993 CET: ISDN Se0/0/1:15 Q931: TX -> SETUP_ACK pd = 8 callref = 0xD900

Channel ID i = 0xA9838F

Exclusive, Channel 15

MILANO-RTR1#

.Jul 30 16:49:35.141 CET: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x5900

Called Party Number i = 0xA1, '6'

Plan:ISDN, Type:National

MILANO-RTR1#

.Jul 30 16:49:36.481 CET: ISDN Se0/0/1:15 Q931: RX <- INFORMATION pd = 8 callref = 0x5900

Called Party Number i = 0xA1, '7'

Plan:ISDN, Type:National

.Jul 30 16:49:36.533 CET: ISDN Se0/0/1:15 Q931: TX -> CALL_PROC pd = 8 callref = 0xD900

.Jul 30 16:49:36.537 CET: ISDN Se0/0/1:15 Q931: TX -> ALERTING pd = 8 callref = 0xD900

Progress Ind i = 0x8088 - In-band info or appropriate now available

.Jul 30 16:49:39.249 CET: ISDN Se0/0/1:15 Q931: RX <- DISCONNECT pd = 8 callref = 0x5900

Cause i = 0x8090 - Normal call clearing

Progress Ind i = 0x8288 - In-band info or appropriate now available

.Jul 30 16:49:39.305 CET: ISDN Se0/0/1:15 Q931: TX -> RELEASE pd = 8 callref = 0xD900

.Jul 30 16:49:39.349 CET: ISDN Se0/0/1:15 Q931: RX <- RELEASE_COMP pd = 8 callref = 0x5900

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: