Like any typical telecom application, the MAS is a distributed application where mul-tiple instances can be hosted over the IMS network keeping in mind load distribution and distributed service availability for the users of the entire IMS network.
The services of the MAS are made accessible by hosting it as an application over the AS, which in turn is deployed over the IMS platform. The AS subscribes to the S-CSCF to request forwarding of specific SIP messages, which are received from specific registered or recognized users. All the SIP messages received by the AS from the IMS network are forwarded to the originating or the terminating side of the MAS, according to the information provided in the relevant header of the SIP message. This however, is determined by the AS (by looking at the ACCEPT-CONTACT2 field of the SIP message) and is not needed to be taken care of by the MAS.
The MAS has two modes of operation, the originating and the terminating. The originating MAS processes requests on the sending users end, whereas the terminating MAS processes messages/requests at the receivers end. Messages/requests processed by the originating part of an MAS will be processed by the terminating part of the next MAS (which may be the same as where the originating is; this is very much possible in distributed applications), before the message or request is completed or delivered to the receiving user.
6.2.1 Originating MAS
The originating MAS is a part of the MAS application, which handles messages soon after it arrives at the home server of the sender. The message is first processed by the originating MAS where logging, message type checking and other relevant actions are taken depending on the type of the message request. If required the message is then forwarded to the AS, which sends it onwards to the MAS at the receiver’s home server;
there the message is processed by the terminating MAS.
The architectural flow of the Originating MAS as shown in the diagram 10 can be described in the following steps:
1. A SIP message received by the AS is forwarded to the “Read SIP” message module, which unpacks and parses the sip message.
2. The message and parsed information is logged (2B), and relevant information from the SIP message is passed to the Type Checker module (2A), concurrently.
Message Type Checker detects the type of request and takes the following actions accordingly.
1. If the request is of type group-message, the message information is sent to the Clone module which sends relevant messages to all the group members.
Group members information is retrieved from the Clone DB.
2. If the request is that for a simple instant message, the message information is forwarded to the “Check Config” module, which may add relevant infor-mation to the message depending upon the sender’s settings as present in the Configuration DB. The message information which may now be mod-ified is forwarded to the next modules. The following two operations may be performed in parallel.
1. Message information is forwarded to the “Send SIP message mod-ule”, which composes a new SIP request and sends it back to the AS, which then forwards this request to the AS-MAS bundle at the re-ceiver’s home server.
2. If the Email copy has been enabled, the “Check Config” module in-vokes the Email-Copy module which then embeds the message body
in an email message and sends it to the email address specified in the Configuration DB.
3. If the request is a 200 OK, the message information is sent to the Check Response Message module, which takes relevant action on the request (if needed). In the current implementation, this module is never used since the AS handles SIP status messages internally and doesn’t forward such requests to the MAS at all.
4. If the type of the request is a REGISTER, then the “Check Offline Mes-sages” module retrieves all the offline messages addressed to the sender, embeds all the messages in new SIP messages addressed to the sender and forwards them to the AS.
Figure 10: MAS originating side message flow
6.2.2 Terminating MAS
The Terminating MAS is the part of the MAS application which handles messages received on the receiver’s home server, after it has been processed by the Originating MAS. Terminating MAS logs the incoming messages just like the Originating MAS.
Besides logging, Terminating MAS takes necessary actions for cloning requests, offline messages, generating Auto-reply and Delivery-receipts. If required, the message is forwarded to the AS which in a final step delivers the message to the receiver.
The architectural flow of the Terminating MAS as shown in the diagram 11 can be described in the following steps.
1. Sip message received by the AS is forwarded to the “Read SIP message” module, which unpacks and parses the SIP messages.
2. The message and parsed information is logged (2B), and relevant information from the SIP message is passed to the Type Checker module (2A), concurrently.
Message Type Checker detects the type of request and takes the following actions accordingly.
1. If the type of the request is “instant message”, the message information is forwarded to the “Check Config” module, which may add relevant infor-mation to the message depending upon the receiver’s settings in the Con-figuration DB. The message information which may now be modified is forwarded to the next modules.
1. If the Email copy has been enabled in the receiver’s settings, the
“Check Config” module invokes the “Email-Copy” module which then embeds the message body in an email message and sends it to the email address specified in the Configuration DB (3.1A)
2. If the receiver is found to be offline through the presence module, the
“Check Config” module invokes the “Auto-Reply” module which may send an auto-reply to the sender if the receiver has enabled this service (3.1.1).
1. If enabled, the “Auto-Reply” module sends the original message to the message store and forwards the auto-reply message to the AS, concurrently.
3. If the receiver is online, as per information form the Presence mod-ule, “Check Config” module forwards the message to the “Deliver or Forward” module, which then forwards the message to the AS to be delivered to the receiver (3.1.2).
2. If the request is a 200 OK (or with any other valid code), the message information is sent to the “Check Response Message” module, which takes relevant action on the request (if needed) and forwards the message to the AS. In the current implementation, this module is never used since the AS handles SIP status messages internally and doesn’t forward such requests to the MAS at all.
3. If the request is an “offline message”, the message is forwarded to the
“Check Config” module. From there the message is forwarded to the “De-liver or Forward” module, which in turn sends the offline message to the AS to be delivered to the receiver.
4. If the request is a group message, it is forwarded to the “Clone” module which takes the following steps accordingly;
1. In case of “Group-Message”, the message is simply forwarded to the
“Deliver or Forward” module, provided the receiver is online. This information is fetched from the Presence module.
2. If the receiver is offline, a “remove me from the group” group message is composed and sent to all the members of the group, which the re-ceiver had been a part of. The group members information is retrieved from the Clone DB.
Presence Module is an information retrieval module, which informs about the on-line status of a user when invoked by any other module or process. Presence module gets the presence status information from the HSS, an essential part of the IMS plat-form.
Figure 11: MAS terminating side message flow