A P2P Architecture to Support Mobile Real-Time ... - Semantic Scholar

514

JOURNAL OF MULTIMEDIA, VOL. 5, NO. 5, OCTOBER 2010

A P2P Architecture to Support Mobile Real-Time Multimedia Communications Daniel G. Costa Department of Technology, State University of Feira de Santana Av. Transnordestina, S/N, Novo Horizonte, 44036-900 Feira de Santana, Bahia, Brazil [email protected]

Sergio Vianna Fialho Department of Computing and Automation, Federal University of Rio Grande do Norte Caixa Postal 1524, Campus Universitário, Lagoa Nova, 59072-970 Natal, Rio Grande do Norte, Brazil [email protected]

Abstract - A new SIP standard based on peer to peer paradigm allows the keeping of user localization information in a decentralized way, adding flexibility to real-time mobile communications. Despite specification of terminal mobility in P2PSIP, handover procedures in transport-layer have better performance when compared with solutions in application-layer of Internet. SCTP transport protocol supports handover and a partial reliable communication service. Putting together P2PSIP and SCTP extensions, an end-to-end architecture can be proposed, aimed at the support of real-time multimedia applications with mobility requirements. Index terms - real-time multimedia communications, Internet mobility, P2P.

I. INTRODUCTION In modern networks, mobility requirements are demanding new solutions related with Internet evolution trends. When these requirements are associated with realtime multimedia communications, a complex environment is created. Mobile real-time multimedia applications are becoming common, due to wireless network spreading and new 3G/4G cellular technologies. This growing demand is harmed by limitations in Internet structure, which motivates the specification of new communication architectures aimed at specific requirements of these applications. Session Initiation Protocol (SIP) [1] is an applicationlayer protocol used to establish, to control and to tear down real-time multimedia communications between two or more applications. Nowadays, SIP stays as the main solution for real-time multimedia communication in Internet environments. Recently, Peer-to-Peer Session Initiation Protocol Work Group (P2PSIP WG) [2] has begun to create a new standard that employs P2P paradigm as the basis for SIP operation. It intends to keep some very important information in a decentralized way, avoiding the use of specific servers, as SIP Registrars. One kind of information that can be kept and managed by

© 2010 ACADEMY PUBLISHER doi:10.4304/jmm.5.5.514-521

a P2P approach is user location (current IP address). That Work Group has written an initial document which describes the expected operation of that new standard [3], though a whole specification will be released just latter. Stream Control Transmission Protocol (SCTP) [4] is a transport-layer protocol initially designed to allow telephone signaling over Internet backbones. Nevertheless, SCTP can provide a series of services not presented in traditional Internet transport-layer protocols, as TCP. One extension for this protocol takes advantage of native multihoming support on transport-layer to provide terminal mobility (handover), avoiding special support from network devices, such as routers and switches. Another SCTP extension allows different data retransmission requirements in the same communication. Users of this communication service can specify what data must be retransmitted if some corruption or lack of information is detected, and what data must not. In [5] one can find a communication architecture that put together SCTP and SIP to support real-time multimedia communications with mobility requirements. In that solution, handover procedures are expected from transport-layer by SCTP, while user localization service is executed by SIP, with direct support from Registrar servers. In the same way, an end-to-end architecture is presented herein, aiming at the support of mobile realtime multimedia communications. However, the core of the architecture is now composed by SCTP and P2PSIP, instead of standard SIP. Keeping information about user location in a P2P overlay brings flexibility for this solution, while makes it more acceptable for modern Internet communication scenarios. This end-to-end operation has a potential better performance than other solutions, as presented by some works [6] [7]. To avoid misunderstandings and operation “deadlocks” in the definitions and descriptions of the proposed architecture, a Control Module is formally specified. This module coordinates the ordered operation of the different protocols that compose the architecture protocol stack. Doing so, one can attests that the architecture works


properly as specified. Moreover, that formal specification can help in experimental simulations or even practical development of communication terminals following the rules and procedures of the proposed architecture. Academic tools designed to simulate the operation of Internet protocols do not support completely SCTP and its extensions. On the other hand, the still young SCTP extensions are not yet available in programming libraries. The same is true for P2PSIP. Formal specification can assist in future implementations of the proposed architecture. This paper is structured in the following way. Section II presents the concepts related with the main protocols that form the proposed mobile real-time multimedia architecture. Section III describes the communication procedures of the solution presented by this paper. Section IV brings the Control Module formal specification. At last, the conclusions and references are presented. II. RELATED PROTOCOLS SIP is an application-layer protocol aimed at the control of real-time multimedia communication sessions. One of the services provided by SIP and some supporting protocols is user localization. Such service allows that the IP address being currently used by a host (user location) be discovered, even if that address just changed due to user mobility through different networks. When P2PSIP is used instead, information about user location is kept by the hosts, not requiring any additional centralized server, as SIP Registrars. SCTP is a reliable transport-layer protocol which has typical services expected from Internet transport-layer, but brings other features not presented in traditional connection-oriented TCP. One of them allows selective retransmission of corrupted data. Moreover, multiple streams create separate control of data being transmitted, enhancing the overall performance in transport-layer. The concept of SCTP association, deeper than TCP connections, is associated with multiple simplex streams with individual logical control of the message-oriented user data. At last, native multihoming support in SCTP association enables hosts to employ more than one IP address to identify the communication, since they have more than one connection point to Internet backbone: each additional address can be used to create a backup link, in the case first IP address is no more accessible. All these features put SCTP as a better solution for communication scenarios traditionally associated to TCP. Using SCTP flexibility to incorporate new extensions, Stream Control Transmission Protocol Partial Reliability Extension (PR-SCTP) [8] comes as a way to send data with distinct reliability requirements at the same association. User can dynamically define what data must be retransmitted if some corruption occurs. With PRSCTP, transport-layer communications acquire other possibilities not presented in TCP and UDP, as for example an ordered but non-reliable transmission service.

© 2010 ACADEMY PUBLISHER

515

ADDIP [9] is a SCTP extension that uses multihoming feature along with address reconfiguration procedures to provide handover support in Internet transport-layer. When a host acquires a new IP address, resulting from user movement across different networks, the remote endpoint notices that new address by the reception of a special message described in ADDIP specification. Such address reconfiguration procedure does not cause any communication cease or loss and does not need any additional support from Internet backbone. ADDIP extension, along with others mobility solutions as MIP (Mobile IP) [10], does not define any user localization service. Doing so, ADDIP cannot be used alone to support mobile communications on Internet. III. FUNCTIONAL SPECIFICATION OF THE ARCHITECTURE The P2P architecture presented herein is intended to support mobile real-time multimedia communications, providing user localization and handover procedures. For that, services from SCTP, PR-SCTP, ADDIP and P2PSIP are combined, as well as specific services from support protocols, as Real Time Protocol (RTP) [11] and Session Description Protocol (SDP) [1]. All of them are already defined for use in Internet backbones, so it is not initially expected performance loss or additional overhead when they work together. Moreover, the end-to-end nature of the proposed architecture does not require any change on networks structure. In fact, only software (protocols and architecture specific code) is required to be installed in the communication hosts. Typical applications for the architecture are videoconference, Video over Demand (VoD), Voice over IP (VoIP) and video phoning, all of them in mobile communication environments. In the first version of the proposed solution, multipoint control units and multicast paradigm will not be considered due to connection-oriented nature of SCTP transport-layer protocol. Only point-to-point communication will be supported. The P2P version of Session Initiation Protocol makes easy the practical use of the architecture, since all control information is kept and managed by hosts. Such decentralized behavior is a potential advantage when compared with solutions based on servers: a communication environment can be quickly set employing only conventional Internet hosts. P2PSIP alone can provide terminal mobility and user localization for mobile hosts. Although such solution works fine, there is a faster way to support handover in Internet, letting P2PSIP only with multimedia control and user location management. As SCTP handover procedures have a better performance, P2PSIP can use underlying SCTP transport-layer protocol to support every communication. Handover in transport-layer is potentially faster, but SCTP alone does not have any support for user localization. Taking advantage of the best part of each particular protocol, the proposed architecture presents itself as a potential better solution for real-time multimedia applications that are also

516


mobile. SIP is seen as the best public multimedia session control protocol for Internet, being employed in almost all modern applications in this area. On the other hand, SCTP has many other advantages than only handover support, when compared with traditional transport-layer protocols in Internet, improving the overall communication in many aspects. Figure 1 presents the protocol stack of the proposed architecture. The Control Module is a code specially designed to coordinate the ordered operation of the protocols that compose the presented stack. Such code also defines an interface between the services provided by the architecture and the user application. In Figure 1, PR-SCTP, ADDIP and SCTP were presented separately in order to ease the perception of the individual functionality expected from each one of the modules. In typical implementations of architecture terminals, however, all of these modules will be located in the Operating System as a Stream Control Transmission Protocol module with two extensions, since application-layer protocols will require the transport-layer service directly from SCTP. For security reasons, real-time multimedia streams can be created using the Secure RTP (SRTP) [12] support. This is not a requirement, but only an optional service with no direct impact on the architecture operation, though cryptographic algorithms can increase the overall latency and jitter of real-time communications.

The architecture communication service is directly managed by the Control Module. This module indicates service primitives that applications must use to interact with the architecture protocols. Table I points out these primitives. It is important to notice that the mobility service is completely transparent for the applications, which have an end-to-end view of the communication. TABLE I SERVICES PRIMITIVES OF THE ARCHITECTURE.

Action

To open a connection

Service Primitive Open_Connection. request Open_Connection. Indication Open_Connection. Response Open_Connection. Confirm

To close a connection

To send data To check host status

Parameters Destination SIP address (SIP URI) Source SIP address The answer for a request to open a connection Confirmation for a request to open a connection Destination SIP address

Close_Connection. Request Close_Connection. Indication Data.request

Data (audio/video)

Data.indication Status.request Status.indication

Data (audio/video) Specific parameters Specific parameters

Source SIP address

A. User localization

Figure 1. Protocol stack of proposed architecture.

When a host changes the network it is attached to, often due to a movement across different wireless networks, Dynamic Host Configuration Protocol (DHCP) [13] can be applied to indicate if such change also requires a new IP address. That service can be provided by other protocol, with no harm to the overall solution.


Communications among IP hosts in a mobile context may be of two kinds: a) the ones initiated from mobile hosts to non-mobile hosts, in wired or wireless networks, and b) the communications targeted to mobile hosts, no matter the origins. In a) there is no need of any user localization mechanism. In this case, the mobile hosts must use the handover support from ADDIP. When a host is wired, its address can be known previously by some means usually presented in IP networks, querying, for example, the Domain Name System (DNS) [14]. However, in b) we wish to know the address being used in a specific moment by a host, though such address can’t be predicted or previously known. In [5] it was described the use of SIP Registrars to keep track of mobile hosts while they move across different Internet networks. Each user must to be registered to a “home” Registrar, which associates one or more IP addresses (referring to mobile hosts) to a globally unique SIP address (SIP URI). When a host acquires a new IP address from the network it moved to, the corresponding SIP Registrar is notified, and the appropriate record in that server is updated to reflect the new location indicated by the host. At this moment, the current location of the terminal in utilization by the user can be discovered just querying the SIP Registrar for the IP addresses associated to a known SIP URI. Registrars IP address can be discovered by consulting DNS records, which represents


the domain part of the SIP address (for the SIP address “sip:[email protected]”, the domain part is “uefs.br”). With P2PSIP, user localization procedures are managed by hosts, which can access any information kept by the P2P overlay, following the specification presented in [15]. In fact, the desired information can be located in one or more hosts in the overlay, including in the requesting host. The Resource Location and Discovery protocol (RELOAD) is defined to manage such information. No SIP Registrar is needed anymore, and the proposed architecture stays with no centralized point (except DHCP and optionally DNS servers, that are already typically deployed in modern networks). How the information is kept by the P2P overlay is out of the scope of the architecture. For the applications, replacing Registrars by a P2P approach has a small impact, since the principle of query/answer is the same. However, when network infrastructure is considered, triangular routing and servers installation requirements count against server-centric solutions. B. Handover Dynamical reconfiguration procedures of transportlayer ADDIP extension make part of the communication services of the proposed architecture. These procedures depend on three basic aspects. First, a host has to discover that it changed the network it was attached to. Second, if the new network is different from the previous one, in logical means, the mobile host has to acquire a new IP address from the visited network. At last, ADDIP handover procedures can be executed. A mobile host (that must to be a wireless host too), from the power level of received signals broadcasted by access points [16], can identify a changing in the network it is attached to. This identification is managed by linklayer procedures. If the logical network has not changed, there is no need to acquire a new IP address. So, in the same logical network, movements across different wireless cells do not require a new IP, though it can be changed. Internet Protocol routing uses a subnet mask to decide if packets must be routed to a pre-defined path or if packets must be delivered locally. However, if mobile hosts move to a different logical network, it has to get a new IP address, which indeed can be automatically received from some network service, as DHCP servers. To identify logical network changes, it is expected some support from an upper layer, since link-layer procedures do not handle IP addresses. As soon as the host realizes it is attached to a different logical network, it can start a procedure to get a new IP and subnet mask information. Additionally, hosts in Internet usually need to know the address of default gateway and DNS servers to send resolving queries. In order to maintain flexibility and high performance of the communications based on the proposed architecture, DHCP is recommended to deliver IP addresses and other relevant information to mobile hosts.


517

If a mobile host is currently on communication with a remote host, when it receives a new IP address, it must immediately inform its communication peer about such new location. This notification uses the support from ADDIP, which provides transparent and seamless handover over IP networks: the host that has acquired the new IP address sends an ASCONF message to the communication endpoint, informing the new address. The correct reception of this message is confirmed by an ASCONF ACK message. Such procedure has a better performance than other mobile architectures as Mobile IP version 6 (MIPv6) [17] and Host Identity Protocol (HIP) [18], as presents some works [6][7]. C. Real-time multimedia communication Using PR-SCTP, together with SCTP reliable transport-layer service, real-time multimedia data and session control information can be transmitted at the same association. Multimedia data is to be sent as a nonreliable stream, since it is time sensitive, while control information flows at a reliable stream. System resources in hosts and network overhead are potentially reduced by using one single SCTP association instead of many separate connections. Time sensitive multimedia data in Internet is encapsulated by RTP packets [11]. Timestamp information presented in RTP packet header is used in a communication endpoint for decoding and reproduction of received media. In the proposed architecture, RTP is used for the same purpose, but not associated with UDP datagrams, as usual. Otherwise, RTP packets will be encapsulated by PR-SCTP. As wireless links have a potential higher error rate than wired links, it is recommended the using of codecs with packet loss tolerance, as iLBC [19] Optionally, encoded real-time multimedia can be sent in a cryptographic stream. When this option is chosen, SRTP must be used instead of RTP. Security management, comprising the keeping and distribution of cryptography keys, is out of the scope of the proposed architecture, though SCTP extensions for security can be used as an additional service. D. A typical communication scenario Figure 2 presents a typical communication scenario following the specifications described in the previous subsections. All services expected from the proposed architecture are comprised in that example, which points out the transmission and reception of messages from SCTP, PR-SCTP, ADDIP, SIP and P2PSIP. When Host B is turned on, it should update its current IP address information in the P2PSIP overlay (message 1). That information is associated to the SIP URI of the user who is using the mobile terminal (in the example, sip:[email protected]).

518


SIP communication session is also created (messages 7, 8 and 9), over the SCTP association. At this point, the realtime multimedia stream (audio and/or video) can flow through the SCTP association, using PR-SCTP extension to avoid undesirable retransmission of time sensitive multimedia packets (messages 10 and 11). After a while, mobile Host B acquires a new IP address from a visited network. As soon as possible, Host B initiates the handover procedures, employing ADDIP extension (messages 12 and 13). After the sending of an ASCONF message, Host B should update its current location information in the P2PSIP overlay, so other communication terminals can reach it (message 14). When the handover is finished, real-time multimedia streams flow to the current location of Host B (messages 15 and 16). To tear down the communication as a whole, the SIP communication session (messages 17 and 18) and the SCTP association (messages 19, 20 and 21) has to be closed. IV. CONTROL MODULE

Figure 2. Messages in a typical communication scenario.

If Host A wishes to establish a new communication to Host B, it has to query the P2PSIP overlay for the IP address currently associated to the SIP URI [email protected] (message 2). As an answer, the overlay returns the Node-Id [15] of Host B and its current IP address. In fact, Host A may already know the current IP address of Host B, since it also makes part of the overlay. With the IP address of Host B, Host A can start a new communication directly to Host B, without any routing through the overlay. The initial step is to establish a SCTP association (messages 3, 4, 5 and 6). After that, a © 2010 ACADEMY PUBLISHER

The communication scenarios of the proposed architecture are formed by terminals and servers. The terminals are hosts that are executing the software of the architecture (the Control Module and the protocols that compose the architecture protocol stack). The servers can be any of two types: DHCP and DNS (optionally, only for direct mapping between IP address and DNS domain name). As the servers operate as specified by their official documentations, the new element for Internet is only the communication terminal. According to architecture specification, the Control Module is specially designed to coordinate the ordered operation of already defined Internet protocols. Additionally, this module establishes an interface between the architecture operation procedures and the user application. The services expected from the architecture, described in the previous subsections, are indirect definitions of Control Module functionalities. In order to ensure the correct operation of the Control Module, attesting its definitions are free of deadlocks and misunderstandings, the formal specification language SDL (Specification and Definition Language) and its extension SDL/GR (SDL Graphical Representation) [20] were employed. With the specification in SDL, syntactic and semantic verifications could be performed. Only a small part of the final specification is presented in this paper, due to restrictions in the number of pages. Every user who wants to communicate using the services of the proposed architecture has to access a terminal. Typically, terminals will be implemented as software in a host or will make part of a special hardware dedicated to communicate following the standards of the proposed architecture. Terminals will be composed by all protocols specified for the architecture and the Control Module software. It is also expected hardware support for multimedia, as headsets and/or webcams, in order to capture and reproduce audio and/or video.


The formal specification in SDL was performed with focus on communication terminals, as presented in Figure 3. The terminal is formed by many blocks: Control Module, P2PSIP, RTP/SRTP, DHCP, DNS, UDP, PRSCTP, ADDIP and SCTP. The communication among the blocks is identified by SDL signals. The most of these signals are messages of the protocols that compose architecture protocol stack. Control Module is specified as a SDL block with three

519

internal processes: Call Control, Mobility Management and Real-time Data Communication. Each of these processes is related with the control of a specific part of the communication procedures of the architecture. The complete specification of the architecture encloses these three functional parts. The communication among each block that composes a communication terminal is identified by SDL signals, as presented in Table II.

TABLE II SDL SIGNALS OF THE ARCHITECTURE.

Signal

Channel

ADDIP_Control

ADDIP ↔ SCTP

Communication_Close

Control Module ↔ P2PSIP

Communication_Open

Control Module ↔ P2PSIP

DHCP_Message

DHCP ↔ UDP

DNS_Query

DNS ↔ UDP

Find_IP_Remote_User

Control Module → P2PSIP

IP_Changed

DHCP → Control Module DHCP → IP

IP_Packet

IP ↔ Network

Multimedia_Data

RTP/SRTP ↔ Control Module

New_IP_For_Association

Control Module → ADDIP

New_IP_For_Overlay

Control Module → P2PSIP

P2PSIP_Message

PR-SCTP ↔ P2PSIP

PR-SCTP_Control

SCTP ↔ PR-SCTP

PR-SCTP_Data

PR-SCTP ↔ SCTP

Remote_User_IP_Found

P2PSIP → Control Module

RTP_Packet

RTP/SRTP ↔ PR-SCTP

SCTP_Control

SCTP ↔ IP

Terminal_Status

Control Module ↔ User Application

UDP_Message

UDP ↔ IP

User_Application_Control

Control Module ↔ User Application


Description ADDIP control message (ASCONF or ASCONF ACK). Request from the end point to start a new communication (SIP connection over a SCTP association). Request from the end point to close a current communication (SIP connection over an SCTP association). DHCP message (to discover logical IP change and to provide new address), carried within UDP payload area. Message processed by DHCP servers. DNS message carried on UDP payload area. Message treated by DNS servers. A request to find the current IP address of a user, regarding his/her SIP address. Such association is kept by the P2PSIP overlay. Indication of change in IP logical network. DHCP module gives a new IP configuration to IP module. IP packet transmitted through heterogeneous communication links. Encoded audio or video (audio and video are transmitted in different RTP streams). A request to start handover procedures (sending of ASCONF and reception of ASCONF ACK). The new address of the terminal. That address must be “included” in the P2PSIP overlay. SIP/P2PSIP message (e.g. INVITE, ACK, 200 OK, 180 RINGING and BYE) carried in SCTP DATA messages. PR-SCTP control message (FWD-TSN). Conceptually, a SCTP_Data SDL signal. It is separated here just for clarification. The IP address of the destination host discovered by a query to the P2PSIP overlay. RTP packet carried in SCTP DATA messages. SCTP control message (e.g. INIT, INIT ACK and SACK) General information about status of current and past communications. UDP message (typically, will carry DNS_query and DHCP_message). Messages for User Application control of the terminal. Formed by service primitives.

520


Figure 3. Specification of the communication terminal, showing its logical blocks.



V. CONCLUSIONS P2PSIP standard had its first draft published only in July 2008. It is still getting mature, as one can see in P2PSIP Work Group schedule [2]. However, even in the initial stage, many benefits are expected when P2PSIP is adopted in real-time multimedia communication scenarios. Integrating this standard with SCTP, as well as with PR-SCTP and ADDIP extensions, the resulting architecture presents itself as an efficient and flexible solution for real-time multimedia applications with mobility requirements. Its end-to-end nature and decentralized structure give it a huge advantage when compared with other mobility solutions, as Mobile IP. The last years have seen the increase of real-time multimedia applications in Internet. As wireless networks are getting common, those applications tend to become mobile. Supporting this specific but growing group is a big challenge addressed by the proposed architecture. SCTP is still a young protocol that has potential to become the standard transport-layer protocol of Internet. On the other hand, SIP is currently the main public solution for controlling multimedia sessions, especially for videoconference and VoIP applications. Although the actual efficiency of the architecture was not measured yet, due to implementation and simulation restrictions imposed by the still recent SCTP extensions and P2PSIP specification, one can predict a better performance of this architecture over the traditional solutions adopted for Internet mobility. Individual analysis of some specific communication scenarios provided by SCTP and SIP is a good evidence of this assumption [21] [22] [23]. This work is not completed finished. New specifications of the architecture will regard multipoint communication and optional charge mechanisms. Quality of Service, not present in this first specification, can be recommended for specific communication scenarios. These new functionalities may be considered by new versions of the proposed architecture. At last, the implementation of communication terminals is also envisaged in future works. New programming libraries will permit the development of communication terminals in SCTP enabled environments. Following the specification presented herein, these implementations will allow extensive testing of the architecture, finally attesting its already expected good performance.

521

[5] D. G. Costa and S. V. Fialho. A Communication Architecture Based on SCTP and SIP to Support Mobile Real-Time Multimedia Applications, INFOCOMP Journal of Computer Science, Vol. 8, No. 3, 2009. [6] S. Zeadally and F. Siddiqui. An Empirical Analysis of Handoff Performance for SIP, Mobile IP, and SCTP Protocols, Wireless Personal Communications Journal, Vol. 43, Na 2. 2007. [7] M. Ratola. Which Layer for Mobility? – Comparing Mobile IPv6, HIP and SCTP, HUT T-110.551 Seminar on Internetworking. 2005. [8] R. Stewart and Q. Xie. RFC 3758. Stream Control Transmission Protocol Partial Reliability Extension. 2004. [9] Q. Xie and R. Stewart. RFC 5061. Stream Control Transmission Protocol (SCTP) Dynamic Address Reconfiguration. 2007. [10] C. Perkins. RFC 3344. IP Mobility Support for IPv4. 2002. [11] R. Schulzrinne and S. Casner. RFC 3550. RTP: A Transport Protocol for Real-Time Applications. 2003. [12] M. Baugher, D. McGrew, M. Naslund, E. Carrara and K. Norrman. RFC 3711. The Secure Real-Time Transport Protocol (SRTP). 2004. [13] R. Droms. RFC 2131. Dynamic Host Configuration Protocol. 1997. [14] P. Mockapetris. RFC 1034. Domain names - concepts and facilities. 1987. [15] C. Jennings and B. Lowekamp. Internet Draft. REsource LOcation And Discovery (RELOAD). 2008. [16] M. S. Gast. 802.11 Wireless Networks: The Definitive Guide. 2ª ed. O´reilly. 632p. 2005. [17] D. Johnson, C. Perkins and J. Arkko. RFC 3775. Mobility Support in IPv6. 2004. [18] R. Moskowitz and P. Nikander. RFC 4423. Host Identity Protocol (HIP) Architecture. 2006. [19] S. Andersen, A. Duric and H. Astrom. RFC 3951. Internet Low Bit Rate Codec (iLBC). 2004. [20] SDL. “SDL Forum Society”. Available online: http://www.sdl-forum.org. 2009. [21] Wedlung, E. and Schulzrinne, H. Mobility Support Using SIP, 2nd IEEE International Conference on Wireless and Mobile Multimedia. Seatle, USA, 1999. [22] Nooman, J., Perry, P. and Murphy, J. A study of SCTP services in a Mobile-IP network, 1st ACM Workshop on Wireless Multimedia Networking and Performance Modeling. Montreal, Canada, 2005. [23] Marco, G., Vito, D., Longo, M. and Loreto, S. SCTP as a transport for SIP: a case study, Journal of Systemics, Cybernetics and Informatics, Vol. 2, No. 3, 2006 Daniel G. Costa is a Professor of Computing Engineering at the State University of Feira de Santana – UEFS, Brazil. His research interests include real-time multimedia communications, Internet services and applications, network management and mobility.

REFERENCES [1] J. Rosemberg and R. Schulzrinne. RFC 3261. Session Initiation Protocol”. 2002. [2] P2P SIP IETF Work Group. Available online: http://www.ietf.org/html.charters/p2psip-charter.html. 2009 [3] D. Bryan, P. Matthew and E. Shim. Internet Draft. Concepts and Terminology for Peer to Peer SIP. 2008. [4] R. Stewart and Q. Xie. RFC 4960. Stream Control Transmission Protocol. 2007.


Sergio Vianna Fialho, D.Sc. has been working since 1978 for the Federal University of Rio Grande do Norte – UFRN, at the Department of Computing Engineering and Automation, Brazil. His principal areas of interest are communication protocols, Internet services and applications, education, formal description techniques, network management and mobility.