RPAD - DMA dial rule issues

[Anonymous]

I have some problems to configure the DMA to resolve adresses like. name@example.com from a system registered to the DMA. The example.com domain is not registered with h323cs in dns and i guess that the DMA does not search for h323ls in dns for this lookup, then the call fails. (Same issue with VBP) Therefore i should make a rule that send the call to another SBC when @example.com is present in the dial string. It is working with prefixes, but as the h323 names have different beginning that is difficult. I am calling H323, not SIP. Anyone that knows how to make a dial rule in the DMA to solve this?

Another issue is doing dial string maipulation on incom ing calls. When dialing into the RPAD from a system not registered on it I cant dial directly into the meeting room on the RMX, I come to the entry que. Tried 8881001@ip and 1001@ip where 888 is prefix for RMX and 1001 for meeting room. Any ideas how to solve it?

[Anonymous]

I have the same problem. The problem also exists when trying to dial from outside to virtual meeting rooms behind the DMA Conference Manager. Any hints on the required dial rules?

[Anonymous]

I'm having a similar sounding problem. I have several external HDX and LifeSize endpoints that are SIP registered. When I schedule a pooled meeting from my resource manager, dial out fails. I can perform an endpoint to endpoint connection using their SIP URI. I had support on the phone for 5 hours the other day and they reported it was a bug. Appears the SIP registration isn't getting passed to the RPAD, or something. They've passed it on up the food chain, so hopefully it gets fixed soon.

Is that the same issue you're having?

[simons3]

V,

You wrote of having two issues.

Issue 1 #: Someone recently asked me how to do this. The obvious answer was to fix DNS so it would respond correctly. If this is not an option, then you can add a script to the Dial external networks by H.323 URL, Email ID or SIP URI dial rule as below:

DIAL_STRING = DIAL_STRING.replace(/<some_other_domain>/,"140.242.22.51");

<some_other_domain> = the offending DNS name

Of course if the DNS name changes the ip address, this will need to be manually updated in the script to work again.

Issue 2#: Depending on how you have your RPAD H323 & SIP page configured will determine if this works or not. Your note did not include if this was SIP or H323. But in either case, the results should be the same with the exception you can extend this functionality to H323 if needed. By design, we want to be as secure as possible. Therefore, the RPAD was designed to block Guests dialing into your organization and specifically limit them to only 3 unauthorized dial rules. If you look on your DMA under dial rules, you should notice some space near the top. This is for the Guest users dialing into your VTC. By design, they have access to Confernce VMRs, Virtual Entry Queues, and SIP Peers via these dial rules.

So in your example, you are trying to dial the RMX directly via alias which the above 3 dial rules for the DMA do not apply. This is needed so Guests don't dial the alias of your CEO's endpoint for example. The process is that the unauthorized user would call SIP/H323, and the RPAD knows this is a guest user and adds a prefix, 88 for example, to the beginning of the call string. The call gets forwarded to the DMA. The DMA will see the 88 prefix and remove the prefix and route using the unauthorized dial rules.

Again you did not mention if you were dialing via guest or as a registered user. If you are a registered user, then there should not be any dialing in restrictions placed on your call. We would have to look at specific call flow logs to determine the cause of failure if this is the case.

I hope this helps,

S.