cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
882
Views
15
Helpful
11
Replies

Translation Pattern Fax Question

EMcBride
Level 1
Level 1

I'm working with cucm 12.0.1

I have several cisco ata186 connected to fax machines

 

One of my translation numbers doesn't work with faxes but it does on our 7942 phones.

 

This number did work in the past on fax.  Last year.  

 

The settings for the Translation patterns, ata/phones, and directory number are all the same  

Our VoIP pri

 

I'm am at a loss as to why that one number will not work on our ATA.

1 Accepted Solution

Accepted Solutions

Not very easy still to follow the flow of the call. As mentioned before by me and @Nithin Eluvathingal the result BlockThisPattern Unallocated Number in DNA would indicate that the CSS of the device or the CSS used as outbound on the TP does not have visibility of the directory number, ie it does not see the partition where this is kept.

I would suggest that you trace down the flow of the none working and working calls on "paper" so that you can see the difference between them. It could look something like this.

Calling number 2002123 > Dev CSS "Internal" > Called number 666 > TP match 666 in PT "ShortNumbers", outbound CSS "Internal", number transform prefix 1001 > resulting called number 1001666 > DN 1001666 in PT "All_DNs" > device ATA name SEPaabbaabbaabb



Response Signature


View solution in original post

11 Replies 11

What you mean by not working, the call doesn’t land on fax machine ? 

or are you facing any problem receiving fax ?

If calls are not landing, 

do run a dna and see the call flow.



Response Signature


Sorry, we can send faxes out but we cant receive faxes off that number.   I also tested it with an old phone and while I got a dial tone I can't call it.

Also, all our faxes call out as our main outside line number, which is why I can send faxes out.  

 

 

So calls are not landing on your ata. 
Extension on ata is that   in a partition ? 
Run a dna and find the call flow it gives you more viability.



Response Signature


Yes for that number.  I put a different number on that ata and its working now.

 

DNA results for the bad number on the ata

  • Match Result = BlockThisPattern
  • Route Block Cause = Unallocated Number
  • Called Party Number =

I set the call party to 1000 and the dialed Digits to the problem Translation pattern number.

 

I tested it with a working number and those came back as

 

  • Match Result = RouteThisPattern
  • Matched Pattern Information
    • Pattern = ata extension #
    • Partition = CORRECT PATTERN 

But when i change that bad number to a phone i get

  • Match Result = RouteThisPattern
  • Matched Pattern Information
    • Pattern = Phone EXT#
    • Partition = CORRECT PATTERN 

 

Maybe it would be better if you actually share screenshots of the DNA output as it is quite hard to understand this based on the information given.

A BlockThisPattern Unallocated Number means that the CSS of the calling device and/or outbound CSS of the translation pattern used does not have visibility of the partition where the called number is put.



Response Signature


Here are some screenshots that I had to censor a bit

The first one is the bad number on the ata.  It doesn't work  (I get the operator message this party cant be reached)

The second one is the bad number on an IP phone.  it works

The last pic is another number from our translation pattern on the first ata.  it works

Sorry I can't show the numbers as they are phone numbers or some of the partition names

The blacked-out partitions are the same except for the one that is internal.

 

Bad number on ataBad number on ata

Bad number on phoneBad number on phoneGood Number on Same ataGood Number on Same ata

 

 

Not very easy still to follow the flow of the call. As mentioned before by me and @Nithin Eluvathingal the result BlockThisPattern Unallocated Number in DNA would indicate that the CSS of the device or the CSS used as outbound on the TP does not have visibility of the directory number, ie it does not see the partition where this is kept.

I would suggest that you trace down the flow of the none working and working calls on "paper" so that you can see the difference between them. It could look something like this.

Calling number 2002123 > Dev CSS "Internal" > Called number 666 > TP match 666 in PT "ShortNumbers", outbound CSS "Internal", number transform prefix 1001 > resulting called number 1001666 > DN 1001666 in PT "All_DNs" > device ATA name SEPaabbaabbaabb



Response Signature


Extenison1500 in partition  A and 1500 in partition B is two different number for CUCM.

 

Are you using same extension with same partition on ata and 7821 ?



Response Signature


Ok, it's fixed,  Thanks for the help and being patient with me, I'm still learning this system.  

 

I went back and looked at the ext number, and everything.  

I found that it would work when I changed the calling search space for that translation pattern.   

Looking into that calling search space I found that that extension number is also the calling pickup group number/selected call pickup group. I'm not sure if this would affect it or not.  

 

The fax has been down for quite a while and I was just made aware of it.  so I'm not sure what changed since the last time it was functioning. I did have to swap out an old ata which I just made a copy of in the cucm.

 

I have changed the extension number on the ATA and put it back in the correct partition.    

 

 

 

In general it is a bad practice to use the same number for different services. It’s a sure way to get into the type of issue you encountered.



Response Signature


The DNA clearly says that its an unallocated number and block the call. I assume that the number which is not working will be in a partition  Which translation CSS cannot reach.

 

 

 

 



Response Signature