Create an account on the HP Community to personalize your profile and ask a question
12-04-2020 02:46 PM
We have integrated our GroupSeries endpoints with Zoom's OAuth Office365 calendar service, essentially One Touch Dial. There is an entry on the GS touch panel and screen for joining a Zoom meeting and if we schedule a room resource, it adds that the calendar of the appropriate endpoint.
We are using H.323 with Zoom and still register our endpoints to our DMA (9.x). However, the format that Zoom uses for the H.323 calls is the conference/ID@domain format which seems to hang up at the DMA.
0**XXXXXXXXXXemail@example.com is a sample (partially blocked out). When we have an endpoint NOT registered to our DMA, the call goes through to Zoom.
When registered to our DMA, we can direct dial Zoom at the Zoom IP (then enter meeting ID, etc) and we have an SBC on the DMA, with a 99 prefix sending 99[ZoomMeetingID] will route to the same IP. That works and has been working.
On the DMA, the eth0 setup seems fine - proper DNS, etc. And obviously the DMA sends the endpoints to the Zoom IP if directly dialed. However that @ format of the dial string seems to die at the DMA. Dial rule test shows that the 'domain' @22.214.171.124 is controlled by the DMA.
#5: Dial external networks by H.323 URL, Email ID or SIP URI: Domain is controlled by DMA: 126.96.36.199
On the DMA, the call details show the DMA attempting to resolve the address as an 'EMAIL_ID' and then reporting 'UNRESOLVABLE_ADDRESS'.
I have tried a couple things including editing the Dial External Networks dial rule (disabled, removed 323 URL or Email ID, etc), I have also added a hard route on eth0 to send the Zoom IP to the primary gateway on the DMA. Watching traffic on the RPAD, that call doesn't get out of the DMA.
Any ideas? It seems that the DMA doesn't like that @ format for H.323 and whatever Zoom is looking for, it seems to work if the Group Series are unregistered to any GK service - if they just dial out and skip the DMA. I don't see anything at the RMX either, so I don't think the call routes there and dies.
We do have Embedded DNS setup on the DMA, from our initial setup - the server subdomain is 'video.local'. I have tried toggling this, but doesn't seem to have any effect.
I have also played around with dialing Zoom at IP##providedDialstring - thinking I could do a script on the DMA to reconstitute the dial string to something that works, it seems that Zoom really wants that meeting@domain format. I also scripted the removal of the numeric IP and swapped in sj.zoomcrc.com (which is the reverse lookup of that IP) - thinking that maybe it would get through the DMA, but no luck.
Is there a way to make this work?
12-07-2020 03:52 PM
Your reply here https://community.polycom.com/t5/Management-Security-and-Rich/DMA-dial-rule-issue/m-p/71047#M2408 seems what I am looking at - but I am not fully understanding your response.
Is there a way to designate a domain or IP address/range as NOT local to the DMA?
12-08-2020 01:27 PM
This isn't a solution to (what I think) is DNS setup issues on our DMA that I am not quite understanding. When you use Zoom's OTD service, the entries on the Group Series from Zoom (ad-hoc, calendar scheduled meeting, etc) are in the XXXXXXXXXX@ZoomIP format, for H.323 calling.
I noticed that on the Zoom-side of the Group Series config that you can turn on a mode where the Group Series receives the OTD dial info with just the numeric portion, XXXXXXXXXX and it excludes the @ZoomIP portion. You can also add a prefix, so in our case 99 on the DMA redirects to Zoom's IP as an SBC, but strips the 99 prefix. So now the calls from the OTD/ad-hoc service from Zoom connect correctly.