You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
4872 lines
123 KiB
4872 lines
123 KiB
|
|
<!-- 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" />
|
|
<meta name="robots" content="ALL" />
|
|
|
|
|
|
<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;}
|
|
a:link {text-decoration:underline;color:#0000bb;}
|
|
a:visited{text-decoration:underline;color:#bb0000;}
|
|
a:active {text-decoration:underline;color:#bbbbbb;}
|
|
a:hover {text-decoration:underline;color:#bbbbbb;}
|
|
-->
|
|
</style>
|
|
|
|
</head>
|
|
|
|
<body topmargin="0" leftmargin="0" rightmargin="0"
|
|
marginwidth="0" marginheight="0">
|
|
|
|
<h1>Mbuni: Open Source MMS Gateway</h1>
|
|
<!-- 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.
|
|
|
|
<h4>Table of Contents</h4>
|
|
<!--TableOfContents:Begin-->
|
|
<UL>
|
|
<LI><A HREF="#Section_.1.1">Chapter 1: Introduction</A>
|
|
<UL>
|
|
<LI><A HREF="#Section_.1.1.1">Overview of MMS</A></LI>
|
|
<LI><A HREF="#Section_.1.1.2">Features</A></LI>
|
|
<LI><A HREF="#Section_.1.1.3">Requirements</A></LI>
|
|
</UL></LI>
|
|
<LI><A HREF="#Section_.1.2">Chapter 2: Installing The Gateway</A><UL>
|
|
<LI><A HREF="#Section_.1.2.1">Installing Kannel</A></LI>
|
|
<LI><A HREF="#Section_.1.2.2">Installing Mbuni MMS Gateway</A></LI>
|
|
<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</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>
|
|
<LI><A HREF="#mmsbox_admin">Using the VAS Gateway Administration Interface</a></LI>
|
|
<LI><A HREF="#builtin">Built-in Billing, Resolver and Detokenizer Modules</a></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>
|
|
<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>
|
|
</UL>
|
|
<LI><A HREF="#Section_.1.6">Chapter 6: Log Files</A></LI></UL>
|
|
</UL>
|
|
<!--TableOfContents:End-->
|
|
|
|
<br>
|
|
|
|
<H3><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.1"></A><!--TableOfContentsAnchor:End-->Chapter 1: Introduction</H3>
|
|
|
|
|
|
<p>MMS offers mobile
|
|
users enhanced messaging capabilities like the ability to send pictures and
|
|
sound from a cell phone. It is generally considered the natural successor to
|
|
the very popular SMS service.</p>
|
|
|
|
<p>MMS usage has
|
|
continued to grow since introduction, and it is expected that projects
|
|
such as Mbuni should further boost the adoption of MMS and its
|
|
explosion.
|
|
</p>
|
|
<p>
|
|
The Mbuni Project attempts to provide that
|
|
little bit of boost to MMS adoption/growth, by providing two important parts of the
|
|
MMS infrastructure: For the network "operator" 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 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 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
|
|
libraries. Kannel provides
|
|
well-designed, simple interfaces for management of octet strings, lists,
|
|
threads, servers, etc, and a certified WAP implementation. This made
|
|
it a natural choice for Mbuni, rather than re-inventing the wheel.</p>
|
|
|
|
<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.1.1"></A><!--TableOfContentsAnchor:End-->Overview of MMS</H4>
|
|
|
|
<p>The Multimedia
|
|
Messaging Service (MMS), is intended to provide a rich set of content to
|
|
subscribers (pictures, audio, games, etc). It supports both sending
|
|
and receiving of rich content by
|
|
properly enabled client devices. MMS is a non-real-time delivery service, much
|
|
like SMS or email. The service utilises a store-and-forward usage model. </p>
|
|
|
|
|
|
<p> MMS is designed to be transported
|
|
largely over IP rather than traditional GSM (SS7) networks. It is also designed
|
|
to interoperate with other IP services such as email and WAP. In fact, MMS
|
|
messages are typically transported over WAP, and are encoded using WAP MIME
|
|
formats. </p>
|
|
|
|
|
|
<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>
|
|
<img src="images/mmsgw.png" width="430" height="362">
|
|
</center>
|
|
<p >The elements
|
|
shown in the figure can be summarised as follows:</p>
|
|
|
|
<ul>
|
|
<li><b>MMS
|
|
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 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. This is also more properly known as the MMSC.
|
|
<li><b>MMS
|
|
Server:</b> This component
|
|
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
|
|
MMSC to receive and send MMS content. The Interface used is termed
|
|
MM7.
|
|
<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) 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). 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. 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 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 MMSC
|
|
to ensure correct delivery to each of the recipients. </p>
|
|
|
|
|
|
<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 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>
|
|
|
|
|
|
|
|
<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 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]> <![endif]></p>
|
|
|
|
<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
|
|
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
|
|
|
|
<li> Automatic content adaptation: The server modifies message
|
|
content depending on the capabilities of the receiving terminal
|
|
|
|
<li> Integrated Email-to-MMS and MMS-to-Email gateway
|
|
|
|
<li> Support for persistent storage of messages for subscribers (MMbox).
|
|
|
|
<li> Inter-MMSC message exchange (MM4 interface)
|
|
<li> Support for MMS Value Added Service Providers using MM7
|
|
protocols (SOAP or EAIF).
|
|
<li> Support for integration with subscriber database to enable
|
|
smart handling of handsets that do not support MMS, handsets not
|
|
provisioned, etc.
|
|
|
|
<li> Support for flexible billing structure through billing/CDR plug-in architecture
|
|
|
|
<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 SOAP, EAIF, MM1 and MM4 connectivity with an operator
|
|
MMSC (plus a special HTTP-based relay mechanism)
|
|
<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>
|
|
|
|
The Gateway is designed and tested to conform to Open Mobile Alliance
|
|
(OMA), WAP and 3rd Generation Partnership Project (3GPP) MMS standards
|
|
including:
|
|
|
|
<ul>
|
|
<li> WAP: 209
|
|
<li> OMA: MMS v1.2, UAProf v1.1
|
|
<li> 3GPP: TS 23.140
|
|
</ul>
|
|
|
|
</p>
|
|
|
|
<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.1.3"></A><!--TableOfContentsAnchor:End-->Requirements</H4>
|
|
|
|
<p>
|
|
Mbuni is being developed on MacOS X and Linux systems using the C programming language. It should compile and run on any similar system.
|
|
</p>
|
|
|
|
<p>
|
|
Mbuni utilises some libraries that are part of the Kannel source,
|
|
specifically GWLIB and WAP libraries. In order to install Mbuni you
|
|
will need to install Kannel (and therefore fulfil those
|
|
dependencies Mbuni shares with it).
|
|
</p>
|
|
<a name="required"></a>
|
|
The following additional components are required:
|
|
<ul>
|
|
<li> Libiconv v2.0 or higher is required for character set conversions
|
|
<li> Audio conversion tools required by the content adaptation module:
|
|
<ul><li> Sox from <a
|
|
href="http://sox.sourceforge.net">sox.sourceforge.net</a>
|
|
<li> Lame (v3.93 or higher) from <a
|
|
href="http://www.mp3dev.org">www.mp3dev.org</a>
|
|
<li> Mpg123 from <a href="http://www.mpg123.de">www.mpg123.de</a>
|
|
<li> AMR encoder/decoder from <a
|
|
href="http://www.3gpp.org">www.3gpp.org</a> (modified, <a href="#install">see below</a>)
|
|
</ul>
|
|
<li> Image conversion tools required by the content adaptation
|
|
module:
|
|
<ul>
|
|
o ImageMagick from <a href="http://www.imagemagick.org">www.imagemagick.org</a>
|
|
</ul>
|
|
<li> Mail server such as Postfix (<a href="http://www.postfix.org">www.postfix.org</a>)
|
|
<li> You will also need to be running a WAP gateway (we recommend Kannel).
|
|
<li> You may optionally need to run an HTTP proxy such as Squid
|
|
(<a href="http://squid-cache.org">squid-cache.org</a>), since some
|
|
newer phones (e.g. Nokia 6600) do
|
|
not send MMS over WAP but directly over HTTP via an HTTP Proxy.
|
|
</ul>
|
|
|
|
Hardware requirements will depend on amount of traffic, required
|
|
response times, etc. Keep in mind however that the gateway performs a
|
|
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.
|
|
|
|
<a name="install"></a>
|
|
<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. <strong>If you are
|
|
installing from a binary distribution, you may safely skip to <a
|
|
href="#required_comps">here</a></strong>.
|
|
</p>
|
|
|
|
<p>
|
|
In brief, to install Mbuni, you need to:
|
|
<ul>
|
|
<li>Download and install required packages (such as libXML, libiconv)
|
|
<li>Download and install Kannel (v1.4.2 and above)
|
|
<li>Download and install Mbuni
|
|
<li>Download, patch and install the AMR encoder/decoder
|
|
<li>Download and install additional <a href="#required">requried</a> packages
|
|
</ul>
|
|
</p>
|
|
|
|
<p>The source code
|
|
for Mbuni is available for download from the <a
|
|
href="http://www.mbuni.org/downloads.shtml">download area</a> of the website
|
|
</p>
|
|
|
|
|
|
|
|
<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.2.1"></A><!--TableOfContentsAnchor:End-->Installing Kannel</H4>
|
|
|
|
<p>In order to compile the software, you
|
|
will first need to download and install Kannel (v1.4.2 and above) from <a
|
|
href="http://www.kannel.org/">kannel.org</a>:</p>
|
|
|
|
|
|
|
|
<p>Unpack the kannel
|
|
source files using a command like:</p>
|
|
|
|
<p><tt>tar xvf
|
|
kannel-<i>version</i>.tar.gz</tt></p>
|
|
|
|
|
|
|
|
<p >Then proceed to
|
|
compile and install Kannel normally:</p>
|
|
|
|
<p>
|
|
|
|
<tt>cd kannel-<i>version</i>; ./configure</tt>
|
|
<br>
|
|
<tt>make install</tt>
|
|
</p>
|
|
|
|
<H4><!--TableOfContentsAnchor:Begin--><A NAME="Section_.1.2.2"></A><!--TableOfContentsAnchor:End-->Installing Mbuni MMS Gateway</H4>
|
|
|
|
|
|
<p>Download and
|
|
unzip/tar Mbuni sources in a directory of your choice:</p>
|
|
|
|
|
|
<tt>tar xzf mbuni-<i>version</i>.tgz</tt>
|
|
|
|
|
|
<p>Where <i>version</i> is the verion of Mbuni (e.g. 1.5.0). Compile and
|
|
install mbuni as follows:</p>
|
|
|
|
<p ><tt>cd
|
|
mbuni-<i>version</i></tt><br>
|
|
|
|
<tt>./bootstrap</tt><br>
|
|
<tt> ./configure</tt><br>
|
|
<tt>make insall</tt>
|
|
</p>
|
|
You need to have AutoMake for the above to work
|
|
<p >If you installed
|
|
Kannel in a non-standard location, you will need to supply the location to <tt>configure</tt> using <tt>--with-kannel=<i>kannel_directory</i></tt></p>
|
|
|
|
<h5>Installing from CVS</h5>
|
|
<p> If you want to try out the development version of Mbuni, you can
|
|
download it from the CVS on sourceforge.net:</p>
|
|
|
|
<tt>cvs -d:pserver:anonymous@mbuni.cvs.sourceforge.net:/cvsroot/mbuni login</tt><br>
|
|
|
|
followed by<br>
|
|
|
|
<tt> cvs -z3 -d:pserver:anonymous@mbuni.cvs.sourceforge.net:/cvsroot/mbuni co -P mbuni</tt><br>
|
|
|
|
you can then
|
|
install as above.
|
|
|
|
|
|
<p >Mbuni consists of
|
|
3 programs:
|
|
<ul>
|
|
<li><tt>mmsc</tt>
|
|
<li><tt>mmsfromemail</tt>
|
|
<li><tt>mmsbox</tt>
|
|
</ul>
|
|
which are by
|
|
default installed in <tt>/usr/local/bin</tt>
|
|
</p>
|
|
|
|
<p ><tt>mmsc</tt> is the MMSC component. It consists of the relay
|
|
server (<tt>mmsrelay</tt>), which routes
|
|
incoming messages to email, other MMS gateways, MMS clients/handsets,
|
|
and the client-facing MMSC interface (<tt>mmsproxy</tt>) via which messages are
|
|
sent and received by MMS clients (MM1 as well as MM7). <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>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>
|
|
|
|
|
|
|
|
<p>Mbuni expects that an AMR decoder is installed and can be invoked
|
|
as: <br>
|
|
<tt>amrdecoder <i>infile outfile</i> </tt>
|
|
<br>
|
|
|
|
to decode an AMR
|
|
file to header-less (raw), 16-bit signed, mono, 8kHz audio samples in
|
|
the output file. (Input and output files may be '-' for standard input
|
|
or output respectively.)</p>
|
|
|
|
<p>Similarly, it is expected that an AMR encoder
|
|
called <tt>amrencoder</tt> exists and can be executed as follows:
|
|
<br>
|
|
<tt>amrencoder <i>mode infile outfile</i></tt>
|
|
<br>and convert raw, 16-bit signed, 8kHz
|
|
mono audio samples in the input file to AMR using the supplied
|
|
encoding mode.
|
|
|
|
<br>
|
|
<br>
|
|
For the AMR encoder/decoder, we have adapted the sample provided on the 3GPP
|
|
website. Follow the instructions below to install it:<br>
|
|
|
|
<ul>
|
|
<li>Download the AMR encoder/decoder source from <a
|
|
href="http://www.3gpp.org/ftp/Specs/archive/26_series/26.104/26104-520.zip">here</a>
|
|
|
|
<li>unzip/unpack the zip file, and unpack the source within:<br>
|
|
|
|
<tt>unzip 26104-520.zip</tt><br>
|
|
|
|
<tt>mkdir amr</tt><br>
|
|
|
|
<tt>cd amr</tt><br>
|
|
<tt>unzip ../26104-520_ANSI_C_source_code.zip</tt><br>
|
|
|
|
<li>Download the AMR code patch from the mbuni.org <a href="downloads.shtml">download section</a> and apply as follows:<br>
|
|
|
|
<tt>patch -p1 < ../mbuni-amr-patch</tt>
|
|
<li> You should then compile and install the AMR encoder/decoder as follows:<br>
|
|
|
|
<tt>make -f makefile.gcc</tt><br>
|
|
<tt>cp -f amrdecoder amrencoder /usr/local/bin</tt>
|
|
</ul>
|
|
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>
|
|
|
|
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 the command <tt>mmsc</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. </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
|
|
own line. Each group begins with the group name. Comments are lines that begin
|
|
with a hash (#) and are ignored.
|
|
<br><br>
|
|
A
|
|
variable definition line has the name of the variable, an equals sign (=) and
|
|
the value of the variable. The name of the variable can contain any characters
|
|
except white space and equals. The value of the variable is a string, with or
|
|
without quotation marks (") around it. Quotation marks are needed if the value
|
|
begins or ends with white space or contains special characters. Normal C escape
|
|
character syntax works inside quotation marks.</p>
|
|
|
|
<p >The variable <i>group</i> marks the
|
|
beginning of a new group with the given name.</p>
|
|
|
|
<b>Configuring Mbuni using a Loadable Module</b>
|
|
<p>Mbuni supports configuration using a dynmically linked module.
|
|
This is particularly useful if you wish to configure Mbuni from a
|
|
database or a script. <br/><br/>
|
|
In order to do this, the first (and only) group in the config file
|
|
must be a <tt>config-source</tt> group. An example is shown below:
|
|
<br><br>
|
|
|
|
<tt>
|
|
group = config-source<br>
|
|
config-library = <i>path_to_dll</i><br>
|
|
config-library-init-param = <i>init_param_for_dynamic_lib</i><br>
|
|
</tt>
|
|
<br><br>
|
|
Mbuni will load the supplied DLL and get all subsequent configuration
|
|
parameters from the module. (See <tt>mms_cfg-imp.h</tt> for DLL requirements.)
|
|
|
|
<br><br>
|
|
|
|
</p>
|
|
|
|
<b>Configuration Items</b>
|
|
<p>
|
|
If not using a module as configuration source,
|
|
the <tt>config-source</tt> group must not exist. The rest of the
|
|
configuration file must have the format as described above. Groups
|
|
and respective items are described below.
|
|
</p>
|
|
<p >The core group is
|
|
<i>core</i> and defines the log file location, log level (amount of debugging
|
|
information – the lower the number the more debugging
|
|
information), the location of the access log, the HTTP interface to
|
|
listen on for incoming connections, HTTP proxy
|
|
host/port if any (HTTP proxy host/port and HTTP interface name
|
|
are 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>
|
|
<tt>
|
|
|
|
group =
|
|
core<br>
|
|
log-file
|
|
= log/mmsgw.log<br>
|
|
log-level
|
|
= 0
|
|
<br>
|
|
access-log = log/access.log<br>
|
|
http-interface-name = "*"<br>
|
|
</tt>
|
|
</p>
|
|
<p>
|
|
This should be followed by the main gateway configuration group (<i>mbuni</i>).
|
|
<br>
|
|
<br>
|
|
<tt>
|
|
|
|
group =
|
|
mbuni<br>
|
|
|
|
name =
|
|
"My MMSC"<br>
|
|
|
|
hostname
|
|
= ds.co.ug<br>
|
|
|
|
host-alias
|
|
= mmsc<br>
|
|
|
|
local-prefixes
|
|
= 075;+25675;25675<br>
|
|
|
|
directory-store
|
|
= spool<br>
|
|
|
|
max-send-threads
|
|
= 5<br>
|
|
|
|
send-mail-prog
|
|
= /usr/sbin/sendmail -f %f %t<br>
|
|
|
|
...<br>
|
|
</tt>
|
|
</p>
|
|
<p >The table below
|
|
lists all the configuration directives. The column <b>Mode</b>
|
|
indicates operation mode in which the parameter is applicable:
|
|
Config params marked <i>VAS GW</i>
|
|
are only applicable when
|
|
operating in VAS Gateway mode, while those marked <i>MMSC</i>
|
|
are only applicable when
|
|
operating in
|
|
MMSC mode. The rest are used in both modes.</p>
|
|
|
|
<table border=0 cellspacing=2 cellpadding=1 >
|
|
<tr>
|
|
<td valign=top>
|
|
<b>Variable
|
|
Name</b>
|
|
</td>
|
|
|
|
<td valign=top>
|
|
<b>Mode</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 >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top>
|
|
mbuni
|
|
</td>
|
|
<td valign=top>
|
|
Mandatory
|
|
variable
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
|
|
<td valign=top ><tt>name </tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
|
|
<td valign=top>
|
|
User-friendly
|
|
name for the Gateway, used in notices, etc
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top ><tt>hostname
|
|
</tt>
|
|
</td>
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
<td valign=top >
|
|
Local hostname.
|
|
This is added as a qualifier to the sender address when MMS is forwarded to
|
|
Email or to a foreign MMSC via SMTP. Defaults to <tt>localhost</tt>
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top ><tt>host-alias
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top>
|
|
string
|
|
</td>
|
|
<td valign=top s>
|
|
Short MMC
|
|
hostname. This is used in generating message IDs as well as the
|
|
message retrieval URL (sent as part of the MMS
|
|
notification): For instance if you have this as <tt>mmsc</tt> then
|
|
the retrieval URL will have the form
|
|
<tt>http://mmsc/<i>msgtoken</i></tt> (no port is added). Be sure to
|
|
keep this value short (as some handsets do not like long URLs in MMS
|
|
notifications), and it must not include non-alphanumeric characters
|
|
as this can screw up URL location parsing. 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
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top ><tt>local-prefixes</tt>
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number
|
|
prefix list
|
|
</td>
|
|
<td valign=top >
|
|
Number prefixes
|
|
that should be considered local. Messages to numbers that match these
|
|
prefixes will be delivered locally (via <tt>mmsrelay</tt>)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top ><tt>mmsc-services</tt>
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Comma-separated list
|
|
</td>
|
|
<td valign=top >
|
|
Comma-separated list of MMSC services to be started/activated on
|
|
this host. List should contain one or more of the following
|
|
items <tt>MM1</tt>, <tt>MM7</tt>, <tt>Relay</tt>: These activate MM1
|
|
message processing, MM7 message processing, and the Relay function
|
|
respectively. To start all services, leave out this directive
|
|
entirely, or set it to <tt>All</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top ><tt>smtp-relay</tt>
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
SMTP relay host in the form <i>host:port</i>. (If <i>port</i> is
|
|
not included, defaults to 25.) If set, mmsbox uses this to relay
|
|
all outgoing MM4 and email requests. Otherwise the sendmail
|
|
command defined above is used.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>storage-directory
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Directory name
|
|
(string)
|
|
</td>
|
|
<td valign=top >
|
|
Directory where Mbuni creates message queues, MMBoxes, and the
|
|
User Agent profiles cache. Mbuni creates a set of sub-directories in here
|
|
for each function
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>max-send-threads</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number
|
|
</td>
|
|
<td valign=top >
|
|
How many queue
|
|
processing threads to start. A higher value means messages get delivered
|
|
faster.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<a name="send-mail-prog"/><tt>send-mail-prog</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command to use for sending email messages
|
|
(MMS-to-email or to foreign MMS gateways via SMTP). This command can include variables: %f
|
|
– replaced with the message from address, %t – replaced with the
|
|
recipient address (RFC 822 compliant), %s – the message subject, %m
|
|
– the message ID. (NOTE: Special shell characters —
|
|
&, |, $, (, ), and so on &mdash are escaped
|
|
after variable substitution, hence parameter quoting is not necessary.)
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>strip-prefixes
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A semi-colon (;) separated string of prefixes that should (if
|
|
found) be stripped off the phone number <i>prior</i> to number
|
|
normalisation as described below. Only the first prefix that matches
|
|
will be stripped.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>unified-prefix
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A string to
|
|
unify received phone numbers, so that routing works correctly. Format is that
|
|
first comes the unified prefix,
|
|
then all prefixes which are replaced by the unified prefix, separated with
|
|
comma (','). For example "+256,000256,0;+,000" should
|
|
ensure correct UG prefixes. If
|
|
there are several unified prefixes, separate their rules with semicolon (';')
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>maximum-send-attempts
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
integer
|
|
</td>
|
|
<td valign=top >
|
|
Maximum number
|
|
of attempts gateway must make to deliver message before giving up (e.g.
|
|
mobile phone is off, VAS service is down, email domain is unavailable)
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-maximum-notify-attempts
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
integer
|
|
</td>
|
|
<td valign=top >
|
|
Maximum number
|
|
of attempts gateway must make to notify a device of a pending
|
|
message on the MM1 interface, before giving up. Defaults to <tt>maximum-send-attempts</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mmsbox-maximum-request-attempts
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
integer
|
|
</td>
|
|
<td valign=top >
|
|
Maximum number
|
|
of attempts VAS Gateway must make to fetich a MMS service URL before
|
|
giving up. Defaults to <tt>maximum-send-attempts</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
|
|
<td valign=top >
|
|
<tt>default-message-expiry</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
Default number
|
|
of seconds in which message expires and is purged from queue (if not yet
|
|
delivered). This value is overridden by whatever is in the message.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>max-message-expiry</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
Maximum age (in seconds) allowed for all messages. If set, this
|
|
determines when messages must mandatorily be expired. This cannot be
|
|
overridden by the expiry value requested in the message.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>queue-run-interval</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Real
|
|
</td>
|
|
<td valign=top >
|
|
How many
|
|
seconds between each queue run
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-queue-run-interval</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Real
|
|
</td>
|
|
<td valign=top >
|
|
How many
|
|
seconds between each queue run for the MM1 queue. Defaults to the
|
|
value given above (<tt>queue-run-interval</tt>)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>queue-manager-module</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Library to handle queue/message storage and processing (see
|
|
<tt>mms_queue.h</tt> for details)
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>queue-module-init-data</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Initialiser data for queue/message storage engine.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>send-attempt-back-off</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
The exponential back-off factor to employ on subsequent message
|
|
delivery attempts, when a delivery attempt fails.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendsms-url</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
URL of the
|
|
service through which SMS can be sent to a mobile subscriber (e.g. for WAP
|
|
Push). It is expected that this url expects/supports Kannel-style send-sms
|
|
parameters (udh, from, to, text, etc.)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendsms-username</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Username to
|
|
pass (for authentication) to send-sms URL
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendsms-password</tt>
|
|
</td>
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Password to
|
|
pass (for authentication) to send-sms URL
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendsms-global-sender</tt>
|
|
</td>
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional sender
|
|
(<i>to</i> field) to use in send sms url
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-port</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
Port on which <tt>mmsproxy</tt> listens for MMS messages from MMS
|
|
clients (Default
|
|
is 8191).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mm7-port</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
Port on which <tt>mmsproxy</tt> listens for MM7 requests from Value
|
|
Added Services providers. If this port is not supplied, the MM7
|
|
sub-system is not started.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mm4-port</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSBOX</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
<td valign=top >
|
|
Port on which <tt>mmsbox</tt> listens for MM4 requests from Value
|
|
Added Services providers. If this port is not supplied, the MM4 receiver
|
|
sub-system is not started.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mmsbox-mm4-domain-number-prefixes</tt>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSBOX</i>
|
|
|
|
</td>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>allow-ip</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
List of IP
|
|
addresses
|
|
</td>
|
|
<td valign=top >
|
|
List of IP
|
|
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 by the MMSC. Leave out to allow all machines to connect.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>deny-ip</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
List of IP
|
|
addresses
|
|
</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).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-client-msisdn-header</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Comma-separated list of HTTP
|
|
request headers MMSC should look for to determine sender MSISDN.
|
|
WAP gateway should insert one of these headers as part of MMS request to indicate MSISDN
|
|
of sender. Note that typically the MMS client does not indicate its MSISDN in
|
|
the MMS message, it is up to the gateway to discover this and insert it. We
|
|
rely on the WAP gateway to provide the MSISDN as an HTTP request header
|
|
(default header name is <tt>X-WAP-Network-Client-MSISDN</tt>)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-client-ip-header</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Comma-separated list of HTTP
|
|
request headers MMSC should look for to determine sender IP
|
|
address. WAP gateway or HTTP proxy should insert one of these
|
|
headers as part of MMS request to
|
|
indicate IP Address
|
|
of sender. Similar to the above, if the MSISDN is not set, then we
|
|
assume that the client is identified by IP address, which we extract
|
|
from the request headers (using this header). Default header name
|
|
is <tt>X-WAP-Network-Client-IP</tt>. If the header is not
|
|
found, we assume the IP address as seen by Mbuni's MM1 interface.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>allow-ip-type</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Set this to false to prevent Mbuni accepting and processing messages from
|
|
senders identified by IP address (i.e. not by MSISDN). Default: True.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>optimize-notification-size</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Set this to true make Mbuni attempt to squeeze MMS notifications
|
|
in one WAP Push SMS, by leaving out subject and sender
|
|
fields. Default: false
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>content-adaptation</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Set this to false to turn off content adaptation in Mbuni. This will
|
|
cause the MMSC to ignore client capabilities when sending messages,
|
|
and could cause problems so beware! Default: true
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>send-dlr-on-fetch</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
The MMSC sends a confirmation delivery report to the sender only
|
|
when the recipient confirms receipt on the MM1 interface. If you
|
|
want a report as soon as the recipient fetches the message (before
|
|
receipt of the acknowledge-ind MM1 packet) set this to true. Default: false
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>email2mms-relay-hosts</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A semi-colon separated list of hosts/domains. When MMS is received
|
|
via SMTP, the gateway needs to determine whether it is for a local or a
|
|
foreign recipient. To determine if the recipient is local recipient, we use
|
|
the resolver module, if supplied. (Note that default resolution
|
|
uses <tt>local-prefixes</tt> setting to determine if the recipient
|
|
is local, returning the local MMSC name, if not, then it checks each
|
|
of the defined relays to see if the recipient address is for one
|
|
of them, by checking the prefixes, returning the matching
|
|
proxy/relay name.) The resolver should return a host name that is
|
|
matched against this setting. If any name matches, the message is
|
|
queued, otherwise it is discarded.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>billing-library</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional
|
|
library containing billing and CDR functions. This library is loaded at
|
|
runtime and should contain functions to be called to effect billing and CDR
|
|
generation. See <tt>mms_billing.h</tt> for
|
|
details. (<a href="#builtin"><tt>builtin:shell</tt></a> supported as a special built-in library.)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>billing-module-parameters</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Parameters to
|
|
pass to the billing module specified above when it is loaded. This is a
|
|
generic string whose interpretation is entirely up to the module.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mmsbox-cdr-module</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional
|
|
library containing CDR functions for mmsbox. This library is loaded at
|
|
runtime and should contain functions to be called to effect CDR
|
|
logging for the VAS Gateway. See <tt>mmsbox_cdr.h</tt> for
|
|
details. (Default behaviour is to log CDR to tab-delimited file <tt><i>storage-dir</i>/mmsbox-cdr.asc</tt>)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mmsbox-module-parameters</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Parameters to
|
|
pass to the mmsbox CDR module specified above when it is loaded. This is a
|
|
generic string whose interpretation is entirely up to the module.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>resolver-library</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional
|
|
library containing functions for resolving recipient MSISDN to hostname
|
|
of Proxy-Relay that should handle the message (on the MMC side) or
|
|
the connected MMC that should (internally) route an incoming MM7
|
|
message (on the MMSBOX side). <br> For Mbun MMSC, supplying this libary
|
|
over-rides the <tt>local-prefixes</tt> setting given above. If the
|
|
Proxy-Relay hostname returned by the module is the hostname of the
|
|
local MMSC, then the recipient is considered local. See
|
|
<tt>mms_resolve.h</tt> for details. (See <tt>mmsbox_resolve.h</tt> for usage under
|
|
mmsbox). (<a
|
|
href="#builtin"><tt>builtin:shell</tt></a> supported as a special
|
|
built-in library.)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>resolver-module-parameters</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>ALL</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Parameters to
|
|
pass to the Resolver module specified above when it is loaded. This is a
|
|
generic string whose interpretation is entirely up to the module.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>detokenizer-library</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Optional
|
|
library containing functions for finding MSISDN from request URL
|
|
sent by client. The last part of URL is treated as a string that is
|
|
interpreted by the library and transformed into an MSISDN. This libary
|
|
is only a fall-back in case the default sender address resolution
|
|
fails. See
|
|
<tt>mms_detokenize.h</tt> for details. (<a href="#builtin"><tt>builtin:shell</tt></a> supported as a special built-in library.)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>detokenizer-module-parameters</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Parameters to
|
|
pass to the De-tokenizer module specified above when it is loaded. This is a
|
|
generic string whose interpretation is entirely up to the module.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>prov-server-notify-script</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Subscriber
|
|
database interface script 1: This script will be called by the gateway to
|
|
notify the subscriber database of per-subscriber events such as when a
|
|
subscriber sends a message, successfully fetches a message, etc. This script
|
|
is called with 4 arguments. Argument 1 is one of fetched, sent,
|
|
failedfetch; argument 2 is the subscriber MSISDN; argument 3, in case of a
|
|
failed fetch provides a description of the error (e.g. message
|
|
expired); argument 4 is the message ID (if any). NOTE: Any missing
|
|
argument is passed as a quoted empty string for ease of parsing in
|
|
the script.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>prov-server-sub-status-script</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
<td valign=top >
|
|
Subscriber
|
|
database interface script 2: This script is called
|
|
by <tt>mmsrelay</tt> to determine whether the recipient's
|
|
device supports MMS. The script should exit with a value of 0 to indicate
|
|
that the device does not support receipt of MMS notifications; 1 to indicate
|
|
that the device supports MMS; -1 if the subscriber is not known or not
|
|
provisioned for MMS. The return value determines how
|
|
<tt>mmsrelay</tt> will deliver the message (see below).
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top>
|
|
<tt>notify-unprovisioned</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Whether
|
|
subscribers who are not provisioned for MMS should receive any notifications
|
|
(e.g. SMS) when an MMS message is received for them.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top>
|
|
<tt>mms-notify-text</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Message to send
|
|
to device that does not support MMS, when a message is received for the user.
|
|
This message is sent as plain SMS via the Send SMS URL specified above.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-notify-unprovisioned-text</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top>
|
|
String
|
|
</td>
|
|
<td valign=top>
|
|
Message to send
|
|
to devices that are not provisioned for MMS (only if
|
|
<tt>notify-unprovisioned</tt> is true).
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-message-too-large-txt</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
If a device
|
|
tries to fetch a message, which during content adaptation is determined to be
|
|
too large for the target device (based on capabilities data supplied by the
|
|
device), the message is discarded, this text is sent to the device instead as
|
|
part of an MMS message.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-to-email-html</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
<td valign=top >
|
|
When an MM is
|
|
destined for email, we must format it to make it more suitable for email
|
|
readers. (For instance, the SMIL part of the MM will make no sense to most email
|
|
readers.) The gateway formats
|
|
the message as follows: It generates a multi-part MIME message with the main
|
|
part being an HTML entity in which MM parts are embedded. The text given here
|
|
is tagged at the bottom of the HTML.
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-to-email-txt</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
This string is
|
|
placed in the MMS converted to email as an alternative to the HTML part, for
|
|
email clients that do not support HTML.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mms-to-email-default-subject</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>MMSC</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
This string is used as the default message subject when sending
|
|
MMS to email in the event that no subject is defined in the message
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendmms-port</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
number
|
|
</td>
|
|
<td valign=top >
|
|
The port on which the MMS VAS gateway listens for incoming MMS send
|
|
requests. (Optional.)
|
|
</td>
|
|
</tr>
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>sendmms-port-ssl</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Boolean
|
|
</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.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mmsbox-mt-filter-library</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Optional library to be used for filtering/transforming all content (except
|
|
SMIL), while building the MT MMS from a SMIL file (or from a
|
|
file). This is useful if say you want to implement custom
|
|
filtering/transformation of content (e.g. DRM wrappers around
|
|
selected content). Note that only elements
|
|
referenced by URL/file name (e.g. within the returned SMIL or if fetched by
|
|
the send-mms interface via URL) are filtered. See
|
|
<tt>mmsbox_mt_filter.h</tt> for details. Also see
|
|
<tt>mm7-mt-filter-params</tt> config variable in the <a href="#mmsc_vasp">VAS specific
|
|
config section</a>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>mmsbox-admin-port</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Integer
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Optional port where <tt>mmsbox</tt> listens for administrative
|
|
commands (see <a href="#mmsbox_admin">below</a>).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>admin-port-ssl</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Whether admin port (above) is SSLed.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>admin-allow-ip</tt>
|
|
</td>
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
If set, admin requests will only be allowed if originated by one of
|
|
the IP addresses listed here (semi-colon separated list).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>admin-deny-ip</tt>
|
|
</td>
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
If set, admin requests will <b>not</b> be allowed if originated by one of
|
|
the IP addresses listed here (semi-colon separated list).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>admin-password</tt>
|
|
</td>
|
|
<td valign=top >
|
|
string
|
|
</td>
|
|
|
|
<td valign=top >
|
|
<i>VAS GW</i>
|
|
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Authentication password for admin port
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
<br>
|
|
|
|
<a name="mmsbox_admin"></a><h4>Using the VAS Gateway Administration
|
|
Interface</h4>
|
|
|
|
Mbuni VAS Gateway provides an administration interface (HTTP-based)
|
|
to view the status of MMSC connections, start or stop all or a
|
|
specific MMSC connection. (This is especially useful if the
|
|
configurations are being loaded dynamically using a configurations module.) To use the interface, you load a
|
|
URL of the form:
|
|
|
|
<p>
|
|
<tt>http://<i>server_ip</i>:<i>server_admin_port</i>/<i>command_uri</i>?password=<i>admin_password</i>?mmsc-id=<i>mmsc</i></tt>
|
|
</p>
|
|
|
|
If <tt>admin-port-ssl</tt> was set to <tt>yes</tt> then you must
|
|
use <tt>https://</tt>. The <tt>server_admin_port</tt> and <tt>admin_password</tt> should be given
|
|
as specified in the configuration file. Supported <tt>command_uri</tt>
|
|
values are:
|
|
<dl>
|
|
<dt>stop</dt> <dd>To stop a specific MMSC link, specified using
|
|
the <tt>mmsc-id</tt> CGI parameter.This means no MT MMS will be
|
|
routed out via this connection until it is started again. The provided ID must match
|
|
the ID of one of the <tt>mmsc</tt> groups defined in the
|
|
configuration file. If <tt>mmsc-id</tt> is not provided, all
|
|
defined MMSC connections are stopped. </dd>
|
|
|
|
<dt>start</dt> <dd>To start a specific MMSC link, specified using
|
|
the <tt>mmsc-id</tt> CGI parameter. The provided ID must match
|
|
the ID of one of the <tt>mmsc</tt> groups defined in the
|
|
configuration file. If <tt>mmsc-id</tt> is not provided, all
|
|
defined MMSC connections are started. </dd>
|
|
|
|
<dt>status</dt> <dd>To retrieve the status of a specific MMSC link, specified using
|
|
the <tt>mmsc-id</tt> CGI parameter. The provided ID must match
|
|
the ID of one of the <tt>mmsc</tt> groups defined in the
|
|
configuration file. If <tt>mmsc-id</tt> is not provided, all
|
|
defined MMSC connections' status is reported. </dd>
|
|
|
|
</dl>
|
|
|
|
The response in each case is XML-formatted. For the <tt>status</tt>
|
|
command, the result is the following form:
|
|
<pre>
|
|
|
|
<mmsbox>
|
|
<mmsc id="eaif" type="EAIF">
|
|
<port>8190</port>
|
|
<group>eaif</group>
|
|
<throughput>0.0000</throughput>
|
|
<re-route>false</re-route>
|
|
<reroute-mmsc>N/A</reroute-mmsc>
|
|
<stats>
|
|
<uptime>23 secs</uptime>
|
|
<last-pdu>n/a</last-pdu>
|
|
<mt><pdus>0</pdus><errors>0</errors></mt>
|
|
<mo><pdus>0</pdus><errors>0</errors></mo>
|
|
</stats>
|
|
</mmsc>
|
|
<mmsc id="mail" type="MM4">
|
|
<port>n/a</port>
|
|
<group>mail</group>
|
|
<throughput>0.0000</throughput>
|
|
<re-route>false</re-route>
|
|
<reroute-mmsc>N/A</reroute-mmsc>
|
|
<stats>
|
|
<uptime>23 secs</uptime>
|
|
<last-pdu>n/a</last-pdu>
|
|
<mt><pdus>0</pdus><errors>0</errors></mt>
|
|
<mo><pdus>0</pdus><errors>0</errors></mo>
|
|
</stats>
|
|
</mmsc>
|
|
<mmsc id="http" type="HTTP">
|
|
<port>9001</port>
|
|
<group>http</group>
|
|
<throughput>0.0000</throughput>
|
|
<re-route>true</re-route>
|
|
<reroute-mmsc>local</reroute-mmsc>
|
|
<stats>
|
|
<uptime>23 secs</uptime>
|
|
<last-pdu>n/a</last-pdu>
|
|
<mt><pdus>0</pdus><errors>0</errors></mt>
|
|
<mo><pdus>0</pdus><errors>0</errors></mo>
|
|
</stats>
|
|
</mmsc>
|
|
<mmsc id="local" type="SOAP">
|
|
<port>12345</port>
|
|
<group>local</group>
|
|
<throughput>0.0000</throughput>
|
|
<re-route>false</re-route>
|
|
<reroute-mmsc>N/A</reroute-mmsc>
|
|
<stats>
|
|
<uptime>23 secs</uptime>
|
|
<last-pdu>n/a</last-pdu>
|
|
<mt><pdus>0</pdus><errors>0</errors></mt>
|
|
<mo><pdus>0</pdus><errors>0</errors></mo>
|
|
</stats>
|
|
</mmsc>
|
|
</mmsbox>
|
|
</pre>
|
|
The information includes basic MMSC configuration data, connection
|
|
uptime, time of last received PDU, received and sent PDUs, errors.
|
|
|
|
For the <tt>start</tt>
|
|
command, the response is the same as that for <tt>status</tt> if the
|
|
command succeeds, otherwise the result is of the form:
|
|
|
|
<pre>
|
|
<Start-Mmsc><Error><i>error message</i></Error></Start-Mmsc>
|
|
</pre>
|
|
|
|
For the <tt>stop</tt> command the result is of the form:
|
|
<pre>
|
|
<Stop-Mmsc><Success/></Stop-Mmsc>
|
|
</pre>
|
|
|
|
or
|
|
<pre>
|
|
<Stop-Mmsc><Failed/></Stop-Mmsc>
|
|
</pre>
|
|
depending on whether the command succeeded or failed.
|
|
|
|
|
|
|
|
<a name="builtin"></a><h4>Built-in billing, resolver and detokenizer
|
|
modules</h4>
|
|
Mbuni supports one type of built-in modules: Shell script
|
|
handlers. Each expect a parameter that is a shell script that is
|
|
used as follows:
|
|
<ul>
|
|
<li> If <tt>billing-library</tt> configuration parameter is set
|
|
to <tt>builtin:shell</tt>, the <tt>billing-module-parameters</tt>
|
|
must the path to the shell script to be called by Mbuni to provide
|
|
billing and CDR handling. For each message, the script will be with invoked
|
|
each recipient as follows:
|
|
<br><tt><i>script from_address to_address</i></tt>
|
|
<br>
|
|
If the script returns with a non-zero exit status, the message is
|
|
discarded.
|
|
<li> If <tt>resolver-library</tt> is set
|
|
to <tt>builtin:shell</tt>, <tt>resolver-module-parameters</tt> must
|
|
be set to a the path to the shell script to be invoked for each
|
|
destination address to determine how to deliver the message. The
|
|
script is invoked with one command line parameter (the destination
|
|
address) and should output (on standard output) the hostname of the
|
|
home MMSC (or MM7 connection ID in the case of <tt>mmsbox</tt>), to which the message should be routed.
|
|
<li>If <tt>detokenizer-library</tt> is set to <tt>builtin:shell</tt>
|
|
then <tt>detokenizer-module-parameters</tt> should be set to the
|
|
script that should be called to resolve the last part of the MM1
|
|
request URL (the token) or
|
|
sender IP address to sender number. The shell is called with two
|
|
arguments: The URL token and the IP address (in that order), and
|
|
should output (on standard output) the sender number.
|
|
</ul>
|
|
<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>
|
|
<h5>MM7 Configuration</h5>
|
|
|
|
<!--- MM7 stuff -->
|
|
<p >MMS Value-Added Service Providers (VASPs) are configured using
|
|
one or more <i>mms-vasp</i> groups:</p>
|
|
|
|
<br>
|
|
<tt>
|
|
group =
|
|
mms-vasp<br>
|
|
|
|
vasp-id = newcorp<br>
|
|
|
|
type =
|
|
soap<br>
|
|
|
|
short-code
|
|
= 100<br>
|
|
vasp-username
|
|
= newscorp<br>
|
|
vasp-password
|
|
= news123<br>
|
|
|
|
vasp-url
|
|
= http://mmsc1:pass@example.vasp.com:8080/mm7<br>
|
|
</tt>
|
|
|
|
<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>mms-vasp</tt>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasp-id</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
User friendly
|
|
name
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>type</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
This should be one of: soap, eaif
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm7-version</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. The MM7 version to use on this interface. (defaults are "5.3.0" for
|
|
XML/SOAP, "3.0" for EAIF.) For SOAP, this is
|
|
used as the value for the MM7Version XML node. For EAIF it is
|
|
reported in the HTTP headers.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm7-soap-xmlns</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. The namespace URI for the "mm7:" XML
|
|
namespace. Only valid for MM7/SOAP, and is used in the SOAP message
|
|
to identify the namespace for all MM7/SOAP specific elements. Default value is <i>http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0</i>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>use-mm7-soap-namespace-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Optional. Set to <tt>true</tt> if the MM7/SOAP tags should have the
|
|
<tt>mm7:</tt> prefix. Some MMC/VAS GW implementations do not seem to
|
|
like this, so you can set this to false to see what mileage you get.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>short-codes</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Number
|
|
</td>
|
|
<td valign=top >
|
|
Semi-colon separated list of short numbers for this VASP: Messages
|
|
received by Mbuni to any of these numbers are routed to the VASP via MM7.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasp-url</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Outgoing messages to the VASP are sent via this URL (using HTTP POST)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasp-username</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Incoming HTTP authentication: The username used by the VASP to
|
|
authenticate itself to Mbuni when sending data
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasp-password</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Incoming HTTP authentication: The password used by the VASP to
|
|
authenticate itself to Mbuni when sending data
|
|
to the VASP
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mms-to-email-handler</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Set this to <tt>true</tt> if all MMS destined to email addresses should be
|
|
routed via this VASP by the MMC. The message will be packed as an
|
|
MM7 message and handed over. This could be used to customise the
|
|
appearance of the email.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mms-to-local-copy-handler</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Set this to <tt>true</tt> if all MMS destined to local recipients
|
|
(e.g. mobiles) should be copied to this VASP. This is useful if you
|
|
want to implement a web-based viewer (as a backup solution) for your
|
|
users.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>send-uaprof</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. This parameter determines whether the User Agent string is
|
|
sent to the VASP (for MM7/SOAP only, as part of
|
|
<tt>UACapabilities</tt> entity). Set to <tt>ua</tt> to send the
|
|
full client User Agent string (i.e. the value of the HTTP request
|
|
header <tt>User-Agent</tt>). Set to <tt>url</tt> to send the client
|
|
Profile URL (i.e. the value of the <tt>X-WAP-Profile</tt> HTTP
|
|
request header). Leave empty not to send any info. Note that this
|
|
field is only sent in MO transactions (e.g. message delivery,
|
|
delivery reports).
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
|
|
Note that currently only HTTP Basic Authentication Scheme is supported
|
|
by Mbuni (for both incoming and out-going requests).
|
|
|
|
|
|
<a name="mm4"></a>
|
|
<h5>MM4 Configuration</h5>
|
|
|
|
<!-- Foreign MMSC stuff -->
|
|
|
|
<p >Foreign MMS
|
|
Gateways are configured using one or more <i>mmsproxy</i> groups:</p>
|
|
|
|
<br>
|
|
<tt>
|
|
group =
|
|
mmsproxy<br>
|
|
|
|
name =
|
|
"A test mms proxy"<br>
|
|
|
|
host =
|
|
test.com<br>
|
|
|
|
allowed-prefix
|
|
= "075"<br>
|
|
|
|
denied-prefix
|
|
= "077"<br>
|
|
|
|
<br>
|
|
</tt>
|
|
|
|
<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>mmsproxy</tt>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>name</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
User friendly
|
|
name
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>host</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Fully qualified
|
|
domain name
|
|
</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 Proxy
|
|
</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 proxy
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>confirmed-delivery</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Specifies whether to use request MM4 acknowledgement from the
|
|
recipient MMC for each message. Default is true.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr >
|
|
<td valign=top >
|
|
<tt>send-mail-prog</tt>
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command to use for sending messages (via email)
|
|
to foreign MMS gateways. This command over-rides, for this proxy,
|
|
the <a href="#send-mail-prog">global</a> <tt>send-mail-prog</tt> setting, and provides the same variable
|
|
substitutions.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>strip-prefixes
|
|
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A semi-colon (;) separated string of prefixes that should (if
|
|
found) be stripped of the phone number <i>prior</i> to number
|
|
normalisation and message sending, as described below. Only the first prefix that matches
|
|
will be stripped.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>unified-prefix
|
|
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A string to
|
|
unify received phone numbers, so that routing works correctly. Format is that
|
|
first comes the unified prefix,
|
|
then all prefixes which are replaced by the unified prefix, separated with
|
|
comma (','). For example "+256,000256,0;+,000" should
|
|
ensure correct UG prefixes. If
|
|
there are several unified prefixes, separate their rules with semicolon (';')
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
</table>
|
|
|
|
<p>
|
|
When an MM destined to an MSISDN cannot be delivered locally, the
|
|
gateway searches the list of Proxies to see if one of them can handle
|
|
the message. If one is found, the message is formatted as MM4 MIME
|
|
(according to 3GPP TS 23.140) 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>
|
|
group-id = mmc1<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). For MM7 connections it also used as the VASP ID parameter, when vasp-id is not specified.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasp-id</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional:
|
|
For MM7 connections it is used to explicitly set the VASP ID parameter. If left unspecified, the id is used instead.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>group-id</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional:
|
|
Can be used to group different MMCs for purposes of receiving DLRs,
|
|
etc.
|
|
</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, <tt>eaif</tt> for Nokia EAIF protocol, <tt>mm4</tt> for 3GPP
|
|
MM4, <tt>http</tt> for
|
|
special HTTP-based inter-mmsbox message relay (see
|
|
below), <tt>mm1</tt> for GPRS/3G modem access to an operator MMSC, or <tt>custom</tt> for
|
|
a custom implementation handled by a loadable module (see
|
|
<tt>mmsc-library</tt> below).<br> For <tt>type = http</tt> the VAS GW
|
|
will forward the message to the URL provided using HTTP POST, with
|
|
CGI parameters: <tt>mms</tt> – the binary mms, <tt>from</tt>
|
|
– the sender address, <tt>to</tt> – the recipient
|
|
address. This allows fast inter-mmsbox message
|
|
exchange. <br>For <tt>type=mm1</tt> it is expected
|
|
that <tt>mmsbox</tt> will send/receive messages directly from the
|
|
operator using an attached modem. To receive MMS, Kannel (or similar
|
|
SMS Gateway) must pass all received SMS to Mbuni via the
|
|
MMSC <tt>port</tt>. To send MMS, Mbuni will use
|
|
the <tt>mm1-sms-off-command</tt> (see below) to temporarily shutdown
|
|
the SMS Gateway, and then use the modem to send MMS
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm7-version</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. The MM7 version to use on this interface. (defaults are "5.3.0" for
|
|
MM7/SOAP, "3.0" for EAIF.) For SOAP, this is
|
|
used in the MM7Version tag. For EAIF it is
|
|
reported in the HTTP headers.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm7-soap-xmlns</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. The namespace URI for the "mm7:" XML
|
|
namespace. Only valid for MM7/SOAP, and is used in the SOAP message
|
|
to identify the namespace for all MM7/SOAP specific elements. Default value is <i>http://www.3gpp.org/ftp/Specs/archive/23_series/23.140/schema/REL-5-MM7-1-0</i>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>use-mm7-soap-namespace-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
Optional. Set to <tt>true</tt> if the MM7/SOAP tags should have the
|
|
<tt>mm7:</tt> prefix. Some MMC/VAS GW implementations do not seem to
|
|
like this, so you can set this to false to see what mileage you get.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>default-vasid</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Optional. The default VAS ID for this connection. Only valid for MM7/SOAP.
|
|
</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. When type
|
|
is <tt>MM4</tt>, this <b>must</b> be set to the MM4 domain. If you
|
|
wish to support email senders, create an <tt>mmsc</tt> group where
|
|
the domain is set to <tt>*</tt>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>maximum-request-size</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
int
|
|
</td>
|
|
<td valign=top >
|
|
Optional:
|
|
Maximum request size that this interface will receive. Larger
|
|
requests will be dropped. Default is 500k.
|
|
</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. Not
|
|
used for MM4 incoming connections (<tt>mm4-port</tt> is used
|
|
instead). For <tt>mm1</tt> MMSCs this is the port to which (MO) MMS
|
|
notification messages should be routed. In this case, the
|
|
notification SMS should be contained in a <tt>text</tt> CGI parameter.
|
|
</td>
|
|
</tr>
|
|
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>strip-domain</tt>
|
|
|
|
</td>
|
|
<td valign=top >
|
|
boolean
|
|
</td>
|
|
<td valign=top >
|
|
Optional:
|
|
MM4 MMSC connections only: Whether to strip the domain name from
|
|
the received sender/recipient addresses (if they are phone numbers)
|
|
</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>
|
|
</td>
|
|
<td valign=top >
|
|
List of IP
|
|
addresses
|
|
</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>
|
|
</td>
|
|
<td valign=top >
|
|
List of IP
|
|
addresses
|
|
</td>
|
|
<td valign=top >
|
|
List of IP
|
|
addresses of hosts <i>not</i> allowed to use/access the incoming
|
|
MMS port
|
|
</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>allowed-sender-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
List of
|
|
sender number prefixes that can use this MMSC
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>denied-sender-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
List of
|
|
sender number prefixes that cannot use 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>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>max-recipients</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Number
|
|
</td>
|
|
<td valign=top >
|
|
Maximum number of recipients per transaction for this MMSC
|
|
(ignored for custom MMSC type). This controls how many <tt>To</tt>
|
|
addresses are included in each send transaction. Default is
|
|
1. Note that failure of of the MMSC to accept any of the
|
|
recipients can result in the entire send request being retried.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>strip-prefixes</tt>
|
|
</td>
|
|
|
|
|
|
<td valign=top >
|
|
Number list
|
|
</td>
|
|
<td valign=top >
|
|
A semi-colon (;) separated string of prefixes that should (if
|
|
found) be stripped off the phone number prior to sending message. Only the first prefix that matches
|
|
will be stripped.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>reroute</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
If set to <tt>true</tt> all messages received from this MMSC are
|
|
routed directly to the outgoing queue (never to an MMS Service).
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>reroute-mmsc-id</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
If set (and <tt>reroute</tt> is <tt>true</tt>) then all messages
|
|
received on this connection will be sent out directly via the MMSC
|
|
with the ID set here.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>reroute-add-sender-to-subject</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
If <tt>reroute</tt> is <tt>true</tt> and this flag is also true then all messages
|
|
received on this connection are re-routed, and the original sender
|
|
is added to the message subject line
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm7-mt-filter-params</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Parameter(s) to be passed to the <tt>init</tt> function of the MT
|
|
MMS filter module specified in <tt>mmsbox-mt-filter-libary</tt>
|
|
above. (See
|
|
<tt>mmsbox_mt_filter.h</tt> for details.) The <tt>init function</tt> is called once for each MMC
|
|
connection, and must return no error, otherwise no filtering will be
|
|
done on MT messages via this MMC.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mmsc-library</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
If MMC type is <tt>custom</tt>, this parameter provides the dynamic
|
|
shared object (DSO) library to be loaded to provide connectivity to
|
|
the MMC. (See <tt>mmsbox_mmsc.h</tt> for details on required
|
|
exported symbols.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>custom-settings</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
If MMC type is <tt>custom</tt>, this parameter provides settings to
|
|
be provided to the dynamic
|
|
shared object (DSO) library loaded to provide connectivity to
|
|
the MMC. (See <tt>mmsbox_mmsc.h</tt> for details on how this is used.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>no-sender-address</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Boolean
|
|
</td>
|
|
<td valign=top >
|
|
If set to <tt>true</tt> Mbuni will not set
|
|
the <tt>SenderAddress</tt> tag in the SOAP Message Submit XML packet
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-http-proxy</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
HTTP Proxy (in the form <i>host:port</i> to be used when sending MMS to the MMSC. (<tt>mm1</tt> MMSC only)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-http-proxy</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
HTTP Proxy (in the form <i>host:port</i>) to be used when sending MMS to the MMSC. (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-gprs-on-command</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command <tt>mmsbox</tt> will call to start a GPRS/3G operator
|
|
connection when sending MT MMS via the <tt>mm1</tt> type. This
|
|
command typically invokes <tt>pppd</tt> with suitable
|
|
parameters. <b>NOTE</b>: This command should return immediately
|
|
(i.e. it shouldn't block). (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-gprs-off-command</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command <tt>mmsbox</tt> will call to stop the GPRS/3G operator
|
|
connection after sending MT MMS via the <tt>mm1</tt> type. This
|
|
command typically kills the <tt>pppd</tt> in charge of the
|
|
connection started with the command above. (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-gprs-pid-command</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command <tt>mmsbox</tt> will call to determine the ID of
|
|
the process controlling the GPRS/3G operator
|
|
connection after it is started. If this option is provided, then
|
|
a <tt>kill(2)</tt> will be used to terminate the GPRS/3G
|
|
connection, rather than the <tt>mm1-gprs-off-command</tt>. (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-sms-off-command</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command <tt>mmsbox</tt> will call to stop the SMS Gateway modem link, just
|
|
before starting the GPRS/3G operator
|
|
connection. Because MO MMS is received as (SMS) notifications, the
|
|
modem must be shared with the SMS Gateway (such as Kannel). When a
|
|
notification is received by <tt>mmsbox</tt>, we must shutdown the
|
|
SMS Gateway's connection to the modem (typically, if using Kannel,
|
|
this means a call to the admin interface), fetch the MMS (via a
|
|
GPRS/3G connection initiated using the same modem), and then turn
|
|
SMS reception back on (see below). (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-sms-on-command</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
Command <tt>mmsbox</tt> will call to start the SMS Gateway modem
|
|
link, once <tt>mmsbox</tt> has completed fetching MO MMS or sending
|
|
MT MMS via a GPRS/3G operator
|
|
connection. Typically, if using Kannel,
|
|
this means a call to the Kannel admin interface to start the
|
|
specific modem SMSC link. (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mm1-ua-string</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
HTTP User Agent String to send to MMSC in HTTP requests (e.g. "Mozilla/5.0 (SymbianOS/9.4;U;
|
|
Series60/5.0 Nokia5800d-1/52.50.2008.24;
|
|
Profile/MIDP-2.1Configuration/CLDC-1.1 )
|
|
AppleWebKit/413 (KHTML, like Gecko)
|
|
Safari/413" to fake a request as
|
|
a Nokia 5800). This is
|
|
useful if the MMSC transcodes MT MMS based on the receiver type. (<tt>mm1</tt> MMSC only.)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>carrier-id-header</tt>
|
|
</td>
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
<td valign=top >
|
|
HTTP Header used by Carrier to send us a special identifying ID
|
|
for the subscriber. This is passed on as is to the mms service
|
|
in a <tt>X-Mbuni-CarrierID</tt> header.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>retry-statuses
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
String
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Optional. Semicolon separated list of HTTP and MM7 statuses that makes MBUNI to retry sending to MMSC.
|
|
MM7 statuses are checked only when HTTP 200 is received from MMSC (HTTP 200 is always assumed as retry status).</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>allow-adaptations
|
|
</tt>
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Number
|
|
</td>
|
|
|
|
<td valign=top >
|
|
Optional. Should be 1 (yes) or 0 (no). This flag will be passed on to the operator MMSC (MM7/SOAP only) to turn on/off content adapation. If not passed, it is set to yes. This setting can be overwritten by <i>allow-adaptations</i> passed in the sendmms request.</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>delivery-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>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mmsc</tt>
|
|
</td>
|
|
<td valign=top>
|
|
string
|
|
</td>
|
|
<td valign=top>
|
|
Optional id of the mmsc to use, if none is specified using the CGI Variables
|
|
</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</p>
|
|
|
|
<p>
|
|
The Send MMS service can be invoked using HTTP GET or POST 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 </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. Note too that MT MMS filtering will not be
|
|
done on messages sent via the send-mms interface unless a particular
|
|
destination MMC is specified using this variable</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>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>content-url</tt>
|
|
</td>
|
|
<td valign=top >
|
|
If provided, specifies the URL of the content to be sent.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>content</tt>
|
|
</td>
|
|
<td valign=top >
|
|
If provided, specifies the arbitrary content for the MM. The Content type of
|
|
the content is determined either by the <tt>content_type</tt> CGI
|
|
variable (see below), or if <i>enctype=multipart/form-data</i> is
|
|
used in the HTTP POST request, then the content type associated with
|
|
this variable data is used.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>content_type</tt>
|
|
</td>
|
|
<td valign=top >
|
|
If the <tt>content</tt> variable is provided, this variable
|
|
specifies the content type of the <tt>content</tt>. The default, if
|
|
no content type is provided (or can be gleaned from the HTTP
|
|
request), this is set to <i>application/octet-stream</i>.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>base-url</tt>
|
|
</td>
|
|
<td valign=top >
|
|
If the <tt>smil</tt> URL parameter is provided, then this
|
|
parameter may be supplied to be used as the base URL for resolving
|
|
all relative URLs specified within the SMIL file while building the
|
|
MM. Default: <tt><i>http://localhost/</i></tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>vasid</tt>
|
|
</td>
|
|
<td valign=top >
|
|
This will be passed on the MMC as the VASID parameter in the
|
|
MM7/SOAP message. If not provided, defaults to <tt>sendmms-user</tt>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>servicecode</tt>
|
|
</td>
|
|
<td valign=top >
|
|
This will be passed on the MMC as the ServiceCode parameter in the
|
|
MM7/SOAP message. If not provided, this parameter is not sent.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>allow-adaptations</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Should be 1 (yes) or 0 (no). This flag will be passed on to the
|
|
operator MMSC (MM7/SOAP only) to turn on/off content adapation. If not passed, then setting in MMSC section in mmsbox.conf will be used.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mclass</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Message Class. (e.g. Personal)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>priority</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Message Priority. (e.g. Normal)
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>mms-direction</tt>
|
|
</td>
|
|
<td valign=top>
|
|
MT (mobile terminating) or MO (mobile orginating). When set to MO,
|
|
the MMS is queued as if it came from the
|
|
operator MMSC side. This is useful for testing service
|
|
configurations as it mimics receiving an MO MMS. Default is MT.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>distribution</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Optional. Should be <tt>true</tt> or <tt>false</tt>. This is set as the
|
|
MM7/SOAP <tt>DistributionIndicator</tt> parameter.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>validityperiod</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Optional. Should be an integer, giving the number of minutes before
|
|
this message is considered expired by the receiving MMSC.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>charged-party</tt>
|
|
</td>
|
|
<td valign=top>
|
|
Optional. Set to the MM7/SOAP <tt>ChargedParty</tt> parameter.
|
|
</td>
|
|
</tr>
|
|
|
|
</table>
|
|
|
|
</p>
|
|
|
|
<p>
|
|
<b>Note: </b> Only one
|
|
of <tt>text</tt>, <tt>smil</tt>, <tt>content-url</tt> or
|
|
<tt>content</tt> should be speficied, as only one makes sense at any time. Specifying more than one causes others
|
|
to be (silently) ignored.
|
|
</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>
|
|
|
|
<p>
|
|
The SendMMS interface can also be used to send binary content
|
|
(e.g. binary-coded MMS, image or audio)
|
|
directly to Mbuni. This is done as follows:
|
|
<ul>
|
|
<li>Send the binary content as the body of an HTTP POST request to the
|
|
SendMMS port. Be sure to specify the correct body content type as part of
|
|
the HTTP request headers. This is interpreted according to the rules
|
|
set out <a href="#how_content">below</a>.
|
|
<li>Supply to the request URL all but the <tt>text</tt> and <tt>smil</tt> URL
|
|
parameters (as described above) as part of the request URL.
|
|
</ul>
|
|
</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 — the keyword — 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&images[]=%i&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>allowed-receiver-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Strings
|
|
</td>
|
|
<td valign=top >
|
|
Semicolon-separated strings: List of receiver short code prefixes
|
|
allowed to use
|
|
this MMS Service.
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td valign=top >
|
|
<tt>denied-receiver-prefix</tt>
|
|
</td>
|
|
<td valign=top >
|
|
Strings
|
|
</td>
|
|
<td valign=top >
|
|
Semicolon-separated strings: List of receiver short code prefixes not
|
|
allowed to use
|
|
this MMS Service.
|
|
|
|
</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&myname=test&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>pass-thro-headers</tt>
|
|
</td>
|
|
<td valign=top >
|
|
List
|
|
</td>
|
|
<td valign=top >
|
|