The primary considerations for the Now MMSC in an operator environment pertain to user provisioning and user identification.

In the standard configuration for the MMSC, it is a requirement that each user be configured with a special MMS Message Server URL. The URL contains the username and password of the user account on the MMSC. In an operator environment, it is not practical to provision phones with unique MMS Message Server URLs, and it is also not practical to manually configure user accounts on the MMSC.

The reason that the standard configuration of the MMSC requires each user to be configured with a special MMS Message Server URL, is because the connection that the phone makes to the MMSC is IP-based, and contains no information about the MSISDN (phone number) of the user that is making the request. In fact, the MMSC only sees an HTTP request coming from the IP address of the WAP gateway that is proxying the request on behalf of the mobile device. Without further hooks into the operator network to determine the identity of the device making the request, the MMSC relies on the username and password in the URL request to identify the user.

To overcome this limitation, it is possible to configure the MMSC to receive user identity information directly from the operator network, without requiring the username and password on the URL.

To integrate into the operator network, the Now MMSC expects to receive user information from the operator WAP gateway. As all requests to the MMSC are being proxied through the operator WAP gateway, it is best that the WAP gateway take responsibility for user identification. Additional information on configuring the NowWAP Proxy to provide this information is provided later in this document.

The WAP gateway must be configured to forward the MSISDN of the requesting user to the MMSC via a configurable HTTP header. For example, the NowWAP Proxy uses the “X-MSISDN:” header to forward the MSISDN to HTTP content servers such as the MMSC.

To configure the Now MMSC to read the MSISDN from an HTTP header, configuration settings must be applied to the MMSC.INI file. The following configuration settings may be applied within the [MMSC] section of the MMSC.INI file:


MSISDNHeader=header-name

The MSISDNHeader setting specifies the name of the HTTP header that will contain the MSISDN. For example, with NowWAP, the appropriate setting would be:

MSISDNHeader=X-MSISDN

MSISDNHeaderGateways=1.2.3.4,5.6.7.8,9.10.11.*

The MSISDNHeaderGateways setting specifies a list of one or more IP addresses from which the MMSC will accept the MSISDNHeader. This is to prevent forged requests, where another gateway or application inserts an MSISDN header to attempt to fool the MMSC. One or more IP addresses can be listed in this configuration setting. Each address must be separated by a comma. Wildcard addresses are supported by placing a “*” in place of a position within the IP address. For example, a setting of 9.10.11.* would mean that the MSISDNHeader would be accepted from any request originating from an IP address in the range of 9.10.11.1 thru 9.10.11.255.

MSISDNHeaderDefaultCountryCode=##

The MSISDNHeaderDefaultCountryCode setting specifies a default country code to be applied to MSISDN numbers presented in the MSISDNHeader, so that the gateway can convert the MSISDN address to international format automatically.

MSISDNHeaderLocalPrefix=#

The MSISDNHeaderLocalPrefix setting specifies the default prefix that is used for phone numbers in the MSISDN header that are in local (national) format. For example, in the UK, the MSISDNHeaderDefaultCountryCode would be 44, and the MSISDNHeaderLocalPrefix would be 0. With these settings, and MSISDN header of “07778001210” would automatically be converted to “+447778001210” by the MMSC.

MSISDNHeaderAutoProvision=Yes/No

The MSISDNHeaderAutoProvision setting specifies whether or not user accounts should be automatically provisioned on the MMSC the first time that a user sends a message through the MMSC. This removes the requirement to automatically provision accounts. Any user that makes a request through the appropriate WAP gateway with the MSISDNHeader set will be automatically provisioned on the MMSC.

Configuring the NowWAP Proxy to Forward MSISDN

When a mobile device connects to a WAP Gateway, the connection requests are made over the IP protocol, and there is no part of the WAP standard that specifies how the MSISDN is presented to the WAP gateway.

The mobile device is generally assigned an IP address when it connects to the GGSN (or network access server for dial-up connections, collectively we’ll refer to them as this point on as an “access server”). This IP address is usually dynamically assigned and changes between sessions.

The WAP gateway needs to receive information from the “access server” in order to identify the MSISDN of a device associated with the IP address making a request of the WAP gateway.

The NowWAP Proxy integrates with access servers using the Radius accounting protocol, which is one of the Radius (Remote Authentication Dial In User Service) protocols. The Radius authentication protocol is defined in internet RFC 2865, and the Radius accounting protocol is defined in internet RFC 2866. The two protocols are frequently used together.

The Radius authentication protocol is used to authenticate a user. When a new connection is received by an access server (including a GGSN), the access server can be configured to use Radius authentication to determine whether or not to accept the connection. The access server sends a Radius authentication request over UDP to a Radius server. This request includes the username presented and a hash of the password against a shared secret, and usually the CLI (caller line identification) of the station making the request. The Radius server responds back over UDP to the access server telling the access server whether or not to allow the connection, and in some configurations, the Radius server can also tell the access server what IP address to assign to the client.

After a connection has been authenticated, the access server can be configured to use the Radius accounting protocol to inform an accounting server of a new connection. Similarly, the access server notifies of a dropped connection. The Radius accounting protocol is also UDP-based, but it is an informational protocol. After a new connection is authenticated, the access server sends a Radius accounting packet over UDP to the configured accounting server(s). This packet includes a hash of a shared secret for packet validation, and typically includes the username that connected, the IP address that was assigned, and the CLI of the station that connected.

In an operator environment, users are typically not assigned their own username for the purposes of Radius authentication. Instead CLI is the determining factor.

To provide MSISDN support, NowWAP needs to be configured as a Radius accounting server, so that it

receives Radius accounting packets from the access server. This support is activated in NowWAP on the MSISDN page of the configuration dialog.

In the configuration dialog, you must specify a port (1813 is the default according to the specification, but some access servers default to 1646 which is an incorrect default from an older specification), and the appropriate shared secret.

This setting enables the NowWAP Proxy to receive Radius accounting packets from the access server.

Check "Forward MSISDN to Content Servers", and add your local domain name as a content domain. The

gateway will then include the MSISDN in any requests to content servers within any listed domains. For example, if “operator.net” is listed as a supported content domain, then the MSISDN would be forwarded to a content server named “mms.operator.net”, or a content server simply named “operator.net”. The gateway will forward the MSISDN to the content server in all HTTP requests sent to the content server, using the HTTP “X-MSISDN:” header.

As long as the Radius accounting feed from the access server is reliable, it may be desirable to require an MSISDN for any connections to the WAP gateway. This can be enabled by checking “Require MSISDN for all gateway connections”. Connections from IP addresses where the WAP gateway has not received an MSISDN assignment from the access server will be rejected.

Getting the Radius accounting feed setup in the access server correctly, so that it is sent to the WAP gateway is the hardest part of this process. Unfortunately, NowWAP doesn't give you much indication as to whether or not it is receiving a Radius accounting feed. When testing, it is best to enable the debug log in NowWAP (edit WAPGW.INI, add Debug=Yes under [WAPGW] section header), and monitor the WAPDEBUG.LOG for a keyword of "Radius", where it will log all Radius packets that the gateway receives. If you have problems getting the Radius configuration working, then it is best to contact NowWAP technical support for further advice.

NowWAP can also be configured to be a Radius authentication server, but it is a VERY simple Radius authentication server. When NowWAP is a Radius authentication server, it will accept any authentication request. We do not recommend the use of this setting, except for testing purposes. (This setting was added originally for a particular customer that needed it.)

Return to Now SMS/MMS Gateway Technical Bulletins