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

Comments

  1. Hello Lasse,
    I am a Lync/Cisco voice implementer and constantly refer to your blog for is in-depth perspective on these integrations. Thanks for the resource and I do have a question:
    We have a Lync 2010 deployment. 2 mediations, 2 FE’s, single 3925 CUBE connected to a Verizon SIP trunk for PSTN. No CUCM. We have an issue where if a call comes from the PSTN, is answered in Lync, then put on hold, then resumed, in 8 out of 10 cases the call will resume but audio cannot be heard from the PSTN to the Lync client for up to 10 seconds. Then everything kicks in and is fine. During the “silent time” we see no SIP messages sent to the CUBE by Lync until the “kick in time” where we see Lync send a flurry of messages. We have a partner case open currently but they are asking about PRACK and MTP’s which is a little scary. I suspect we are having a delayed SDP issue but I can’t be sure. We have fiddled with the CUBE and Lync settings on both sides and can’t seem to get the right config in place. Any tips?

    ReplyDelete
  2. Hi,

    Ooo. A hard one without actuall access to the system. But I can give you a couple of thoughts:

    First up: Are you 100% sure you have disabled refer support on all dial-peers on CUBE, and on the trunk(s) in Lync Control Panel. I would say this configuration is the #1 cause of the error you describe.

    Second: Do you have a (or more) edge servers available in your deployment. I have sometimes found situations where associating the edge server with both FE and ME solves problems in applications and services using MCU. To me it could sound like one or another Lync component is trying to connect to something (not responding), and by the time it decides to do something, everything has timed out. (Providing an Edge as a relay point could help you out)

    Third (or maybe this should be first) You really should debug the sip messages in CUBE, and try to see if there are any SDP messages sendt, which are not supported by the trunk vendor.

    Unless told otherwise, CUBE will tell Lync all of it's capabilities (and even some the trunk provider will not support). Lync will answer happily, and CUBE will relay this to the provider, not knowing what the provider supports or not. I had a case regarding ringback tone, related to irregular SDP messages. And in the end, we had the provider tell us exactly what set of SDPs they could/would accept, and then configure this strict on the dial-peer toward Lync.

    Am I making any sense?

    ReplyDelete
  3. Thanks for the response Lasse,
    1. I currently have refer support enabled. when i disable on both sides, then any time I put a call on hold, the resume has delayed audio, making the issue worse. I am not using media bypass (which also seems to make things worse), so I believe I am OK to have refer support enabled.
    2. i am interested in your second point. how do you mean about associating the edge with both FE and ME? i do have some MCU errors in event viewer which I haven't been able to resolve yet.
    3. CUBE debug does not give much. during the problem, no SIP messages are received by cube during debug ccsip all, so I think the delay is on the Lync side.

    ReplyDelete
  4. Hi,
    How much delay are we talking about, with the sip refer turned off? IT should not be so. I mentioned this because some of the equipment and vendors I have been working with, does not support sip-refer. And in my opinion, a delayed setup is better than no setup.

    Both Frontend server and mediation server can connect to an edge server for media resources. I do not believe this is a requirement, but I have come across situations where a deployed edgeserver is necessary, even without an actual remote setup. There are certain applications which behave "better" when they all can use the edge server. It shouldn't be so, but in my experience it sometimes is. Which is why I asked if you have one deployed, and associated it.

    Talk to your vendor about supported SDP messages (or study the incoming ones from the PSTN). Make sure you set up CUBE to offer/replicate those SDP messages to the CUBE. If you do not adjust this. The CUBE will tell Lync a different setup than what is supported in the PSTN. And when Lync tries to send messages back to the PSTN, only CUBE understands what Lync is saying. but the PSTN does not.

    ReplyDelete
  5. Hello Lasse,
    Just a follow-up.we were able to get this fixed. Cisco TAC identified a bug in the software version that the CUBE was running. their notes below for anyone else hitting this.
    After some further deep dive I examined the RTCP traffic present in the call. What I found was that in both good and bad calls, the CUBE is sending a RTCP BYE right after it gets the Reinvite to reestablish media from Lync. I believe that the difference between good and bad calls is how Lync is handling this RTCP BYE. However that is a moot point because the CUBE should not send that. I was able to find a bug on this very issue. The DDTS number is CSCtr54269. The IOS you are running now is susceptible to this defect. The CUBE Is currently running 15.2(1)T. The fix for this defect is in 15.2(1)T1 or later versions of that train. From my analysis if you change the IOS of the CUBE to a version that has this defect fixed, then it should resolve the problem you are hitting.

    ReplyDelete
  6. Hello Lasse,
    Just a follow-up.we were able to get this fixed. Cisco TAC identified a bug in the software version that the CUBE was running. their notes below for anyone else hitting this.
    After some further deep dive I examined the RTCP traffic present in the call. What I found was that in both good and bad calls, the CUBE is sending a RTCP BYE right after it gets the Reinvite to reestablish media from Lync. I believe that the difference between good and bad calls is how Lync is handling this RTCP BYE. However that is a moot point because the CUBE should not send that. I was able to find a bug on this very issue. The DDTS number is CSCtr54269. The IOS you are running now is susceptible to this defect. The CUBE Is currently running 15.2(1)T. The fix for this defect is in 15.2(1)T1 or later versions of that train. From my analysis if you change the IOS of the CUBE to a version that has this defect fixed, then it should resolve the problem you are hitting.

    ReplyDelete
  7. Hello Lasse,
    Just a follow-up.we were able to get this fixed. Cisco TAC identified a bug in the software version that the CUBE was running. their notes below for anyone else hitting this.
    After some further deep dive I examined the RTCP traffic present in the call. What I found was that in both good and bad calls, the CUBE is sending a RTCP BYE right after it gets the Reinvite to reestablish media from Lync. I believe that the difference between good and bad calls is how Lync is handling this RTCP BYE. However that is a moot point because the CUBE should not send that. I was able to find a bug on this very issue. The DDTS number is CSCtr54269. The IOS you are running now is susceptible to this defect. The CUBE Is currently running 15.2(1)T. The fix for this defect is in 15.2(1)T1 or later versions of that train. From my analysis if you change the IOS of the CUBE to a version that has this defect fixed, then it should resolve the problem you are hitting.

    ReplyDelete
  8. Excellent posts!!! I breifly went over all your blogs and need to go back through them when I have more time. I appreciate the information.

    I have a scenario where a company has lync 2010 for IM capabilities. They have CUCM phones registered back to another companies CUCM cluster. The lync using company want to make lync the primary system for all thier phone requirements (PSTN, IM, VM, etc) while utilizing the exsting CUCM cluster as a backup if lync should fail. Also wanting to integrate lync with other companies CUPC clients. I know we would need some gateways on the PSTN aspect but what would you reccomend of you given scenarios and examples? Thank you in advance.

    ReplyDelete

Post a Comment

Comments on old posts will be moderated.
Comments on new posts will appear immediately..