Publication III Jani Hautakorpi, Arturo Salinas, Erkki Harjula, and Mika Ylianttila. 2008. Interconnecting P2PSIP and IMS. In: Khalid Al-Begain and Antonio Cuevas Casado (editors). Proceedings of the Second International Conference on Next Generation Mobile Applications, Services, and Technologies (NGMAST 2008). Cardiff, Wales, United Kingdom. 16-19 September 2008. IEEE. Pages 83-88. ISBN 978-0-7695-3333-9. © 2008 Institute of Electrical and Electronics Engineers (IEEE) Reprinted, with permission, from IEEE. This material is posted here with permission of the IEEE. Such permission of the IEEE does not in any way imply IEEE endorsement of any of Aalto University School of Science and Technology's products or services. Internal or personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution must be obtained from the IEEE by writing to
[email protected]. By choosing to view this document, you agree to all provisions of the copyright laws protecting it.
The Second International Conference on Next Generation Mobile Applications, Services, and Technologies
Interconnecting P2PSIP and IMS Jani Hautakorpi∗ , Arturo Salinas∗ , Erkki Harjula† , and Mika Ylianttila† ∗ Ericsson
Research Nomadiclab FI-02420 Jorvas, Finland Email: {jani.hautakorpi, arturo.salinas}@ericsson.com † MediaTeam Oulu Group, Department of Electrical and Information Engineering Erkki Koiso-Kanttilankatu 3, FI-90014 University of Oulu, Finland Email: {erkki.harjula, mika.ylianttila}@ee.oulu.fi
We have implemented a prototype of the proposed interconnection architecture. The prototype contains a P2P-GW, which implements the gateway, and the novel URI handling mechanism. The prototype proves that the proposed interconnection architecture could be used in real-life networks. The proposed architecture focuses on signaling aspects, and does not focus on the media level issues. Issues related to charging, Network Address Translation (NAT) traversal, and IPv4/IPv6 interworking are excluded from this study. The architecture is built in the manner that does not require any changes to the IMS network itself. It implements an ordinary Session Initiation Protocol (SIP) AS that has an external interface towards P2PSIP network. P2PSIP peers require a novel URI handling mechanism, but the mechanism is designed in such a manner that it does not pose any changes to the typical P2PSIP operations. In the next section we present the background and related work, and in Section III we propose an architecture for interconnecting P2PSIP and IMS. Section IV describes the prototype of the proposed architecture. Section V introduces our plans for future work, and finally in Section VI we present the conclusions.
Abstract—Interpersonal communication using the information networks can be accomplished in many different ways. Users may communicate, for example, by using a specific communication application on an end-user terminal, typical mobile phone, or IP Multimedia Subsystem (IMS) client. Quite often there is no interconnection mechanisms between these different communication methods, and this is emphasized with regards to various communication applications. We propose an architecture for interconnecting Peer-to-peer Session Initiation Protocol (P2PSIP) and IMS networks. The actual gateway, that enables the interconnection, is seen as a peer in the P2PSIP side and as an Application Server (AS) in the IMS side. Furthermore, we present a prototype from the proposed interconnection architecture.
I. I NTRODUCTION Today people have various methods for interpersonal communication. A traditional communication method is to use a fixed phone on a Public Switched Telephone Network (PSTN) or a mobile phone on a Public Land Mobile Network (PLMN). Another communication method is to use some specific communication application in an end-user terminal, such as Skype, MSN Messenger, or Google Talk. The communication application usually uses the Internet, or some other IP based network, as a transport medium. Some years ago the communication applications were used mostly in fixed networks, like with Asymmetric Digital Subscriber Line (ADSL) connections, but today they are also more and more used in mobile networks, like in 3G networks. IP Multimedia Subsystem (IMS) is another usable network for interpersonal communication. Especially the communication applications for specific purposes have problems interconnecting with other communication applications, and they tend to form separated communication islands. This leads to a situation where the users of a communication application can not reach the users using some other communication application. Thus, there is a clear need to create gateways between different communication networks. We propose an architecture for interconnecting Peer-to-peer Session Initiation Protocol (P2PSIP) and IMS networks, so that the users of those networks could reach each other. The main component enabling the interconnection is a gateway that is seen as a peer in the P2PSIP side and as an Application Server (AS) in the IMS side. The proposed architecture contains also a novel URI handling mechanism in the P2PSIP terminals.
978-0-7695-3333-9 /08 $25.00 © 2008 IEEE DOI 10.1109/NGMAST.2008.60
II. BACKGROUND AND R ELATED W ORK SIP, P2PSIP, and IMS are the protocols and a networks that the proposed interconnection architecture is built on. Next we will introduce these protocols and networks one by one. The existing IMS interworking mechanisms are also presented. A. SIP SIP [1] is a text-based, application-layer signaling protocol. It is used for establishing and managing sessions, such as Voice over IP (VoIP) calls, between users. The users are identified by using SIP Uniform Resource Identifiers (URIs), which typically contain a username and and a host name part, for example sip:
[email protected]. SIP is standardised by the Internet Engineering Task Force (IETF). The SIP infrastructure consists of User Agents (UAs), registrars, and proxies. UAs are the endpoints, like mobile phones. Registrars and proxies are centralised elements that are typically operated by a SIP service provider. Registrars are used for creating bindings between the SIP URIs and the
83
IP addresses of the endpoints. These bindings are stored to a database called location service. Both proxies and registrars can access the location service database. Proxies are used for routing SIP between the end-points. Proxies route the requests by using SIP-specific Domain Name System (DNS) procedures [2] and by consulting a location service. There are many extensions to the SIP specification, for example the SIP-specific event notification framework [3] that defines, among other things, SUBSCRIBE and NOTIFY messages. The event notification framework can be used, for example, as an enabler for a presence service. Currently SIP is being utilized in P2PSIP and in IMS networks. In P2PSIP networks, SIP is typically used directly between the end-points, and in IMS, SIP is used in user-tonetwork, network-to-network, and in internal interfaces.
C. IMS IMS [13] [14] is a technology that is targeted for merging the Internet and cellular networks. As in P2PSIP and SIP, the users of IMS are identified by using SIP URIs. The IMS system is standardised at the 3rd Generation Partnership Project (3GPP). The architecture of the IMS consists of a set of functions that are connected to each other with standardised interfaces. The most important functions in the IMS network, with regards to this paper, are Home Subscriber Servers (HSSs), Call/Session Control Functions (CSCFs), and ASs. The HSS is a database storing information about the users. HSS is responsible for storing a user profile, and an Initial Filter Criteria (iFC) [15] as a part of it, for each IMS user. The user profile contains information about the services the user is subscribed to. The CSCFs are SIP servers, and there are three different types of those: P-CSCF (Proxy-CSCF), I-CSCF (Interrogating-CSCF), and S-CSCF (Serving-CSCF). The PCSCF is the first SIP server an IMS terminal contacts, I-CSCF is located at the edge of the IMS network and it is accessible by other IMS networks, and S-CSCF is a central node performing session control. S-CSCF is also able to route calls through application servers based on a user profile. ASs are used for service hosting and execution.
B. P2PSIP P2PSIP is a technology that combines SIP and Peer-toPeer (P2P) networks in a novel manner. The main purpose of P2PSIP is to decentralise the location service of SIP (see Section II-A). In P2PSIP networks, as in SIP networks, the users are identified by using SIP URIs. The P2PSIP technology is currently being standardised in the P2PSIP working group [4] at the IETF and an example of that work is the P2PSIP Concepts draft [5]. There are also a number of publications describing the P2PSIP technology, like [6], [7], and [8]. The current status of the standardisation is such that there is a common understanding of the basic concepts, but many of the details are still being worked on. The decentralisation of the location service can be achieved by using some distributed data mechanism. Distributed Hash Tables (DHTs), like Chord [9], Kademlia [10], and Content Addressable Network (CAN) [11], provide one option for distributed data mechanisms. The suitability of DHTs for interpersonal communication, such as for P2PSIP, is evaluated in [12]. Typical P2PSIP network has a number of peers participating to the network. It is expected that most of the peers are going to be coupled with a SIP entity, such as SIP UA or a proxy. The term P2P network refers, in this context, to a set of nodes that are using some distributed data mechanism among them. All the peers have to provide overlay routing and storage for other peers, and all the peers are able to do get and put operations in the P2P network. The peers have to implement a peer protocol, which is used for communication between the peers. The binding between a SIP URI and an IP of an endpoint, roughly the equivalent of the location service in SIP, is stored in a data structure called resource record. The resource record is located at the peer whose identifier in a P2P network is the closest match to the hash of a SIP URI in the resource record. Each user of a P2PSIP network has a personal resource record. The reading and writing of a resource record can be done by using the get and put operations, respectively. P2PSIP networks do not have a need for SIP-specific DNS procedures [2].
D. Interworking Mechanisms in the IMS IMS contains two specified interworking mechanisms to other networks. First is interworking between legacy Circuit Switched (CS) networks and IMS [16], and the second is interworking between SIP based IP networks and IMS [17]. The interworking between legacy CS networks an the IMS is focused on audio-only calls and works on both signaling and media levels. The interworking is implemented by a distributed gateway which comprises of three functions: Signaling Gateway (SGW), Media Gateway Control Function (MGCF), and IP Multimedia Gateway Function (IM-MGW). The SGW has interfaces to the CS and IMS networks, and it enables the exchange of Bearer Independent Call Control/Integrated Services User Part (BICC/ISUP) messages on top of IP layer between the CS network and MGCF. The MGCF makes a conversion between the BICC/ISUP and SIP, and the IMMGW handles the media conversion between the IMS and the CS network. The interworking between SIP based IP networks and the IMS network is not very mature, and it is lacking, for example, a number of reference point specifications. The [17] is focused on IPv4/IPv6 interworking. The actual gateway between the networks comprises of Interconnection Border Control Function (IBCF) and Translation Gateway (TrGW), which have the abilities to make IPv4/IPv6 translation for both signaling and media, compatibilize SIP headers, and perform topology hiding. In addition to these two previously mentioned interworking mechanisms, there is also a SIP2IMS gateway [18] proposal. The difference between the [17] and the SIP2IMS gateway is that the SIP2IMS gateway resides in user premises. Logically
84
P2PSIP UA
Gateway AS P2PSIP network
Fig. 1.
the registration by using the full SIP URI that contains both username and host name, but the Gateway AS registers only the host name part. The result of the put operation is that a binding between the IMS domain name and the IP address of the gateway node is stored as a resource record to the P2P network. It is noteworthy that multiple IP addresses can be bound to the same IMS domain name. An example situation, where this would occur, is a scenario where one IMS domain has multiple Gateway ASs. This mechanism can be used as a tool for failure avoidance and load balancing. In the second preliminary procedure, those IMS users who want to use the interconnection ability to the P2PSIP network, have to setup appropriate iFCs to their user profiles (see Section II-C). The actual mechanism on how users do this is out of scope for this paper. They could do it, for example, by calling to a customer service of an IMS network operator, or an IMS network operator could provide a web-page where users could sign up for the P2PSIP interconnection service. The appropriate iFC for P2PSIP interconnection contains a session case definition, the address of the Gateway AS, and a Trigger Point with appropriate Service Point Triggers (SPTs). The session case is always Originating, because the iFC needs to be evaluated only on originating session establishments from IMS to P2PSIP. An appropriate SPT, for example in a case where the Gateway AS is connected to p2p-domain.com P2PSIP domain, would be Request-URI=*@p2p-domain.com. It is noteworthy that the user profile, and the iFC, allows the use of multiple Gateway ASs in one IMS network, and that Gateway ASs can be connected to multiple P2PSIP networks. The fact that each user who wants to use the interconnection ability, has to have a specific iFC can be used as a tool for charging. When these preliminary procedures have been performed, all the P2PSIP network users are able to reach all the users in the IMS network, and those IMS users who have set up their user profiles can reach all the users in the P2PSIP network. Actually, the first preliminary procedure is needed only for session establishments from P2PSIP to IMS network, and the second procedure is needed only for the reverse direction.
IMS UA IMS network
Interconnection architecture
the SIP2IMS gateway is located between users’ terminals and a P-CSCF. The idea of SIP2IMS gateway is to make it possible to use non-IMS compliant SIP terminals with IMS. There exists yet another proposed interworking mechanism between the P2PSIP and conventional SIP networks, by Marocco and Bryan [19]. This interworking mechanism is not IMS-specific, and it uses DNS for finding nodes that act as a gateway between the networks. III. I NTERCONNECTION A RCHITECTURE The interconnection architecture that we propose makes it possible to establish sessions between the P2PSIP and IMS networks, see Fig. 1. The main component in the proposed architecture is a Gateway AS, which has interfaces to both networks. In the P2PSIP network side it looks like an ordinary peer, and in the IMS side it looks like a SIP AS. The proposed architecture utilises the fact that both of these networks use SIP URIs for user identification. P2PSIP terminals require a novel URI handling mechanism, which makes it possible to make a separation between the session establishments within the P2PSIP network, and session establishments between P2PSIP and IMS networks. It is noteworthy that it is more convenient to add functionality to the P2PSIP terminals than to IMS terminals due to their standardisation status. Our main focus has been on the signaling level of the interconnection and not on the media level. However, the proposed interconnection architecture does not contain such aspects that would prevent the adding of media level elements in the future. We have explicitly excluded charging, NAT traversal, and IPv4/IPv6 interworking. Next we are going to present the preliminary procedures that need to be performed before a session establishment can be attempted, and a detailed description from the session establishment.
B. Session Establishment When the preliminary procedures have been performed, session establishments between P2PSIP and IMS can be done. The session establishments will work in both directions. The sequence diagrams illustrating the session establishments are shown in Fig. 2 and in Fig. 3. Those sequence diagrams are simplified and they do not show, for example, 100 Trying and 180 Ringing replies. The requests are denoted with solid arrows and replies with dashed arrows. Let us first examine the session establishment from P2PSIP to IMS. The P2PSIP UAs require an added functionality when a session is established from the P2PSIP to IMS network (see Fig. 2). This added functionality is a novel URI handling mechanism evaluating the host name part of URIs in a novel manner. For example, when a P2PSIP UA tries to establish a session to sip:
[email protected], the P2PSIP UA
A. Preliminary Procedures Starting point for preliminary procedures is a situation where a Gateway AS is installed to an IMS network and it has a connection to a P2PSIP network or P2PSIP networks. With preliminary procedures we mean such procedures that need to be performed before the session establishment attempts. There are two preliminary procedures. In the first preliminary procedure the Gateway AS needs to register itself to the P2PSIP network. The gateway does this by performing a put operation using a peer protocol (see Section II-B). The put operation contains the domain name of the IMS network (for example, ims-domain.com) and the IP address of the Gateway AS itself. Typically P2PSIP peers do
85
P2PSIP UA
Gateway AS
1. get() 2. IP
P2PSIP Network
Gateway AS 3. INVITE
10. 200 OK
Fig. 2.
3. INVITE
S-CSCF
4. INVITE
9. 200 OK
S-CSCF
P-CSCF
5. INVITE
8. 200 OK
P2PSIP Network
IMS UA
6. INVITE
7. 200 OK
8. 200 OK
9. 200 OK
10. 200 OK
Session establishment from IMS to P2PSIP network PM1
checks whether the host name part matches the P2PSIP domain where it is currently in, p2p-domain.com. If it matches, then the P2PSIP UA sends a get request with a key being a hash from ”
[email protected]”. If it does not match, then the P2PSIP UA sends a get request (1) with a key being a hash from ”ims-domain.com” (this case is presented in Fig. 2). This kind of host name part handling enables the interconnection of multiple IMS networks to a P2PSIP network, and does it without using DNS. The get operations returns either the address(es) of the callee’s P2PSIP UA(s) or an address(es) of the Gateway AS(s) (2). An alternative for the novel URI handling mechanism would be to use a gateway that would register each IMS user using interconnection ability to a P2PSIP network with a put operation. The disadvantages of that approach would be the increased amount of signaling, higher robustness requirements for the gateway, and heavier use of resources in a P2PSIP network. When the caller’s P2PSIP UA has learned the address of the Gateway AS, it will send the SIP INVITE (3) directly to it. Then the Gateway AS acts as a Back-to-Back UA (B2BUA). The Gateway AS makes a conversion between the plain SIP and 3GPP-specific SIP profile, and then forwards the SIP INVITE (4) to the S-CSCF. It is noteworthy that the Gateway AS has to be located in the same IMS network as the HSS if the IMS network has more than one S-CSCF. The reason for this is that in such scenario, the Gateway AS would be unable to know to which S-CSCF it has to send the INVITE without contacting the HSS. The S-CSCF, in turn, forwards the SIP INVITE (5) to the P-CSCF, which forwards it (6) to the caller’s IMS UA. Then the callee’s UA can send 200 OK (7-10) reply back to the caller’s P2PSIP UA. The session establishment from IMS to P2PSIP network is illustrated in Fig. 3. No added functionality is required for the IMS UAs. Caller’s IMS UA just sends a SIP INVITE (1), for example with a target URI like sip:
[email protected], to a P-CSCF, which in turn forwards it (2) to the S-CFCF. Then S-CSCF evaluates the pre-established iFC and forwards it (3) to the Gateway AS. First the Gateway AS makes a conversion between the 3GPP-specific SIP profile and plain SIP, and then determines where to forward the request.
1. INVITE
5. IP
7. 200 OK
Fig. 3.
2. INVITE
IMS UA
4. get()
P2PSIP UA 6. INVITE
Session establishment from P2PSIP to IMS network
P-CSCF
PM2 VM1 - IMS (P2P-GW) - IMS UA
VM2 - P2PSIP UA 1GB Ethernet
Fig. 4.
VM3 - P2PSIP peer
Network setup for experiments
Gateway AS can be connected to multiple P2PSIP networks, and based on the host name part of the target URI, the Gateway AS can determine in which P2PSIP network it should send the get request. Once the get request (4) is performed, it returns (5) the address of the callee’s P2PSIP UA. Now that the Gateway AS has learned the address of the callee’s P2PSIP UA, it can forward the SIP INVITE (6) directly to it. Then callee’s UA can send 200 OK reply (7-10) back to the caller’s IMS UA. Even though this paper is focused on the session establishment, nothing in the proposed architecture prevents the interconnection of SIP-based services, such as presence. Similar mechanisms, such as the use of iFC and Gateway AS itself, can also be used for forwarding non-INVITE requests, such as SUBSCRIBE and NOTIFY, between the networks. IV. P ROTOTYPE In this section, we present our prototype implementation of the proposed architecture. The main component in the prototype is the P2P-GW, which is an implementation of the Gateway AS. The prototype contains also an implementation of the novel URI handling mechanism in the P2PSIP UAs. The Open IMS Core [20] [21] is used as the IMS network in the prototype, providing the S-CSCF, P-CSCF, and HSS functions. The P2P-GW was implemented as an AS on top of the Open IMS Core. The novel URI handling mechanism was implemented as a part of Sofia-SIP [22] SIP UA library. An implementation of the Peer-to-peer Protocol (P2PP) [23] was used as a P2PSIP peer protocol. The prototype was evaluated by performing a set of performance tests. The network setup for the experiments is illustrated in Fig. 4. We used two physical machines in the experiments, referred as PM1 and PM2. Both of the physical machines had the following configuration:
86
325
1400 Response time
300
Response time
1200
275
1100
250
P2P-GW's forwarding time
Time in ms
Time in ms
1300
1000 900 800 700 600 500
225 200 175 150 125
400
100
300
75
200
50
100
25 0
5
10
15
20
0
Fig. 5.
5
10
15
20
Simultaneous calls
Simultaneous calls
Experiments from P2PSIP to IMS network
Fig. 6.
Two dual-core Intel Xeon 3.40GHz processors 3GB of RAM • 1GB Ethernet network connection • Linux 2.6 operating system (Ubuntu) The physical machines had VMware Server virtualisation software, and there were in total three virtual machines, referred as VM1, VM2, and VM3 (see Fig. 4). All of the virtual machines had Linux 2.6 operating system (Ubuntu), and they were connected to each other by using 1GB Local Area Network (LAN), where each virtual machine had a public IPv4 address. VM1, VM2, and VM3 had 768MB, 384MB, and 768MB of RAM allocated to them by the VMware Server, correspondingly. VM1 was running the IMS, P2P-GW, and IMS UA. VM2 had the P2PSIP UA, and WM3 had a corresponding P2PSIP peer. The corresponding P2PSIP peer in the experiment was the peer in the P2PSIP network where the resource records were stored. In other words, the P2PSIP network in the experiments had only two participating peers. Reason for the small size of a P2PSIP network was that we wanted to focus on the interconnection issues and not on the issues related to P2P networks. Both the physical and virtual machines were under very light load during the experiments. The performance tests were made by using SIPp [24] SIP traffic generator. In the tests, sessions were established from the P2PSIP UA (VM2) to IMS UA (VM1) and the other way around. The tests constituted four sets: 1, 5, 10, and 20 simultaneous session establishments. The SIP messages were transported on top of User Datagram Protocol (UDP). Each set of experiments were repeated ten times. For example, a set with 5 simultaneous session establishments was repeated 10 times, totaling to 50 session establishments. The SIPp on the callee side was configured so that it accepted incoming calls (sent 200 OK) two seconds after receiving the INVITE. The performance tests were focused solely on signaling. The results from the performance tests are illustrated in Fig. 5 and Fig. 6. The curves in the graphs go via the data points that represent the average time in each set. The response time is the time between the sending of an INVITE and receiving of the corresponding 200 OK in the caller’s
Experiments from IMS to P2PSIP network
UA. The P2P-GW’s forwarding time is the time between the receiving of an INVITE and forwarding the INVITE in the P2P-GW. The P2P-GW’s forwarding time is measured only for session establishments from IMS to P2PSIP network, because to the other direction the P2P-GW is not performing any P2PSIP-specific actions, like get operation for example. It is noteworthy that if the P2PSIP network would have had more than two peers, then the forwarding time would probably have been longer. The P2P-GW’s forwarding time is a part of the response time. The results show that the response time and P2P-GW’s forwarding time grew as the number of simultaneous session establishments grew. We did not make the experiments with very high amount of SIP traffic, because our prototype is a proof-of-concept type of implementation and therefore not well-suited for studying scalability issues. The results from the performed experiments show that the proposed architecture for interconnection is valid, and it can be used in real networks. In addition, we performed a small experiment with a presence service. We used the OpenSER [25] presence service module with Open IMS Core to provide a presence service for the users of the IMS network. The users of the P2PSIP network were able to subscribe to the presence information of IMS users. The P2P-GW forwarded the SUBSCRIBE and NOTIFY messages between the networks in a similar manner it forwarded INVITE messages in session establishments. The conclusion from this experiment was that the proposed interconnection architecture does not inherently prevent the interconnection of SIP-based services between the P2PSIP and IMS networks.
• •
V. F UTURE W ORK The proposed interconnection architecture is focused on signaling aspects of the P2PSIP and IMS network interconnections, and therefore it is not an all inclusive gatewaying mechanism. For proving the feasibility of the proposed gateway architecture with SIP-based services, more extensive evaluations are needed. In addition, charging, NAT traversal, and IPv4/IPv6 interworking are topics that require further research.
87
The possible charging mechanisms are probably going to differ depending on the direction of the session establishment. When the direction is from the IMS to P2PSIP network, the mandatory predefined iFC could probably be used as a tool for charging. In addition, the IMS users are authenticated in a manner that enables charging. When the direction is from the P2PSIP to IMS, the charging is more complicated, since the P2PSIP users might not be reliably authenticated and they might not have any kind of existing agreements with the IMS operator. The NAT traversal for signaling could be solved at least in two ways. Either the peer protocol itself could have NAT traversal capabilities, or they could be implemented in a layer below the peer protocol, for example by using Host Identity Protocol (HIP). NAT traversal in the media level would probably require intermediary media elements, which perhaps could be similar than TrGW [17]. The IPv4/IPv6 interworking, in a case of P2PSIP and IMS interconnection, could probably try to utilize the mechanisms described in [17]. Especially the possible re-use of IBCF and TrGW elements require further research. Since the proposed gateway enables the interconnection of the two fundamentally different systems, it at the same time opens new possibilities to build services that can efficiently utilize the benefits of both systems in a single service. The decentralized, P2PSIP-based service might, for example, use IMS-based charging mechanism, which would not be possible without the proposed gateway. The research on the combined application scenarios remains as future work.
[4] Internet Engineering Task Force (IETF), “Peer-to-Peer Session Initiation Protocol (P2PSIP) Charter,” At http://www.ietf.org/html.charters/p2psipcharter.html, Oct. 2007, referenced 13th April 2008. [5] D. Bryan, P. Matthews, E. Shim, and D. Willis, “Concepts and Terminology for Peer to Peer SIP,” Internet Engineering Task Force, InternetDraft draft-ietf-p2psip-concepts-01, Nov. 2007, work in progress. [6] K. Singh and H. Schulzrinne, “Peer-to-peer Internet Telephony Using SIP,” in NOSSDAV ’05: Proceedings of the International Workshop on Network and Operating Systems Support for Digital Audio and Video. New York, NY, USA: ACM Press, 2005, pp. 63–68. [7] D. A. Bryan, B. B. Lowekamp, and C. Jennings, “SOSIMPLE: A Serverless, Standards-based, P2P SIP Communication System,” in Proceedings of the 2005 International Workshop on Advanced Architectures and Algorithms for Internet Delivery and Applications (AAA-IDEA 2005), Jun. 2005. [8] D. A. Bryan and B. B. Lowekamp, “Decentralizing SIP,” ACM Queue, vol. 5, no. 2, Mar. 2007. [9] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek, and H. Balakrishnan, “Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications,” in Proceedings of the ACM SIGCOMM ’01 Conference, San Diego, California, Aug. 2001, pp. 149–160. [10] P. Maymounkov and D. Mazieres, “Kademlia: A Peer-to-peer Information System Based on the XOR Metric,” in Proceedings of the 1st International Workshop on Peer-to-Peer Systems (IPTPS’02), Mar. 2002, pp. 53–65. [11] S. Ratnasamy, P. Francis, M. Handley, R. Karp, and S. Shenker, “A Scalable Content-Addressable Network,” in Proceedings of ACM SIGCOMM ’01 Conference, San Diego, California, Aug. 2001. [12] J. Hautakorpi and G. Camarillo, “Evaluation of DHTs from the Viewpoint of Interpersonal Communications,” in MUM ’07: Proceedings of the 6th International Conference on Mobile and Ubiquitous Multimedia. ACM, 2007, pp. 74–83. [13] 3GPP, “IP Multimedia Subsystem (IMS); Stage 2,” 3rd Generation Parnership Proejct (3GPP), TS 23.228, Dec. 2007. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/23228.htm [14] G. Camarillo and M.-A. Garcia-Martin, The 3G IP Multimedia Subsystem (IMS): Merging the Internet and the Cellular Worlds, Second Edition. John Wiley & Sons, 2006. [15] 3GPP, “IP Multimedia (IM) session handling; IM call model; Stage 2,” 3rd Generation Parnership Proejct (3GPP), TS 23.218, Dec. 2007. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/23218.htm [16] ——, “Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks,” 3rd Generation Parnership Proejct (3GPP), TS 29.163, Dec. 2007. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/29163.htm [17] ——, “Interworking between the IM CN subsystem and IP networks,” 3rd Generation Parnership Proejct (3GPP), TS 29.162, Mar. 2006. [Online]. Available: http://www.3gpp.org/ftp/Specs/html-info/29162.htm [18] J. Johnson and J. Nelson, “Motivation for and Design of a SIP2IMS Gateway,” in The 2007 International Conference on Next Generation Mobile Applications, Services and Technologies, 2007 (NGMAST ’07), 12-14 Sept. 2007, pp. 136–144. [19] E. Marocco and D. Bryan, “Interworking between P2PSIP Overlays and Conventional SIP Networks,” Internet Engineering Task Force, InternetDraft draft-marocco-p2psip-interwork-01, Mar. 2007, work in progress. [20] D. Vingarzan, P. Weik, and T. Magedanz, “Design and Implementation of an Open IMS Core,” in Mobility Aware Technologies and Applications, Second International Workshop (MATA 2005), Oct. 2005, pp. 284–293. [21] Fraunhofer FOKUS, “The Open IMS Core Project,” At http://www.openimscore.org, 2008, referenced 13th April 2008. [22] P. Pessi, K. Vehmanen, and M. Mela, “Homepage of Sofia-SIP,” At http://opensource.nokia.com/projects/sofia-sip/, 2007, referenced 13th April 2008. [23] S. Baset and H. Schulzrinne, “Peer-to-Peer Protocol (P2PP),” Internet Engineering Task Force, Internet-Draft draft-baset-p2psipp2pp-00, Jul. 2007, work in progress, Expired. [Online]. Available: http://tools.ietf.org/id/draft-baset-p2psip-p2pp-00.txt [24] Richard Gayraud and Olivier Jacques, “Homepage of SIPp,” At http://sipp.sourceforge.net, 2008, referenced 13th April 2008. [25] OpenSER, “Homepage of OpenSER - the Open Source SIP Server,” At http://www.openser.org, 2008, referenced 13th April 2008.
VI. C ONCLUSION Many specific communication applications used today tend to form islands, where users of a communication application can not establish sessions with users of an another communication application. Some years ago specific communications applications were mainly used in fixed networks, but currently they are getting more and more popular also in mobile networks. In this paper, we have proposed an architecture for interconnecting the P2PSIP and IMS networks in a manner where the users of those networks would be able to establish sessions between each other. The proposed architecture is focused on the signaling level interconnection, and it is evaluated by implementing a prototype from the architecture. The prototype proves that the proposed architecture is feasible, and that it can be used in real networks. R EFERENCES [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, “SIP: Session Initiation Protocol,” Internet Engineering Task Force, RFC 3261, Jun. 2002. [Online]. Available: http://www.rfc-editor.org/rfc/rfc3261.txt [2] J. Rosenberg and H. Schulzrinne, “Session Initiation Protocol (SIP): Locating SIP Servers,” Internet Engineering Task Force, RFC 3263, Jun. 2002. [Online]. Available: http://www.rfc-editor.org/rfc/rfc3263.txt [3] A. B. Roach, “Session Initiation Protocol (SIP)-Specific Event Notification,” Internet Engineering Task Force, RFC 3265, Jun. 2002. [Online]. Available: http://www.rfc-editor.org/rfc/rfc3265.txt
88
