cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
3309
Views
30
Helpful
16
Replies

# doesn't reduce interdigit time

DOMJAHN DAVID
Beginner
Beginner

Hi there,

I'm struggeling with reducing the T302 timer (I've lowered it from its default value to 4 sec) by putting a # behind

dialed numbers.

With a translation pattern "0.!" and "pre dot trailing #" configured in the called party transformation section I receive a fast busy

immediately when pressing the # key. Without the # key I have to wait for T302 to stop collecting further digits.

With an additional translation pattern of "0.!#" the number is dialed but I have to wait the interdigit timeout to stop CUCM 7.x

collecting further digits (even if # is used Interdigit Timeout waits for further digits...)

Any ideas?

Regards,

David

2 Accepted Solutions

Accepted Solutions

David,

These are the patterns give you problems:

\+49! -> Route list "SIP Provider1" (national calls)

\+!  -> Route list "SIP Provider 2" (international calls)

For example.  Modify the following:

00.[1-9]! / PreDot ; prefix digits \+49 -> CSS E164_Routing

00.[1-9]!#  / PreDot Trailing #; prefix digits \+49 -> CSS E164_Routing

to

00.[1-9]! / PreDot ; prefix digits \+49 -> CSS E164_Routing

00.[1-9]!#  / PreDot; prefix digits \+49 -> CSS E164_Routing

and then add the following route patterns:

\+49!# -> Route list "SIP Provider1" (national calls)

\+!# -> Route list "SIP Provider 2" (international calls)

And see if that resolves the issue for the example.  If so, then modify:

0.[1-9]!# / PreDot ;  prefix digits \+49721 -> CSS  E164_Routing

000.[1-9]!# / PreDot; prefix  digits \+ -> CSS E164_Routing

To remove the "Trailing #" directive.  That should resolve your issue.  Based on the info provided that is.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

View solution in original post

David,

Yes, you would need all four patterns to support both dialing scenarios you want to provide to the end users.  Trying to stear away from that could break things.  For instance, if you had:

Translations:

0.!  (strip pre-dot)

0.!# (strip pre-dot, trailing-#)

Route patterns:

\+!  (flagged as urgent priority)

You can still accomodate the pattern with the octothorpe.  This is because you have the urgent priority flag set on the route pattern and it will route immediately once the translation pattern is satisfied (which means the "#" has been provided by the user).  However, there is a problem with this config.  The urgent priority will negatively impact the "0.!" translation.  Basically, as soon as you enter the second digit (e.g. 04).  The route pattern is evaluated and routed immediately (a la urgent priority).  Translations are interesting in this way, the translated digits are evaluated along with the dialed digits.  IOW, it isn't a two step process.

Now, if we could post-fix an octothorpe at the end of a translation you could limit the number of route patterns you would need.  But this is not possible.  Meaning, there is no config option for this.  Even if there were, you would have the same problem as described above because a call would attempt to route right after you dialed a "0".

So, bottom line I don't think you can avoid the duality of the situation.  However, you can mitigate gross expansion of the dial plan by using Local Route Groups (LRG) and assigning your e.164 route patterns to a route list that leverages local route groups.

HTH.


Regards,
Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

View solution in original post

16 Replies 16

Anthony W.
Beginner
Beginner

Hey David,

I am going to give this one a shot.  Being you are using the 0.! my guess is you are somewhere in Europe or someplace that uses 0 as a local number and can have a varying length number.  Is that correct?

that's right - CUCM is running in Germany using variable length phone numbers.

Unfortunately there is no predefined dial plan support for Germany available in CUCM/CCO.

Thanks,

David

P. S. Playing with urgent priority in the translation pattern configuration doesn't help. When the "PreDot trailing #" option is activated

with "0.!#" or "0.!" interdigit timeout comes to play. "Strip # from calling party number" in service paramter configuration is set to default (true).

Hm...

I lived in Germany for a while so I may be able to help.

You shouldn't have to put a . between the 0 and the !.  Are you using a 9 or any number to get out?  If so then it would be 9.0!# and then you would discard the predot but by putting the 0.! you are separating the 0 from the number.  The 0 is needed for the number as 0 is for local calls and 00 is for international dialing.  I also think you can do this without a translation pattern.  In the route pattern I would try 9.0!# and point it directly to the Route List or Gateway and then discard the predot and see what happens.

Anthony

No, we are using 0 to get out so I need the dot behind 0 in order to strip it of from the called number (using "PreDot trailing #").

Cheers,
David

If you are using the 0 as the outside number.  Then are you dialing 0012345 to get a outside local Germany number? 

to access a phone in Hamburg having the number 04012345 I have to dial 004012345

for a local number 1234 I have to dial 01234

(so in Germany 0 is used for placing an outside call - within the US usually 9 is used)

Cheers,
David

OK that makes sense.  So then try 0.0!# strip predot and see how that works.  The extra 0 after the . may help make it a more direct match incase you have overlapping patterns. 

David,

You say that you are using translation  patterns as opposed to route patterns, correct?  If so, do the  translations expand to digits which you are hoping to match to an offnet  route pattern?  If this is the case, do you have route patterns with  the "!" digit mask that your translation may potentially match?

What  I am thinking may be better illustrated with an example:

Translation:   0.!#

Partition: translation_pt

Translation: Strip pre-dot and trailing #

CSS:  pstn-out_css

=========

Route Pattern: !

Partition: pstn-out_pt

RouteList: Your local route list

So, in this case if I dial 01234#, what happens is that it matches the translation 0.!#, which then strips the "0" and the "#" and gives us a number:  1234.  Then, the CUCM is doing another digit analysis.  With the route pattern above, we will have to wait for the interdigit time out because "!" could match more digits (like 12345 or 123456).

I am taking a guess here, but it is possible that you are running into a situation like the example described.  Sticking with this example, you can fix this with the following config changes:

Translation:   0.!#

Partition: translation_pt

Translation: Strip pre-dot

CSS:  pstn-out_css

=========

Route Pattern: !#

Partition: pstn-out_pt

RouteList: Your local route list

There are two changes.  On the translation, just strip "pre-dot" (i.e. preserve the pound).  Then on the route pattern, add a pound to the existing pattern.  Since you are preserving the pound, the pattern is matched exactly and the call routes immediately.  So, 01234# hits the 0.!# translation and becomes 1234#.  Which then matches the !# route pattern and routes, no interdigit timeout.

This works if you are using \+!# as well.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Hi

If the # doesn't immediately cause the call to route, the other thing you need to do is make sure that you don't have other route patterns that could be matched by the digits you have dialed so far (or further digits).

This is very likely to be happening if you have a lot of very broad route patterns like the one you listed..

Perhaps list all the route patterns you have available in the CSSs you are using, and we can comment further...

Regards

Aaron

Please rate helpful posts...

Aaron Please remember to rate helpful posts to identify useful responses, and mark 'Answered' if appropriate!

thanks, there are quite a lot translation patterns:

0.11[02] / PreDot -> Calling Search Space E164_Routing

0.[1-9]!# / PreDot Trailing # ;  prefix digits \+49721 -> CSS E164_Routing

0.[1-9]! / PreDot ;  prefix digits \+49721 -> CSS E164_Routing

00.[1-9]! / PreDot ; prefix digits \+49 -> CSS E164_Routing

00.[1-9]!# / PreDot Trailing #; prefix digits \+49 -> CSS E164_Routing

000.[1-9]! / PreDot ; prefix digits \+ -> CSS E164_Routing

000.[1-9]!# / PreDot Trailing #; prefix digits \+ -> CSS E164_Routing

Route pattern:

\+49! -> Route list "SIP Provider1" (national calls)

\+! -> Route list "SIP Provider 2" (international calls)

Thanks so far!

Regards,

David

David,

These are the patterns give you problems:

\+49! -> Route list "SIP Provider1" (national calls)

\+!  -> Route list "SIP Provider 2" (international calls)

For example.  Modify the following:

00.[1-9]! / PreDot ; prefix digits \+49 -> CSS E164_Routing

00.[1-9]!#  / PreDot Trailing #; prefix digits \+49 -> CSS E164_Routing

to

00.[1-9]! / PreDot ; prefix digits \+49 -> CSS E164_Routing

00.[1-9]!#  / PreDot; prefix digits \+49 -> CSS E164_Routing

and then add the following route patterns:

\+49!# -> Route list "SIP Provider1" (national calls)

\+!# -> Route list "SIP Provider 2" (international calls)

And see if that resolves the issue for the example.  If so, then modify:

0.[1-9]!# / PreDot ;  prefix digits \+49721 -> CSS  E164_Routing

000.[1-9]!# / PreDot; prefix  digits \+ -> CSS E164_Routing

To remove the "Trailing #" directive.  That should resolve your issue.  Based on the info provided that is.

HTH.

Regards,
Bill

Please remember to rate helpful posts.

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify

Bill, thanks a lot - that did the job!

(I also had to add a route pattern for \+49.! without # for callers not using the octothorpe)

Best regards from the north of Black Forest,


David

David,

Glad to be of assistance!

Regards,
Bill

HTH -Bill (b) http://ucguerrilla.com (t) @ucguerrilla

Please remember to rate helpful responses and identify