Although I had read in the Microsoft blogs  Direct SIP with IP-PBX in Office Communications Server 2007 and Reverse Number Lookup and Dealing with Legacy PBX (and had been told the same thing by Duncan Blake, a Unify Square colleague of mine) that OCS 2007 R2 will normalize both the FROM: Calling Party number and TO: Called Party number on incoming PBX and PSTN calls according to the Location Profile rules assigned to the Mediation Server handling the call, incoming call normalization of either number wasn’t working in my lab environment.

After doing SIPStack trace investigations on both my Front End server and Mediation Server, I discovered that my media gateway—a Quintum Tenor AF running P107-09-00 firmware—was adding a “+” to both the TO: and FROM: numbers before routing the INVITE to the Mediation Server. As per RFC 3966, a leading “+” in a TEL: URI indicates that the phone number is globally-unique (i.e., E.164). To OCS, this means that the numbers are already E.164, so it does not attempt to perform any further normalization on them (this same rule also applies to outgoing calls in OCS and Office Communicator).

So the unexpected “+” was why inbound normalization was failing. However, I was still puzzled because the Tenor was not configured to do translations on either the Calling or Called Party numbers, but just to pass what it received from the Telco. I never deliberately configured it to send a “+”. Then it hit me: beginning with P105-19-00 of the firmware, Quintum added support for some configuration parameters that are not exposed in the gateway user interface, but instead are set using a small text file named var_config.cfg.

From the P105-19-00 release notes:

The default var_config.cfg file for P105-19-00 is:

SipTransportDefault 1
SipPrependPlus 1
SipUserPhone 1
progcause 1

The var_config.cfg file currently on my gateway (that one that Quintum recommends when integrating P107-09-00 Tenors with OCS) was:

SipTransportDefault 1
SipPrependPlus 1
SipUserPhone 1
EarlyMediaRingTone 1
SIPMissingCIDURI anonymous

After changing the second line of my var_config.cfg file to “SipPrependPlus 0” and restarting the gateway, voile! The numbers the Tenor passed to the Mediation Server no longer had the leading “+”, and now OCS’s Inbound Number Translation behaved as expected on both the TO: and FROM: numbers.

I don’t know why Quintum decided to make the SipPrependPlus a default setting, because the only time this would be acceptable would be if you performed E.164 normalization of both the TO: and FROM: numbers on the gateway, before sending the call to OCS.

With my system now working properly, the INVITE from the Tenor gateway looked like this:

which the Mediation Server resends to the Front End as:

INVITE sip:2531234567;phone-context=PawlakLab@pawlaklab.local;user=phone SIP/2.0FROM: <sip:4258650709;phone-context=PawlakLab@pawlaklab.local;user=phone>;epid=AE63718344;tag=d8879a6a5fTO: <sip:2531234567;phone-context=PawlakLab@pawlaklab.local;user=phone>CSEQ: 30 INVITECALL-ID: c26f38ff-cd88-4768-9927-9408465c584cMAX-FORWARDS: 70VIA: SIP/2.0/TLS 192.168.100.22:1952;branch=z9hG4bKb0658337CONTACT: <sip:OCSMEDR2.pawlaklab.local@pawlaklab.local;gruu;opaque=srvr:MediationServer:JD2-_D2V8Uas6PL3dHopYwAA;grid=95b7e3cc247a488daac329263114d09f>;isGatewayCONTENT-LENGTH: 2246SUPPORTED: replacesSUPPORTED: ms-safe-transferSUPPORTED: gruu-10SUPPORTED: 100relUSER-AGENT: RTCC/3.5.0.0 MediationServerCONTENT-TYPE: multipart/alternative; boundary=pslWXe0LgTGWJRLgCrFTghFfvoZi3yw7ALLOW: UPDATEms-call-source: non-ms-rtcALLOW: Ack, Cancel, Bye,Invite,Refer--pslWXe0LgTGWJRLgCrFTghFfvoZi3yw7Content-Type: application/sdp… 

On the Front End Server, the OCS Translation Service normalized the TO: and FROM: numbers using the PawlakLab Location Profile assigned to my Mediation Server. You can see what’s going on in the Front End Server’s TranslationApplication log shown below: 

(TranslationApplication,PhoneProcessor.OnRequest:phoneprocessor.cs(689))( 000000000138C113 )OnRequest: INVITE, reqUri=sip:2531234567;phone-context=PawlakLab@pawlaklab.local;user=phone newHostPart= (TranslationApplication,PhoneProcessor.ProcessFromUri:phoneprocessor.cs(884))( 000000000138C113 )Processing From URI: sip:4258650709;phone-context=PawlakLab@pawlaklab.local;user=phone(TranslationApplication,PhoneNumberTranslator.ApplyProfile:phonenumbertranslator.cs(463))( 0000000001255C0B )ruleName='10-digit' matched Num='4258650709', txNum='+14258650709'(TranslationApplication,PhoneNumberTranslator.TranslateNumber:phonenumbertranslator.cs(250))( 0000000001255C0B )calledNumber='2531234567'(TranslationApplication,PhoneNumberTranslator.ApplyProfile:phonenumbertranslator.cs(463))( 0000000001255C0B )ruleName='10-digit' matched Num='2531234567', txNum='+12531234567'(TranslationApplication,PhoneNumberTranslator.TranslateNumber:phonenumbertranslator.cs(313))( 0000000001255C0B )MATCH: New request Uri='sip:+12531234567@pawlaklab.local;user=phone' 

OCS Inbound Routing then looks up the new request URI sip:+12531234567@pawlaklab.local;user=phone against its database and finds that it matches the msRTCSIP-Line URI belonging to amst@pawlaklab.local (Amy Strande), and the Front End proxies the SIP INVITE shown below to Amy’s registered Office Communicator endpoint:

Note that the TO: and FROM: numbers don’t change, but a new field containing the new request URI, P-Asserted-Identity, is added by the Front-End proxy.

Amy’s Office Communicator rings an incoming call, and if the +14258650709 number in the P-Asserted-Identity (or if the 4258650709 in the FROM: tag) matches a number in Communicator’s GALCONTACTS.DB file or in Amy’s Outlook Contacts, then Communicator’s incoming call “toast” notification will display the caller’s name and, if the call is answered, the resolved name will display in Communicator’s call roster.

Note that you can extend this Caller ID capability to resolve Exchange 2007 Missed Call notifications and Voice Mail notifications, as detailed in Jens Trier Rasmussen’s blog article Additional logic for resolving internal calling numbers in Exchange 2007 SP1 Unified Messaging .

There is a known issue in the OCS 2007 R2 Response Group service.

 The service will not start if you have a SAN certificate assigned to the front end server and the last entry in the SAN list does not match the pool name. One way this can happen is if you ran the OCS Certificate Request wizard and checked that box that says “Automatically included machine name”; this will cause it to put the machine FQDN last in the SAN list, which will cause Response Group startup to fail. 

UPDATE 06/05/09: This problem has been resolved in the following patch - http://support.microsoft.com/kb/967829/ . This patch will also be automatically detected if the OCS server is running Automatic Update.

I encountered a tricky issue with having my simultaneous ring set to go to my cell phone. Like many people, I have a personal cell phone account (in my case with Verizon) that has its own voice mailbox, while I use my Exchange UM voice mail for missed calls at work.

I had set my MOC client for simultaneous ring to my cell phone since Unify Square had cutover onto OCS 2007 R2 a month ago. I had my Verizon account provisioned so that personal calls from people dialing my cell phone number directly (rather than my UC number) would go to my Verizon voice mailbox.  People calling my Unify Square UC number would still go to Exchange UM on a busy/no answer.

Things had been working great, but then one morning, whenever someone called me on my office number (425-865-0709) the call immediately went to my Verizon voice mail.

The problem was caused by my cell phone being turned off. This made Verizon forward the call immediately to voice mail, and that caused OCS to stop ringing my MOC/CPE endpoints. After calling Verizon Support, they told me that there was no provisioning option to make calls to my cell phone do some fixed number of phantom rings when the phone was off or out of service before transferring the call to voice mail. Voice mail is either enable or disabled, and if enabled will pick up immediately if the phone is out of service.

To work around this problem, I set my cell phone account to use Verizon's “No Answer/Busy Transfer” option (see http://support.vzw.com/features/calling_features/no_answer_transfer.html) and tell it to forward calls to my work number (which thereby causes the phone to bypass Verizon’s voice mail.) On a no answer, after 6 ring-back tones Verizon forwards the call to my Unify Square phone number, and then after the MOC time-out timer expires Exchange UM picks up. When the phone is off or out of service, it rings to the forwarded number immediately.

However, this is still not a great solution for several reasons:

·         I had to play with my MOC voice mail time out settings and reduce it from the 15 sec default to 13 sec. Verizon’s “No Answer/Busy Transfer” feature gives up on the forwarded call if it hasn’t been picked up by about 14 secs.

·         When the phone is turned off or out-of-service, the call forwarding behavior changes. To OCS, it looks like multiple calls are coming in, and multiple OCS toasts pop up (1 per ring) until it times out and Exchange UM gets the call. I haven’t done any trace analysis to see why this happens, but the user experience is pretty ugly!

·         You need to use your corporate voice mail system to handle personal calls to your cell phone, which won’t be acceptable for most users.

If any one knows a better solution, please let me know.