(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, 2010
Point-to-Point IM Interworking Session Between SIPand MFTS
1
Mohammed Faiz Aboalmaaly,
2
Omar Amer Abouabdalla
3
Hala A. Albaroodi and
4
Ahmed M. Manasrah
National Advanced IPv6 CentreUniversiti Sains MalaysiaPenang, Malaysia
1
essa@nav6.usm.my,
2
omar@nav6.usm.my,
3
hala@nav6.usm.my,
4
ahmad@nav6.usm.my
Abstract
— This study introduces a new IM interworkingprototype between the Session Initiation Protocol (SIP) and theMultipoint File Transfer System (MFTS). The interworkingsystem design is presented as well. The interworking system relieson adding a new network entity to enable the interworking whichhas the ability to work as a SIP server to the SIP-side of thenetwork and as a MFTS server to the MFTS-side of the network.Use Cases tool is used to describe the translation serverarchitecture. Finally, experimental-based results show that theinterworking entity is able to run a successful point-to-pointinteroperability IM session between SIP and MFTS that involveduser registration and message translations as well.
Keywords- SIP; MFTS; Instant Messaging (IM);
I.
I
NTRODUCTION
Over the last few years, the use of computer network systems to provide communication facilities among people hasincreased; hence the service provided for this area must beenhanced. Various signaling protocols have arisen and manymultimedia conferencing systems have been developed that usethese signaling protocols in order to provide audio, video, dataand instant messaging communication among people.Transparent interoperability between dissimilar signalingprotocols and Instant Messaging and Presence (IMP)applications has become desirable in order to ensure full end-to-end connectivity. In order to enable the interoperabilitybetween two or more different signaling protocols or standards,a translation mechanism must exist in between to translate thenon-similar control options and media profiles. SIP [1], is awell-known signaling protocol that has been adopted in manyareas and applications in the Internet as a control protocol. SIPis an application layer protocol, used for establishing,modifying and ending multimedia sessions in an IP-basednetwork. SIP is a standard created by the Internet EngineeringTask Force (IETF) for initiating an interactive user session thatinvolves multimedia elements such as, video, voice, chat,gaming and virtual reality. It is also, a request-responseprotocol; like the HTTP [2], it uses messages to manage themultimedia conference over the Internet. On the other hand,The Multipoint File Transfer System or (MFTS) [3] is a filedistribution system based on the well knows “client-serverarchitecture”. The MFTS server is actually a distributionengine, which handles the issues related to file sharing as wellas instant messaging exchange among the various MFTSclients. The MFTS has been adopted in the MultimediaConferencing System (MCS) product [4] by the DocumentConferencing unit (DC), which is a network component that isresponsible for any user communications related to file sharingas well as instant messaging interaction.II.
SIP
AND
MFTS
AS
I
NSTANT
M
ESSGING
P
ROTOCOLS
A.
MFTS as an Instant Messaging Protocol
As everyone knows, Instant Messaging is a type of nearreal-time communication between two or more people based ontyped text. The text is carried via devices connected over anetwork such as the Internet. MFTS in turn, uses controlmessages as a carrier to send and receive instant messages(with text) among MFTS clients. As a normal IMcommunication, an MFTS client sends several instant messageswith a variety of lengths to one or more MFTS clients. Figure 1depicts the standard structure of the MFTS control message
Figure 1. MFTS Message Structure
As depicted above, the MFTS message is divided into fivemain fields Message Type, Command, Sender Information,Receiver(s) Information, and Parameters. Message type is usedto indicate the purpose of the message whether it is client toserver message or it is a server to server message, while thecommand indicates the specific name of the message like
Private Chat
(PRCHAT), the Command is a six characterlength. Additionally, Sender info and receiver(s) are used toidentify the IP address of both the sender and the receiverrespectively. Parameters are used to identify protocol-specificissues which out of the scope of this study [5].
84http://sites.google.com/site/ijcsis/ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, 2010
B.
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 [6]. 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 [7], which is designed to transmit a series of related instant messages of arbitrary sizes in the context of asession.III.
I
NTERWORKING
M
ETHOD
As mentioned previously in [8], 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:user2@domain.com SIP/2.0Via: SIP/2.0/TCPuser1pc.domain.com;branch=z9hG4bK776sgdkse Max-Forwards: 70From: sip:user1@domain.com;tag=49583To: sip:user2@domain.comCall-ID: asd88asd77a@1.2.3.4CSeq: 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.
A.
SIP-MFTS Interworking
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 [1]. 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 [3].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
B.
System Model
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.
C.
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.
(sponsors)
85http://sites.google.com/site/ijcsis/ISSN 1947-5500
(IJCSIS) International Journal of Computer Science and Information Security,Vol. 8, No. 7, 2010
Figure 4. Use Case Diagram for the Proposed Translation Server
D.
SIP and MFTS Message Translation
Both SIP and MFTS messages consist of few fields that areused to identify the sender, the receiver or receivers and someother information, in both of them this information isconsidered as a message header. Table I and Table II show thetranslation table that translates MFTS specifications to SIPspecifications and from SIP specifications to MFTSspecifications respectively.
TABLE I. MFTS-
TO
-SIP
T
RANSLATION
T
ABLE
MFTS SIP Header or Contents
Command body of MESSAGEThread Call-IDSender-Info FromReceiver(s) ToTABLE II. SIP-
TO
-MFTS
T
RANSLATION
T
ABLE
SIP Header or contents MFTS
Call-ID threadContent-Language (no Mapping)Cseq (no mapping)From Sender-InfoSubject (no Mapping)To Receiver(s)body of MESSAGE Command
IV.
T
ESTING AND
R
ESULTS
The translation server testing is based on proposing realinteroperability IM scenarios. Two tests are conducted, one tocheck the functionality of the system as an IM interoperabilitymodule between SIP and MFTS, while the second issupplementary to the first one which is to know the timerequired to receive an instant message to the destination client.Both tests are applied on a one-to-one interoperability sessionbetween SIP and MFTS. Moreover, each test is conducted fivetimes to ensure certainty.
A.
Functional Testing
SIP-MFTS Functional testing is basically done by sendingseveral chat messages with a variety of lengths to thedestination/s. It is applied on all proposed scenarios that werementioned in subsection 5.2.1. Five different lengths of messages are sent through the network starting from “Helloworld” sentence and ending with its duplications, for instance,the second sentence is “Hello world Hello world” and so on.All functional tests were done successfully.
B.
Time Required
This part of testing has actually followed the sameconducted steps in the functional testing. All tests at this stageare done by acquiring the required time for each chat messageto reach the other domain. Furthermore, each type of test isdone five times and an arithmetic mean is calculated for them.Table III reports the time required for the messages to be sentfrom the SIP client to the MFTS client, while Table IV showsthe time required for the message to be sent from the MFTSclient to the SIP client. Moreover, there was no significantdifference noticed in both tests (SIP to MFTS) and (MFTS toSIP).
TABLE III. SIP
TO
MFTS
Message Lenght Time (Seconds)
“Hello World” X1 0.23“Hello World” X2 0.27“Hello World” X4 0.34“Hello World” X8 0.45“Hello World” X16 0.43TABLE IV. MFTS
TO
SIP
MFTS SIP Header or Contents
“Hello World” X1 0.29“Hello World” X2 0.28“Hello World” X4 0.26“Hello World” X80.50“Hello World” X160.39
V.
C
ONCLUSION AND
F
UTURE
W
ORK
The
translation server was capable of handling a one - to -one instant messaging conference between SIP and MFTS.Two types of tests were conducted; functionality test and thetime required. All tests are done successfully and were withinan acceptable range. Proposed future work might cover themultipoint IM sessions between SIP and MFTS (work inprogress) and might also include the multiple-protocolinteroperability concept that involves many IM protocolscommunicating together. Furthermore, since MFTS has thecapability to work as a file transfer system, and since there is astudy conducted to make SIP able to work as a file transfer
86http://sites.google.com/site/ijcsis/ISSN 1947-5500
Search History:
Result 00 of 00
00 results for result for
p.
Point-to-Point IM Interworking session Between SIP and MFTS
This study introduces a new IM interworking prototype between the Session Initiation Protocol (SIP) and the Multipoint File Transfer System (MFTS). The interworking system design is presented as well. The interworking system relies on adding a…
(More)
257
Reads
1
Readcasts
4
Embed Views
More From This User
Notes
Load more
