Reverse Number Lookup and Dealing with Legacy PBX

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 ( . 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 ----

INVITE sip:+441189093291@;user=phone SIP/2.0

Via: SIP/2.0/TCP;branch=z9hG4bKac295994674;alias

Max-Forwards: 70

From: "84041212" <sip:84041212@>;tag=1c295989178

To: <sip:+441189093291@;user=phone>

Call-ID: 29598879711200021026@


Contact: <sip:84041212@;transport=tcp>

Supported: em,100rel,timer,replaces,path,resource-priority


User-Agent: Audiocodes-Sip-Gateway-MP-114 FXS_FXO/v.5.00A.035.003

Content-Type: application/sdp

Content-Length: 258

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) [0]0B9C.1004::03/18/2009-13:48:03.831.000010a9 (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record

Instance-Id: 00000134

Direction: incoming


Message-Type: request

Start-Line: INVITE;opaque=user:epid:jDT7sohH91mi5ocvidTJugAA;gruu SIP/2.0

From: <sip:84041212;;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <;user=phone>;epid=7e731b1d1b;tag=03d30514a1


Call-ID: b7a0659b-57d0-4336-98e8-0725f897415b


VIA: SIP/2.0/TLS;branch=z9hG4bK42fecdc

ROUTE: <;transport=tls;opaque=state:T;lr>

CONTACT: <sip:;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway


SUPPORTED: replaces

SUPPORTED: ms-safe-transfer

SUPPORTED: gruu-10


USER-AGENT: RTCC/ MediationServer

CONTENT-TYPE: application/sdp

Message-Body: v=0

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) [0]0B9C.1004::03/18/2009-13:47:56.380.00000f6e (SIPStack,SIPAdminLog::TraceProtocolRecord:SIPAdminLog.cpp(122))$$begin_record

Instance-Id: 00000124

Direction: outgoing


Message-Type: request

Start-Line: INVITE sip:;transport=tls;ms-opaque=29e2f0e8e5;ms-received-cid=800 SIP/2.0

From: <sip:84041212;;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <;user=phone>;epid=7e731b1d1b


Call-ID: b7a0659b-57d0-4336-98e8-0725f897415b


Via: SIP/2.0/TLS;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/", realm="SIP Communications Service"

Max-Forwards: 69

Content-Length: 2492

Via: SIP/2.0/TLS;branch=z9hG4bKdb55b847;ms-received-port=2503;ms-received-cid=E00

Contact: <sip:;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway

Supported: replaces

Supported: ms-safe-transfer

Supported: gruu-10

Supported: 100rel

User-Agent: RTCC/ MediationServer

Content-Type: multipart/alternative; boundary=uuXBWe9zTOKnsjncYiXRaSzuM0iotixl


Allow: Ack, Cancel, Bye,Invite,Refer

P-Asserted-Identity: <;user=phone>

History-Info: <>;index=1

Message-Body: --uuXBWe9zTOKnsjncYiXRaSzuM0iotixl

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.



Telephone Number


Peter Perfect

801 3291


Joe Bloggs

803 1212


Ruth Smith

801 3232


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:

Abserver.exe -testPhoneNorm

Which would give output like the following:-

Running 1 normalization rules tests

Test from Company_Phone_Number_Normalization_Rules.txt on line 37

Input: '8021234'

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:-

ContactId {GUID}


TelephoneNumber 802 1212

TelephoneNumber tel:+442031391212


displayName Joe Bloggs

Sn Bloggs

givenName Joe

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

Comments (11)

  1. Anonymous says:

    One of our consultants in the UK, Paul Brombley did a write up on a deployment and how they dealt with…

  2. carlo says:

    Nice post.  When you create your location profile for mediation server specifically, I am assuming you must name it the netbios name of the mediation server itself for it to work correctly?  In your example, "ReadingMediationServer"  Is this correct?  If so then these rules will be applied for all inbound calls from the gateway to the Mediation Server.  For outbound calls, I’m assuming that the users’ set Location Profile NormRules will only be applied and not the Mediation Server specific rules?


  3. Paul Brombley says:

    The location profile for the Mediation server can be called anything. There are no specific rules. The only time the name of the Location Profile matters is when tying up with Exchange UM.

  4. Jason Shave says:

    The only problem with this scenario as I understand it is that missed call notifications and voice mail notifications only contain the original phone number from the SIP INVITE.

    In other words, you can’t perform click to dial on these "raw" numbers unless you have normalization rules to handle them.

    For example, if a call comes in as a SIP INVITE from "7805551212" here in North America, we can use an inbound normalization rule at the Mediation server to change it to "+17805551212" however the missed call notification will show "7805551212" only.

  5. Reverse Lookup Guru says:

    That was insanely informative, and I’m going to read through it again just to make sure that I got everything. Thanks!

  6. Jonathan McKinney says:

    Has this been verified to be working on R2? My R2 system show the correct behavior from the Mediation Server, but the Front End does not add the p-asserted identity to the invite going to the communicator client.


  7. mike says:

    If you want to find information about an unknown phone number instantly then visit this site –

  8. John Calvin Lewis says:

    Real good information. I like this post.

    Get the detailed report related to any unknown phone number instantly!…/404571.php

  9. Darryl says:

    If you really want to track a phone try this <a href="">Telephone Number Search </a>

  10. Christie Jansen says:

    This post is interesting at some point. If you need more information, I suggest you go to

    to give you more information about it.

Skip to main content