I have a problem regarding International Calling. I currently have 3 route patterns in place.
A internaional call in progress would busy out when all digits are dialed.
I created a more explicit pattern for an International call and that works fine, but will not work with the patterns above. I bumped the ISDN timers and no positive results. The following text is the Debug ISDN Q931. Any help would be great.
debug isdn q931
ISDN Q931 packets debugging is on
2d14h: ISDN Se1/0:23: TX -> SETUP pd = 8 callref = 0x0042
2d14h: Sending Complete
2d14h: Bearer Capability i = 0x8090A2
2d14h: Channel ID i = 0xA98397
2d14h: Calling Party Number i = 0x0081, '2013465045', Plan:Unknown, Type:Unknown
2d14h: Called Party Number i = 0x91, '01181332245000', Plan:ISDN, Type:International
2d14h: ISDN Se1/0:23: RX <- CALL_PROC pd = 8 callref = 0x8042
2d14h: Channel ID i = 0xA98397
2d14h: ISDN Se1/0:23: RX <- PROGRESS pd = 8 callref = 0x8042
2d14h: Cause i = 0x829F - Normal, unspecified
2d14h: Progress Ind i = 0x8488 - In-band info or appropriate now available
2d14h: ISDN Se1/0:23: TX -> DISCONNECT pd = 8 callref = 0x0042
2d14h: Cause i = 0x8090 - Normal call clearing
2d14h: ISDN Se1/0:23: RX <- RELEASE pd = 8 callref = 0x8042
2d14h: ISDN Se1/0:23: TX -> RELEASE_COMP pd = 8 callref = 0x0042
BRM3640#no debug alldebug isdn q931
This is probably because the US Number plan contains some of these elements. Try ticking the Urgent Priority flag in the route pattern of the more specific dialplan.
Otherwise hope someone from the US answers!
Setting the priority may work but you could always try changing the Plan type from international to Unknown. I had a similar problem to this (but in Europe) and this seemed to be the short term solution.
In the dial-peer statement you can use the command
ISDN Numbering plan type UNKNOWN or I also believe that this can be done in the CallManager.
One other thing why the 3 matches? you could just use 9.011! and if you are using dial-peers in your gateway make sure that you have just this entry. If people want to end their call with a # then they can still do this. Try to keep the route patterns as simple as possible.
Depending on the version of callmanager you cant just press # to send call connect you will need a route pattern 9.011!# as well.
This is what i have found .Many moons ago 3.03 and many variations different versions (patches)variations since but some versions (service patches)I have seen do not work and there was no other potential matches.
Have a gander at the CCM trace if you experience issuses.
Have you tried to change the plan on the calling party to unknown?
Have you tried to change the numbering type for the calling to unknown?
You can achieve that by using translation rules on the termination gateway.
The release is coming from you PSTN....
The release is NOT coming from the PSTN!!!
The problem is with the t302 timer on the router. The T302 timer dictates the time the router will wait between setup messages, and in this case the router is timing out and sending disconnect. increase the timer on the router (NOT the one on CALL MANAGER) and you should solve the problem.
This is a listed problem on TAC and there is a white paper discussing this problem available to download. This really should have been the first place to look as I think it's headed something like "problem calling international numbers"
What type of gateway do you have? H.323 or MGCP? If it's H.323 you can config:
Rule 0 ^011 011 international unknown
no ip address
no logging event link-status
isdn switch-type primary-5ess
isdn incoming-voice voice
isdn map address ^011 plan isdn type unknown
no cdp enable
dial-peer voice 9 pots
incoming called-number .
Or in you CCM MGCP configuration page change the default Callmanager numbering plan to UNKNOWN. Your should only have a 9.@ route pattern.
Hope this helps!
Vericom Systems, Inc