Поделиться через


Why Location Profile on OCS 2007 Mediation Server?

In my last blog article OCS 2007 Dialplan fundamentals I have explained that we need Location Profiles in order to maintain the users dialing behavior before the OCS installation. A Location Profile is a set of regular expressions that will be applied on a called party number that is not in +<E.164> format. In General all called party numbers will be normalized to +<E.164> format before being processed by OCS to match a user SIP URI to this +<E.164> number or to pass it on to one of the OCS Mediation Servers. On outbound calls – there might be few exceptions – OCS Mediation Server will always be hit with +<E.164> formatted called party numbers.

On OCS Mediation Server you have to specify a single Location Profile. This is needed for incoming calls coming from a SIP Gateway/SIP connection into the OCS world when the called party number has not been normalized by the previous hop (e.g. Gateway) to +<E.164> format. If OCS Mediation Server receives a SIP INVITE with a called party number that is not in +<E.164> format, OCS Mediation Server will add the Location Profile information to the SIP INVITE (phone-context=<Location Profile>) and OCS Translations application (Not OCS Mediation Server) will apply regular expressions for this Location Profile on the non +<E.164> number in order to normalize the number before trying to match it to a user’s SIP URI using msRTCSIPLine attribute.

To proceed with the example started in blog OCS 2007 Dialplan fundamentals, the OCS Mediation Server in Frankfurt/Germany would be configured to use Location Profile FRA which would be a symmetric use of the Location Profile for local site dialing as well as for the OCS Mediation Server on inbound calls.

It is technically possible and in few situations technically necessary to use an asymmetric Location Profile on OCS Mediation Server. This means that a local OCS Mediation Server will not have the same Location Profile configured as for the local users of the same site. An example might be that the SIP Gateway that is connected to OCS Mediation Server has limitations in manipulating the called party number before sending to OCS Mediation Server and always adds an extra “0” as first digit of the called party number. In such a situation you would create a new Location Profile e.g. FRA_incoming that has basically the same normalization rules as FRA but an additional “0” in front of the called party number will be cut off.