From f101c756a2f79cd3723112cf9e97d409b4a589bc Mon Sep 17 00:00:00 2001
From: bagyenda <>
Date: Mon, 17 Oct 2005 17:05:21 +0000
Subject: [PATCH] Update documentation to cover VAS GW changes.

---
 mbuni/doc/userguide.shtml | 1489 ++++++++++++++++++++++++++++++++++---
 1 file changed, 1379 insertions(+), 110 deletions(-)
diff --git a/mbuni/doc/userguide.shtml b/mbuni/doc/userguide.shtml
index 8e5cd0f..63c51b9 100644
--- a/mbuni/doc/userguide.shtml
+++ b/mbuni/doc/userguide.shtml
@@ -1,8 +1,10 @@
 
-<!-- when on site, user #include virtual="header.html" -->
-<!-- otherwise we use this:  --> 
+<!-- when on site, use #include virtual="header.html" -->
+<!--  otherwise use this: -->
 
 <!-- begin header -->
+<html>
+<head>
 <title>Mbuni: Open Source MMS Gateway - User documentation</title>
 <meta name="author" content="info@mbuni.org" />
 <meta name="Description" content="Open Source MMS Gateway" />
@@ -12,10 +14,14 @@
 <style type="text/css">  
   <!--
    H1       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT;color:#000000;}
-   H2       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#000000;}
-   H3       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#000000;}
-   H4       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#000000;}
-   body     {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#000000;}
+   H2       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#
+000000;}
+   H3       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#
+000000;}
+   H4       {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#
+000000;}
+   body     {font-family:Geneva,Verdana,Book Antiqua,Cochin,Calisto MT,Verdana;color:#
+000000;}
    a:link   {text-decoration:underline;color:#0000bb;}
    a:visited{text-decoration:underline;color:#bb0000;}
    a:active {text-decoration:underline;color:#bbbbbb;}
@@ -32,6 +38,7 @@ marginwidth="0" marginheight="0">
 <!-- end header -->
 
 
+
   <H2><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1"></A><!--TableOfContentsAnchor:End-->User Guide</H2>
   
 This document describes the installation and usage of the MMS Gateway.
@@ -51,17 +58,35 @@ This document describes the installation and usage of the MMS Gateway.
 <LI><A HREF="#Section_.1.2.3">Installing Required Components</A></LI>
 </UL></LI>
 <LI><A HREF="#Section_.1.3">Chapter 3: Running the Gateway</A><UL>
+<LI><A HREF="#run_mmsc">Running Mbuni as a MMSC</A></LI>
+<LI><A HREF="#run_vas">Running Mbuni as a VAS Gateway</A></LI>
 <LI><A HREF="#Section_.1.3.1">General Configuration File</A></LI>
+<LI><A HREF="#mmsc_conf">MMSC-specific Configuration</A><UL>
 <LI><A HREF="#mm7">MM7 Configuration</A></LI>
-<LI><A HREF="#mm4">MM4 Configuration File</A></LI>
+<LI><A HREF="#mm4">MM4 Configuration</A></LI>
+</UL>
+</LI>
+
+<LI><A HREF="#mmsvas_conf">MMS VAS Gateway-specific Configuration</A><UL>
+<LI><A HREF="#mmsc_vasp">MMSC Connection Configuration</A></LI>
+<LI><A HREF="#sendmms">SendMMS User Configuration</A></LI>
+<LI><A HREF="#mms_service">MMS Service Configuration</A></LI>
+</UL>
+</LI>
+
 </UL></LI>
 <LI><A HREF="#Section_.1.4">Chapter 4: Gateway Architecture</A><UL>
+<LI><A HREF="#mmsc_arch">MMSC Architecture</A><UL>
 <LI><A HREF="#Section_.1.4.1">MMS Proxy</A></LI>
 <LI><A HREF="#Section_.1.4.2">MMS Relay</A></LI>
 
 <LI><A HREF="#Section_.1.4.4">SMTP/Mail Interface</A></LI>
 <LI><A HREF="#Section_.1.4.5">Utilities</A></LI>
-</UL></LI>
+</UL>
+</LI>
+<LI>
+<A HREF="#vas_arch">VAS Gateway Architecture</A></LI>
+</UL>
 <LI><A HREF="#Section_.1.5">Chapter 5: Tips & Tricks</A><UL>
 <LI><A HREF="#Section_.1.5.1">Passing MSISDNs to Mbuni</A></LI>
 <LI><A HREF="#Section_.1.5.2"> Sample Kannel WAP configuration</A></LI>
@@ -91,18 +116,18 @@ explosion.
 </p>
 <p>
 The Mbuni Project attempts to provide that
-little bit of boost to MMS adoption/growth, by providing a crucial part of the
-MMS infrastructure in the form of a fully-fledged Open Source MMS Gateway (more
-commonly called a MMS Centre).</p>
+little bit of boost to MMS adoption/growth, by providing two important parts of the
+MMS infrastructure:  For the network &quot;operator&quot; Mbuni
+includes a fully-fledged MMS switching centre (MMSC), while for the MMS
+content provider Mbuni includes a MMS Value Added Services (VAS)
+Gateway (MMSBox).</p>
 
-<p>Mbuni aims to 
-support all the major MMS interfaces, including phone-to-phone (so-called MM1
+<p>Mbuni implements all major MMS interfaces, including phone-to-phone (so-called MM1
 interface), phone-to-email (MM3), inter-MMSC (MM4) and MMS VAS
-(MM7). The
-current release fully supports the MM1, MM3 and MM7 interfaces, and provides
-rudimentary support for the MM4 interface. This version also supports
-network-side MMBox storage and transactions as specified in the OMA
-MMS v1.2 specification. </p>
+(MM7). The level of support for each type of interface is listed on <a
+								       href="status.shtml">status 
+    page</a> of the website.
+</p>
 
 <p>Mbuni is
 inspired, in part by the Kannel project, and utilises Kannel's GWLIB and WAP
@@ -128,8 +153,13 @@ messages are typically transported over WAP, and are encoded using WAP MIME
 formats. </p>
 
 
-<p> The MMS Gateway acts as the
-message-switching device in the MMS architecture. The general architecture is
+<p> Multimedia messages can be originated by or terminate to end-user
+  client devices (i.e. MMS-enabled phones) or third party applications
+  (typically used by MMS content providers).  In the MMS architecture,
+  the MMSC acts as the
+message-switching system within the core network, while the MMSBox
+  acts as the message dispatch and content management system on the
+  VAS (third party) side. The overall architecture is
 shown below.</p>
 
 <center>
@@ -143,52 +173,60 @@ shown in the figure can be summarised as follows:</p>
 Client: </b>A device through
 which the user receives or sends multimedia messages. This might be a phone or
 a PC-based MMS client. The Client sends messages to and receives messages from
-the Gateway using WAP/HTTP as transport.
+the MMSC using WAP/HTTP as transport.
 <li><b>MMS
 Gateway:</b> Switches
 messages between different MMS clients and between MMS and Email. The Gateway
 may also interface with other gateways to exchange messages destined for
-foreign networks.
+foreign networks. This is also more properly known as the MMSC.
 <li><b>MMS
 Server:</b> This component
-typically providers persistent storage of messages on the network. Typically
+ provides persistent storage of messages on the network. Typically
 users can access stored messages via a web interface.
 <li><b>Other MMS
 Systems:</b>Other systems,
 such as Third Party MMS systems (e.g. MMS VAS providers) can interface to the
-Gateway to receive and send MMS content. The Interface used is termed
+MMSC to receive and send MMS content. The Interface used is termed
 MM7.
-<li><b>SMSC: </b>The MMS Gateway utilises WAP Push to send
+<li><b>SMSC: </b>The MMSC utilises WAP Push to send
 notifications to MMS Clients. These are typically sent using SMS as the bearer
 service, hence the need for a link to a Short Message Service Centre.
 </ul>
 
 
 <p>Typically, the
-message cycle begins with a user sending a multimedia message (MM) via the MMS
+message cycle begins with a user sending a multimedia message (MM) from the MMS
 client. The client must be configured for MMS, which includes bearer settings
 (i.e. GPRS or GSM/CSD settings), WAP gateway address and MMS Gateway address (a
-URL).</p>
+URL). On receipt of the message, the MMSC decides how to deliver the
+  message (e.g. to another MMS client or to a VASP), and proceeds to
+  dispatch the message. A VASP may also originate a message to the
+  MMSC, for onward delivery.</p>
 
 
 <p>An MM is typically a multi-part message
 with pictures, sound, text and other media. Each part of the message is
-identified by media (MIME) type, name and/or Content ID. When submitting a
+identified by media (MIME) type, name and/or Content ID. Usually the
+  message is of a multipart/related MIME type, with the start element
+  being a <a href="http://www.w3.org/AudioVideo/">SMIL</a> part that
+  controls how the message should be displayed.
+<br><br>
+ When submitting a
 message, the MMS client indicates the intended recipient list, but usually not
-the sender address, which the MMS Gateway retrieves from the WAP
+the sender address, which the MMSC retrieves from the WAP
 gateway. Like Email, a single MMS can specify
-multiple recipients (MSISDNs and Email addresses), and it is up to the Gateway
+multiple recipients (MSISDNs and Email addresses), and it is up to the MMSC
 to ensure correct delivery to each of the recipients. </p>
 
 
-<p>When the gateway
+<p>When the MMSC
 receives a message destined for an email address, it typically re-codes the
 message as standard MIME and passes it on to an SMTP server for delivery. Email
 messages received are similarly re-coded as MMS and forwarded to the relevant
 MMS Client.</p>
 
-<p>When the gateway receives a message
-destined to MMS Clients in the area served by the gateway, the message is
+<p>When the MMSC receives a message
+destined to MMS Clients in the area served by the MMSC, the message is
 stored and an MMS notification sent to the recipient via WAP Push. On receipt
 of the notification, the client typically fetches the message via a URL
 provided in the notification.</p>
@@ -198,27 +236,34 @@ provided in the notification.</p>
 <p>When a recipient requests an incoming MM
 from the server, it indicates to the server its capabilities for a User Agent
 Profile URL. The profile data includes such things as supported media types,
-screen size, supported character sets, etc. Typically, the gateway will re-code
+screen size, supported character sets, etc. Typically, the MMSC will re-code
 the MM to suit the client's capabilities before returning the message. Messages
 destined to email may also be re-coded to make them more suitable for email
 readers.</p>
 
 <p><![if !supportEmptyParas]>&nbsp;<![endif]></p>
 
-<p>The gateway may also interface with a
+<p>The MMSC may also interface with a
 subscriber database, which controls message delivery and billing. The
 subscriber database will provide such information as which subscribers are
 provisioned for MMS, tariffs, etc.</p>
 
-
+<p>
+  On the VASP side of things, typically the content provider receives
+  a request MM from a subscriber and must respond with an MM. The
+  content to be sent back depends on the contents of the request.
+</p>
 
 <H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.1.2"></A><!--TableOfContentsAnchor:End-->Features</H4>
 
 
 <p>Mbuni MMS gateway is a modular software system, designed to
-be full-featured, efficient and simple, supporting current generation two-way
-multimedia messaging. Feature highlights include:</p>
+be full-featured, efficient and simple, supporting current generation 
+multimedia messaging. Mbuni operates in one of two modes: As an MMSC
+  or as a VAS gateway. </p>
 
+<ul>
+<li> Operating as <b>MMSC</b>, Mbuni provides:
 <ul>
 <li>	Phone-to-phone messaging
 
@@ -241,7 +286,21 @@ provisioned, etc.
 <li>	Bearer (data) technology neutral: Works with GSM/CSD or GPRS.
 
 </ul>
+<li>Operating as a <b>VAS Gateway</b>, Mbuni provides:
 
+ <ul>
+   <li> Support for both SOAP and EAIF connectivity with an operator
+   MMSC
+   <li> Multiple connections to different MMSC of different types can
+   be maintained
+  <li> MMS content can be loaded from file, URL or as the output of a
+  program
+  <li> MM composition from <a href="http://www.w3.org/AudioVideo/">SMIL</a>: The gateway will automatically fetch
+  all components referenced in the SMIL and add them to the MM.
+  <li> A URL interface for MM dispatch.
+ </ul>
+
+</ul>
 
 <p>
 
@@ -297,7 +356,7 @@ not send MMS over WAP but directly over HTTP via an HTTP Proxy.
 
 Hardware requirements will depend on amount of traffic, required
 response times, etc. Keep in mind however that the gateway performs a
-lot of heavy media re-coding tasks, particularly during content
+lot of heavy multimedia re-coding tasks, particularly during content
 adaptation, so you should always err on the side of more rather than
 less power. 
 
@@ -305,8 +364,10 @@ less power.
 <H3><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.2"></A><!--TableOfContentsAnchor:End-->Chapter 2: Installing The Gateway</H3>
 
 <p>This section
-explains the steps required to install the gateway. Currently only installation
-from source is provided (binary option coming soon).</p>
+explains the steps required to install the gateway. If you are
+  installing from a binary distribution, you may safely skip to <a
+								   href="#required_comps">here</a>.
+</p>
 
 <p>
 In brief, to install Mbuni, you need to:
@@ -426,31 +487,34 @@ Kannel in a non-standard location, you will need to supply the location to <tt>c
 
 
 <p >Mbuni consists of
-3 programs:
+4 programs:
 <ul>
 <li><tt>mmsc/mmsrelay</tt>
 <li><tt>mmsc/mmsproxy</tt>
 <li><tt>mmsc/mmsfromemail</tt>
+<li><tt>mmsbox/mmsbox</tt>
 </ul>
 which are by
 default installed in <tt>/usr/local/bin</tt>
 </p>
 
-<p ><tt>mmsrelay</tt> is the main relay server. It routes
+<p ><tt>mmsrelay</tt> is the main relay server of the MMSC. It routes
 incoming messages to email, other MMS gateways, MMS clients/handsets,
 etc. It also manages routing messages to MMS clients 
 using WAP Push, sending of delivery reports, etc.
 <br><br>
  <tt>mmsproxy</tt>
-provides the HTTP interface via which messages are 
-sent and received by MMS clients. <br><br><tt>mmsfromemail </tt>Is
-the email2MMS gateway module. All programs must be configured, and the first
-three running for the gateway to function smoothly.</p>
+provides the HTTP interface of the MMSC via which messages are 
+sent and received by MMS clients. <br><br><tt>mmsfromemail </tt>is
+the email2MMS MMSC module. <br><br><tt>mmsbox</tt> is the VAS gateway
+
+</p>
 
 
+<a name="required_comps"></a>
 <H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.2.3"></A><!--TableOfContentsAnchor:End-->Installing Required Components</H4>
 
-<p>Be sure to install all other required
+<p>If you intend to use Mbuni as an MMSC, be sure to install all other required
 components as detailed above, otherwise parts of the MMS gateway may not
 function correctly. </p>
 
@@ -504,20 +568,28 @@ This AMR encoder
 is not very efficient but it works (which is important!)</p>
 
 <H3><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.3"></A><!--TableOfContentsAnchor:End-->Chapter 3: Running the Gateway</H3>
-
-<p>To run the gateway, you must run the
-two programs listed above (<tt>mmsrelay</tt>
+ 
+ How one runs Mbuni depends on its intended use or mode of
+ operation. We look at the two usage scenarios below.
+ 
+<h4><a name="run_mmsc"></a>Running Mbuni as a MMSC</h4>
+<p>To run the MMSC, you must run  (<tt>mmsrelay</tt>
 and <tt>mmsproxy</tt>). <tt>mmsfromemail</tt>
 should be called from your MTA (SMTP Mailer) to convert
 and deliver an MMS from an email sender. The order in which they are started
-is unimportant. They expect the configuration file to be passed as the last
-argument on the command line (default is <tt>mmsc.conf</tt>). The
-configuration file controls most aspects of 
-the operation of the gateway. </p>
+is unimportant. </p>
+
+<h4><a name="run_vas"></a>Running Mbuni as a VAS Gateway</h4>
+<p> To run Mbuni as a VAS gateway you must run <tt>mmsbox</tt> </p>
 
 <H4><!--TableOfContentsAnchor:Begin--><A
 NAME="Section_.1.3.1"></A><!--TableOfContentsAnchor:End-->General Configuration File</H4>
 
+<p>All Mbuni programs expect the configuration file to be passed as the last
+argument on the command line (default is <tt>mbuni.conf</tt>). The
+configuration file controls most aspects of 
+the operation of the gateway. </p>
+
 <p >The configuration file format is the same as that used
 by Kannel. The configuration file consists of groups of configuration
 variables. Groups are separated by empty lines, each variable is defined on its
@@ -538,8 +610,13 @@ beginning of a new group with the given name.</p>
 <p >The core group is
 <i>core</i> and defines the log file location, log level (amount of debugging
 information &#8211; the lower the number the more debugging
-information), the location of the access log and the HTTP proxy host/port if any. (HTTP proxy host/port
- is specified using the exact same parameters as used by Kannel.)
+information), the location of the access log, the HTTP proxy
+host/port if any (HTTP proxy host/port 
+ is specified using the exact same parameters as used by Kannel.) and
+SSL client and server certificate files to be used for incoming and
+outgoing HTTPS connections, if Kannel and Mbuni are compiled to have
+SSL enabled. The syntax for specifying SSL certificates is exactly as
+that used by Kannel. 
 
 <br>
 <br>
@@ -556,14 +633,13 @@ access-log = log/access.log<br>
 </tt>
 </p>
 <p>
-This should be
-followed by the main MMS gateway configuration group (<i>mmsbox</i>). 
+This should be followed by the main gateway configuration group (<i>mbuni</i>). 
 <br>
 <br>
 <tt>
 
 group =
-mmsbox<br>
+mbuni<br>
 
 name =
 &quot;My MMSC&quot;<br>
@@ -593,7 +669,17 @@ send-mail-prog
 </tt>
 </p>
 <p >The table below
-lists all the configuration directives</p>
+lists all the configuration directives. Items in black are used by
+  both modes of operation, while those in <b><span style="color: #001177;
+						       background:
+						       white">blue</span></b>
+  are used only when 
+  operating in VAS Gateway mode, and those in <b><span style="color:
+							   #770011;
+						       background:
+						       white">red</span></b> when
+    operating in 
+  MMSC mode.</p>
 
 <table border=0 cellspacing=2 cellpadding=1 >
  <tr>
@@ -608,7 +694,7 @@ lists all the configuration directives</p>
   <b>Description</b>
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr >
   <td valign=top><tt>group </tt>
   &nbsp; &nbsp;</td>
   <td valign=top>
@@ -630,7 +716,7 @@ lists all the configuration directives</p>
   name for the Gateway, used in notices, etc
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top ><tt>hostname
   </tt>
   &nbsp; &nbsp;</td>
@@ -643,7 +729,7 @@ lists all the configuration directives</p>
   Email or to a foreign MMSC via SMTP. Defaults to <tt>localhost</tt>
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top ><tt>host-alias
   </tt>
   &nbsp; &nbsp;</td>
@@ -661,7 +747,7 @@ lists all the configuration directives</p>
   notifications. If you do not supply a host alias, the gateway will create a long form URL (http://<i>hostname:port/msgtoken</i>) when it sends notifications
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td valign=top >
   <tt>local-mmsc-domains</tt>
 
@@ -676,7 +762,7 @@ lists all the configuration directives</p>
   or MMS messages received destined to these domains should be treated as local
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top ><tt>local-prefixes</tt> 
   &nbsp; &nbsp;</td>
   <td valign=top >
@@ -717,7 +803,7 @@ lists all the configuration directives</p>
   faster.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>send-mail-prog</tt>
   &nbsp; &nbsp;</td>
@@ -761,7 +847,7 @@ lists all the configuration directives</p>
   <td  valign=top >
   Maximum number
   of attempts gateway must make to deliver message before giving up (e.g.
-  mobile phone is off, email domain is unavailable)
+  mobile phone is off, VAS service is down, email domain is unavailable)
   &nbsp; &nbsp;</td>
  </tr>
  <tr>
@@ -800,12 +886,11 @@ lists all the configuration directives</p>
   Integer
   &nbsp; &nbsp;</td>
   <td  valign=top >
-  <tt>mmsrelay</tt> uses a form of exponential back-off
-  when sending notifications to MMS clients. This figure provides the starting
-  back-off value (in seconds).
+   The exponential back-off factor to employ on subsequent message
+  delivery attempts, when a delivery attempt fails.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>sendsms-url</tt>
   &nbsp; &nbsp;</td>
@@ -819,7 +904,7 @@ lists all the configuration directives</p>
   parameters (udh, from, to, text, etc.)
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>sendsms-username</tt>
 
@@ -832,7 +917,7 @@ lists all the configuration directives</p>
   pass (for authentication) to send-sms URL
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>sendsms-password</tt>
   &nbsp; &nbsp;</td>
@@ -844,7 +929,7 @@ lists all the configuration directives</p>
   pass (for authentication) to send-sms URL
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>sendsms-global-sender</tt>
   &nbsp; &nbsp;</td>
@@ -856,7 +941,7 @@ lists all the configuration directives</p>
   (<i>to</i> field) to use in send sms url 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-port</tt>
 
@@ -871,7 +956,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mm7-port</tt>
 
@@ -896,12 +981,31 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
   <td  valign=top >
   List of IP
-  addresses of hosts allowed to use/access the MMS Port (above). You can use
+  addresses of hosts allowed to use/access the Send MMS Port (MM1
+  interface for MMSC
+  or SendMMS port  for VAS Gateway). You can use
   this for instance to insist that only connections coming via a known/trusted
-  WAP gateway are serviced. Leave out to allow all machines to connect. 
+  WAP gateway are serviced by the MMSC. Leave out to allow all machines to connect. 
   &nbsp; &nbsp;</td>
  </tr>
+
  <tr>
+  <td  valign=top >
+  <tt>deny-ip</tt>
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses of hosts <i>not</i> allowed to use/access the Send MMS Port (MM1
+  interface for MMSC
+  or SendMMS port  for VAS Gateway). 
+  &nbsp; &nbsp;</td>
+ </tr>
+
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-client-msisdn-header</tt>
   &nbsp; &nbsp;</td>
@@ -917,7 +1021,7 @@ lists all the configuration directives</p>
   (default header name is <tt>X-WAP-Network-Client-MSISDN</tt>) 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-client-ip-header</tt>
   &nbsp; &nbsp;</td>
@@ -936,7 +1040,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>allow-ip-type</tt>
   &nbsp; &nbsp;</td>
@@ -948,7 +1052,7 @@ lists all the configuration directives</p>
   senders identified by IP address (i.e. not by MSISDN). Default: True.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>optimize-notification-size</tt>
   &nbsp; &nbsp;</td>
@@ -961,7 +1065,7 @@ lists all the configuration directives</p>
   fields. Default: false
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>content-adaptation</tt>
   &nbsp; &nbsp;</td>
@@ -975,7 +1079,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>email2mms-relay-prefixes</tt>
   &nbsp; &nbsp;</td>
@@ -992,7 +1096,7 @@ lists all the configuration directives</p>
   list.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>billing-library</tt>
   &nbsp; &nbsp;</td>
@@ -1006,7 +1110,7 @@ lists all the configuration directives</p>
   generation. See <tt>mms_billing.h</tt> for details.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>billing-module-parameters</tt>
   &nbsp; &nbsp;</td>
@@ -1020,7 +1124,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>resolver-library</tt>
   &nbsp; &nbsp;</td>
@@ -1037,7 +1141,7 @@ lists all the configuration directives</p>
   <tt>mms_resolve.h</tt> for details. 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>resolver-module-parameters</tt>
   &nbsp; &nbsp;</td>
@@ -1051,7 +1155,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>detokenizer-library</tt>
   &nbsp; &nbsp;</td>
@@ -1068,7 +1172,7 @@ lists all the configuration directives</p>
   <tt>mms_detokenize.h</tt> for details. 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>detokenizer-module-parameters</tt>
   &nbsp; &nbsp;</td>
@@ -1082,7 +1186,7 @@ lists all the configuration directives</p>
   &nbsp; &nbsp;</td>
  </tr>
 
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>prov-server-notify-script</tt>
   &nbsp; &nbsp;</td>
@@ -1099,7 +1203,7 @@ lists all the configuration directives</p>
   failed fetch provides a description of the error (e.g. message expired). 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>prov-server-sub-status-script</tt>
   &nbsp; &nbsp;</td>
@@ -1117,7 +1221,7 @@ lists all the configuration directives</p>
   <tt>mmsrelay</tt> will deliver the message (see below). 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top>
   <tt>notify-unprovisioned</tt>
   &nbsp; &nbsp;</td>
@@ -1130,7 +1234,7 @@ lists all the configuration directives</p>
   (e.g. SMS) when an MMS message is received for them.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top>
   <tt>mms-notify-text</tt>
   &nbsp; &nbsp;</td>
@@ -1143,7 +1247,7 @@ lists all the configuration directives</p>
   This message is sent as plain SMS via the Send SMS URL specified above.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-notify-unprovisioned-text</tt>
   &nbsp; &nbsp;</td>
@@ -1156,7 +1260,7 @@ lists all the configuration directives</p>
   <tt>notify-unprovisioned</tt> is true).
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-message-too-large-txt</tt>
   &nbsp; &nbsp;</td>
@@ -1171,7 +1275,7 @@ lists all the configuration directives</p>
   part of an MMS message.
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-to-email-html</tt>
   &nbsp; &nbsp;</td>
@@ -1188,7 +1292,7 @@ lists all the configuration directives</p>
   is tagged at the bottom of the HTML. 
   &nbsp; &nbsp;</td>
  </tr>
- <tr>
+ <tr style="color:  #770011; background: white">
   <td  valign=top >
   <tt>mms-to-email-txt</tt>
   &nbsp; &nbsp;</td>
@@ -1201,11 +1305,43 @@ lists all the configuration directives</p>
   email clients that do not support HTML.
   &nbsp; &nbsp;</td>
  </tr>
+
+
+ <tr style="color:  #001177; background: white">
+  <td  valign=top >
+  <tt>sendmms-port</tt>
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  number
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  The port on which the MMS VAS gateway listens for incoming MMS send
+  requests. (Optional.)
+  &nbsp; &nbsp;</td>
+ </tr>
+ <tr style="color:  #001177; background: white">
+  <td  valign=top >
+  <tt>sendmms-port-ssl</tt>
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+Boolean
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+    Set to true if SendMMS port of VAS Gateway should be secure
+  (HTTPS). This is only supported if Mbuni is compiled with SSL support.
+  &nbsp; &nbsp;</td>
+ </tr>
+
 </table>
 <br>
 
+<a name="mmsc_conf"></a>
+<h4>MMSC-specific Configurations</h4>
+ This section describes extra configuration sections that should only
+ be used when Mbuni is configured to operate as an MMSC. 
+
 <a name="mm7"></a>
-<h4>MM7 Configuration</h4>
+<h5>MM7 Configuration</h5>
 
 <!--- MM7 stuff -->
 <p >MMS Value-Added Service Providers (VASPs)  are configured using
@@ -1374,7 +1510,7 @@ by Mbuni (for both incoming and out-going requests).
 
 
 <a name="mm4"></a>
-<h4>MM4 Configuration</h4>
+<h5>MM4 Configuration</h5>
 
 <!-- Foreign MMSC stuff -->
 
@@ -1485,20 +1621,1103 @@ the message. If one is found, the message is formatted as MIME and
 sent via SMTP to the proxy. 
 </p>
 
+<a name="mmsvas_conf"></a>
+<h4>MMS VAS Gateway-specific Configuration</h4>
+<p>
+ When Mbuni is used as a VAS Gateway, the configurations in this
+ section are required to ensure smooth functioning of the system. We
+ describe each configuration set in turn.
+
+</p>
+
+<a name="mmsc_vasp"></a>
+<h5>MMSC Connection Configuratiom</h5>
+
+<p>
+  MMSC connections are configured using one or more <i>mmsc</i>
+  groups:
+</p>
+
+<tt>
+group = mmsc<br>
+id = testone<br>
+mmsc-url = http://mbuni:test@192.168.129.52:8080/eaif<br>
+incoming-username = user<br>
+incoming-password = pass<br>
+incoming-port = 10002<br>
+type = eaif<br>
+</tt>
+
+<br>
+Supported configuration parameters are:
+<br>
+<table border=0 cellspacing=2 cellpadding=2 >
+ <tr>
+  <td  valign=top >
+  <b>Variable</b>
+  </td>
+  <td  valign=top >
+  <b>Type</b>
+  </td>
+  <td  valign=top >
+  <b>Description</b>
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+  <tt>group</tt>
+
+  </td>
+  <td  valign=top >
+  String
+  </td>
+  <td  valign=top >
+  Mandatory:
+  <tt>mmsc</tt>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>id</tt>
+
+  </td>
+  <td  valign=top >
+  String
+  </td>
+  <td  valign=top >
+  Mandatory:
+   Identifying name for this connection (used in logs for instance)
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>type</tt>
+
+  </td>
+  <td  valign=top >
+  String
+  </td>
+  <td  valign=top >
+  Mandatory:
+   Protocol spoken by this MMSC, one of <tt>soap</tt> (for 3GPP MM7
+   SOAP) or <tt>eaif</tt> for Nokia EAIF protocol.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>mmsc-url</tt>
+
+  </td>
+  <td  valign=top >
+  String
+  </td>
+  <td  valign=top >
+  Mandatory:
+   URL address for  the MMSC. Used for outgoing messages
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>incoming-port</tt>
+
+  </td>
+  <td  valign=top >
+  Number
+  </td>
+  <td  valign=top >
+   Port at which Mbuni listens for incoming messages from MMSC
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>incoming-user</tt>
+
+  </td>
+  <td  valign=top >
+string 
+  </td>
+  <td  valign=top >
+   Username to be used by MMSC to authenticate itself to Mbuni for
+   incoming connections. (Using HTTP basic authentication scheme.)
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>incoming-password</tt>
+
+  </td>
+  <td  valign=top >
+string 
+  </td>
+  <td  valign=top >
+   Password to be used by MMSC to authenticate itself to Mbuni for
+   incoming connections
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>incoming-port-ssl</tt>
+
+  </td>
+  <td  valign=top >
+  Boolean
+  </td>
+  <td  valign=top >
+   Specifies whether incoming port is secure (i.e. incoming requests
+   use secure HTTP). Only supported if Mbuni is compiled with SSL support.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>allow-ip</tt>
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses of hosts allowed to use/access the incoming MMS port</td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>deny-ip</tt>
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses
+  &nbsp; &nbsp;</td>
+  <td  valign=top >
+  List of IP
+  addresses of hosts <i>not</i> allowed to use/access the incoming
+  MMS port
+  &nbsp; &nbsp;</td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>allowed-prefix</tt>
+  </td>
+  <td  valign=top >
+  Number list
+  </td>
+  <td  valign=top >
+  List of
+  recipient number prefixes that can be delivered via this MMSC (used
+  for routing out-going messages)
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+  <tt>denied-prefix</tt>
+  </td>
+  <td  valign=top >
+  Number list
+  </td>
+  <td  valign=top >
+  List of
+  recipient number prefixes that cannot be delivered via this MMSC
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>max-throughput</tt>
+  </td>
+  <td  valign=top >
+  Number
+  </td>
+  <td  valign=top >
+    Maximum number of messages per second (outgoing) that this MMSC
+    can handle.
+  </td>
+ </tr>
+
+</table>
+
+
+<a name="sendmms"></a>
+<h5>SendMMS User Configuration</h5>
+
+<p>
+ To be able to send MMS into Mbuni via the sendMMS port (if
+ configured), at least one sendmms user must be configured:
+</p>
+
+<tt>
+
+group = send-mms-user<br>
+username = tester<br>
+password = foobar<br>
+faked-sender = 100<br>
+</tt>
+<p>
+ Configuration parameters are:
+
+<table border=0 cellspacing=2 cellpadding=2 >
+ <tr>
+  <td  valign=top >
+  <b>Variable</b>
+  </td>
+  <td  valign=top >
+  <b>Type</b>
+  </td>
+  <td  valign=top >
+  <b>Description</b>
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>group</tt>
+  </td>
+  <td  valign=top >
+  mandatory
+  </td>
+  <td  valign=top >
+  <tt>send-mms-user</tt>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>username</tt>
+  </td>
+  <td  valign=top >
+  mandatory
+  </td>
+  <td  valign=top >
+   Username
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>password</tt>
+  </td>
+  <td  valign=top >
+  mandatory
+  </td>
+  <td  valign=top >
+   Password
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>faked-sender</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+   Optional sender address used (irrespective of whether from address
+   has been specified in MMS send request).
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>deliver-report-url</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+   Optional URL to call to send message delivery status as reported to
+   the VAS gateway by a MMSC for a message submitted by this user.
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>read-report-url</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+   Optional URL to call to send message read status reports as returned to
+   the VAS gateway by a MMSC for a message submitted by this user.
+  </td>
+ </tr>
+</table>
+
+</p>
+
+<p>
+  The Send MMS service can be invoked using HTTP GET requests to the
+  Send MMS port on the VAS Gateway hosts. The interface expects and
+  processes the following CGI paramerters:
+</p>
+<p>
+<table border=0 cellspacing=2 cellpadding=2 >
+
+ <tr>
+  <td  valign=top nowrap>
+    <b>CGI Variable&nbsp;</b>
+  </td>
+  <td  valign=top >
+    <b>Description</b>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>username</tt>
+  </td>
+  <td  valign=top >
+  authentication username (must match a configured send-mms-user).
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>password</tt>
+  </td>
+  <td  valign=top >
+  authentication password (must match password of corresponding send-mms-user).
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>from</tt>
+  </td>
+  <td  valign=top >
+   Message sender. This is over-ridden by <tt>faked-sender</tt>
+   setting of the send-mms-user.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>to</tt>
+  </td>
+  <td  valign=top >
+  Message recipient(s). Multiple recipients can be separated with a whitespace.
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+    <tt>subject</tt>
+  </td>
+  <td  valign=top >
+   Message subject
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+    <tt>mmsc</tt>
+  </td>
+  <td  valign=top >
+    Outgoing MMSC via which to route the message. If this is not
+    given, the VAS Gateway routes the message based on the recipient
+    address and the <tt>allowed-prefix</tt>/<tt>denied-prefix</tt>
+    settings for the configured MMSCs. <i>Note: The VAS Gateway
+    considers that any MMSC can handle email and IP address recipient
+    addresses and so routes messages to such destinations to the first
+    configured MMSC</i>
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+    <tt>dlr-url</tt>
+  </td>
+  <td  valign=top >
+  URL to invoke when a delivery report for this message is received
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+    <tt>rr-url</tt>
+  </td>
+  <td  valign=top >
+   URL to invoke when a read report for this message is received
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>text</tt>
+  </td>
+  <td  valign=top >
+  If provided, this is used as the (text) content of the MM to be
+  sent. The content type of the MM is set to <tt>text/plain</tt>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>charset</tt>
+  </td>
+  <td  valign=top >
+  Used in conjuction with the <tt>text</tt> parameter, it specifies
+  the character set of the text, if it is not the default (iso-8859-1).
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+    <tt>smil</tt>
+  </td>
+  <td  valign=top >
+  If provided, specifies the SMIL for the MM. An MM is built out of
+  the SMIL as described <a href="#how_content">below</a>, and the MM body
+  will have content type <tt>multipart/related</tt>, which is the
+  expected default.
+  </td>
+ </tr>
+
+</table>
+  
+</p>
+
+
+<p>
+
+If a <tt>delivery-report-url</tt> or <tt>read-report-url</tt> is
+specified for the send mms user (or as parameters in the send mms
+request), and a report is sent to the VAS
+Gateway by a MMSC, the relevant URL is called (using the HTTP GET
+method), and information about the report sent to it via <a
+							    href="#x_mbuni_headers"><tt><i>X-Mbuni</i></tt>
+    headers</a>.
+</p>
+
+<a name="mms_service"></a>
+<h5>MMS Service Configuration</h5>
+
+<p>
+ Messages are routed to services based on the first word of the text
+ part of the MM. That is, Mbuni extracts the first text part of the
+ MM, and finds the first word &mdash; the keyword &mdash; in the
+ message. Mbuni then searches through the list of
+ configured MMS Services for a matching service based on the
+ keyword, and fetches the response from the  associated URL, file or
+ program. 
+</p>
+
+<p>
+ A sample service configuration might look like this:<br>
+
+<tt>
+group = mms-service<br>
+name = me<br>
+post-url = http://localhost/photoblog.php<br>
+catch-all = true<br>
+http-post-parameters = fx=true&amp;images[]=%i&amp;text[]=%t<br>
+accept-x-mbuni-headers = true<br>
+keyword = test<br>
+</tt>
+
+<br>
+A detailed list of configuration parameters for MMS Services is given below.
+</p>
+
+
+<p>
+
+<table border=0 cellspacing=2 cellpadding=2 >
+ <tr>
+  <td  valign=top >
+  <b>Variable</b>
+  </td>
+  <td  valign=top >
+  <b>Type</b>
+  </td>
+  <td  valign=top >
+  <b>Description</b>
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>group</tt>
+  </td>
+  <td  valign=top >
+  mandatory
+  </td>
+  <td  valign=top >
+  <tt>mms-service</tt>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>name</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+   Service name. Used for logging, also sent to MMSC as VAS ID
+   parameter for MM7 SOAP requests
+  </td>
+ </tr>
+
+
+ <tr>
+  <td  valign=top >
+  <tt>keyword</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    mandatory keyword. Incoming messages whose text part matching this
+    parameter will be routed via this service.
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+  <tt>aliases</tt>
+  </td>
+  <td  valign=top >
+  list of string
+  </td>
+  <td  valign=top >
+   semi-colon separated list of keyword aliases. Any of these keywords
+   will also match and cause message to be routed via the service.
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+  <tt>catch-all</tt>
+  </td>
+  <td  valign=top >
+  boolean
+  </td>
+  <td  valign=top >
+  Set this to <tt>true</tt> if this is the default service (i.e. all
+  other messages routed through this service in case of no match).
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+  <tt>accepted-mmscs</tt>
+  </td>
+  <td  valign=top >
+  list of strings
+  </td>
+  <td  valign=top >
+    semi-colon separated list of MMSCs (listed by ID). Only messages
+    from these MMSCs will be routed to this service on match. Leave
+    this empty to allow all.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>denied-mmscs</tt>
+  </td>
+  <td  valign=top >
+  list of strings
+  </td>
+  <td  valign=top >
+     Messages
+    from these MMSCs will <i>never</i> be routed to this service on match. Leave
+    this empty to allow all.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>get-url</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+  The URL to fetch for response content. No parameter substitution is
+  done, but <i>X-Mbuni</i> headers are sent as part of the HTTP request. See
+  <a href="#how_content">below</a> for an explanation on how the
+  response content is interpreted. 
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>exec</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    Program to execute to obtain response content. Response is
+    exptected on standard output, and <b><i>must</i></b> be of type
+    SMIL. See <a href="#how_content">below</a> for an explanation on how
+    the SMIL is processed. 
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>file</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    File from which to obtain response content. Response type is
+    inferred from the file name extension for a few well-known media
+    types (text, SMIL, GIF, JPEG, PNG, BMP/WBMP, WAV, AMR, MP3, etc.),
+    otherwise it defaults to <tt>application/octet-stream</tt>. See <a
+    href="#how_content">below</a> for further information on how
+    fetched content is converted to an MM. 
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>text</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    If provided, the response content is the value of this parameter,
+    and is assumed to be of media type <tt>text/plain</tt>.
+  </td>
+ </tr>
+
+
+  <tr>
+  <td  valign=top >
+  <tt>post-url</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    Response content is obtained as result of sending a HTTP POST
+    request to the provided URL. The POST message is <i>always</i>
+    submitted using the
+    <tt>multipart/form-data</tt> encoding (such as that used by a web  browser
+    when an HTML form has the <tt>enctype=multipart/form-data</tt>
+    parameter set). If <tt>http-post-parameters</tt> field is given
+    (see 
+    below), then the relevant parameters are sent as part of the
+    request. <i>X-Mbuni</i> headers are sent as well. See
+  <a href="#how_content">below</a> for an explanation on how the
+  response content is interpreted. 
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>http-post-parameters</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    Used in conjunction with <tt>post-url</tt>. Parameters are
+    provided in the same way as would be provided in an HTTP GET
+    request (e.g. <i>message=true&amp;myname=test&amp;image=%i</i>). 
+    Parameter values that begin with % are interpolated according to
+    the rules listed <a href="#post_params">below</a>.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>accept-x-mbuni-headers</tt>
+  </td>
+  <td  valign=top >
+  boolean
+  </td>
+  <td  valign=top >
+    Set this to true if Mbuni should honour <i>X-Mbuni</i> HTTP
+    headers in the service response. See <a
+    href="#x_mbuni_headers">below</a> for the list of headers.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>omit-empty</tt>
+  </td>
+  <td  valign=top >
+  boolean
+  </td>
+  <td  valign=top >
+    Set this to true if Mbuni should send an empty response to the
+    requestor if one is returned by the service
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>assume-plain-text</tt>
+  </td>
+  <td  valign=top >
+  boolean
+  </td>
+  <td  valign=top >
+  Set this to true if an unknown content type in the response should
+  be mapped to plain text.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+  <tt>faked-sender</tt>
+  </td>
+  <td  valign=top >
+  string
+  </td>
+  <td  valign=top >
+    If set, Mbuni will change the sender address in the response
+    message to this value, irrespective of any <i>X-Mbuni</i> headers
+    or the original recipient address.
+  </td>
+ </tr>
+
+</table>
+<br>
+ Note that only one
+ of <tt>get-url</tt>, <tt>post-url</tt>, <tt>file</tt>
+ or <tt>text</tt> may be specified.
+</p>
+
+<br>
+<a name="how_content"></a>
+<b>How Response Content Is Interpreted</b>
+
+<p>
+  When the MMS Service response content is fetched by the  VAS
+  gateway, it is converted into an MM based on the reported or
+  inferred (in the case of <tt>file</tt> content) response content
+  type. For content fetched from URLs, the content type is taken as
+  received from the HTTP server. For <tt>file</tt> content it is
+  inferred from the file extension. For <tt>exec</tt> content, it is
+  assumed to be SMIL. 
+
+ General conversion rules are as follows:<br>
+
+ <ul>
+  <li><b>SMIL:</b> If the content type is <tt>application/smil</tt>,
+  the VAS gateway parses the SMIL and finds all content (e.g. images,
+  audio) it references. (&quot;Referenced&quot; is
+  currently interpreted as any element with an <tt>src</tt>
+  attribute.) These are fetched and added to the
+  response MM, and corresponding SMIL component modified
+  (i.e. the <tt>src</tt> attribute modified) to reference
+  the content within the MM. Note that the VAS gateway is smart enough
+  to understand partial URL or file references
+  (e.g. <tt>images/smile.gif</tt> or <tt>./test.txt</tt>), as well as
+  absolute (e.g. <tt>/images/smile.gif</tt>
+  or <tt>http://somehost/test.txt</tt>) references within the
+  SMIL. It will attempt  to fetch the content relative to the
+  location of the base SMIL content in the case of relative references. To prevent
+  the content from being fetched, you can prepend a backslash to the
+  location value. <br>
+    The resulting MM will be a standard multipart/related message,
+  with the SMIL as the start element.
+  </li> 
+<li><b>MMS Content Type:</b> If the returned content type
+  is <tt>application/vnd.wap.mms-message</tt>, the content is assumed
+  to be a binary-coded MM and will be returned as the response
+  content. 
+</li>
+<li>
+  <b>Other Content Types:</b> All other content types cause an MM to
+  be built having the corresponding content type. Where the content
+  type is not reported (or is impossible to determine) in the
+  response, if the parameter <tt>assume-plain-text</tt> is set, MIME
+  type <tt>text/plain</tt> is assumed.
+  </li>
+ </ul>
+
+</p>
+
+<br>
+<a name="x_mbuni_headers"></a>
+<b><i>X-Mbuni</i> Headers</b>
+<br><br>
+<p>
+   Mbuni VAS Gateway utilises a number of HTTP extension headers to
+   pass additional MM information to and receive information from the
+   MMS Service. Note that all applicable headers are always sent in
+   the HTTP request, but headers are only honoured in the response if
+   the <tt>accept-x-mbuni-headers</tt> parameter of the service is set
+   to <tt>true</tt>. On the response side, if honoured, the set values
+   over-ride the ones in the request, and are used in the response.
+
+ <br><br>
+ The list of supported headers is listed below:<br><br>
+
+<table border=0 cellspacing=2 cellpadding=2 >
+
+ <tr>
+  <td  valign=top nowrap>
+    <b>Header&nbsp;</b>
+  </td>
+  <td  valign=top >
+    <b>Description</b>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-From</tt>
+  </td>
+  <td  valign=top >
+    MM Sender address (e.g. +25674334444/TYPE=PLMN)
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-Subject</tt>
+  </td>
+  <td  valign=top >
+    MM Subject
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-To</tt>
+  </td>
+  <td  valign=top >
+    Recipient address. Multiple recipients can be specified as
+    separate headers or as a comma-separated value
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-Expiry</tt>
+  </td>
+  <td  valign=top >
+    MM Expiry as an HTTP date.
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-DLR-Url</tt>
+  </td>
+  <td  valign=top >
+    Delivery report URL. This URL will be called with the delivery
+    report status. It is also sent <i>X-Mbuni</i> headers
+  </td>
+ </tr>
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-RR-Url</tt>
+  </td>
+  <td  valign=top >
+   Read Report URL. This URL is called with the read report status. It
+   is sent <i>X-Mbuni</i> headers.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-MMSC</tt>
+  </td>
+  <td  valign=top >
+    MMSC (id) through which message was received (on the request side)
+    or through which it
+    should be routed.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-Message-ID</tt>
+  </td>
+  <td  valign=top >
+    MM message ID. Only makes sense on the request side.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-Report-Type</tt>
+  </td>
+  <td  valign=top >
+    One of <tt>delivery-report</tt> or <tt>read-report</tt>, used when
+    calling the DLR or RR URL.
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>X-Mbuni-MM-Status</tt>
+  </td>
+  <td  valign=top >
+    Report status. Used in conjuction with <i>X-Mbuni-Report-Type</i>
+    for transmitting report status.
+  </td>
+ </tr>
+</table>
+</p>
+
+<br>
+
+<a name="post_params"></a>
+<b>HTTP POST Parameters</b>
+<br>
+<p>
+  When a <tt>post-url</tt> is used, you may specify the GCI parameters
+  to be sent in the POST transaction, using % escaepe codes as
+  interpolation markers. The list of supported escape codes is listed
+  below:<br>
+
+<table border=0 cellspacing=2 cellpadding=2 >
+
+ <tr>
+  <td  valign=top nowrap>
+    <b>Escape Code&nbsp;</b>
+  </td>
+  <td  valign=top >
+    <b>Description</b>
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%i</tt>
+  </td>
+  <td  valign=top >
+    Image part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%v</tt>
+  </td>
+  <td  valign=top >
+    Video part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%t</tt>
+  </td>
+  <td  valign=top >
+    Text part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%s</tt>
+  </td>
+  <td  valign=top >
+    SMIL part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%a</tt>
+  </td>
+  <td  valign=top >
+    Audio part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%b</tt>
+  </td>
+  <td  valign=top >
+    Entire, binary coded MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%z</tt>
+  </td>
+  <td  valign=top >
+    All part(s) of the MM
+  </td>
+ </tr>
+
+ <tr>
+  <td  valign=top >
+    <tt>%o</tt>
+  </td>
+  <td  valign=top >
+    Other part(s) of the MM (not text, video, audio, smil, or audio)
+  </td>
+
+ <tr>
+  <td  valign=top >
+    <tt>%%</tt>
+  </td>
+  <td  valign=top >
+   Interpolated as %.
+  </td>
+
+ </tr>
+
+</table><br><br>
+
+ Note that the parameter name/value is repeated as many times in the
+ POST data as there are matching parts in the message. That is, if
+ there are three images in the MM and <tt>http-post-parameters</tt>
+ is <i>image=%i</i> then the parameter <i>image</i> will be passed
+ thrice, with different values. (The CGI script used must therefore
+ be prepared to handle multiple parameters with the same name.) <br><br>
+
+ Because <tt>multipart/form-data</tt> encoding is used in the HTTP
+ POST transaction, the content type of each element, as well as its
+ name (if present in the MM) are sent to the service URL. 
+
+ <br><br>
+
+ All other URL parameter name/value pairs are passed to the service
+ URL as-is.
+</p>
+<br>
+
 <H3><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4"></A><!--TableOfContentsAnchor:End-->Chapter 4: Gateway Architecture</H3>
 
 <p>
  In this section we provide an overview of the gateway architecture.
 
 <br>
-<br>
-As indicated, there are thre components to the gateway: The Relay
+
+<a name="mmsc_arch"></a>
+<h4>MMSC Architecture</h4>
+
+As indicated, there are three components of the MMSC: The Relay
 (<tt>mmsrelay</tt>), the Proxy
 (<tt>mmsproxy</tt>) and SMTP/Email Interface (<tt>mmsfromemail</tt>). We describe the
 function of each of these in turn. 
 </p>
 
-<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.1"></A><!--TableOfContentsAnchor:End-->MMS Proxy</H4>
+<H5><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.1"></A><!--TableOfContentsAnchor:End-->MMS Proxy</H5>
 
 <p>
 
@@ -1577,15 +2796,14 @@ original submitted can cancel a message.
 				th queue.
 </ul>
 <br>
-Note that only SOAP MM7 requests are supported at this stage.
+Both SOAP and EAIF MM7 requests are supported.
 
 <br>
 This component must always be running.
 
-
 </p>
 
-<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.2"></A><!--TableOfContentsAnchor:End-->MMS Relay</H4>
+<H5><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.2"></A><!--TableOfContentsAnchor:End-->MMS Relay</H5>
 
  The Relay manages routing of all messages (to phone, email, VASP). 
 <p>
@@ -1664,7 +2882,7 @@ See <tt>mms_queue.h</tt> for details.
 </p>
 
 <p>
-<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.4"></A><!--TableOfContentsAnchor:End-->SMTP/Mail Interface</H4>
+<H5><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.4.4"></A><!--TableOfContentsAnchor:End-->SMTP/Mail Interface</H5>
 
 The SMTP/Mail interface receives MMS from the MTA and routes them
 depending on recipient or sending proxy. Specifically:
@@ -1695,8 +2913,8 @@ and be handed over to this interface if they are legitimate.
 </p>
 
 <p>
-<H4><!--TableOfContentsAnchor:Begin--><A
-NAME="Section_.1.4.5"></A><!--TableOfContentsAnchor:End-->Utilities</H4>
+<H5><!--TableOfContentsAnchor:Begin--><A
+NAME="Section_.1.4.5"></A><!--TableOfContentsAnchor:End-->Utilities</H5>
 
  We plan to add a number of utilities to the gateway.  The first of
  these is <tt>mmssend</tt>.
@@ -1727,13 +2945,62 @@ The message is placed in he global queue with expiry set to the system
 maximum, and the queue entry ID is printed to standard output.
 </p>
 <p>
+
+<a name="vas_arch"></a>
+<H4>VAS Gateway Architecture</H4>
+
+<p>
+ The VAS gateway consists of a single multi-threaded
+ program <tt>mmsbox</tt>. This program performs a number of
+ simultaneous functions, including receiving incoming MM from MMSCs,
+ dispatching requests to services, composing and sending responses,
+ and listening for and handling sendmms requests.  The key modules of
+ the engine are described below.
+
+</p>
+
+<p>
+ The VAS gateway maintains two main message queues: One for incoming
+ messages (received from MMSCs), one for outgoing messages (received
+ from services or the send-mms port). These are maintained in
+ the <tt><i>storage-directory</i></tt> directory, in
+ directories <tt>mmsbox_incoming</tt> and <tt>mmsbox_outgoing</tt>
+ respectively. Queue structure is the same as that used by the MMSC component.
+
+ <br> A separate directory (<tt>mmsbox_dlr</tt>) is maintained for storing DLR URLs.
+
+</p>
+
+<ul>
+<li><b>SendMMS Module:</b> This module listens on
+  the <tt>send-mms-port</tt> for incoming requests. These are
+  received and turned into MM as described <a
+  href="#how_content">above</a> and written to the outgoing
+  queue. If the
+  sender requested a read or delivery report (by specifying the
+  requisite URL), the relevant URL is
+  stored to the DLR URL store for future use. </li>
+<li><b>MMSC handler module:</b> Receives messages coming from MMSCs,
+  and saves them to the incoming queue. Also watches the outgoing
+  message queue for new messages, which it dispatches to the relevant
+  MMSC based on recipient number routing (if the destination MMSC was
+  not set)</li>
+<li><b>Service Dispatch:</b> Reads messages from the incoming queue,
+  determines which service to invoke, receives the result and creates
+  a response MM, which is written to the outgoing queue. If the
+  service requested a read or delivery report, the relevant URL is
+  stored to the DLR URL store for future use.</li>
+</ul>
+
 <H3><!--TableOfContentsAnchor:Begin--><A
 NAME="Section_.1.5"></A><!--TableOfContentsAnchor:End-->Chapter 5: Tips & Tricks</H3>
 
  This section is a compilation of tips and tricks on making Mbuni work
  better for you 
 
-<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.5.1"></A><!--TableOfContentsAnchor:End-->Passing MSISDNs to Mbuni</H4>
+<H4><!--TableOfContentsAnchor:Begin--><A
+ NAME="Section_.1.5.1"></A><!--TableOfContentsAnchor:End-->Passing
+ MSISDNs to Mbuni MMSC</H4>
  As indicated earlier, Mbuni expects the MSISDN to be sent to it as a
  special HTTP request header. There are however times when it is
  either not possible, or not practical to insert the header into the
@@ -1800,3 +3067,5 @@ format.
 </body>
 </html>
 <!-- end of footer -->
+
+
