One WAP Gateway for both MMS and Browser Data

Posted by on Jul 7, 2008 in Support Blog

Topic Keywords: , ,

Smaller mobile operators often ask us how to deploy a single WAP Gateway (or WAP Proxy if you prefer that terminology, as our marketing folks seem to prefer) to deploy both MMS traffic and general browser traffic.

Of course, technically there is no reason that a single WAP Gateway can’t support both types of traffic. So if you’re not a mobile operator, you’re probably wondering what the point of this posting is.

In most environments, the mobile operator does not charge for data that is transferred to and from the MMSC. This MMS data is simply considered to be a part of the charge for sending or recieiving the MMS message, as it is difficult to explain to a user that they are charged both for the message and the related data traffic.

However, other non-MMS data traffic is considered chargeable.

The way that this is normally implemented is that at least two different APNs are deployed on the GPRS/EDGE/WCDMA network. One APN is for for MMS data traffic only, and another is for browsing data traffic. (Additional APNs might support general internet traffic, or the general internet traffic might use the browsing APN.)

When a user connects to the MMS APN, they should only be allowed to communicate with the MMSC.

If the same WAP Gateway is to be used for both MMS and browsing data traffic, how does the WAP Gateway know whether or not to limit access?

There are two ways that this can be configured using the NowWAP 2008 release.

I would stress that this solution is only recommended for smaller to small/medium sized operators where there is insufficient data traffic to warrant multiple WAP gateways.

As part of a contingency plan to allow for future growth, the first recommendation that we would make is that even though both services will be sharing the same WAP gateway, the mobile phone settings for your subscribers should have different IP addresses for the WAP gateway configured in the mobile phone settings for MMS or web browsing. It is an easy task to provision multiple IP addresses on the server that is running the WAP gateway, and we strongly recommend that this be done. If your traffic grows in the future, it will then make it a simpler task to migrate to separate WAP gateways for MMS and browsing traffic.

Within NowWAP, it is possible to limit certain client connections so that they are only able to connect to the host/domain names that are listed in the “Content Domains to receive X-MSISDN header” setting on the MSISDN page of the NowWAP configuration.

This setting is primarily used for determing which hosts should receive the “X-MSIDN:” header, which contains the phone number of the user making the request.

As a refresher, here is the description of this setting from the NowWAP documentation:

When a content domain is added to this list, a host name that exactly matches the content domain, as well as any host names within the content domain will receive the “X-MSISDN:” header. For example, if “now.co.uk” is added to the content domain list, the “X-MSISDN:” header would be forwarded to a host named “now.co.uk” as well as for “www.now.co.uk” and “mms.now.co.uk”. If you wish to have the “X-MSISDN” header forwarded to all content servers, define a content domain named “*”.

Within NowWAP, it is then possible to specify that certain client connections should only be allowed to connect to hosts/domains that are in this list. And obviously, the MMSC needs to be in this list in order to receive MSISDN information, as this is how that information is supplied to the MMSC.

To configure that all client connections should only be allowed to connect to hosts/domains in this list, edit WAPGW.INI and under the [WAPGW] header, add IncludeMsisdnConnectOnly=Yes.

Obviously, the above setting will only work for an MMS-only proxy, as it would otherwise be too restrictive.

However, it is also possible to selectively restrict a connection to hosts/domains in this list based upon one of the following criteria:

1.) Restriction based upon Multi-Homed Gateway IP Address

This is best described with an example.

Let’s say that the MMS-only APN gives out IP addresses on the 192.168.0.0 network.

The other APN, for browser traffic, gives out IP addresses on the 10.10.0.0 network.

The same WAP gateway is being used, the server operating system configured to be multi-homed on multiple networks.

Server address 10.10.0.1 would serve the browser network, and 192.168.0.1 would serve the MMS only network.

By adding IncludeMsisdnConnectOnlyGWIP=192.168.0.1 to the [WAPGW] section of the WAPGW.INI file, this would tell the WAP gateway that for any requests received by the server on 192.168.0.1, the gateway should only allow connections to domains/hosts in the “X-MSIDN” list. Connections to the gateway on other server addresses would not be restricted.

In order to make this solution work, it must not be possible (via firewall or networking setup) for any clients on the 192.168.0.0 network to connect to the WAP gateway on 10.10.0.1.

2.) Restriction based upon Client IP Address

This is, again, best described with an example.

Let’s say that the MMS-only APN gives out IP addresses on the 192.168.0.0 network.

The other APN, for browser traffic, gives out IP addresses on the 10.10.0.0 network.

The same WAP gateway is being used, the server operating system may be configured to be multi-homed on multiple networks (this is not required, but recommended to allow for possible separation of MMS and browser traffic in the future).

By adding IncludeMsisdnConnectOnlySourceIP=10.10.*.* to the [WAPGW] section of the WAPGW.INI file, this would tell the WAP gateway that for any requests that come from clients in that IP address range, the gateway should only allow connections to domains/hosts in the “X-MSIDN” list. Connections to the gateway from other client addresses would not be restricted. This setting can have a comma delimited list of IP addresses (e.g., 10.10.*.*,10,11.*.*). It does not support net masks … it can only use the “*” character as a wildcard in parts of the IP address.

For comments and further discussion, please click here to visit the NowSMS Technical Forums (Discussion Board)...