SIPTalk: An IMS-like Platform for Telecommunication Services

Transcription

1 SIPTalk: An IMS-like Platform for Telecommunication Services T. Rachidi, A. Mourhir, and F. Chaatit Al Akhawayn University in Ifrane, Ifrane, Morocco Abstract This paper details the architecture, the key design decisions, and implementation of SIPtalk, an IP Multimedia Subsystem (IMS)-based communications platform for operators. SIPTalk offers a rich set of services aimed at providing a unified solution for communication across heterogeneous telecom networks. These services include duplex voice, video conferencing, instant messaging, media sharing, children position tracking, active contacts, and reading. As a business model, SIPTalk leverages subscription information by delivering targeted video advertisement services as a payment method for calls terminating at landline or mobile network. Subscribers can also use SIPTalk prepaid service for these calls. In addition to system and software design patterns, the paper addresses critical issues, such as scalability, NAT traversal, network interconnect, ease of service provisioning, user experience, and last but not least system and service administration. The paper also contrasts SIPtalk implementation to 3GPP standard IMS release 7 specifications. I. INTRODUCTION Today's telecommunication arena is rapidly moving towards next-generation networks (NGNs) that offer ubiquitous, converged services over converged voice, video, data and mobile networks. The IP Multimedia Subsystem (IMS) [9] is a unifying architecture that allows delivery of identical services to fixed and mobile customers - regardless of whether they are connected through the packet-switched (PS) or circuit-switched (CS) network. IMS-based services enable communication in a variety of modes including voice, text, location, presence, messaging, pictures and video, or any combination of these. In contrast to traditional networks where a central office switch does it all, including call control and service control, IMS distributes functions over specialized network nodes. With IMS, a service provider may initially have a small number of subscribers, and as the subscriber base grows, the IMS network can seamlessly scale up by adding extra nodes. IMS uses the Session Initiation Protocol (SIP)[14], originally standardized by the IETF, as its base signaling protocol. SIP is an Internet protocol that can accommodate convergence, with the potential to meet all the needs of the IMS architecture, as well as those of Unified Communications [13]. Unlike H323, SIP, for instance, can signal between different network entities, including endpoints and servers. SIP's flexibility enables IMS networks to adapt and change signaling protocols to meet dynamic market needs for telecommunication services. Yet, despite of these promises, IMS has been slow 1 in penetrating the market of service providers. This is because of the complexities in rolling out fully compliant IMS solutions. Many service providers have settled for solutions that are diminished implementation of IMS standard architecture. These solutions generally make use of key components of the IMS architecture such as P-CSCF and S- CSCF-nodes, HSS, doing without other components such as BGs, SBCs, and I-CSCF nodes. In this paper we present SIPTalk, which is our implementation of IMS for a national telecommunication operator. SIPTalk is a complete solution for unified communications that comprises core signaling and Application server nodes, as well as subscriber client software for both PCs and mobile devices. While SIPTalk architecture uses a subset of IMS nodes, it retains high degree of compliance with IMS standard architecture. From a business model point of view, SIPTalk tries to outlast the stream of fees for PSTN interconnection; calls can be made to mobile phones and landlines using prepaid cards or toll free if caller agrees to watch a multimedia advertisement. From this point of view SIPTalk is an innovative solution that provides the service operator with an extra stream of revenue from the publicity market, while offering a free alternative to making landline calls. In addition to delivering targeted ads, SIPTalk engineering took into consideration a number of key functional and non-functional requirements, namely: low cost of ownership, ease of roll out and administration of services, a rich user experience through a unified user console, that includes functionalities such as Active phonebook that extends presence to accessibility by voice, video, or instant messaging channels; a tracking service, that delivers notifications as soon as a target (one s kids, for instance) exit a predefined tracking area (a school for instance). SIPTalk therefore offers an alternative to major VoIP solutions such as Skype [23], Google Talk[22], and MSN [26]: Though Skype provides a rich set of services [24-25], is in fact on a philosophical back foot, as its is a closed software. SIPTalk, on the other hand, is based on the IMS open technology that enables it to transfer sessions across other IMS-based networks, and to integrate Application Servers from different vendors. Furthermore, SIPTalk s feature set has a number of innovative elements that Skype 1 Information collected both at the SIP 07 and SIP 08 conferences in Paris. 1

2 hasn t. Google Talk on the other hand, is missing from a SIPTalk user's point of view almost everything. The design and implementation of SIPTalk went through numerous challenges, namely system and software design patterns for scalability, NAT traversal, network interconnect, ease of service provisioning, user experience, and last but not least system and service administration. These will be depicted throughout this paper. Section 2 of this paper addresses SIPTalk system and software architectures, while implementation issues are described in section 3. Section 4 gives details about the level of compliance of SIPTalk to standard IMS release 7. II. SIPTALK ARCHITECTURE SipTalk is a distributed multi-service communication platform. Figure 1 shows the components of the different tiers of SipTalk architecture. These are the clients (front end tier), the gateways (middle tier), and the services together with the central the databases (back end tier). Thus, as the number of subscribers increases, more gateways and backend servers are started on different physical servers. Each group of subscribers is assigned a serving Gateway. The gateways themselves access backend services through a load balancing module (operates in round robin) at the level of the central registry. The SIPTalk platform is fully distributed and scalable architecture. B. SIPTalk Softphone SIPTalk softphone implements most of the intelligence. Access to all services is proxied through the Serving Gateway. The central registry (obtained from a configuration file) allows the softphone to discover its serving gateway. Other configuration parameters like the SIP domain, the audio and video codecs are obtained from the serving gateway; these parameters are set centrally by the operator for a given gateway in order to guarantee an optimum traffic. Figure 2 gives the software architecture of SIPTalk Softphone. Each of the modules that make up the softphone runs as a separate thread. All SIP data and control messages are handled by the SIP user agent. Simple request/reply protocols are used by other modules. The main communication services delivered through the softphone are given in Table I. Figure 1. SIPTalk System architecture A. Scalability through distribution An important requirement for SIPTalk is scalability. Scalability indicates the capability of a system to maintain performance under increased load, that is when the number of subscribers increases to reach 100s of thousands of subscribers. Distribution has been adopted as a key design feature for fulfilling the scalability requirement. A look at SIPTalk system architecture in Figure 1 unveils that: The Services and gateways are independent from each other and can be launched on separate servers. The system can handle duplicate gateways and duplicate services running on multiple gateways. A central registry keeps tracks of the location of the different services and gateways. As many instances of the same service as needed can be launched on different physical servers, and the request to these duplicate services can be load balanced. Session control messages are exchanged centrally, while media/information delivery is performed on a peer-to-peer (P2P) basis. TABLE I. Figure 2. SIPTalk softphone software Architecture Logon authentication MAJOR SERVICES PROVIDED BY THE SOFTPHONES. and Profile management Viewing contacts profiles Managing the buddy list (add/delete users contacts) Tracking (geolocalization) of contacts read out (in progress) Establishing sessions with other users and make audio/video calls Make landline and mobile calls Call transfer Sponsoring through viewing third party ads. Prepaid services (buying SipTalk credit) Conference with up to 4 participants Media sharing Instant messaging Advanced Presence and active phonebook Automatic Update 2

3 C. Large scale Deployment From a deployment perspective, SIPTalk softphone is available for PCs and PDAs running Windows Mobile 5+. It can be started directly from the Internet using a web browser using the Java WebStart framework [19]. The softphone is typically initiated through the browser, deployed to the client machine and executed outside the scope of the browser. Once deployed, it automatically download updates on startup if the user is connected to the Internet without requiring the user to go through the whole installation process again, thus easing the burden of deployment. D. Firewall Traversal While today's Firewalls are able to dynamically open and close multiple ports as required by VoIP signaling protocols, such as SIP, they remain ineffective at supporting unsolicited incoming media flows. NAT devices prevent two-way voice and multimedia communication, because the private IP addresses and ports inserted by client devices (IP phones, video conferencing stations etc.) in the packet payload are not routable in public networks. Thus, incoming calls that are essential in any VoIP service are not possible with existing NAT/Firewalls. In its current version SIPTalk uses a simple solution based on STUN protocol [7], it allows SIPTalk softphones to discover whether they are behind a NAT or not, and if so determine the exact type of NAT they are behind. SIPTalk softphones can traverse NAT devices in the scenarios of Table 2 provided that the caller and called person are behind different NATs : TABLE II. NAT SCENARIOS SUPPORTED BY SIPTALK Scenario Caller Called Platform NAT.1 Caller is Caller is Open behind Full behind Full Internet Cone NAT Cone NAT NAT.2 Caller is Caller is Open behind Port behind Full Internet Restricted Cone NAT NAT NAT.3 Caller is Caller is Open if NAT.2 is behind Full behind Port Internet successful Cone NAT Restricted NAT. Another challenge was to find a good compromise between using the SIP protocol -along with its extensions- to handle session establishment; and the amount of traffic that can be generated by the SIP messages, and the frequency of refreshing these messages. The problem can be accentuated when these messages are handled in a centralized model like in the case of the presence and tracking servers. Both servers are based on SIMPLE; the SIP extensions for Presence and Instant Messaging. SIMPLE s core protocol machinery provides the actual SIP extensions for subscriptions, notifications and publications. SUBSCRIBE allows to subscribe to an event on a server, the server responds with NOTIFY, whenever the event comes up. To cut down on the traffic load on the server, we decided that User Agent needs only to send one subscribe message for every contact when the softphone initializes. However, this approach has a drawback; the SUBSCRIBE message establishes a "dialog" with the presence server, but not refreshing the SUBSCRIBE actually causes the dialog to timeout. SUBSCRIBE messages are cached on the presence server, this way the dialog can be recovered when NOTIFY requests need to be sent out. Both Active phone book and geolocalization services are built around this solution. E. Gateway Gateways are located in the middle tier of SIPTalk system architecture (see Figure 1). A gateway receives softphone requests, invokes the appropriate backend service, then returns results to the requesting Softphone in the appropriate protocol. From a software architecture point of view, a gateway is a set of different proxies that hide the system complexity for the softphones. The main modules of a gateway are: The SIP Server: The SIP server is a stateless SIP Redirect Server that accepts clients requests (registration, location, etc), process these messages in order to retrieve the appropriate parameters, and through RMI[16], it accesses the registration and location services in order to get the appropriate results and send them back to the user. Ads and Skins proxy: This module receives from the user a request to see if a sponsor is already sponsoring a target destination. If yes, the proxy downloads the ads to be played. Watching third party s ads allows users to make free calls for mobile phones or landlines. Banner Proxy: This proxy allows softphones to refresh banners. Banners are selected depending on user profiles. CDR proxy: Whenever a communication starts or ends, the front-end system informs this module, which in return forwards the information to the billing and statistics service in order to record who called who, the duration of the call, the sponsor of the call, etc. Profile Management proxy: Whenever the subscriber would like to register the first time, log on, add/delete/modify personal information, add/delete users contacts, it contacts this proxy that will extract the information and forward it correctly to the appropriate service (profile management) via RMI, then it will send back the response to the client. Prepaid Proxy: this module allows users to buy SIPTalk credit using prepaid cards in order to be able to call mobile phones or landlines. The proxy redirects the calls to the Prepaid RMI service and takes care of sending the response back to clients. Configuration Proxy: this module allows softphones to retrieve after logon the audio and video parameters that are in use on a specific gateway, this centralized configuration lets the operator decide what codecs are best for an optimum traffic. Gateways can be mounted and launched individually on separate physical platforms. A set of Serving gateways are automatically assigned to each connecting softphone to achieve resilience. 3

4 F. Back end The back end system is composed of the different RMI services available that use the data tier in order to satisfy the user requests proxied by the gateways. 1) Central Service Registry This service keeps track of all available services and gateways that are up and running inside the system. Whenever a service or a gateway gets started, it registers itself with this service. Each time that a service or a gateway needs to access functionalities of other services, it uses the central registry in order to locate the appropriate service (see Figure 3). A round robin mechanism is used inside the central registry, so that the load is distributed among the available services that are offering the same functionalities. Real Time Billing System. BS then calculates the charge of the call BS deduces this amount from the balance of the user. Figure 4. Prepaid Billing System s Architecture. Figure 3. Load balancing through a central service registry 2) PSTN Gateway and billing The PSTN gateway is an adapter which converts signaling and speech from Internet to PSTN and vice versa. Asterisk PBX[1] together with Digium cards have been used for this task. Users can call from the SIPTalk softphone to contacts that have a landline or a mobile phone with local rates. The billing system uses MCC in order to control PSTN calls. The architecture of the prepaid billing system is given in Figure 4. The customer initiates a call to the PSTN gateway. The gateway gathers the account information by gathering information from the incoming call, (eg calling number or user name). The gateway sends the account information, the phone number dialed, and account number) to the real time prepaid billing system. The Billing System (BS) identifies the call rate from the correct table and uses the account number to know the balance of the user. Using the call rate and user balance, the real time billing system determines the maximum available time for the call duration. This information is sent back to PSTN gateway and the gateway connects if the user has enough credit to make the call, if not the call is rejected. If the call is connected, the gateway maintains during the call progress a timer so the caller cannot exceed the maximum amount of time that the user s balance allows. When the call is complete, the PSTN gateway records the duration of the call and send it to the RMI 3) Presence Server This is the backend component that interacts with the softphones to provide the Presence functionality. The Presence server maintains online status information for each user along with media availability and willingness to communicate either through voice, video, instant messaging or . The Presence server also ensures that users can subscribe to information about the online status of other users; it processes the SIP requests (SUBSCRIBE, NOTIFY) that are used to manage the presence. Basically, it receives subscriptions to some events and sends back notifications to the subscribed client when the presence status changes by issuing a REGISTER message. The presence server is based on SIMPLE [2](SIP for Instant Messaging and Presence Leveraging Extensions). 4) Tracking Server Tracking allows users to subscribe to geo-localization events for their mobile contacts whenever they enter or exit a GPS tracking zone with some threshold. Devices with a GPS receiver register on a regular basis their GPS coordinates. It takes care of managing all information regarding geographical tracking such as subscriptions, tracking request processing, updates of GPS positions and sending information regarding position changes to the clients. The tracking server is based on SIMPLE [2] (SIP for Instant Messaging and Presence Leveraging Extensions) 5) STUN Server The STUN served assists SIPTALK softphones to determine the relevant type of NAT in order to open and maintain a whole through the firewall. G. Backend Design patterns By applying the Model-View-Controller (MVC) architecture in SIPTalk Platform (see Figure 5), a clear separation was made between core model functionality and the presentation and control logic that uses this functionality. Such separation allows in general multiple views (softphone types) to share the same data model. 4

5 Figure 5. SIPTalk Model View Controller Architecture 1) Client Façade The bigger and more complex a system based on subsystems gets, the more difficult it is for a client to make requests and get what is expected. The ClientManager facade acts as an interface to simplify communication with the elements that make up the SipTalk subsystem and the client. So instead of communicating with all of the components of the subsystem, the client interacts with a single component, the ClientManager. 2) Utility Design Pattern The Utility pattern is a creational software pattern that is used for utility classes that do not require instantiation and only have static methods. A number of utility classes are used with SipTalk like RawContentHandler used for parsing SIP messages in different ways, a FileSystemUtility for introspecting local disk capabilities and SystemInetAddressUitliy to discover the network interfaces on a local machine. 3) Remote Proxy design pattern It provides a local representative for an object in a different address space. Remote proxies are responsible for encoding a request and its arguments and for sending the encoded request to the real subject, or another proxy in a different address space, on a different machine. The Proxy design pattern is used heavily since all the backend services are RMI services. 4) Singleton pattern The singleton pattern is a design pattern that is used to restrict instantiation of a class to one object. This concept is also sometimes generalized to restrict the instance to more than one object, as for example, we can restrict the number of instances to five objects. This is useful when exactly one object is needed to coordinate actions across the system. Sometimes it is generalized to systems that operate more efficiently when only one or a few objects exist. The Singleton design pattern is used to control the Instant Messaging or chat sessions, the number of sessions is limited to 3. It s also used to manage the download sessions that can take place at the same time, these are fixed to maximum 3. The Façade object as well is a singleton object, only one instance is needed at the level of the client. 5) Factory Design Pattern (used by JAIN-SIP) A factory design pattern is one in which a specific class is defined to create object instances of other classes whose implementation is hidden. Proprietary stack features are hidden behind a Factory. Through a combination of common JAIN and JAIN SIP interfaces, a protocol stack provider is obtained to which JAIN SIP listeners can then register : As a part of the JAIN SS7 API, a factory class, jain.protocol.ss7.jainss7factory, is defined and used to create an object instance of the class implementing JainTcapStack. Protocol stack vendors will provide a class com..jain.protocol.ss7.tcap.jaintcapstackimpl, which implements JainTcapStack interface, and a class com..jain.protocol.ss7. tcap.jaintcapproviderimpl, which implements JainTcapProvider interface H. System administration and service provisioning 1) System administration SIPTalk comes also with tools that enable administration and monitoring of servers, gateways and PSTN gateways from a remote console. An administrator can activate or deactivate a service or a gateway remotely. The operation is executed through a remote administration service running on the local machine of the gateway or the service. The administration service notifies the load balancer, this later one will mark the gateway or the service as being up. Deactivation is performed in a similar way, a deactivated gateway or server won t be accessible anymore by other components and it won t contribute to load balancing. 2) Unified console with Web access for placing ads The business model of SIPTalk tries to outlast the stream of fees for PSTN interconnection, calls can be made to mobile phones and landlines using prepaid cards or can be deferred to a third party sponsor provided that the end user agrees to watch a sponsor advertisement. A web access allows sponsors to load their ads and banners along with any information on user profiles that the sponsor is willing to support. Ads and banners are validated by administrators using a console, according to the internal validation procedure of the operator. Only validated ads and banners will downloaded to clients. 3) Ease of service provisioning, and system roll out A number of custom scripts are used for production roll out of the different services. These scripts automate the back end provisioning and re-provisioning process, the services and the gateways are configured and deployed consistently and reliably. The scripts are also configured for automatic startup and shutdown. 5

6 III. IMPLEMENTATION The selection of implementation tools, and already available software components was driven by a low cost of ownership requirement. To this end, the system makes use of a high number of open source components: The SIPTalk platform contains 2 softphones, a java client and a Pocket PC client gateways and backend services. This section lists the development and integration environments, APIs and middleware used to implement the different components. Java SIP Protocole Stack API : JAIN SIP [12] is the standardized Java interface to the Session Initiation Protocol for desktop and server applications. JAIN SIP enables transaction stateless, transaction stateful and dialog stateful control over the protocol. JAIN SIP API was used to develop the SIP UserAgent which is part of the client modules, the SIP redirect server, the tracking and presence servers. Java Media Framework (JMF): The Java Media Framework API (JMF) [5] enables audio, video and other time-based media to be added to applications and applets built on Java technology. This package, which can capture, playback, stream, and transcode multiple media formats, extends the Java 2 Platform, Standard Edition (J2SE) for multimedia developers by providing a powerful toolkit to develop scalable, cross-platform technology. JMF was used to implement the RTP [17] modules and the ads player in the client tier. Asterisk: Asterisk [1] is an open source software implementation of a telephone private branch exchange (PBX) originally created in 1999 by Mark Spencer of Digium. Like any PBX, it allows a number of attached telephones to make calls to one another, and to connect to other telephone services including the public switched telephone network (PSTN). The basic Asterisk software includes many features available in proprietary PBX systems: voice mail, conference calling, interactive voice response (phone menus), and automatic call distribution. Users can create new functionality by writing dial plan scripts in Asterisk's own language, by adding custom modules written in C, or by writing Asterisk Gateway Interface (AGI) scripts in Perl or other languages. Asterisk s modular architecture allows it to convert between a wide range of communications protocols and media codecs. Asterisk was used as a media gateway, bridging the legacy PSTN to the IP telephony to allow users to make calls to mobile phones and landlines. MCC: MCC [6] is a complete advanced VoIP billing and routing solution based on Asterisk PBX. It integrates the vital core AAA functions (Authentication, Authorization and Accounting) which facilitate the effective management of all billing-related processes. MCC was integrated with asterisk to support prepaid billing of calls to mobile phones and landlines in real time. IndependentSoft SIP.NET: SIP.NET [10] is a Session Initiation Protocol API for.net Framework and.net Compact Framework. Built from same source code all classes and methods support Microsoft.NET Framework and Microsoft.NET Compact Framework. The API is written in 100% managed C# code. SIP.NET is used as a SIP stack in the Pocket PC client. RTP stack for.net compact Framework: The RTP stack for windows mobile was based on PJMedia [11]. PJMEDIA is a rather complete media stack, distributed under Open Source/GPL terms, and featuring small footprint and good extensibility and portability. The source code for PJMedia is in unmanaged code; that is, code that does not use.net Framework. Our solution was to call unmanaged code from managed code, also known as Platform Invoke or P/Invoke. A Dynamic Link Library is used to tell the.net Compact Framework which unmanaged function to be called. jstun server: JSTUN [8] is a Java-based STUN (Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translation (NAT) [18]) implementation. STUN [7], as described in RFC 3489, provides a means for applications to discover the presence and type of firewalls or NATs between them and the public internet. jstun was used to allow SipTalk softphones, in presence of NAT, to discover the public IP address assigned to the NAT. IV. IMS COMPLIANCE Figure 6. SIPTalk s IMS-like layered architecture The IMS [9] standard architecture is composed of three main layers. The first one is the IMS control layer which mainly implements the call session control functions, the second layer which is named the services and applications layer constitutes a set of databases and it is mainly composed of the home subscriber server (HSS), or in the case of multiple HSSs, the SLR is also present, as well as the applications server, where IMS standard services reside, and where SIP based applications developed by third parties reside. The third tier which is named the transport layer is composed of the media and transport gateways. A. SIPTALK Components and Functions Specified by IMS Standard : The user profile database together with the profile management services fit in the home subscriber server tier. 6

7 The remaining databases, which include the presence database, the location database, as well as the application specific database, do not form part of the HSS. However, the presence server together with the presence database is standardized by IMS and they are an example of an IMS application server, so they fit in this layer. The location database together with the registrar and locations services modules are not standardized by IMS. However, they might be considered as an IMS applications server. The PSTN gateway and the billing system are not standardized by IMS. The Ads and Skins services, the Banner Services, the CDR services, and the prepaid services are not standardized by IMS, but they can be application servers, so they can fit on that tier. The banner proxy, the ads skins proxy, the CDR proxy, the prepaid proxy, and the configuration proxy are specified by IMS but their functionality might be incorporated to the proxy call session control function (P- CSCF). The SIP redirect server and the tracking server are not specified in IMS. However, due to their functionality, the SIP redirect server might be incorporated to the proxy call session control function (P-CSCF), and the tracking server might be incorporated to a separate application server. A summary of the SIPTALK components and functions specified by IMS is illustrated in Table 3. TABLE III. TABLE 3: SIPTALK COMPONENTS VERSUS IMS STANDARD COMPONENTS IMS Component/Presence Present Not Present The Home Subscriber No No Yes Server HSS The Subscription Locator No Yes No Function SLF Application Server APs No No Yes Serving Call Session No Yes No Control Function (S- CSCF) Interrogating Call Session No Yes No Control Function (I-CSCF) Proxy Call Session Control No No Yes Function (P-CSCF) Gateways No No Yes Partially Implemented B. IMS Compliant Interfaces Present in SIPTALK The only IMS compliant interface that is present in SIPTALK is the Gm reference point. It is the interface that connects the user equipment (soft phone) to the operator network, and it uses the SIP protocol for communication as it is stated by IMS. The ISC server is partially implemented even though the I-CSCF and S-CSCF are not present in SIPTALK, because it is the interface through which application servers are accessed. C. IMS Compliant Services Present in SIPTALK The IMS standard services present in SIPTALK include: presence, messaging, and conferencing. The non-ims compliant services present in SIPTALK are Pre-call Sponsoring, Streaming of ads, File sharing, Geographic localization, prepaid calls, read out. These services can be IMS compliant if they are deployed within IMS application servers, and if they are made accessible through the SIP protocol. V. CONCLUSION AND FUTURE WORK The development of SIPTalk has brought about numerous challenges in terms of System and software design, scalability, service provisioning, and last but not least user experience. We have detailed through the paper the solutions we adopted for each challenge. Currently, the system is undergoing further improvements related to mutual authentication, stress testing and user experience, together with resource (CPU, Memory, bandwidth) sizing for large ( subscribers) deployment REFERENCES [1] Asterisk [2] J. Rosenberg. A Presence Event Package for the Session Initiation Protocol (SIP): draftietf-simple-presence-10.txt, January [3] Daniel Collins, Carrier Grade Voice over IP. Second Edition, Chapter 5 (PSTN Interworking). [4] Remote Method Invocation: [5] Java Media Framework: [6] MCC homepage [7] STUN RFC [8] jstun : Java Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translation (NAT) jstun [9] IP Multimedia Subsystem [10] SIP.NET from Independent Soft [11] PJMEDIA library [12] JAIN SIP: [13] IMS SIP and Unified Communications [14] The Session Initiation Protocol RFC [15] H.323. Web ProForum Tutorials. [16] Java RMI, RMI Tunneling and Web Services Comparison and Performance Analysis. Matjaz B. Juric, Bostjan Kezmah,, Marjan Hericko. University of Maribor, FERI, Institute of Informatics. [17] RTP: A Transport Protocol for Real-Time Applications. H. Schulzrinne. Columbia University. [18] NAT Traversal: [19] [20] Java Web Start : p [21] ed.htm [22] Google Talk: [23] Skype: [24] SkypeOutdetails: [25] SkypeIn details [26] MSN live Messanger: 7