Northwest Microsoft UC User Groups Portland, Seattle and Boise Upcoming June Meetings

Not going to TechEd, we got you covered! Come have more fun than a trip to Maui*

* Fun experienced during meeting may be less than trip to Maui

We are a forum for computer professionals in the Portland, Boise and Seattle areas who are interested in gaining and sharing knowledge in Microsoft Unified Communications technologies through networking and education.

The presentation starts around 11:00am. 

Come when you can, and leave when you must. (We are an informal groups)
Interested in joining our group - just attend a meeting!  That is it.  There is no fee to join just your enthusiastic participation is requested!

Agenda is as follows:

10:30am - 11:00am	Welcome
11:00am – 11:45am	Lync-specific network impacts Polycom Video interoperability
12:00pm – 12:30pm	Lunch
12:30pm- 1:30pm	Overview WAN and SIP trunk considerations Lync 2013 mobility capability and cost savings review
1:30pm – 2:00pm	UC discussions: Lync 2010, tips and tricks, challenges, solutions, Future meeting topics.

Seattle June 4th

Date: June 4th Time: 11:00 – 2:00pm

Location: Polycom Executive Briefing Center –Bellevue 411 108th Ave NE Suite 2100 Bellevue WA 98004

Seattle - Register Here

Boise June 4th

Date: June 4th Time: 11:00 – 2:00pm

Location: Microsoft Boise Office  401 West Front Street

Boise - Register Here

Portland June 6th

Date: June 6th Time: 11:00 – 2:00pm

Location: Microsoft 1414 NW Northrup St Suite 900 Portland OR 97209

Portland -Register Here

Come and take part in our Second User Group meetings of the year and catch up on what's happening with Lync 2013.

Hope to see you there.

VoIPNorm

Lync Server 2013 Call Park Retrieval Issues From CUCM 8.x

The last few days I have been helping out a peer do some troubleshooting around Lync Call Park. We managed to work out a few different issues that may arise when using the Lync Call Park Service with CUCM (Cisco Unified Communications Manager). I am glad to say that there are resolutions to these issues though. I was lucky enough to find these issues because of changes and configured items in my lab but all of them seemed relevant. Had my lab not been such a mess I may have not discovered they were issues. So, here's to having a lab in a mess, who says it doesn’t pay to be unorganized : )

Issue – Normalization and call routing

The Call Park orbit numbers are typically 3 or 4 digit numbers which is fine for normal call routing within the Lync environment but when dialing from a PBX or CUCM this may cause a issue with inbound normalization. Last thing you need is one of your inbound normalization rules to append + or other digit by accidently using the wrong normalization rule. Call orbit numbers can not utilize the + which means that they can not be in E.164 format. They can how ever use other prefixed digits like a * which is my preferred digit for this service.

Solution

Use the * prefix on your orbit numbers as shown below. Now this doesn’t mean that a user has to dial the star as you can normalize client side but it gives you a unique set of numbers that you can create inbound normalization rules for when your dialing from a external PBX.

Below I created a inbound normalization rule that adds the * digit to inbound calls from CUCM. So the CUCM user doesn’t have to dial the * they just need to know the 3 digit orbit number. Of course if that’s all to confusing you can just allow a normalization rule that passes the star coming inbound from CUCM as well. Adding the * in the normalization rule will require a customized rule. You can not add the * through the normal UI rules. You can use *$1 as the translation rule using the edit button on the UI page.

Issue – Lync Trunk to Trunk Call routing stops Call Park orbit lookup

With trunk to trunk call routing enabled (which is new in Lync 2013) external inbound calls to the call park orbit numbers will not be forwarded to the call park service. So basically if a person tries to retrieve a parked call from a CUCM (or other PBX) phone it will fail. Instead Lync will attempt to lookup possible route patterns after the usual reverse number lookup occurs. I am not sure the reason why call park orbit numbers are skipped over but this is the current behavior. In Snooper the call trace will show a 403 forbidden or a 404 not found depending on you call routing setup. The 403 occurs when you do not have a matching outbound route but have PSTN usage records applied to your trunk. The PSTN usage records applied to the trunk prevent the call orbit lookup.

A 404 may occur when the call does indeed have a matching route. The call is passed back to CUCM and it does not have a matching route, rejecting the call with a 404. In this case you may see traffic backwards and forwards between Lync and CUCM.

Solution

The most obvious solution here is to have a trunk that has no PSTN usage records applied to it as shown below. That may mean that if you require trunk to trunk routing that you may need to build a separate route to CUCM for the purposes of allowing inbound calls to the call park service. The good thing is that with Lync 2013 this is not all that complicated.

Issue – Refer Enabled

This issue is a little tricky. Even though the OIP page mentions refer is support for CUCM 8.5 and above it will cause issues with retrieving a call from the call park service from CUCM. The behavior is a little odd in that once a call is parked and you attempt to call into the service from a CUCM endpoint it seemingly makes a connection but then drops. The result is a 486 busy here.

Solution

Disable refer. It’s a simple fix but runs in the face of the OIP page which mentions that Refer is supported as of 8.5.

See below for the PowerShell and UI changes for turning off Refer to the CUCM trunk.

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

I noticed a few comments in various forums around accessing the Call Park service for the purposes of retrieving calls from external PBX’s. Hopefully this will help someone out. I did not find a single reference to these issues anywhere else on the web even though TechNet mentions that call retrieval is possible from a PBX. I am not sure if its because its not widely used or because these issues seldom occur but for what ever reason I thought it was important to document them.

VoIPNorm

Updated: 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

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

Device Review: Jabra UC Motion and Speak 510 MS

In my previous post I talked about the new offerings from Plantronics. Well it wasn't long before Jabra sent me their latest and greatest with the UC Motion and Speak 510. Between the two different offerings from each vendor there are some differences and depending on what you want I am sure there is a solution available for what you need. I am not going to compare the sets of devices from the different vendors here. I really like products from both vendors and they have both come a long way in the last couple of years with some great offerings.

Jabra UC Motion

Jabra’s new Bluetooth headset has a lot going for it. It really is packaged great and although the travel case is a bit bulky in your pocket it is sturdy and will protect your investment. In my book a sturdy case is a good thing because my laptop bag gets thrown around while traveling. I also think that the case is a good size to add more features to in the future like a battery backup charge. What impresses me even more though is how they put the inside of the case together to be a complete place to store everything and also act as a stand.

 

The ear piece is well put together. I have found it pretty comfortable and the fact that closing the boom turns the device off is smart. The only thing I have issue with is the volume slider. Its kind of odd and although it works just fine I do find it a little difficult to adjust the volume with at times. The dongle for plugging into the PC is, well a dongle:) I do like the LED indicators to show your on a call and its probably one of the smallest I have seen.

I like this device a lot and have used it with Lync and my cell phone and both have worked great. I believe this is their best headset yet across all headset classes and competes well with Plantronics similar offerings. Nice job Jabra.

Jabra Speak 510 MS

I do and always have had a preference for the Jabra Speak 410. The Speak 410 was a great device and I think what Jabra did to improve on this device was smart and appropriate. The Speak 510 MS adds a nice Bluetooth capability but still kept the ability to use the USB cable connection as a way to utilize the device and not just as a charging port. Good choice in my opinion.

The 510 is going to be the device to beat in this category. For a small compact speaker phone I have used it in meeting rooms that can seat 16 people successfully. Although microphone extensions would be handy, its such a great device that in most circumstances they really are not required.

I have used the Bluetooth option paired to my cell phone and with Lync on an iPad and both worked flawlessly. It really is a leading class device that keeps getting better. This is one device that I cant say anything negative about. I carry one with me everywhere I go.

Overall Jabra has done a great job on these devices and in my opinion their build quality and comfort for the wireless headset has improved considerably over previous offerings. I am looking forward to what they can do to keep improving these already impressive products.

VoIPNorm