02-09-2010 09:04 AM - edited 03-18-2019 11:04 AM
Hi all,
I am hoping that this may well be something really obvious that I have missed but here goes.
One of our customers has an established centralised Multi-site CUCM v6.1(3) solution with 1 x Publisher & 1 x subscriber.
The Core site has a 2811 ISR configured for H.323.
The Telco is sending in 4 digits inbound and these are mapped to 4 digit internal extensions.
the DDI numbers are 60XX & 92XX.
There are no called translation rules or profiles to amend digits being sent to the CUCM cluster.
There are ordered voip dial-peers pointing with destination patterns of 6... & 9... with IPV4 session targets of the subscriber IP address & then second choice the Publisher (reflecting the Call-manager group configured on CUCM using the Subscriber as the call processing agent).
They have generated CDRs from yesterday after they had some weird calls coming inbound to a specific number, however the called number was not a DDI number.
The called number was 6216.
I have checked the CDRs and the number 6216 is found in the "originalCalledPartyNumber" column (which according to the documentation also can be the resulting number at the end of any translations). I have checked the translation patterns and nothing matches this. The source IP address is the local voice gateway and destination IP, the IP Phone.
If there was a DDI extension with a CFA set to 6216 the "originalCalledPartyNumber" would reflect this DDI & then the "finalCalledPartyNumber" would reflect 6216.
Definitions as per the guide
originalCalledPartyNumber - This number designates the originally called party, after any digit translations have occurred.
FinalCalledPartyNumber - For forwarded calls, this number designates the last party to receive the call. For non-forwarded calls, this field shows the original called
party.
I have tried to call the full external DDI number + this internal extension (whilst monitoring debug isdn q.931 on the voice gateway) externally and it definitely does not arrive at the gateway
They have had a malicious caller withholding his number for a while now (they believe using an autodialer). The end user using 6216 stated that when these calls were happening, the call came in and then 6216 got connected to someone else on cluster. Weird again but I don't actually see this on the CDRs.
Has anyone ever heard of anything like this where someone can get directly connected to a number that is non-DDI? I tested an inbound call from the gateway using the csim start command and viewed it on CDRs, but as the call doesn't connect no destination IP address appears in the CDRs (think I was off track with this but I was wondering if the gateway had been compromised).
thanks in advance for any ideas,
Stuart
02-09-2010 09:54 AM
One option is to pull the CallManager Trace Files for the time period that the call came in, probably 2 minutes on either side to be sure. Then load those trace files into the Voice Log Translator within RTMT. VLT is a plug-in that you have to download from Cisco, but it is free and worth its weight in gold (which isn't saying much since it's software and it's weight is just that of a few trillion electrons, but I hope you get the idea). The VLT will recontruct the Q.931 setup messages that the H.323 VG sent to the CUCM, so you can see what digits were received from the PSTN.
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