tag:blogger.com,1999:blog-2158853543793456735.post5311535303611664401..comments2023-10-02T04:50:01.667-07:00Comments on VoIPNorm's Collaboration Blog: Updated: CUCM SIP URI Dialing to Lync 2013–Adding Cisco Expressway for VideoChris Normanhttp://www.blogger.com/profile/07200178774058910421noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-2158853543793456735.post-52395915021452925832014-10-10T08:42:31.049-07:002014-10-10T08:42:31.049-07:00Did you apply the normalization script on the SIP ...Did you apply the normalization script on the SIP trunk to Lync? Sounds like the multiple pool issue that this solves.Chris Normanhttps://www.blogger.com/profile/07200178774058910421noreply@blogger.comtag:blogger.com,1999:blog-2158853543793456735.post-72395594951613179852014-10-08T14:23:39.701-07:002014-10-08T14:23:39.701-07:00Norm. Thanks for the info. Hey, wanted to share a...Norm. Thanks for the info. Hey, wanted to share an experience that we had. We just migrated to Lync 2013, and were in coexistence. We were using the mobility (or, sipurl dial, whatever) to solution the CUCM DID call simultaneous ring to Lync. The @sipuri on the CUCM side was pointing the call over to the Lync 2010 FE server and that was working. What I found out, and maybe this is known - but when I migrated a user over to Lync 2013 - that sip forward started failing (when I moved the user back to the 2010 registrar, it started working again.) So, for some reason I figured that Lync would proxy that call from the 2010FE over to the 2013FE and figure out a way to complete the call. But, it didn't. Maybe somebody could explain why ... but, anyways - we changed the CUCM side to point over to the 2013 FE's and now the solution is working again as expected. (just, obviously not on a user still on 2010 registrar). So, an FYI gotcha during coexistence. Anonymoushttps://www.blogger.com/profile/16561724531458923477noreply@blogger.com