Celebrating 10 Years as a Microsoft MVP!

Back from my vacation, I am thrilled to share that I have been awarded the Microsoft Most Valuable Professional (MVP) award for the 10th consecutive year. In addition to being recognized as an expert within Teams, I am have also been recognized as an expert with Microsoft Copilot. This means a lot to me.  Being an MVP has been an incredibly rewarding journey, both personally and professionally. It has provided me with countless opportunities to grow, learn, and connect with like-minded professionals who share a passion for technology and innovation.  The award is not just a title; it's a testament to the hard work, dedication, and contributions to the tech community. It's a privilege to be part of such an esteemed group of individuals who share the same love for technology, and sharing their knowledge about it.  As I reflect on the past decade, I am thankful for the experiences and knowledge I've gained. This recognition motivates me to continue sharing my expertise, mentor

Lync in coexistence with CUCM part 5

I think it's time to take on just one more way to have your Lync server coexist with your CUCM installation. This time, the goal is not to integrate it in any way, but simply connect a sip trunk to a CUBE (Cisco Unified Border Element) as a stand alone PBX, side-by-side CUCM.

In this scenario, you should have a separate number range (identifiable by a mask on the CUBE dial-peer) on your Lync server. It could be a part of your CUCM range, but you should isolate a range for CUCM ony, and a range for Lync only (the configuration example will clarify).

Microsoft has released a great document on the CiscoISR-CUCM-LYNC setup, but it doesn't cover the things written in this post (I think).

I won't spend much time on the Lync configuration. You can either read the Microsoft documentation or take a look on my post on Lync and CUCM to get a grasp of things. The settings I have set on the Lync side are these: Disable refer support, Disable encryption, enabled media bypass (Your choice really. Cisco ISR supports both, but have in mind all clients need full reach-ability to the Cisco ISR ip address for media bypass to work.

Now: to the Cisco router, and what needs to be done (This should work on most gateways licensed for ip-ip voice).

First of all, you need to enter the global voice configuration to set your router up for sip-to-sip communication. You may choose other protocols to the CUCM and or PSTN, but this is a simple setup to explain how easy it really is. I've also entered a few more commands to control the SIP traffic on the CUBE.
You might notice a few fax and modem commands here, they could just as easily be entered under each and every dial-peer if you don't want to enter them globally.

The bind commands are here to control which interface sip binds to. If your router has several interfaces, sip might not always originate (source ip) from the desired interface unless these commands are typed. If the source ip is wrong, the call will fail.


Next, I like to set up global codec selections and global sip-profiles. The codec selection is a list of available codecs. The sip-profiles is a list sip commands alternations from the default behavior. You do not necessarily need these sip-profiles, but in my lab I need them to adapt to the PSTN vendor I am using (Ask your PSTN vendor about this). The sip-header manipulation in this example was made to prevent a session teardown after 25-30 minutes into a call. My vendor's SBC and the Cisco ISR had different ways of sending "keep alive".

You will call upon the codec selection and sip-profiles from the dial-peers.


I also like to control how the sip-ua handles retries and it's timers.


With the configuration above, we're ready to create dial-peers on the Cisco router. I am going to show just three dial-peers, you might need more based on your number ranges here and there.
First off is the dial-peer to PSTN (A SIP trunk provider).
Here's a quick walk-through of some of the configuration:
Description: I use this as a documentation, so others may quickly identify it's purpose.
Destination pattern: I've made a really simple "default route, matching any E.164 number beginning with a + sign.
RTP: Some vendors have specific ways they expect fax tones or dtmf signalling to behave. Mine expects the settings in this dial-peer.
Session protocol: Should be explanatory enough.
Session target: Ip address of the other side of the trunk.
Voice-class codec: This is where we are calling upon the "voice class codec above".
My vendor expects the sip early-offer, and it has to be forced.
DTMF-relay is set to be rtp-nte (and nte was set to 96 in a previous line)
A few fax commands to ensure fax calls go through with supported values.
Finally, we tell the dial-peer to use the header manipulation defined in the sip-profile 2.


Next I have the dial-peer to the CUCM. It's very similar to the one above, with a few exceptions:
Destination pattern is set to match any number within the range of +4712340000 - +4712349999.
We do not want the early offer sent to CUCM in our deployment.
And we want the sip-profile 1 instead of sip-profile 2.


Finally, the dial-peer to the Lync mediation server. Please pay attention to the following important lines:
"no vad" - silence suppression is not supported
"no supplementary-service sip refer" - Refer support is not supported, and will cause call transfer to fail within Lync (and/or to unified messaging).

You might also notice the number ranges listed here are within the range defined on CUCM. As these are more specific, this dial-peer will take precedence. Just to explain the mask, i have routed +4712342XXX, +4712345XXX and +4712347XXX to the Lync mediation server.


This configuration should work on most Cisco routers. There is one flaw with the configuration above however. With only outgoing dial-peers you do not have control over incoming call legs. On older routers, Cisco would select a "deafault dial-peer", but on newer routers you must have a separate, configured dial-peer. I would always recommend you configure at least one incoming dial-peer, but in this scenario we treat the inside and the outside differently with different sip-profiles. My suggestions for incoming dial-peers are as these:

To handle incoming from PSTN, we create a dial-peer almost identical to the outgoing one, with the exception of removing destination pattern with incoming called-number.


And finally, we create one for handling the incoming part on the internal side:


This should cover all the routing basics you need to get your Cisco ISR and Lync and or any other SIP PBX up and running side by side with separate number ranges.

See the other posts for more information on CUCM and Lync