07-30-2009 03:03 AM - edited 03-15-2019 07:08 PM
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
07-30-2009 05:33 AM
What do you see in your debug isdn q931 - 7 or 8 digits?
07-30-2009 05:38 AM
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.
07-30-2009 05:44 AM
ISDN PRI sends digts enblock by default, so how can you disconnects before call finished?
07-30-2009 05:49 AM
not always
07-30-2009 05:43 AM
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
07-30-2009 05:58 AM
Hi,
Follow this thread it will fix this issue for you. I just had the same issue in Italy.
07-30-2009 05:59 AM
07-30-2009 06:41 AM
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.
07-30-2009 06:57 AM
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
07-30-2009 09:40 AM
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
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide