RSS Subscription 168 Posts and 2,769 Comments

Lync 2010 Enterprise Voice DID vs Non-DID Users

General Information

With Lync 2010, there are a couple ways to handle non-DID users.  Our company uses both Lync 2010 for Enterprise Voice as well as Nortel CS1000 for other users.  Our Nortel CS1000 is configured so when you send it  improperly formatted Caller ID, it will send it out to the PSTN with the main DID number of our officelocation.  In Lync 2010, you can have users that are Enterprise Voice enabled but do not have a DID.  That are some disadvantages to not having a TEL URI such as the inability to set a Conferencing PIN when logging into your Dial-In Conferencing Web Page.

An important thing to understand is when a user is dialing out to the PSTN Gateway Object in Lync 2010, there is a SIP Invite Message that gets sent out to the Gateway.  The SIP Invite Message will be constructed differently depending on whether a user has a DID specified in the TEL URI or whether that TEL URI is blank.  Let’s take a look at how both messages are constructed.

SIP Invite Messages

User with DID:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Shudnow, Elan”<sip:+13129998888@collocatedFEMediation.internalAD.domain.com;user=phone>;epid=AA4B5C1773;tag=d73f8df627
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

User without DID:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Test, Elan”<sip:etest@internalAD.domain.com>;epid=AA4B5C1773;tag=d17641157b
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

As can be seen, the big change between the user with the DID and without the DID is that the FROM field for a DID user displays the user’s E.164 formatted DID that is defined in the TEL URI whereas the user without the DID has their SIP Address defined instead of a DID.  This means that, even if a user does not have a DID defined in the TEL URI but is still enabled for Enterprise Voice, their phone call requests will still go out to the gateway.

What to do?

Well, in Lync 2010, there are two options:

  1. Configure our gateway to handle the user’s that have their Caller ID (Calling ID) in the form of a SIP Address instead of a telephone number and send it out to the PBX.  As stated earlier, our PBX will see this and change it to the main office DID. This solution requires you to configure your PBX to do this as well as your gateway to take the SIP Address into consideration from a Caller ID (Calling ID) perspective.
  2. Configure a new Voice Policy, Phone Usages, and Voice Routes that utilize the new Supress Caller ID feature to rewrite Caller ID for any user that is utilizing those routes.  Hence the need for new routes that have new phone usages assigned to the as well as a new voice policy that uses those phone usages.  You will then take this new voice policy and assign it to all non-did users.

For each option, there are some pros and cons.  As has been stated, Option #1 requires configuration on the PBX and the Gateway.  Option #2 has more configuration required on Lync itself and if you ever assign a non-DID user a DID, this user would need to be moved to the Lync Voice Policy that does not supress Caller ID.

Option #1 Configuration (Modify PBX/Gateway)

I will show how to configure the Voice Gateway (in this case, a NET UX2000 gateway) but not the PBX.

When taking a look at the Translation rules on our NET UX, you can see how we are handling E.164 calls coming in from Lync and sending it off to our Nortel.  We have a Called Address/Number (how the TO: field is specified in the SIP Invite from Lync) and a Calling Address/Number (how the FROM: field is specified in the SIP Invite from Lync).  In our translation rule, Lync is sending the TO: in E.164 format so the NET takes anything with the + and 11 digits, strips the +, and sends just the 11 digits to our Nortel. For the Calling Address Number, we take anything that has + as the starting digit, and sends the Caller ID information to our Nortel without the +.  Because of this, the Nortel will retain the original Caller ID and all is well.

But, what about non-DID users?  How can we configure our UX2000 to translate anything with Caller ID as a SIP Address and pass it off unchanged to the Nortel so it can rewrite it with the main office’s DID?  Well, it’s easy.  We just have to create an entirely new Translation rule since we can’t have more than one Calling * specified in a given Translation Rule.

As we can see in our new Translation Rule, we didn’t modify the Called Address/Number.  This stays the same because the TO: field doesn’t change between a DID and a non-DID user as can be seen above in the SIP Invite Messages section.  What does change between the DID and Non-DID user is the FROM: field.  Because of this, we need to change the Calling field.  In this Translation Rule, instead of choosing Calling Address/Number, we change the gateway to utilize Calling Numbering Type.  We choose H.323 ID or SIP as the Input Field Value.  For the Output to Nortel, we still specify Calling Numbering Type and choose the value as Unknown.  Now anything the gateway has a FROM: field specified as a SIP Address instead of a DID formatted in E.164, it’ll send it off as is to the Nortel which will then change the Caller ID to the office’s main DID number.

Option #2 Configuration (Lync Caller ID Supression)

What if Option #1 won’t work for you?  Your gateway guy doesn’t want to do it, your PBX guy doesn’t want to do it, your PBX can’t do it, etc…  Well, Lync 2010, again, provides a new option which previously didn’t exist in Office Communications Server 2007 or Office Communications Server 2007 R2.

In order to do to do this, we will need to create 3 new things:

  1. Lync Voice Policy
  2. Lync Phone Usages
  3. Lync Voice Routes

By itself, Phone Usages don’t do anything.  They are only the secret sauce that links a Voice Policy to a Route.  If we take a look at our Lync Route, we can see the new option for Supressing Caller ID with a specific phone number. In this case, let’s assume +13125556666 is our main office DID.

In the above screenshot, we can also see that we have an Associated PSTN usage record of Non-DID.  We also have a Voice Policy assigned called Non-DID users.  For our DID users, they will be in a different Voice Policy that utilizes a Voice Route that does not have Supress Caller ID enabled.

If you decide to use this configuration, any non-DID users will have their FROM: field modified to +13125556666 once they are moved into the Non-DID Users Voice Policy.  Their SIP Invite message will now look this:

INVITE sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone SIP/2.0
FROM: “Test, Elan”<sip:+13125556666@collocatedFEMediation.internalAD.domain.com;user=phone>;epid=AA4B5C1773;tag=d57257363e
TO: <sip:+18002223333@lyncgateway.internalAD.domain.com;user=phone>

So with Option #2, we will end up with the following:

DID Users

  • DID Voice Policy
  • DID Phone Usage assigned to DID Voice Policy
  • DID Phone Usage assigned to DID Voice Route with no Caller ID Suppression linking the DID Users to the DID Voice Routes

Non-DID Users

  • Non-DID Voice Policy
  • Non-DID Phone Usage assigned to the Non-DID Voice Policy
  • Non-DID Phone Usage assigned to the DID Voice Route with Caller ID Suppression linking the Non-DID Users tot he Non-DID Voice Routes

For more information on Phone Usages and Voice Policies, see this excellent article written by Ken Lasko here.

TL_INFO(TF_PROTOCOL) [2]264C.36C4::02/07/2011-14:39:17.432.0144d6e3 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(613))[1244851085]
>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_3255BCF>], 172.31.10.124:62951->172.31.10.54:5067
INVITE sip:+13126086141@lyncux.corp.projectleadership.net;user=phone SIP/2.0
FROM: “Shudnow, Elan”<sip:+13122585378@chlyncfe01.corp.projectleadership.net;user=phone>;epid=AA4B5C1773;tag=d73f8df627
TO: <sip:+13126086141@lyncux.corp.projectleadership.net;user=phone>
CSEQ: 389 INVITE
CALL-ID: f47cbdb1-6ed1-4c1f-b709-adc90bbf08df
MAX-FORWARDS: 70
VIA: SIP/2.0/TLS 172.31.10.124:62951;branch=z9hG4bK276ccb43
CONTACT: <sip:CHLYNCFE01.corp.projectleadership.net:5067;transport=Tls;ms-opaque=6dc157028aaf7847>
CONTENT-LENGTH: 527
SUPPORTED: 100rel
USER-AGENT: RTCC/4.0.0.0 MediationServer
CONTENT-TYPE: application/sdp
ALLOW: ACK
Allow: CANCEL,BYE,INVITE,PRACK,UPDATE
v=0
o=- 3675 1 IN IP4 172.31.10.124
s=session
c=IN IP4 172.31.10.124
b=CT:1000
t=0 0
m=audio 52402 RTP/SAVP 97 101 13 0 8
c=IN IP4 172.31.10.124
a=rtcp:52403
a=label:Audio
a=crypto:1 AES_CM_128_HMAC_SHA1_80 inline:cNQ3+rsqhQyDU8WHrCrDr3lfe4/cJWXrrtwfsp3a|2^31|1:1
a=crypto:2 AES_CM_128_HMAC_SHA1_80 inline:4Z/f29R0OcxKQf8J0FR+26sjq9yc0aQ5gBKXRaFJ|2^31
a=sendrecv
a=rtpmap:97 RED/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=ptime:20
————EndOfOutgoing SipMessage
Share

8 Responses to “Lync 2010 Enterprise Voice DID vs Non-DID Users”

  1. […] http://www.shudnow.net/2011/03/03/lync-2010-enterprise-voice-did-vs-non-did-users/ Share this:FacebookDiggEmail […]

  2. on 12 Mar 2012 at 11:36 amJason

    Thanks so much for this!

  3. on 01 Jun 2012 at 4:11 amNORichard

    горы на сайте о строительстве tvoakvartira.ru.

  4. on 16 Jul 2012 at 3:29 pmKTee

    this is awesome! Thanks. We had this come up today, where a user doesn't want their caller-id displayed. I found a technet article stating it can be done, but no information on how to actually perform the steps. We assume this only affects PSTN calls. Will calls internal to lync will continue to display caller-id? I assume yes, but we haven't tested yet.

  5. on 10 Jan 2013 at 6:16 amPatrik

    Hi. I tested this on my Lync server (option 2). Unfortunately it STILL sends the username and not a phone number :(

  6. on 10 Jan 2013 at 9:21 pmElan Shudnow

    Try the test voice routing feature and make sure the non-did users are getting the proper voice policies, usages, and hitting the correct voice route with the caller id override.

  7. on 11 Jan 2013 at 1:37 amPatrik

    Yes the expected translation and policies do all pass.

  8. on 16 Jan 2013 at 4:40 amPatrik

    We have now reinstalled the Lync 2013 server completely and we still cannot get the server to send anything else but sip:user@exampledomain.com in the FROM: string.

    I don't know if this is a bug in Lync 2013 or something blocking the use of TEL URI.

Trackback this post | Feed on Comments to this post

Leave a Reply