Problems with outgoing calls across AT&T T1 link in Indiana (US)???

[r.ferrero]

Hi all,

I am experiencing problems with outgoing calls across T1.

The local prefix in Indiana is 812. Well, when I dial 9812xxxxxxx (9 is digit for get line) the call is not able to go out. However if I dial 91812xxxxxxx the call goes out properly. The second way is like a long distance call in US (calls from a State to another State) The curious is that any other long distance calls, but the 812 code, works.

Other added problem is that international calls don`t works. I can see the same behavior like the long distance calls.

Nevertheless, toll free numbers 9.18XX are working fine.

The unique information I have from AT&T is:

isdn switch-type primary-5ess

protocol NI-2

and 7 digits out (in outgoing calls): I am not sure if it refers to called or calling end.

-It seems like a transformation mask in the calling party for 7 digits XXXXXXX the calls tries to go out but finally fails.

-Without the mask I get a incorrect number message:

005103: *Dec  2 17:59:24.117 GMT: ISDN Se0/0/0:23 Q931: TX -> DISCONNECT pd = 8  callref = 0x0140

        Cause i = 0x80AC - Requested circuit/channel not available

-Applying the mask in the called end I get this message:

Cause i = 0x809C - Invalid number format (incomplete number)

Somebody knows if is there any typical type/plan pair for this configuration?

Here is the debug output when I try to dial international Spanish mobile number from Indiana:

004920: *Dec  2 16:49:31.301 GMT: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 3

004921: *Dec  2 16:49:31.301 GMT: ISDN Se0/0/0:23 Q931: pak_private_number: Invalid type/plan 0x0 0x0 may be overriden; sw-type 3

004922: *Dec  2 16:49:31.305 GMT: ISDN Se0/0/0:23 Q931: Applying typeplan for sw-type 0x3 is 0x2 0x1, Called num 01134606899545

004923: *Dec  2 16:49:31.305 GMT: ISDN Se0/0/0:23 Q931: TX -> SETUP pd = 8  callref = 0x012F

        Bearer Capability i = 0x8090A2

                Standard = CCITT

                Transfer Capability = Speech 

                Transfer Mode = Circuit

                Transfer Rate = 64 kbit/s

        Channel ID i = 0xA98397

                Exclusive, Channel 23

        Calling Party Number i = 0x2181, '9854034'

                Plan:ISDN, Type:National

        Called Party Number i = 0xA1, '01134606899545'

                Plan:ISDN, Type:National

004924: *Dec  2 16:49:31.353 GMT: ISDN Se0/0/0:23 Q931: RX <- CALL_PROC pd = 8  callref = 0x812F

        Channel ID i = 0xA98397

                Exclusive, Channel 23

004925: *Dec  2 16:49:31.689 GMT: ISDN Se0/0/0:23 Q931: RX <- PROGRESS pd = 8  callref = 0x812F

        Cause i = 0x829F - Normal, unspecified

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

Somebody knows what I might be doing wrong????

Thanks in advance

[Udit Mehrotra]

Hi,

What is the gateway protocol? Try sending all calls as Type and Plan "Unkown" and let the telco decide how to route the call.This can help in international and 10 digit dialing.

Also, does the telco support 10 digit dialing? If 7 digit dialing is supported, can strip the area code and send the call out.

HTH

[r.ferrero]

Hi,

The gateway is configured in H323.

In the light of test I think when Telco said "7 digits out" they referred to strip the called party.

When I stripped only the calling number, I got error messages saying more or less  "incorrect number"

When a US Telco says "7 digits out", Is the company tipically refers to calling end or called end?

If I would strip the calling number, it could be successful for local or long distance calls but in my opinion, it won't be successful for international calls, in example, calling to Spain : 9 011 34 91437XXXX  (9-get dial tone; 011 international prefix; 34 international prefix in Spain; 91437XXXX number allocated in Madrid)

Thanks

[asandborgh]

Hi,

Typically if a US carrier states 7 digits out they are indicating that you can send a local call with only 7 digits in the CALLED number field  - which is how it was for decades before they started running out of numbers and started overlaying area codes.  See:

http://en.wikipedia.org/wiki/List_of_area_code_overlays

Norally here you would have certain route patterns as a norm for NANP - 911, 9.911, 9.[2-9]XXXXXX, 9.1[2-9]XX[2-9]XXXXXX, 9.011!# and 9.011! if you were in an area like Indiana (no overlay).  In overlayed areas you can't use 7 digit dialing so you have to dial 10 digits, so you would drop the 9.[2-9]xxxxxx and substitue 9.[2-9]XX[2-9]XXXXXX (note -  no leading 1 which indicates long distance here).

So - going back to what I suggested earlier, did you set the type/plan to unknown/unknown and send 10 digits as the calling# (quite normal in NANP areas)?

again HTH,

Art

[asandborgh]

Good evening (or day depending on where you are),

Cause i = 0x80AC - Requested circuit/channel not available - try configuring "isdn bchan ascending" on the serial controller of the T1 - that looked like glare

For the other issue I would try sending 10 digits CLID out - most US switches will either like this or mask it, but generally accept it.

Additionally, do as Udit recommended - send everything out type/ plan as unknown/unknown and the CO switch should be more forgiving.  You sent the Int'l call as a national call and that is a no-no in the carrier world.

HTH,

Art