09-26-2012 09:34 AM - edited 03-16-2019 01:24 PM
Hi All, I have a really strnage case,
I have severam branch office's partitions, and all of these partitions are in a Calling Search Space named "intracuster". When I try to make a Call telling the phone we have that partition, the phone does not find the DN and the call report fast busy tone.
nonetheless, I have an alternate routing to those partitions by our Gatekeeper, When I delete the Translation Patter, the call itself go through the GK configuration and return again to the call manager and actually it can make the call sucessfully.
I am starting to thinking, the call manager does not permit hops beetween several tranlations patterns. Or the call manager does not know they have that DN on the that publisher.
Here is an image of the configuration that doesnt works. (fast busy)
Here an image of the configuration that WORKS! I just deleted the translation pattern of "808652XXX"
It takes our gatekeeper.
Also, If I try to change de phone to other subscriber it marks me "rejected" on the call Manager status.
¿Could you please help me with this?
Regards.
Solved! Go to Solution.
11-05-2012 09:12 AM
Hi Juan,
I just came across this post. Glad to see that the issue got resolved!
Please take a look at the blog and video I posted on dbreplication runtimestate:
Please feel free to provide your feedback and any additional questions you may have on this topic.
Thanks,
Harmit.
09-26-2012 10:01 AM
Also I have this error on the Data base reportin too.
09-26-2012 10:33 AM
Here is my TFTP configuration Options on the publisher.
09-26-2012 10:01 AM
What is the CSS on the xlation pattern set to?
Can the CSS on the xlation pattern call the xlated number?
Please rate all useful posts
"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson
10-04-2012 04:03 PM
Hi, aokanlawon
Every route CSS, partition, devicepool, DNA, route plan report, name, IP, is Fine
11-02-2012 09:05 AM
We solved this!
This was cause a failure in a Data Base replication, on one subscriber, but, it was not reflected on the database sumary status on the RTMT not the CLI. So we open a TAC and a Database Specialist found the problem and fixed it. We asked for a Full Deep Database examination.
You can verify this by entering those commando on the Publisher CLI.
1.- utils dbreplication runtimestate
2.- utils dbreplication status
Please use "file view activelog cm/trace/dbl/sdi/ReplicationStatus.2012_10_09_10_52_25.out "
3.- file view activelog cm/trace/dbl/sdi/ReplicationStatus.2012_10_09_10_52_25.out
On our case, the file viewed had like 17 000 lines of error of database.
So after the help of the TAC assitant it was reduced to 8 lines indicationg everything is ok.
After that, no strage problems were reported.
Reggards.
11-05-2012 09:12 AM
Hi Juan,
I just came across this post. Glad to see that the issue got resolved!
Please take a look at the blog and video I posted on dbreplication runtimestate:
Please feel free to provide your feedback and any additional questions you may have on this topic.
Thanks,
Harmit.
11-09-2012 06:37 AM
Thanks Harmsing,
Very helpful,
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