Multimedia messaging service (mmmsg) from Acrobits is a service that facilitates file transfer between users of Acrobits’ applications. It is based on a “store&forward” principle: the files are uploaded to a server and links to these files are sent as a message with a special content type. On server side, the store&forward is handled by Acrobits MMMSG server.
By this principle, we have two channels used in messaging:
This is the channel normally used for text messaging. It can currently be SIP/SIMPLE or web service messaging service described in _send_message_webservice. This channel MUST support different Content-Types and the value sent in Content-Type must be passed from sender to recipient. SIP/SIMPLE typically supports this, for web service messaging it is easy to accomplish.
Content type used to signal messages with file attachments from Acrobits apps is
For security, it is highly recommended to use TLS for signalization channel. Use the tls transport for SIP communication in case of SIP/SIMPLE, or use https: in case of web service messaging.
File transfer channel¶
Files are transferred using HTTP protocol over TLS transport (https url scheme) to Acrobits MMMSG service. This service is running at https://mmmsg.acrobits.net, but it may be installed on your own premises. The service supports the following methods:
The server receives content-type and size of the file which the client is about to upload and if the size does not exceed the configured maximums, the server returns success response with an URL where the file should be uploaded.
The client does PUT to the URL returned in the successful response from POST. During PUT, the file is uploaded to the server and stored. The file is uploaded over TLS connection and it is encrypted.
The client does GET to the URL received over the signalization channel and downloads the encrypted file.
Example of a typical operation¶
- client A decides to send a file image.jpg, size is 4MB to client B
- client A does POST to MMMSG server at
image/jpegcontent type and 4MB content length in the request body
- MMMSG server decides the upload is within allowed limits and returns
https://mmmsg.example.com/E94CD15C-7964-4A9B-8AC4-10D7CFB791FDas file URL
- client A generates a new encryption key (the key length is 128 bits)
- client A does PUT to the file URL and uploads the file encrypted using symmetric AES cipher (in counter mode, AES-CTR)
- when upload is done, client A sends a message to client B over signalization channel. The message contains the file URL and the symmetric key
- client B receives the message from client A, does GET to the URL from the message, decrypts the content using the symmetric key from the message and displays the file.
Notes about security of the solution¶
- the files are stored on the server in encrypted form, under a generic identifier. The server does not know who was the sender, nor who are the recipients. The server only knows the content type and size of the file.
- each file on the server is encrypted using a unique encryption key. The server does not know the key; the clients never send the key to the server.
- the decryption key is sent via the signalization channel together with the URL. In case the signalization channel is not secured, anyone who intercepts the communication will be able to download and decrypt the file.
- MMMSG server is open source, anyone can install it on their premises and verify the operation described on this page. Details about how to install it can be found in our Installation Guide.