Working with customers I have come across a number of scenarios where the caller ID presented from the PBX is not in E164/DID (Direct Inward Dial) format. Some gateways allow for extensive manipulation of the caller ID, some less so. The good news is that in OCS 2007 R2 you can now easily solve the problem and this has also been made available as a hotfix for OCS 2007 R1 (http://support.microsoft.com/kb/954647/en-us) . Below is an explanation of how it works and what you need to put in place.
In a simple scenario, you have 2 sites, each with a PBX. There is in place standard short code site dialing. I have also included the PBX node numbers as I have seen these exposed in some cases.
Now if we take the simple scenario of Peter in Reading on OCS which is connected through a mediation server and a basic gateway to a PBX in Reading. Joe is a user in London connected to a PBX in London.
When Joe calls Peter the following occurs
The call is routed from the London PBX to the Reading PBX and then on to the basic gateway.
The gateway will create a SIP invite message and the “to” address is usually formatted correctly but the “from” address could be in one of several formats depending on your legacy PBX
DID number 442031391212
Short Dial number 8021212
Internal dial number 84041212
If you are fortunate and it is in DID format then the basic gateway can easily add +, as can the mediation server. More likely though you either have the short dial number, or as in this case the internal dial number (using the PBX node number)
You can see from the log from my basic gateway the formatting of the different addresses I have highlighted in red.
---- Outgoing SIP Message to 10.1.10.7:5060 ----
INVITE sip:+email@example.com;user=phone SIP/2.0
Via: SIP/2.0/TCP 10.1.10.10;branch=z9hG4bKac295994674;alias
From: "84041212" <sip:firstname.lastname@example.org>;tag=1c295989178
CSeq: 1 INVITE
User-Agent: Audiocodes-Sip-Gateway-MP-114 FXS_FXO/v.5.00A.035.003
When the message is received by the mediation server, because the “from” number is not in E164 format it will add its configured location profile to the “from” address as a phone-context which I have highlighted in red in the log below.
TL_INFO(TF_PROTOCOL) 0B9C.1004::03/18/2009-13:48:03.831.000010a9 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
Start-Line: INVITE sip:email@example.com;opaque=user:epid:jDT7sohH91mi5ocvidTJugAA;gruu SIP/2.0
CSeq: 16 INVITE
VIA: SIP/2.0/TLS 10.1.1.7:2503;branch=z9hG4bK42fecdc
CONTACT: <sip: redmed01.europe.corp.microsoft.com @microsoft.com;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway
USER-AGENT: RTCC/184.108.40.206 MediationServer
The pool front end server uses the location profile in the phone-context to normalise the number. I would recommend using a different location profile to the one you assign to users as the rules can be slightly different and allows you the flexibility to customise it to your PBX.
It adds a “P-Asserted-Identity” field to the invite message with the normalised number as shown towards the bottom of the invite message below.
TL_INFO(TF_PROTOCOL) 0B9C.1004::03/18/2009-13:47:56.380.00000f6e (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record
Start-Line: INVITE sip:10.1.1.1:3121;transport=tls;ms-opaque=29e2f0e8e5;ms-received-cid=800 SIP/2.0
CSeq: 14 INVITE
Via: SIP/2.0/TLS 10.1.1.2:5061;branch=z9hG4bK494BEF08.940AE2E3D46C2B3C;branched=TRUE;ms-internal-info="aaJ40wWI6TcWSrM9kHR3RfmIeBWPvj4gqUlmojpgAA"
Proxy-Authentication-Info: Kerberos rspauth="602306092A864886F71201020201011100FFFFFFFF4B108BAF713F56BEA6F3CC8B197124B2", srand="F46844E8", snum="51", opaque="30115551", qop="auth", targetname="sip/dubocs01.europe.corp.microsoft.com", realm="SIP Communications Service"
Via: SIP/2.0/TLS 10.1.1.7:2503;branch=z9hG4bKdb55b847;ms-received-port=2503;ms-received-cid=E00
Contact: <sip: redmed01.europe.corp.microsoft.com @microsoft.com;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway
User-Agent: RTCC/220.127.116.11 MediationServer
Content-Type: multipart/alternative; boundary=uuXBWe9zTOKnsjncYiXRaSzuM0iotixl
Allow: Ack, Cancel, Bye,Invite,Refer
When the invite message is received by the Office Communicator client it uses either the “From” field or the “P-Asserted-Identity” field to match against the address book and local Outlook contacts. The problem here is that the numbers in the address book come from Active Directory and these are usually in the short dial format as they are used by users who are not using OCS enterprise voice.
SIP Line URI
For this you need to amend the company normalization rules file (Company_Phone_Number_Normalization_Rules.txt) so that it generates number that can be matched against. In this example for London you would add
# 802xxxx +44203139xxxx London
I would also recommend you add a test input entry
#TestInput: 8021234 TestResult: +442031391234
This enables you to easily test your address book normalization rules using the command line:
Which would give output like the following:-
Running 1 normalization rules tests
Test from Company_Phone_Number_Normalization_Rules.txt on line 37
Expected Result: '+442031391234'
Actual Result: '+442031391234'
Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 15
You can also output the Address book to a text file to view how your numbers are normalizing e.g.
Abserver.exe /dumpFile “f-0bb5.dabs” c:\absdump.txt
Where f-0bb5.dabs is the latest full address book file. You will see entries similar to the following:-
TelephoneNumber 802 1212
displayName Joe Bloggs
Notice that there is an additional telephone number entry with the normalised version of the number. This is the normal telephone number field in Active Directory, not the SIP Line URI.
To summarise what you need to do is:
· Create location profile for mediation server
· Have a consistent number format for telephone numbers in Active Directory
· Edit Company_Phone_Number_Normalization_Rules.txt file to normalize numbers from Active Directory for the address book.
Posted by Paul Brombley