Can Microsoft Lync Server 2010 handle line URI extensions with the format “1234567890;ext=xxxx” that start with a “0”?

For those who have come across one of my previous posts about Microsoft Lync Server 2010 handling extensions that start with a “0”: https://blog.terenceluk.com/2011/02/can-microsoft-lync-server-2010-handle.html

Can Microsoft Lync Server 2010 handle extensions that start with a “0”?

… the project with the client who initially asked me this questions finally kicked off this week and while I was onsite today, I was told that I had interpreted the question incorrectly.  What they were asking was not whether Lync Server 2010 supported line URIs with an extension that starts with a “0” such as “+0123” which I had tested to work but rather whether the format “1234567890;ext=0xxx” was supported.  They have indicated that if such a line URI was processed by OCS 2007 R2, the 0 would get dropped.  Having been intrigued with this question since I was asked a while ago, I went ahead and said we should test it right now.  Here’s what the normalization rule looked like:

Pattern to match: ^(0d{3})$

Translation rule:  +1xxx123xxxx;ext=$1

Once the normalization rule kicked in, we tried entering an extension into the MOC client and long behold, this is what we saw:

… doesn’t look good does it?  The translated extension appears to suggest that the 0 has indeed been dropped but I didn’t want to take this visual representation as a fact so I started a trace on the Lync front-end server as well as the NET UX2000 gateway we were working with and this is what I saw in the trace logs:

TL_INFO(TF_PROTOCOL) [10]3E40.3144::03/16/2011-14:53:10.312.004f2093 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(660))[825729205]
<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_C22FF>], 132.216.75.61:5070<-132.216.75.61:50730
INVITE sip:+15145555555;ext=0123@NET-SBC1.domain.ca:5070;user=phone;maddr=lync.domain.ca SIP/2.0
FROM: “Lync Test1″<sip:lync.test1@domain.ca>;tag=f1cc7c7bc1;epid=ddc9a3667c
TO: <sip:+15143984400;ext=0123@domain.ca;user=phone>
CSEQ: 1 INVITE
CALL-ID: a5d5102f296141f29986a8bfd6c041ee
MAX-FORWARDS: 69
VIA: SIP/2.0/TLS 132.216.75.61:50730;branch=z9hG4bK193ABD3D.DBA09024B7D96C76;branched=FALSE
VIA: SIP/2.0/TLS 132.206.35.97:62270;ms-received-port=62270;ms-received-cid=487500
RECORD-ROUTE: <sip:lync.domain.ca:5061;transport=tls;ms-fe=LYNCFE01.domain.CA;opaque=state:T;lr>;tag=3504A5D80AECAB1E3E86A40C5049003A
CONTACT: <sip:lync.test1@domain.ca;opaque=user:epid:RNQyjfkeulKdtEdAgsJTPwAA;gruu>
CONTENT-LENGTH: 4229
SUPPORTED: ms-dialog-route-set-update
SUPPORTED: timer
SUPPORTED: histinfo
SUPPORTED: ms-safe-transfer
SUPPORTED: ms-sender
SUPPORTED: ms-early-media
SUPPORTED: 100rel
SUPPORTED: replaces
SUPPORTED: ms-conf-invite
USER-AGENT: UCCAPI/4.0.7577.108 OC/4.0.7577.108 (Microsoft Lync 2010)
CONTENT-TYPE: multipart/alternative;boundary=”—-=_NextPart_000_0856_01CBE3C8.56A55030″
ACCEPT-LANGUAGE: en-US
ALLOW: INVITE, BYE, ACK, CANCEL, INFO, UPDATE, REFER, NOTIFY, BENOTIFY, OPTIONS
P-ASSERTED-IDENTITY: “Lync Test1″<sip:lync.test1@domain.ca>,<tel:+15143999584>
ms-application-via: SIP;ms-urc-rs-from;ms-server=LYNCFE01.domain.CA;ms-pool=lync.domain.ca;ms-application=ad894dc3-55e0-44bf-a07e-3c073aaa4a57
ms-application-via: sql1vs5_vs5;ms-server=LYNCFE01.domain.CA;ms-pool=lync.domain.ca;ms-application=51FB453D-5B9F-45df-83B4-ADD1F7E604A8
Ms-Conversation-ID: Acvj6d2DHE7BRe5PQQC19ELJkcEewA==
ms-keep-alive: UAC;hop-hop=yes
ms-subnet: 132.206.35.0
ms-endpoint-location-data: NetworkScope;ms-media-location-type=Intranet
ms-user-data: ms-publiccloud=TRUE;ms-federation=TRUE
——=_NextPart_000_0856_01CBE3C8.56A55030

As shown in the snooper logs, we can see that the extension 0123 is indeed passed as the extension even though the Lync client appears to have disregarded it.  I’ve also gone ahead to have a look at the UX2000 gateway logs and confirmed that the full line URI was sent over with the extension: “0123”.