MCS UK Unified Communications Blog

All things UC related from Microsoft Consulting Services UK : architecture, best practice, news for Exchange and Lync, both on-premise and cloud

Reverse Number Lookup and Dealing with Legacy PBX

Reverse Number Lookup and Dealing with Legacy PBX

  • Comments 11
  • Likes

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.

Untitled2

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.

Untitled

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:+441189093291@10.1.10.7;user=phone SIP/2.0

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

Max-Forwards: 70

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

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

Call-ID: 29598879711200021026@10.1.10.10

CSeq: 1 INVITE

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

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

Allow: REGISTER,OPTIONS,INVITE,ACK,CANCEL,BYE,NOTIFY,PRACK,REFER,INFO,SUBSCRIBE,UPDATE

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

Peer: redmed01.europe.corp.microsoft.com:2503

Message-Type: request

Start-Line: INVITE sip:peter@microsoft.com;opaque=user:epid:jDT7sohH91mi5ocvidTJugAA;gruu SIP/2.0

From: <sip:84041212;phone-context=readingmediationserver@microsoft.com;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <sip:+441189093291@microsoft.com;user=phone>;epid=7e731b1d1b;tag=03d30514a1

CSeq: 16 INVITE

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

MAX-FORWARDS: 70

VIA: SIP/2.0/TLS 10.1.1.7:2503;branch=z9hG4bK42fecdc

ROUTE: <sip:redmed01.europe.corp.microsoft.com:5061;transport=tls;opaque=state:T;lr>

CONTACT: <sip: redmed01.europe.corp.microsoft.com @microsoft.com;gruu;opaque=srvr:MediationServer:kqKefwcAxUeuOkjBv6DxWwAA;grid=92401592ca3b413db9bf01d752fdbf7b>;isGateway

CONTENT-LENGTH: 704

SUPPORTED: replaces

SUPPORTED: ms-safe-transfer

SUPPORTED: gruu-10

SUPPORTED: 100rel

USER-AGENT: RTCC/3.5.0.0 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.

Untitled1

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

Peer: 10.1.1.1:3121

Message-Type: request

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

From: <sip:84041212;phone-context=readingmediationserver@microsoft.com;user=phone>;epid=1460650F33;tag=dedea5f4a2

To: <sip:+441189093291@microsoft.com;user=phone>;epid=7e731b1d1b

CSeq: 14 INVITE

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

Record-Route:<sip:redmed01.europe.corp.microsoft.com:5061;transport=tls;opaque=state:F:Ci.R800:Ieh.F3iAkjnCzw86ws8Paad7Q-xhoz-dlzMeAcTz0kz9ap5Qzj4gqUobs-iQAA;lr;ms-route-sig=aayPE3zUoe-C6QGmGlfPRG4c_CpiLj4gqUobs-iQAA>;tag=5394737F5C726A52BF0897201BE0E06B

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"

Max-Forwards: 69

Content-Length: 2492

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

Supported: replaces

Supported: ms-safe-transfer

Supported: gruu-10

Supported: 100rel

User-Agent: RTCC/3.5.0.0 MediationServer

Content-Type: multipart/alternative; boundary=uuXBWe9zTOKnsjncYiXRaSzuM0iotixl

Allow: UPDATE

Allow: Ack, Cancel, Bye,Invite,Refer

P-Asserted-Identity: <sip:+442031391212@microsoft.com;user=phone>

History-Info: <sip:peter@microsoft.com>;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.

e.g.

User

Telephone Number

SIP Line URI

Peter Perfect

801 3291

Tel:+441189093291

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

##

802[\s()\-\./]*(\d\d\d\d)

+44203139$1

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'

Test PASSED

Matching Rule in Company_Phone_Number_Normalization_Rules.txt on line 15

^802[\s()\-\./]*(\d\d\d\d)$

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}

Mail joe@microsoft.com

TelephoneNumber 802 1212

TelephoneNumber tel:+442031391212

msRTCSIPPrimaryUserAddress sip:joe@microsoft.com

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.

Summary

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
  • PingBack from http://free-reverse-cell-phone-lookup.info/?p=1205

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

  • 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?

    Thanks

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

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

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

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

    -jonmck

  • If you want to find information about an unknown phone number instantly then visit this site - www.cellarchive.com/612/612516.php

  • Real good information. I like this post.

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

  • If you really want to track a phone try this <a href="

    http://phonenumberownerdetails.com">Telephone Number Search </a>

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

    to give you more information about it.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment