Device Review: Cisco DX650 - The Desk phone just got a lot smarter

When I first come across the DX650 it wasn’t clear to me what the use case was and I was more interested in the list price which as everyone points out no body pays anyway. While working for Microsoft I was heavily focused on their own ecosystem of products that getting time to evaluate a Android device just wasn’t at the top of my priority list (and maybe frowned upon somewhat:). Although other desk phone manufactures are using Android as a phone OS it’s a locked down version that somewhat obscures Androids real capabilities. The DX650 has the capabilities to lockdown the user to only the preloaded app’s but the part of power of any Android device is the Google Play Store. Which I will cover more a little later.

I am not going to chant through all the technical details of this device as there are quite a few. Below is the main product video which is about an hour long run through of the entire device which is much nicer than me writing about it here. Look out for David Scott, he really knows his stuff on the DX650. David is a product manager at Cisco so he gives some great insight into the product and its configuration inside CUCM.

DX650 on TechWiseTV

Also here are some links to some more tech spec which should cover the deeper technical questions.

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps12956/ps12959/solution_overview_c22-726842.html

http://www.cisco.com/en/US/prod/collateral/voicesw/ps6788/phones/ps12956/ps12959/solution_overview_c22-726841_ps12956_Product_Solution_Overview.html

My view

I have been using the DX650 for a few weeks now. It’s a interesting product with some compelling use cases. Probably the most interesting of which is remote worker/telecommuter and VDI access. There are others like remote video enabled contact center agent but that’s an entire post all on its own.

Remote worker

I have been a telecommuter/remote worker for a good part of 7-8 years now. At Microsoft and now Cisco I have never been allocated desk space and my previous employer before either of those mentioned I telecommuted at least one day a week. Seattle traffic sucks btw. So having a solid work at home solution for communications is very beneficial. A PC/MAC with soft client although good short term for longer term home worker there are better solutions. Obviously a highly mobile worker at their desk less than 25% of their time is not going to benefit as much as say a knowledge/contact center worker.

I have tried a host of solutions over the years from PC with soft client to personal telepresence video solutions and now the DX650. While those other solutions have their place the DX650 seems to be better suited to someone like me that needs a communications solution but my company may not be willing to spend large amounts of dollars on something more high end like an EX90/EX60.

One thing I noticed and this might just be me but even now working at Cisco, if the remote device only does voice it doesn’t get used and I go back to a soft client which has more functionality. So in other words if the device doesn’t have integrated contacts, calendar integration, video etc., it turns into a dust collector. The only time I used a voice only device is if someone calls and my MAC wasn’t up and my cell phone was MIA. So to me a well integrated desktop device is way more functional and therefore more likely to get used than just a normal desktop phone (in my opinion). I have found using WebEx on the DX650 is the new audio conference for this device. 

There are a few things that make the DX650 so compelling in this situation:

• Easy access to video
• Secure always on connection with VPN if required
• Integrated WebEx and Jabber
• Access to the Google Play store to add additional functionality

There are others like Wifi, Bluetooth etc but the ones above really stick out. Below is the DX650 with a personalized wallpaper image. I am actually using a Logitech USB headset with it but this could be a Bluetooth device just as easy. This is the logon screen which requires a pin to unlock. It gives me a quick view of event, voicemail etc without having to unlock the device.

Below is my customized start screen, I have added a RDP client from the Google Play Store and placed a calendar widget on my start screen. No Angry Birds as yet! This is a screenshot btw. When I first started writing this post I was taking photos of the screen before it dawned on me that there must be away to take screenshot. Of course there is with Android ICS. Volume down button and lock button pressed simultaneously dummy.

You will also notice a WebEx app. This was way more capable than I first thought it would be. You can do most things from generating the invitation, to starting and hosting the meeting from the DX650. Below is a photo of a screen sharing session with my home PC.

So if I happen to be on my MAC working jumping on a WebEx no longer ties up my MAC to keep the content front and center. This is an issue with always using a MAC/PC to attend virtual meetings because once you switch off of the content its pretty easy to loose focus or have an issue finding the right window again.

Below is the contacts which can be imported from a variety of places but you'll notice that some are showing presence being imported from Jabber.

Finally calendar integration.

So really well integrated communications platform, much more akin to a smartphone but with a better quality user experience for voice and video. I even loaded Twitter!

Remote desktop/VDI Experience

Let me first give a bit of a description of my setup. I have MAC running VMware Fusion that is running a Windows desktop. I wanted to test out RDP running from the DX650 so I loaded a free RDP client from the Google Play Store on the DX650 than launched a RDP session to the virtual desktop. I also have a Bluetooth Keyboard paired with the DX650 because typing on screen just didn’t make sense for this.

Below is the logon screen during the RDP session:

Logged into the RDP session and running Jabber. Not that this is it real use case but basically this is way to run any legacy Windows app just add your flavor of VDI into the mix such as VMware or Citrix.

During my RDP testing I only added a keyboard and used the on screen touch to drive the interface but a mouse could be added as well as using a dual display. Having a communications device that can produce high quality voice and video as well as run a VDI session overcomes one of the biggest limitations to VDI. Real time media within the VDI session. Although there are plugins there is always some limitation around the underlying OS or the quality isn't great depending on the hardware, it just seems as though removing the media from the VDI is a more sensible approach.

Obviously this removes the need for another device to run the VDI session and having a separate communications device.

The Power is in the Apps

As I pointed out earlier part of the power of this device is in the apps delivered through the Google Play Store. I was able to create an RDP session just with a simple app download. So this makes for a powerful communications device. If I just look at my device I can access Twitter, Google Hangouts, Enterprise HD Video & Voice, Webex, email (Exchange and Google), calendar, VDI, RDP etc etc all with the use of apps. Some are DX650 specific and others are typical downloads from the Play Store. So making the desktop phone relevant again for various use cases but also a communication hub for the user.

Hell, if Samsung wants to put a internet connection in a fridge we should expect more from communications devices. Taking advantage of the established Google Play Store makes a lot of sense to provide a richer experience for the user.

Does it run Lync?

No it doesn’t. Mainly because Microsoft controls which hardware and software Lync can load onto that they have tested. It can however run a number of other UC clients that run on Android.

Conclusion

The DX650 is not your ordinary desktop replacement. Thinking that you would replace every users phone with a DX650 probably isn't going to happen at most organizations but with the right use case it may make sense versus the cost. This is an intelligent device that takes communications to a new level. Everyone seems fixed on using a tablet for everything that maybe this device can do but like I mentioned in a tweet, no one wants to see nose cam every time you make a video call especially in the contact center. I also haven't ventured into CEBP and how Android apps combined with the device could really skyrocket use cases like telemedicine (should be renamed to collabhealth) but I will leave that for another day.

VoIPNorm

Switching from PC to MAC and from Microsoft to Cisco

As some of you may have noticed I have had a recent lull in activity both here on VoIPNorm and on Twitter. I was going through somewhat of a techie rebirth. I know that sounds a little hippie but it is the best way I could think to describe it. Let’s put it this way for a least a while my head was spinning and I wasn’t sure if it was just going to pop off with all the gyrations. With all the head spinning though when I informally announced my move to Cisco on LinkedIn through a profile update I got lots of questions and congrats. I know I haven't responded to everyone directly but hopefully this blog post will help do that.

Switching from PC to MAC 

Out of all the things I have done in my career this was one of the most frustrating weeks of my life but its not all that it seems. After 14 years or so of working on a Windows machine, I was switching my work PC to a MAC in my first week at a new job at a new company. This is not something I would recommend to everyone but in the end a lot of my frustration was mainly self inflicted by not asking for help.

This is what I have learnt about the MAC. Microsoft Office on the MAC or more to the point Outlook is no where even close to the Windows version. PowerPoint and Word are just fine for what I need but I really don’t like Outlook. The Windows version is better but it’s a Microsoft product on a Apple platform so I can’t say that I am all that surprised. So I am in search of a better mail client I just don’t know what that is yet. The native client has been suggested to me but I am going to do some digging before I make a change.

OneNote which I used heavily previously is not available on the MAC. I really like OneNote so I was bummed there was no MAC version, but a great alternative is Evernote. It is a little less organized in its layout compared to OneNote but I like the way it syncs across my MAC and other devices without needing to put anything on SkyDrive. I noticed some folks running a Windows VM on the MAC but that just didn’t seem attractive to me. I would rather find alternative applications if needed.

My last frustration came down to my lack of MAC knowledge which was the track pad. Two finger tap is a right mouse click dummy. It took a coworker to help me solve that puzzle. If I had just asked for help earlier!

In the end it was a combination of a lack of MAC knowledge and finding substitutes for applications causing most of my frustration, most of which I have remediated. Overall though I am impressed with the stability and usability of the MAC. I have had to reboot for updates once or twice but that’s been it, the MAC is super stable. Obviously MAC presents less hardware choices which leads to a more stable platform but the design of the MAC hardware is pretty impressive.

So I am sticking with my MAC and marching forward. Everyday gets a little easier for this 14 year PC veteran.

Switching from Microsoft to Cisco

Of course this probably came as a huge surprise to a lot of people and something at one stage I may have never considered but change is good. There are a lot of similarities but also a lot of differences between the two companies. This was never “its greener on the other side of the fence” type situation but something I looked on as a personal growth opportunity.

Lync presents a great software solution but as anyone in the industry knows it takes more than great software to build a communications solution. Cisco offered me a chance to get a better insight into an end to end solution that is unrivaled in the industry for completeness of vision. I will be the first to admit that both companies face unique challenges in todays UC market. This makes for an exciting transition with moving to Cisco and seeing the challenges from both sides now.

In my opinion there is nothing more challenging than understanding a completely different perspective than the one you have today. It has certainly opened my eyes to a whole new way to look at UC which  only serves to benefit the companies I am trying to help succeed with Cisco UC. I really did enjoy my 4 years at Microsoft but am looking forward to new success at Cisco.

VoIPNorm

Updated: CUCM SIP URI Dialing to Lync 2013–New SIP URI Normalization rules on CUCM

I created the original post for this configuration back in July of last year and its seen quite a bit of traffic and had some great comments. I just thought with the release of Lync 2013 and some new interesting developments it would be worth adding new info and refreshing some of the content to better speak to Lync 2013.

I have recently added community fixes to issues that have arisen so this post is certainly worth a revisit when I make updates. Please continue to comment and make suggestions. I know quite a few companies are now using this configuration based on this blog post so keep the info and questions coming and I will keep updating.

What's this post all about?

I have seen quite a bit of using Cisco’s mobility feature to dual ring a Cisco phone and Lync. There is an interesting feature in CUCM that could make your life easier. Its called SIP URI dialing. This isn't a new feature as its been around since 7.x days or possibly earlier. It sparked my interest back in 2008 but I never really investigated it further until 2012.

SIP URI dialing is really a pretty basic concept. Instead of using a normal DID route pattern to designate a destination you use a SIP URI such as lyncuser1@contoso.com. By specifying @contoso.com as your SIP route you assign a SIP trunk that points to Lync. Its actually pretty simple and works with Cisco’s mobility feature used in Remote Destination Profiles.

There are some caveats with this feature though and its not terribly flexible. It does require some special configuration but could possibly make dial plans and  interoperability a little easier. Also you can remove the issue of requiring unique DID’s on both systems because now that your ringing between systems with a unique SIP URI using the same DID on both systems is much less problematic. So users don’t have to change numbers or use a new number for Lync, it can be the same as their Cisco IP phone.

To make things a little easier to understand, in this post I am referencing the To field in a SIP message when I am talking about Tel URI or SIP URI. I am using Tel or SIP to define trunk routing behavior even though both are configured as SIP trunks when configured in CUCM. Its just the routing behavior based on the address format I am trying to better define. Hope that’s not to confusing.

Why use it?

While working in the field I get a lot of questions from engineers around how do I make my Cisco phone and Lync ring at the same time. As I have covered here on my blog there are a couple of ways to do this from either CUCM, Lync or even potentially from a gateway. But there is a level complexity in regards to how to configure DID’s and how to make DID’s unique enough so that you can route between the two platforms. Well using SIP URI dialing instead of DID’s this simplifies this portion of the configuration and leaves Lync’s Sim Ring feature open for users to configure it for their cell phones. Using Sim Ring as the tool to ring a Cisco desk phone in my opinion is a waste of an easy to configure end user setting. I strongly believe this feature is better used to ring a cell phone or other devices self administered by the user.

The interface for configuring Cisco Remote Destination Profiles is potentially very intimidating for normal users. There are settings and timers that if set incorrectly can cause issues. That’s why in my opinion RDP’s should be configured by an administrator and Sim Ring on Lync is a better choice for self service by the average user. There is only one timer and phone number fields can be prepopulated making the users phone number selection easy. Also Sim Ring has the ability to use the business hours set in Outlook where as Cisco’s RDP requires this to be recreated under the RDP profile. If your using RDP’s for more than just ringing Lync this might be handy.

From a self service point of view Lync allows the user to set Sim Ring and Business hours which are inherent in Outlook straight from within Lync. Timers for voicemail forwarding are available but other timers are system controlled and not exposed to users removing the potential to create issues. Sim Ring can also be changed by the user from all the mobile apps.

RDP’s although not overly end user friendly can be used in different ways to help integrate Lync into your preexisting environment. It can ring up to 5 endpoints. RDP could also be used as way to keep voicemail in a different voicemail messaging platform other than Exchange UM for Lync users but still allow a user to have Lync as a softphone. This might be important for companies that do want voicemail in email for compliance reasons etc. So RDP has some great uses for working around common issues.

Caveats for SIP URI dialing?

The single biggest caveat for SIP URI dialing is that when you create a SIP Route pattern in CUCM it does not allow assigning a route group to it. You have to directly assign a trunk to the route pattern. The main issue is that once assigned to the SIP route pattern you can no longer assign the same trunk to a route group which limits your options. The best way to deal with this is to have a SIP trunk just for SIP URI routing. In CUCM 8.6 you can have multiple endpoints (in our case mediation servers) assigned within a SIP trunk which means that this isn't a redundancy problem. Its more a configuration issue on the CUCM side but since this configuration is for a specific purpose I don’t consider this a show stopper.

With Lync 2013 this trunk can now have its own port within the Lync trunk configuration. This means we can create a trunk with its own rules on either system. It really doesn’t mean that its simpler but certainly more configurable from a call control point of view.

How to set it up?

The easiest way to do the setup is to follow this guide with a few alteration which I will call out below. This is the Microsoft produced guide. In the Microsoft guide they make use of Calling Search Spaces (CSS) which gives a more complete picture of the settings required. In the Cisco guide there is no call authorization setup so unless you know which CSS to configure you could easily miss a setting as there are multiple places to set CSS on various pages. The one that caught me out was the rerouting CSS on the Remote Destination Profile.

What's needed for Lync?

The SIP URI trunk is for inbound use only. This means that setup on the Lync is pretty simple if you already have a SIP trunk setup for your CUCM deployment. As long as your CUCM servers are already added to the topology as gateways you are already done. Just make sure that the inbound SIP URI trunk to Lync is using already established ports.

In Lync Server 2013 we can take the configuration a little further than 2010. We can define individual trunks for each dialing type. Like I said earlier this doesn’t make it simpler to configure but it can make the configuration clearer to understand. Now we have two well define trunks to the same gateway and we can name it accordingly so we have a clear understanding of the configuration.

If creating two trunks in Lync 2013 the individual trunks are identified by the inbound port on the gateway side of the configuration (in our case CUCM).

The trunk configuration is then completed in the Lync Control Panel or PowerShell. Below are a couple of screen shots for the configuration I completed in my lab but for more complete details on setting up a SIP trunk to CUCM refer to this document http://www.microsoft.com/en-us/download/details.aspx?displaylang=en&id=26800. Although this document refers to Lync 2010 a lot of the same rules apply to 2013. Also keep in mind there are variances in the exact setup according to the version of CUCM you are using. In my example lab REFER is support by CUCM 8.6 so I left it as enabled but other versions this will differ. Use this link to match your CUCM version setting requirements http://technet.microsoft.com/en-us/lync/gg131938.aspx.

Trunk settings for encryption, enable media bypass and REFER for CUCM 8.6.

The last time I posted this info Alex Lewis asked the question about “You say the DID can be the same in Cisco and in Lync but if I'm in Lync and dial another user then only their Lync endpoint will ring.” Well thanks to an Anonymous tipster I believe that we have somewhat of a solution to this. There is an attribute that can be added to the users Tel URI that will stop Lync from doing the usual RNL behavior. This means that any call to the users extension can be routed to CUCM regardless of whether its configured in Lync as the user line URI while allowing the RDP in CUCM to ring the Lync client. Now this is by no means a perfect solution. There is potential hair pinning of calls through Lync to CUCM and back to Lync. While this has the potential to consume some extra resources its not going to be life threatening in most cases. Its just a matter of planning for it and understanding call flows in your environment.

What you potentially end up with is a Line URI that looks like this:

tel:+12345678;ext=5479;ms-skip-rnl

The ms-skip-rnl is what will cause Lync to pass the call directly out to CUCM rather than follow normal reverse number look up behavior for calls to be routed to users. This attribute is actually used else where in the product for certain functions such as CAC and RCC so its not a total mystery of its existence but this is not its normal use.

Lastly I just want to mention, use this configuration at your own risk. This is not the usual configuration that one would follow in setting up Lync. When calling in a support ticket this attribute may be required to be removed if you are having issues. As my friend and college Doug wrote to me in an email exchange “The mechanism that it leverages will probably remain in the product forever but, if they called support, the engineer would probably go, “huh?”. I think you get the idea now.

How do I configure CUCM?

In my testing I was using CUCM 8.6 so your settings may vary depending on the version you have.

SIP Trunk

The thing with this configuration is that you are creating a SIP trunk for one purpose and that is to ship messages with headers that have the “to” field with a SIP URI format to Lync. So LyncUser1@contoso.com as an example.

Your Tel URI and SIP URI SIP trunks can share the same SIP Security Profile and outbound ports to Lync but you will need to use different DNS/SRV names or IP address DNS name combinations. So as an example:

SIP URI Trunk – FQDN – 2013-lync-fe.contoso.com

Tel URI SIP Trunk – IP Address 192.168.0.170

Below is my trunk configuration for my SIP URI routing with a FQDN for my Lync 2013 Mediation Server.

SIP Profile for calling out a specific listening port:

In my case I used a IP address on one trunk for Tel URI calling and the FQDN on the SIP URI trunk. Now if you are not that fixed on configuring route groups and route lists for the SIP trunk connecting to Lync you can configure the trunk directly on both DID and SIP URI route patterns and just have one trunk. I tried both in my lab and it worked either way.

In this 2013 update I changed around my configuration somewhat to route to separate trunks that have separate port numbers as well. Like I said earlier this give the ability to create more control at either end of the trunk on either Lync or CUCM.

Update: SIP Normalization Rules

I received quite a few emails and comments from people that ran across an issue. If your Lync deployment was larger than a single pool the port specified in the SIP invite from CUCM would cause calls to fail. If you user wasn’t part of the pool associated with the mediation server receiving the invite from CUCM redirecting the invite to the correct pool would fail. The error message generated indicated a port issue.

LogType: diagnostic
Severity: warning
Text: Message was discarded by the application
Result-Code: 0xc3ee7964 ES_E_REQUESTURI_VALIDATION_FAILED
SIP-Start-Line: INVITE sip:firstname.lastname@contoso.com:5060 SIP/2.0
SIP-Call-ID: a5c03a60-e790-4490-9e02-75baf13b8250
SIP-CSeq: 51567 INVITE
Data: application="http://www.microsoft.com/LCS/UserServices"
$$end_record

Seems Lync didn’t like the header with port 5060 being part of it when passed to another pool. The exact reason why it doesn’t like it I am not sure why but this was the issue identified.

This really stumped me. I wasn’t quite sure how to work around it but luckily a reader supplied the answer. CUCM has the ability to create normalization scripts to fix header issues like this. This is somewhat similar to MSPL scripts in Lync which many of you are probably familiar with but uses an open source scripting language called Lua http://www.lua.org/docs.html. Here is a similar example I also found that replaces IP address with a domain name.

Creating the Script: Device>Devices Settings>SIP Normalization Script

Add new-

Paste in the follow contents, name the script and save::

M = {}
function M.outbound_INVITE(msg)
local method, ruri, ver = msg:getRequestLine()
local uri = string.gsub(ruri, "5060", "5061")
msg:setRequestUri(uri)
end
return M

Finally apply the script to your CUCM SIP trunk for SIP URI dialing.

SIP Route

Probably the new piece of configuration to most people will be the SIP route itself. Its pretty easy to configure. See below. I created a domain route to contoso.com to route my SIP URI traffic that I setup for my users on their Remote Destinations.

User Setup

As far as the user setup goes the only variation between the standard setup mentioned in the guide I referenced earlier is to configure the user with a SIP address to route calls in the Destination Number under Remote Destination configuration. In my case I used garthf@contoso.com as my destination number rather than a DID or other number.

This configuration is probably one of the most important interoperability pieces I have written in a while. I can see this alleviating quite a few issue I have come across in the field and hopefully this article will get good circulation so more people know about it. If I look over all the possible ways to do interoperability between Lync and CUCM (RCC, Plugins etc, etc) this really does give the best of both worlds without sacrificing one for the other unlike other methods like plugins which ruin the Lync UI experience. There are some complexities for the initial setup but at the end of the day your using the features available of both products without the use of third parties or additional servers. Call it the biggest bang for your buck if you will.

If folks need more explanation please feel free to post your questions.

VoIPNorm

Updated Again: Important Settings to Know When Integrating Lync Server 2010/2013 with Cisco ISR’s

This is an update to an update to a previous post with new ring back information. By far one of the most referenced posts I have done to date on interoperability with Cisco. I have come across a number of important settings that are a must know for this interoperability scenario. One thing to keep in mind is that while Cisco ISR’s are a supported gateway they do only provide basic functionalities. Behaviors for basic gateways can differ from that of an enhanced gateway. Support for SIP Refer is a good example.

Some of the information below has been taken from other posts on topics concerning this interoperability situation.

By far the most common issue with Lync to a Cisco ISR is ringback. With later releases of the Cisco IOS a lot of these issues have been addressed. Read on below to find out how.

How do I set comfort noise on the ISR for interoperability with Lync?

There are two ways to configure comfort noise on the gateway. First off you can disable Voice Activity Detection all together on the outbound dial peer. The second option is to change the payload type for comfort noise to the compatible format. It’s pretty common for people to turn VAD off by default so some people may not have realized this issues existed. Previous Cisco documentation for OCS R2 has VAD enabled which it is by default so people migrating to Lync hoping to take advantage of media bypass might be caught out.

Option 1

dial-peer voice 1999 voip
tone ringback alert-no-PI
description TO Lync
destination-pattern 55555
session protocol sipv2
session target ipv4:192.168.1.250:5068
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
fax protocol none
no vad

Option 2

dial-peer voice 1999 voip
tone ringback alert-no-PI
description TO Lync
destination-pattern 55555
session protocol sipv2
session target ipv4:192.168.1.250:5068
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
fax protocol none
rtp payload-type comfort-noise 13

How do I configure for ringback issues?

There is some really good info around on ringback issues with both CUCM and ISRs on both my own blog and others. But seeing as this is just a ISR post I am going to just focus on that for now.

For PRACK issues disable rel1xxx

voice service voip
sip
rel1xx disable

Ringback with or without 183 SDP?

The first option presented is typically the normal way to ignore session progress 183 coming from Lync. This will cause the gateway to ignore 183 messages and signal the caller system to play local ringback rather than create a early media session with Lync. Lync does not provide early media for remote ringing.

dial-peer voice 1999 voip
description TO Lync
voice-class sip block 183 sdp present
destination-pattern 55555
session protocol sipv2
session target ipv4:192.168.1.250:5068
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
fax protocol none
rtp payload-type comfort-noise 13

Here is a big “well” you might also want to try the following if you get limited ringback or just one ringback and the sdp present command doesn’t solve your issues. CCME in particular this command seems to work better as the 183 messages do not have SDP information coming from Lync because the initial invite from CCME does have SDP information. So there may be some variation depending on SDP initiation. A simple “debug ccsip message” on the router should point you in the right direction on which command to use.

dial-peer voice 1999 voip
description TO Lync
voice-class sip block 183 sdp absent
destination-pattern 55555
session protocol sipv2
session target ipv4:192.168.1.250:5068
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
fax protocol none
rtp payload-type comfort-noise 13

Update. I have another consideration and a new twist. What if you have a call forwarded back to the PSTN with no ringback. The below command should help solve that issue

dial-peer voice 1999 voip
description TO Lync
voice-class sip block 181 sdp absent
voice-class sip block 183 sdp absent
destination-pattern 55555
session protocol sipv2
session target ipv4:192.168.1.250:5068
session transport tcp
dtmf-relay rtp-nte
codec g711ulaw
fax protocol none
rtp payload-type comfort-noise 13

Similar to a 183 message a 181 message coming from Lync will not have SDP information. This command may solve this issue of forwarded calls not having ringback seeing as Lync wont generate ringback for remote endpoints.

SIP/2.0 181 Call Is Being Forwarded
FROM: "Norman, Christopher"<sip:+12065555555@10.10.10.46>;tag=3846A278-5CC
TO: <sip:12065555556@10.10.10.58>;epid=E9EAEE5866;tag=d9ed9a43f5
CSEQ: 101 INVITE
CALL-ID: 64096B15-29C211DD-840A9822-A319A9A1@130.42.18.46
VIA: SIP/2.0/TCP 10.10.10.46:5060;branch=z9hG4bK9721D8
CONTENT-LENGTH: 0
SERVER: RTCC/3.0.0.0 MediationServer

Update: It’s a new day and a new ringback scenario. What if you have H.323 configured on a gateway to CUCM and CUCM has a SIP trunk to Lync. All inbound calls from the PSTN to Lync come in through your H323 gateway and CUCM. Although calls from CUCM to Lync receive ringback calls inbound from the PSTN do not. Below are two viable solutions that I have seen used. This info is straight from Cisco so I have reprinted here as is with links.

Complete one of these solutions:

1. Configure the progress_ind setup enable 3 Cisco IOS command under the voice dial-peer # VoIP configuration in the Cisco gateway/router.

   This command forces the gateway/router to treat the inbound ISDN Setup message as if it came in with a PI equal to 3 and to generate an in-band ringback tone towards the calling party if the H.225 Alert message does not contain a PI of 1, 2 or 8.

   Refer to Cisco IOS Voice, Video, and Fax Command Reference, Release 12.2 for more information on this command.

   Note: The progress_ind alert and the progress_ind setup commands are hidden in some versions of Cisco IOS Software and are not visible within the help parser. However, if the progress_ind progress command is available in the help parser, these commands are also available and are entered into the dial peer in their entirety. These commands subsequently appear in the running configuration.

2. An alternate to the progress_ind setup command is the dial-peer voice # voip subcommand tone ringback alert-no-pi .

   This causes the gateway to generate ringback towards the calling party if an alert is received on the IP call leg with no PI present. It differs from the progress_ind setup command in that the outbound H.225 setup message does not contain a PI of 3 with the tone ringback command. It is possible that some devices do not accept setup messages when a PI is included.

How do I disable SIP refer on a Cisco Router and in Lync for Media Bypass?

Cisco Router configuration to disable SIP refer -

Router(config)#voice service voip
Router(conf-voi-serv)#no supplementary-service sip refer

There are two options to disable SIP refer in Lync the first is through the Lync Control Panel and the second is in PowerShell. In this case disabling Refer in PowerShell is probably the easiest since you will need to do a few other things while you are there.

Disable Refer in Lync Control Panel:

Disable Refer in PowerShell:

Set-CsTrunkConfiguration –Idenity <Xds Identity> -EnableReferSupport $false

To find your trunk identity:

Get-CsTrunkConfiguration

Below is a screen shot of the full command parameters.

How do I disable RTCP and session timers in Lync?

Disabling RTCP and its timers are required for similar reasons as they were in OCS R2. I wrote a blog article outlining the reasons for disabling RTCP and session timers for OCS R2 a while ago and while the product has changed into Lync the reasons for disabling both of these are still the same.

http://voipnorm.blogspot.com/2010/07/kb-article-981218-rtcp-timer-confusion.html

Disabling both of these will remove 30 minute call drops due to RTCP incompatibilities between the two platforms. I am not going to go into a whole RFC thing of who’s right and wrong so just know this is something you have to do otherwise you will run into call drop issues.

Below is a screen shot of what the trunk will look like when you run the Get-CsTrunkConfiguration command before you change the required settings. By default both session timers and RTCP are enabled.

Below shows disabling the required settings:

The full command is:

Set-CsTrunkConfiguration –Identity <see example> -EnableSessionTimer $false –RTCPActiveCalls $false –RTCPCallsOnHold $false

Hopefully this will save someone from having to call support to set up this configuration.

VoIPNorm