<font><font face="verdana,sans-serif">thanks Ryan much appreciated</font></font><div><font><font face="verdana,sans-serif"><br></font></font><br><div class="gmail_quote">On Mon, Jun 25, 2012 at 11:18 PM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Inline..<div><br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div>
-Ryan</div></span>
</div><div class="im">
<br><div><div></div></div><blockquote type="cite"><div><div>On Jun 22, 2012, at 7:02 PM, Daniel wrote:</div><br><font><font face="verdana,sans-serif"><div><font><font face="verdana,sans-serif">Thanks for the reply Ryan,</font></font></div>
<div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">The reason for "<a href="mailto:dan@test.com" target="_blank">dan@test.com</a>" on both systems is that if I was called from CUCM, Expressway, or Control that all my devices would ring, people would just ring that one URI. Maybe I should use SNR on CUCM and Findme on VCS to achieve this. Have different endpoint names but still have the same FQDN.</font></font></div>
</font></font></div></blockquote><div><br></div></div><div>This is how we do it today on the alpha cluster I'm using but we don't have URIs configured in UCM yet.  I have a remote destination for <a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a> on my main phone that routes to a VCS (via sip route pattern) and my video endpoint there will ring. </div>
<div class="im"><br><blockquote type="cite"><div><font><font face="verdana,sans-serif">
<div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">My other question is that if both systems are using "@<a href="http://test.com/" target="_blank">test.com</a>" when a call comes from a CUCM endpoint to a VCS endpoint if the URI "<a href="mailto:dan@test.com" target="_blank">dan@test.com</a>" doesn't exist on CUCM will it use the catch all "@<a href="http://test.com/" target="_blank">test.com</a>" SIP route pattern to route the call to VCS? Same thing for VCS to CUCM would it use the search patterns so that any "@<a href="http://test.com/" target="_blank">test.com</a>" calls with the endpoint that don't exist go to CUCM?</font></font></div>
</font></font></div></blockquote><div><br></div></div><div>Most users dialing from UCM endpoints will still be dialing DNs.  Full user@domain URIs will most likely get routed via call history (if present) or by desktop apps in deskphone mode.   I haven't tested overlapping domains on UCM but I would expect the behavior you describe with the sip route pattern picking up for any calls to URIs that don't exist locally.</div>
<div class="im"><br><blockquote type="cite"><div><font><font face="verdana,sans-serif">
<div><font><font face="verdana,sans-serif"><br></font></font></div><div><font><font face="verdana,sans-serif">Next question about registration and DNS SRVs, is CUCM 9+ going to change the way endpoints register at all? What if both CUCM and VCS utilise SIP DNS SRV to register the endpoints? You would not be able to use the same FQDN then would you? Or is it as simple as using another subdomain. CUCM would have an SRV of "_sip._<a href="http://tcp.cucm.test.com/" target="_blank">tcp.cucm.test.com</a>" and VCS would have "_sip._<a href="http://tcp.vcs.test.com/" target="_blank">tcp.vcs.test.com</a>" for registering endpoints?</font></font></div>
</font></font></div></blockquote><div><br></div></div><div>Phone registration won't change (Cisco phones still use option 150 and register via DN).   I'm not familiar enough with the Tandberg endpoints to recommend a solution regarding the SRV records.  I think you'll want to look closely at feature parity between native UCM registration and keeping them on the VCS and go from there.  A subdomain very likely could reduce the complexity.</div>
<div><div class="h5"><br><blockquote type="cite"><div><font><font face="verdana,sans-serif">
<div><font><font face="verdana,sans-serif"><br></font></font></div><br></font></font><br><div class="gmail_quote">On Sat, Jun 23, 2012 at 12:17 AM, Ryan Ratliff <span dir="ltr"><<a href="mailto:rratliff@cisco.com" target="_blank">rratliff@cisco.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">I'll defer to the 9.0 SRND when it's out but I believe you will be ok with the same domain on both.  Expressway can send incoming calls to both VCS and UCM.  On UCM 9.0 the service that takes care of sharing URI information among clusters is ILS.  VCS can't talk directly to ILS yet but ILS does support importing data from VCS so that UCM will know exactly which URIs should route to VCS.  What this doesn't help with is shared URIs on both VCS and UCM.   Is there a reason you'd have <a href="mailto:dan@test.com" target="_blank">dan@test.com</a> in both systems? <div>

<br><div> <br><div>
<span style="text-indent:0px;letter-spacing:normal;font-variant:normal;text-align:auto;font-style:normal;font-weight:normal;line-height:normal;border-collapse:separate;text-transform:none;font-size:medium;white-space:normal;font-family:Helvetica;word-spacing:0px"><div>

-Ryan</div></span>
</div>
<br><div><div><div><div>On Jun 22, 2012, at 7:54 AM, Daniel wrote:</div><br><p>Hi All,</p><p>There’s a lot of acronyms in that subject!!</p><p>We’re currently looking at integrating VCS into our CUCM and H323 Tandberg environment to migrate our VC/Tandberg/Telepresence gear to SIP and enable external IP video conferences.</p>
<p>We're on CUCM 8.5 with the new VCS being VCS-C 7.1 we will have VCS-E also.</p><p>My question is on the strategy for our domain name and what to use for DNS SRV and URI Dialling.<br>When we upgrade to CUCM 9.0 and have URI dialling within CUCM do the domain names need to be different on CUCM and VCS?</p>
<p>How will it work, how will the call route if I'm <a href="mailto:dan@test.com" target="_blank">dan@test.com</a> on CUCM and VCS.?<br>Does it need to be <a href="mailto:dan@test.com" target="_blank">dan@test.com</a> on CUCM and <a href="mailto:dan@video.test.com" target="_blank">dan@video.test.com</a> on VCS?<br>


This would be eaiser with a SIP route pattern of "@<a href="http://video.test.com/" target="_blank">video.test.com</a>" to VCS etc... <br>External DNS (VC calls form the internet) would then be transformed from "@<a href="http://test.com/" target="_blank">test.com</a>" to "@<a href="http://video.test.com/" target="_blank">video.test.com</a>" on the VCS<br>


Calls from VCS to CUCM would use DNS SRV, zones, and search rules pattern matching @<a href="http://test.com/" target="_blank">test.com</a> to be sent to CUCM. CUCM would be configured with a cluster wide FQDN as "<a href="http://test.com/" target="_blank">test.com</a>"</p>
<p>Right now its <a href="mailto:1234@%3CCUCM" target="_blank">1234@<CUCM</a> IP> on CUCM and <a href="mailto:dan@test.com" target="_blank">dan@test.com</a> (@<a href="http://test.com/" target="_blank">test.com</a> external also) on VCS which is very simple.</p>
<p>I think I understand how it works for registration but not for call routing.</p><p>I just want to make sure we configure the correct domain name now so we don't have to change it in the future when upgrading to CUCM 9+.</p>
<p>Does anyone have any experience with this?</p><p>thanks</p><p>Dan</p><div> <br></div></div></div>
_______________________________________________<br>cisco-voip mailing list<br><a href="mailto:cisco-voip@puck.nether.net" target="_blank">cisco-voip@puck.nether.net</a><br><a href="https://puck.nether.net/mailman/listinfo/cisco-voip" target="_blank">https://puck.nether.net/mailman/listinfo/cisco-voip</a><br>

</div><br></div></div></div></blockquote></div><br>
</div><br></blockquote></div></div></div></div></blockquote></div><br></div>