Sharing your Copilot notebooks - Is being rolled out

Microsoft is rolling a new update to Copilot Notebooks that make collaboration even easier: the ability to share Copilot Notebooks with your colleagues.  Personally, I like Notebooks because they feel almost like small, personal agents I don’t have to configure. They give me a safe space to collect notes and documents and then work on them over time. With this update, that personal space can become a shared space for a selected group of  colleagues, without compromising security or permissions. I think it is also important to note that your chat and chat history within the Notebook stays private. The web rollout began in late October and will finish by December, while mobile access starts in early November and are related to the Microsoft 365 Roadmap ( ID 506851 )  You can also read more about the Copilot Notebooks experience on the Microsoft website here . If you like this update and want to stay informed about similar improvements, feel free to follow me on LinkedIn!

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