(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, 2010
SIP as Instant Messaging Protocol
The Internet Engineering Task Force (IETF) has definedtwo modes of instant messaging for SIP. The first is the pagermode, which makes use of the SIP MESSAGE method, asdefined in . The MESSAGE method is an extension to theSIP that allows the transfer of Instant Messages. This modeestablishes no sessions, but rather each MESSAGE request issent independently and carries the content in the form of MIME (Multipurpose Internet Mail Extensions) body part of each request. Additionally, grouping these independentrequests can be achieved at the SIP UA’s by adding a userinterface that lists these messages in ordered way or grouped ina dialog initiated by some other SIP request. By contrast, thesession mode makes use of the Message Session RelayProtocol or MSRP , which is designed to transmit a series of related instant messages of arbitrary sizes in the context of asession.III.
As mentioned previously in , SIP handles twomethods for instant messaging services, pager mode andsession mode. In a session mode there will be a sessionestablishment using Message Session Relay Protocol (MSRP)while in the pager mode there is no need to establish a session,because the MESSAGE method in SIP is actually a signalingmessage or request which is the same as INVITE, CANCELand OPTION. On the other hand, the MFTS server is thedistributing engine responsible for sending instant messagesamong MFTS users, which uses control messages for thatpurpose. From this point, we found out that it is more stable tochoose the SIP pager mode for instant messaging as the otherpart to communicate with MFTS users. Figure 2 below showsthe SIP MESSAGE request.
MESSAGE sip:email@example.com SIP/2.0Via: SIP/2.0/TCPuser1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70From: sip:firstname.lastname@example.org;tag=49583To: sip:email@example.comCall-ID: firstname.lastname@example.orgCSeq: 1 MESSAGE Content-Type: text/plainContent-Length: 18 Hello World
Figure 2. SIP MESSAGE Request
Since both MFTS and SIP use the Transmission ControlProtocol (TCP) for sending and receiving control messages(signaling) between their network components, the translationmodule should use TCP as well.
In order to ensure that a message will reach its destination,SIP proxy server may forward a SIP message request toanother server; in other words, a SIP message request maytraverse through several proxies before it reaches the finaldestination of the end user . On the other hand, in MFTS,similar mechanism is used to ensure that an MFTS messagewill reach to the user that resided behind another MFTS .The proposed interworking module will take the advantage of these features. The idea is to combine both the proxy servercapabilities with MFTS server capabilities in one entity. Thisentity should also include a translation component thattranslates SIP messages to MFTS messages and vice versa. Inthis case, both SIP proxy server and MFTS server willcommunicate with this entity as a server analogous to them.Accordingly, this method will provide transparentcommunication to the users and to the servers as well. Inaddition to that, the translation process will be done within thatbi-directional translation server. The Figure below illustratesthe general interworking prototype between SIP and MFTS.
Figure 3. SIP-MFTS Interworking
Before starting the interworking session, the translationmodule must register itself with the SIP server and supports theaddress resolution schemes of SIP. In MFTS, there are twotypes of registration. The first registration is that the MFTSserver should register itself to other MFTS servers, since thetranslation model is considered as another MFTS server from aMFTS user’s side; it must register itself with MFTS server. Thesecond type of registration is the process by which an MFTSclient logs into the MFTS server, and informs it of its IPaddress. Registration will occur before any instant messagingsessions are attempted. The MFTS server will respond witheither a confirmation or a reject message. In SIP, theREGISTER request allows a SIP registrar server to know theclient’s address.
Interworking Module Requirements
Each entity in the interworking module has been analyzedbased on its normal functionalities. According to that, Figure 4shows the internal modules by using the use case tool of theproposed translation server and the number of connections tothe SIP side of the network and to the MFTS side of thenetwork. As illustrated in figure 4, two modules are used forthe registration for both SIP and MFTS, and two additionalmodules are used for sending and receiving the controlmessages, these two modules are linked together by thetranslation function module to translate between the two typesof instant messages (MESSAGE and PRCHAT).
National Advanced IPv6 Centre.