Monthly Archives: September 2015

Good to Know: Explaining Exchange UM Diversion Header Preference

What’s the Issue?

Here’s another one that I’ve personally fought a few times with clients that use Exchange 2007, 2010, or 2013 Unified Messaging with Avaya, Cisco or other PBX systems.  We’ve also seen it come up a few times on TechNet.  After bouncing around within voicemail, calls don’t end up where we might expect them too.  An example call flow is as follows:

  1. A call comes into an Exchange UM Automated Attendant.
  2. The caller presses a key to be transferred to User A.
  3. User A doesn’t answer.

The question is: when User A doesn’t answer, what do you expect to hear?  Do you expect to go back to the Automated Attendant or do you expect to hear User A’s voicemail?  With Microsoft Exchange, you’ll go back to the Automated Attendant, while many used to other more traditional voicemail systems are expecting to hear User A’s voicemail.   Why is this?   Simply, it’s diversion headers.

What’s a Diversion Header?

If you’re not familiar with diversion headers within your SIP packets, they’re defined a bit in RFC 5806. In a nutshell they’re used to signal a change to the ultimate endpoint that will receive a call.  We see these used heavily in voicemail systems.  When a call is routed to voicemail, the SIP INVITE is sent to the voicemail subscriber access or dial plan number with a diversion header specifying the phone number that corresponds to the mailbox.  To see this, let’s say a call comes in from the phone number 555-555-5555 to a user with phone number 888-888-8888, the Exchange dial plan has the phone number 88895 assigned.   The SIP INVITE would look like the following:

 INVITE sip:88895@10.19.10.21;user=phone SIP/2.0 
 Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac214495832;alias
 Max-Forwards: 70
 From: <sip:555555555@10.19.10.131>;tag=1c213481216
 To: <sip:88895@10.19.10.21;user=phone>
 Call-ID: 213439323315201145819@10.19.10.131
 CSeq: 1 INVITE
 Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
 Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
 Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
 Diversion: <tel:8888888888>;reason=no-answer;counter=1;screen=no;privacy=off
 User-Agent: Mediant 1000/v.6.60A.030.010
 Content-Type: application/sdp
 Content-Length: 231
 v=0
 o=AudiocodesGW 212414200 212414170 IN IP4 10.19.10.131
 s=Phone-Call
 c=IN IP4 10.19.10.131
 t=0 0
 m=audio 8330 RTP/AVP 0 101
 a=ptime:20
 a=sendrecv
 a=rtpmap:0 PCMU/8000
 a=rtpmap:101 telephone-event/8000
 a=fmtp:101 0-15

The issue comes in when the call bounces around and the diversion headers stack up.  Let’s look at another invite.  This time, a call comes in from the phone number 555-555-5555 to an automated attendant with phone number 666-666-6666, the Exchange automated attendant has the phone number 88895 assigned.  The caller hits a key and the call is transferred to a user with the phone number 777-777-7777.  The 7777 number doesn’t answer and is sent back in toward Unified Messaging.  The INVITE coming back in now looks like this:

INVITE sip:88895@10.19.10.21;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.19.10.131:5060;branch=z9hG4bKac1145709558;alias
Max-Forwards: 70
From: <sip:555555555@10.19.10.131>;tag=1c1145125933
To: <sip:88895@10.19.10.21;user=phone>
Call-ID: 1145084972315201145825@10.19.10.131
CSeq: 1 INVITE
Contact: <sip:555555555@10.19.10.131:5060;transport=tcp>
Supported: em,100rel,timer,replaces,path,resource-priority,sdp-anat
Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE
Diversion: <tel:7777777777>;reason=no-answer;counter=1;screen=no;privacy=off
Diversion: <tel:6666666666>;reason=unknown;counter=1;screen=no;privacy=off
User-Agent: Mediant 1000/v.6.60A.030.010
Content-Type: application/sdp
Content-Length: 233
v=0
o=AudiocodesGW 1143825135 1143825105 IN IP4 10.19.10.131
s=Phone-Call
c=IN IP4 10.19.10.131
t=0 0
m=audio 6990 RTP/AVP 0 101
a=ptime:20
a=sendrecv
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15

Exchange sees the last diversion header and sends it right back to the Automated Attendant listening on 666-666-6666 and we’re back in the menu.  The telephony team may have instead preferred that Exchange looks at the first diversion header and transfer to the 777-777-7777 user’s voicemail.

How Do You Change It?

Within Exchange, there is no method to alter this.  With most session border controllers or IP gateways, such as Sonus, AudioCodes, etc, you do have options.  Some of these come in the form of checkboxes, sometimes you’re working with SIP message manipulations.   Armed with this understanding and your own SIP trace files, you should be able to work with your gateway or PBX vendor to find a solution.  I have intentionally left instructions to manipulate the SIP messages in various systems out of the article as a misstep can cause disaster for a production systems, please work with your vendor for more specific help.

 

Create your Skype QoS Settings with PowerShell

For those out there using Group Policy on your Lync or Skype for Business servers to configure QoS, I wanted to make sure you’re aware of a method to set your QoS markings via quick and easy PowerShell commands using Net-NewQoSPolicy.  This PowerShell command is available in Windows Server 2012 R2 and up, which you’ll see most new deployments using, and Windows 8.1 and up, which isn’t always rolled out completely in an organization.

Elan Shudnow created his authoritative QoS blogs a while back, which I live by and we will be referencing today.  The 2013 versions are here:

Because I highly recommend the reading of these articles, and I reference them regularly myself, we will be using the same ports the Elan uses in his articles within our PowerShell commands.  Specifically, that means using the following non-default ranges:

  • Modifying application sharing from the default range of 49152-65535, which overlaps with audio and video ports, to the more unique range 40803-49151.
  • Modifying client ports from the default of any high port 1024-65535 to the following:
    • Client Audio Ports: 20000-20039
    • Client Video Ports: 20040-20079
    • Client App Sharing Ports: 20080-20119
    • Client File Transfer Ports: 20120-20159
    • Client Media Ports: 20160-20199

To set these values, the following two commands should be run from the Lync or Skype for Business Management Shell:

Set-CsConferenceServer -Identity <Front End Pool FQDN> -AppSharingPortStart 40803 -AppSharingPortCount 8348

Set-CsConferencingConfiguration -ClientAudioPort 20000 -ClientAudioPortRange 40 -ClientVideoPort 20040 -ClientVideoPortRange 40 -ClientAppSharingPort 20080 -ClientAppSharingPortRange 40 -ClientFileTransferPort 20120 -ClientFileTransferPortRange 40 -ClientMediaPort 20160 -ClientMediaPortRange 40

Also, we’re going to set our DSCP markings using the following tags:

  • Audio = DSCP 46 (EF)
  • Video = DSCP 34 (AF41)
  • All Else = No tag, best effort

Now, on to the fun part, setting our DSCP values via PowerShell.   On each Front End server, run the following commands:

New-NetQosPolicy -Name “Skype Conferencing Audio” -IPProtocol Both -IPSrcPortStart 49152 -IPSrcPortEnd 57500 -DSCPValue 46

New-NetQosPolicy -Name “Skype Conferencing Video” -IPProtocol Both -IPSrcPortStart 57501 -IPSrcPortEnd 65535 -DSCPValue 34

SkypeConf

On a Mediation Server, we’re only concerned with audio traffic and we can pin it down to the Mediation service specifically.

New-NetQosPolicy -Name “Skype Mediation” -AppPathName “MediationServerSvc.exe” -IPProtocol Both -IPSrcPortStart 49152 -IPSrcPortEnd 57500 -DSCPValue 46

SkypeMed

Quick and easy, no MMC or policy!  Drop it in with your prerequisites.  If you have many many servers, an AD level group policy may still save you time however, so use your own judgement.

If you have a mix of operating systems in the environment, I would still suggest using group policy for these as only Windows 8.1 and up support this command.  However, if you do happen to have a PowerShell workstation provisioning script, here are the commands you would need and a screenshot of them being executed on Windows 10:

New-NetQosPolicy -Name “Skype Client Audio” -AppPathName “lync.exe” -IPProtocol Both -IPSrcPortStart 20000 -IPSrcPortEnd 20039 -DSCPValue 46

New-NetQosPolicy -Name “Skype Client Video” -AppPathName “lync.exe” -IPProtocol Both -IPSrcPortStart 20040 -IPSrcPortEnd 20079 -DSCPValue 34

SkypeClient

 

One final note before I leave you, if you receive an “New-NetQosPolicy : Access to a CIM resource was not available to the client.” error, make sure you’re running your PowerShell as administrator, we are making a machine-wide change after all.