Work package contributing to Deliverable WP5 Type of Deliver

32603 Deliverable D5.7

Report on Integration of SIP and IPv6

Project Number: IST-2001-32603

Project Title: 6NET

CEC Deliverable Number: 32603/FhG/DS/D5.7/A1

Contractual Date of Delivery to the CEC: August 31st, 2003

Actual Date of Delivery to the CEC: September 30th, 2003

Title of Deliverable: Report on Integration of SIP and IPv6

Work package contributing to Deliverable: WP5

Type of Deliverable*: R

Deliverable Security Class**: PU

FOKUS

Editor: FhG Contributors: Workpackage

5

* Type: P - Prototype, R - Report, D - Demonstrator, O - Other

** Security Class: PU- Public, PP – Restricted to other programme participants (including the Commission), RE – Restricted to a group defined by the consortium (including the Commission), CO – Confidential, only for members of the consortium (including the

Commission)

Abstract:

This deliverable reports on the integration of SIP and IPv6. It aims at trying to provide an assessment of the role SIP will presumably play in the IPv6 world and how far the integration of SIP in IPv6 related applications and protocols has taken place.

The proliferation of communication services like IP telephony and advanced supplementary services, video conferencing, application data exchange, presence and instant messaging using SIP increases the need for public IP addresses that can only become available with the deployment of IPv6. The lack of IP addresses will become even more evident with the introduction of IP based communication in next generation 3GPP networks.

In this document, we are taking a look at the benefits of using IPv6 for SIP based applications and the extensions needed for SIP to work properly in an IPv6 environment. Besides the need for applications and SIP components that can deal with IPv6 there is a clear need for components that provide for a smooth transition from IPv4 to IPv6 networks. In this context we will describe the IPv6 SIP applications and components developed in 6net.

Finally the document presents a general overview on the testing activities of IPv6 SIP components in the context of 6net.

Keywords:

SIP, IPv6, VoIP, IP telephony

32603 Deliverable D5.7

Report on Integration of SIP and IPv6

2

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

3 Executive Summary

The primary goal of WP5 is to develop solutions that seamlessly evolve the deployment of IPv6-enabled business applications and middleware as well as understand the impact of novel, demanding applications on an IPv6 infrastructure, and to assess and report on the benefits and impact of IPv6 when used to deliver those applications. Of primary importance is the

integration and testing of existing applications and middleware with minor modification. The incorporation of applications and middleware that have not been specifically modified for IPv6 is also an important issue.

SIP and IPv6 must co-habit in many applications. The fact that this combination will be required in several of the applications, will allow different comments from the user communities.

This deliverable expands on these issues and provides a framework document for

organisations wishing to implement and deploy SIP based applications in an IPv6

environment.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

4 Table of Contents

1.

INTRODUCTION.......................................................................................................................................6 2. OVERVIEW OF PREFERRED SIGNALLING PROTOCOLS FOR IP TELEPHONY.. (7)

2.1. H.32

3....................................................................................................................................................7 2.2.

MGCP/H.248/M EGACO ........................................................................................................................7 2.3.

SIP........................................................................................................................................................8 2.4.

SIMPLE...............................................................................................................................................9 3.

SIP BENEFITS FROM IPV6.....................................................................................................................9 3.1.

D YNAMIC CONFIGURATION .................................................................................................................10 3.2. A NYCAST ............................................................................................................................................10 3.3.

IP V 6 SOLVES THE SIP NAT P ROBLEM ?..............................................................................................10 4.

TRANSITION STRATEGIES.................................................................................................................10 5. AVAILABLE APPLICATIONS.. (11)

5.1. V OCAL (11)

5.1.1. High-Level System View (11)

5.1.2. System Components......................................................................................................................12 5.1.3. Servers...........................................................................................................................................13 5.1.4. Support for IPv6 Mbone tools in Vocal SIPSet User Agent.........................................................14 5.1.5. VOCAL porting............................................................................................................................15 5.2. SIP E XPRESS P LATFORM ....................................................................................................................16 5.2.1. SIP Express Router (SER).............................................................................................................17 5.2.2. Mini SIP Proxy (MSP)..................................................................................................................18 5.3. B ONEPHONE ........................................................................................................................................20 5.3.1. General Architecture (21)

5.3.1.1

Media engine.......................................................................................................................................21 5.3.2. SIP Protocol Stack.........................................................................................................................24 5.3.2.1 NIST SIP protocol suite.......................................................................................................................24 5.3.2.2 SIP user agent.....................................................................................................................................25 5.3.3. Phone Controller (25)

5.3.4. Graphical User Interface (25)

5.3.5. Phonebook.....................................................................................................................................25 5.4. KP HONE (25)

5.4.1. KPhone Components.....................................................................................................................26 5.4.1.1 libdissipate..........................................................................................................................................27 5.4.1.2 KPhone application classes.................................................................................................................32 5.4.1.3 Basic testing and outlook.....................................................................................................................33 5.5.

6VOICE.............................................................................................................................................35 6.

INTEROPERABILITY OF SIP IMPLEMENTATIONS......................................................................35 6.1. I NDIVIDUAL T ESTS ..............................................................................................................................35 6.2.

M ULTI -PARTY T ESTS ...........................................................................................................................35 7.

ENUM.........................................................................................................................................................36 8.

IMPACT OF 3G NETWORKS ON INTEGRATION OF SIP AND IPV6..........................................37 9.

CONCLUSION..........................................................................................................................................37 10.

REFERENCES.....................................................................................................................................39 11.

ABBREVIATIONS...............................................................................................................................40 12.

GLOSSARY..........................................................................................................................................40 13.

SIP ACTIVITIES AND SITES............................................................................................................41 14. SIP RELATED STANDARDS STATUS.. (44)

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

5 15.

APPENDIX A........................................................................................................................................46 15.1. 3GPP STANDARDIZATION FOR IMS AND SIP.. (46)

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

6

1. Introduction

Over the past decade, the telecommunications industry has witnessed rapid changes in the way people and organizations communicate. Many of these changes spring from the explosive growth of the Internet and from applications based on the Internet Protocol (IP). The Internet has become a ubiquitous means of communication, and the total amount of packet based network traffic has quickly surpassed traditional voice (circuit switched) network traffic (DataQuest, 1998).

In the wake of these technology advancements, it has become clear to telecommunications carriers, companies, and vendors that voice traffic and services will be one of the next major applications to take full advantage of IP. This expectation is based on the impact of a new set of technologies generally referred to as voice over IP (VoIP) or IP telephony.

VoIP supplies many unique capabilities to the carriers and customers who depend on IP or other packet based networks. The most important benefits include the following:

?

Cost savings —By moving voice traffic to IP networks, companies can reduce or eliminate the toll charges associated with transporting calls over the Public Switched Telephone Network (PSTN). Service providers and end users can also conserve bandwidth by investing in additional capacity only when it is needed. This is made possible by the distributed nature of VoIP and by reduced operations costs as companies combine voice and data traffic onto one network.

? Open standards and multivendor interoperability —By adopting open standards, both

businesses and service providers can purchase equipment from multiple vendors and eliminate their dependency on proprietary solutions.

? Integrated voice and data networks —By making voice “just another IP application,”

companies can build truly integrated networks for voice and data. These integrated networks not only provide the quality and reliability of today's PSTN, they also enable companies to quickly and flexibly take advantage of new opportunities within the changing world of communications. In 1995, the first commercial VoIP products began to hit the market. These products were targeted at companies looking to reduce telecommunications expenses by moving voice traffic to packet networks. Early adopters of VoIP networks built toll-bypass solutions to take

advantage of favourable regulatory treatment of IP traffic. Without any established standards, most early implementations were based on proprietary technology.

As these packet telephony networks grew and interconnection dependencies emerged, it became clear that the industry needed standard VoIP protocols. Several groups took up the challenge, resulting in independent standards, each with its own unique characteristics. In particular, network equipment suppliers and their customers were left to sort out the

similarities and differences between different signalling and call-control protocols for VoIP:

?

Session Initiation Protocol (SIP) ?

H.323 ?

Media Gateway Control Protocol (MGCP) ? H.248/Megaco

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

7 The present paper will outline these different protocols and discuss our experience when deploying SIP in an IPv6 network.

2. Overview of Preferred Signalling Protocols for IP Telephony

2.1. H.323

H.323 was originally created to provide a mechanism for transporting multimedia applications over local area networks. Although H.323 is still used by numerous vendors for

videoconferencing applications, it has rapidly evolved to address the growing needs of VoIP networks. Because of its early availability and these advancements, H.323 is currently the most widely used VoIP signalling and call-control protocol, with international and domestic carriers relying on it to handle billions of minutes of use each year.

H.323 is considered an “umbrella protocol” because it defines all aspects of call transmission, from call establishment to capabilities exchange to network resource availability. H.323

defines Registration, Admission, and Status Protocol (RAS) protocols for call routing, H.225 protocols for call setup, and H.245 protocols for capabilities exchange.

Figure 1 H.323 protocol components

H.323 is based on the Integrated Services Digital Network (ISDN) Q.931 protocol, which allows it to easily interoperate with legacy voice networks such as the PSTN or Signalling System 7 (SS7).

As a protocol used in a distributed architecture, H.323 allows companies to build large scale networks that are scalable, resilient, and redundant. It provides mechanisms for

interconnecting with other VoIP networks, and supports network intelligence on either the endpoints or the gatekeepers.

2.2. MGCP/H.248/Megaco

MGCP and H.248/Megaco were designed to provide an architecture where call control and services could be centrally added to a VoIP network. In that sense, an architecture using these protocols closely resembles the existing PSTN architecture and services.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

8 MGCP and H.248/Megaco define most aspects of signalling using a model called packages. These packages define commonly used functionality, such as PSTN signalling, line-side device connectivity, and features such as transfer and hold. In addition, Session Definition Protocol (SDP) is used to convey capabilities exchange.

Figure 2 MGCP/H.248/MEGACO architecture

In a centralized architecture, MGCP and H.248/Megaco allow companies to build large scale networks that are scalable, resilient, and redundant. It provides mechanisms for

interconnecting with other VoIP networks and for adding intelligence and features to the call agent.

2.3. SIP

SIP was designed as a multimedia protocol that could take advantage of the architecture and messages found in popular Internet applications. By using a distributed architecture—with URLs for naming and text based messaging—SIP attempts to take advantage of the Internet model for building VoIP networks and applications. In addition to VoIP, SIP is used for videoconferencing and instant messaging.

As a protocol, SIP only defines how sessions are to be set up and torn down. It utilizes other IETF protocols to define other aspects of VoIP and multimedia sessions, such as SDP for capabilities exchange, URLs for addressing, Domain Name System (DNS) for service location, and Telephony Routing over IP (TRIP) for call routing.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

9

Figure 3 SIP distributed architecture

Although the IETF has made great progress defining extensions that allow SIP to work with legacy voice networks, the primary motivation behind the protocol is to create an environment that supports next generation communication models that utilize the Internet and Internet applications.

As a protocol used in a distributed architecture, SIP allows companies to build large scale networks that are scalable, resilient, and redundant. It provides mechanisms for

interconnecting with other VoIP networks and for adding intelligence and new features on either the endpoints or the SIP proxy or redirect servers.

2.4. SIMPLE

SIP for Instant Messaging and Presence Leveraging Extensions (SIMPLE) uses the Session Initiation Protocol to implement services collectively known as instant messaging and presence (IMP). As the most common services for which SIP is used share quite a bit in

common with IMP, the adaptation of SIP to IMP seems a natural choice given the widespread support for the SIP standard.

3. SIP Benefits from IPv6

The most obvious reason for using IPv6 with SIP is naturally the huge amount of available addresses. This is especially important when considering 3G architectures with millions of SIP based mobile phones all requiring their own IP addresses. But phones are not the only IP capable devices from the SIP point of view. Internet capable gaming stations or even appliances are also thought to be triggered by SIP. However, besides this obvious reason, IPv6 provides SIP with a row of other advantages especially in the area of dynamically configuring end systems and load balancing.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

10 3.1. Dynamic configuration

When starting a SIP user agent in some network, the UA needs to establish a new IP address besides some SIP specific parameters such as the address of an outbound proxy, a registrar and home domain name. As such information might change depending on the location of the UA, i.e. is which network it is currently in, the setting of this information needs to be realized dynamically. The dynamic configuration capabilities of IPv6 can be very helpful in such a situation resulting in simpler configuration of user agents in a standardized manner.

3.2. Anycast

For a user agent to start a communication session it might need to send all its SIP messages to a registrar or an outbound SIP proxy which might be responsible for the authentication of the user or controlling a firewall. Finding out the location of this registrar or outbound proxy might be statically configured in the user agents. A more flexible solution is to have all proxies with similar functionalities under the same anycast address. In this scenario the messages will get directed to the closest entity. For example if for load balancing reasons more than one registrar exists, an UA might send its registration to the general address of the registrars and the registration gets to the closest one.

3.3. IPv6 solves the SIP NAT Problem?

NAT traversal is one of the biggest problems for SIP telephony in IPv4 networks. NAT servers and firewalls were not originally designed to communicate with SIP servers or to accommodate SIP’s dynamically assigned ports and real-time traffic. However, under the IPv6 protocol in principle NAT shouldn’t longer be an issue because the reasons for NAT—address shortage and security requirements—are not longer existent with IPv6’s extended address space and its integrated IPsec functions. On the other hand there is not only a small chance that NAT during the transition period to IPv6 indeed will play a role as not all NAT devices will be completely removed in the IPv6 networks because of the tendency to retain the old NAT structures instead of configuring the new IPv6 networks so they could do without NAT components.

4. Transition Strategies

Due to the tremendous technological and administrative effort required on behalf of the user, system administrators and service provides, in order to reconfigure end devices, routers and servers from IPv4 to IPv6, the transition to IPv6 networks will be done gradually [7]. Three major transition mechanisms can be distinguished:

? Dual stack operation

This presumes support for both IPv6 and IPv4 at the same time. That is, the networks run both IPv4 and IPv6 routing protocols and the end systems are capable of sending and receiving IPv4 and IPv6 data packets and possess both an IPv4 and an IPv6

address. In case a data packet with an IPv4 address is received, the end system replies with packets carrying its IPv4 address. Sending data to another host is done in a

similar manner. If a DNS query resulted in an AAAA record then the IPv6 address is used. While this is a simple transition mechanism it requires providing IPv4 addresses to all end systems, which negates the major advantage of IPv6. Further, it complicates

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

11 the network architecture, as it requires managing both IPv4 and IPv6 routing

protocols.1

? Tunnelling

With this approach IPv6 islands are connected through tunnels established over IPv4 networks. Both ends of the tunnel act as dual stack routers connected to both IPv6 and IPv4 networks. IPv6 packets arriving at one end of the tunnel are encapsulated in an IPv4 packet and sent over the IPv4 network. At the other end of the tunnel, the packets are decapsulated and sent as IPv6 packets to their final destination. While simple to deploy in restricted areas, managing a large number of tunnels becomes complicated. ? Protocol Translation (NATPT)

With this approach a gateway is placed between IPv4 and IPv6 networks. These

gateways act similar to network address translators [23]. That is, such a gateway

manages a pool of IPv4- and IPv6 addresses. After receiving a packet from one

interface—e.g., IPv4—the source destination is replaced with one of the gateways addresses —e.g., IPv6—and vice versa. This approach has the advantage that end

devices and networks need only to run either IPv4 or IPv6. However, this approach breaks the end-to-end transparency of the Internet and is accompanied by similar

problems as introduced by NATs [12]. That is, besides translating the IP headers

special attention needs to be paid to protocols such as SIP and FTP, which carry

addressing information in the protocol messages themselves. 5. Available Applications

5.1. Vocal

The Vovida Open Communication Application Library (VOCAL) is an open source project targeted at facilitating the adoption of VoIP in the marketplace. VOCAL provides the development community with software and tools needed to build new and exciting VoIP features, applications and services.

Vovida Networks has been acquired by Cisco Systems in 2000 and Cisco continues the support of the Vocal open source project.

The VOCAL system is a distributed network of servers that provides Voice over Internet Protocol (VoIP) telephony services. VOCAL supports devices that communicate using the Session Initiation Protocol (SIP, RFC 3261). VOCAL also supports analogue telephones via residential gateways.

VOCAL supports on-network and off-network calling. Off-network calling enables

subscribers to connect to parties through either the Internet or the Public Switched Telephone Network (PSTN).

5.1.1. High-Level System View

The next figure shows a high-level, simplified view of the system.

1 There are different approaches for overcoming this requirement, but they further increase the complexity of the network.

Server(s)

Server(s)

Server(s)

Server(s) Server(s) Server

Party Billing Clearing House

Marshal Server Marshal Server

Gateway

Marshal Server SIP IP Phone Marshal Server

Marshal Server

Figure 4 VOCAL Architecture

5.1.2. System Components

From a high-level point-of-view, the VOCAL system appears as an assembly of basic components. These components are described below in Table 1.

Component Description

VOCAL System This is the telephony application. Figure 2 shows an abstract

representation of the VOCAL system server modules. A

description of each server appears in the next section, see

“Servers”

Protocols The VOCAL system uses several protocols to communicate

between its components. The call signalling processes use SIP

messaging to communicate internally within the VOCAL system

and externally with gateways and IP phones.

GUI The graphical user interface (GUI) enables technicians to

provision the system, and administrators to set up users and

monitor the system’s performance.

IP Phone VOCAL supports a variety of phone appliances including SIP

phones and SIP User Agent (UA) software applications. SIP

phones may be connected to the VOCAL system over any IP

network.

Gateways Gateways not only provide entry points between networks, they

also provide translation between SIP-based networks and other

network types. The VOCAL system works with two types of

gateways, the Residential Gateway and the Trunking Gateway.

Residential Gateway

12

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

13 Residential gateways translate analogue signals into IP packets, to

permit subscribers with analogue phone sets/devices to make and

receive SIP-based calls.

Trunking Gateway

Trunking gateways permit SIP-based networks to exchange calls

with end-points on the PSTN, by providing translation between

SIP messages and one of these signal types:

? Analogue

? Channel Associated Signalling (CAS)

? Primary Rate Interface

Table 1 VOCAL basic components

5.1.3. Servers

Table 2 describes the server modules included in the VOCAL system. Component

Description Marshal Server The Marshal Server (MS) is an implementation of the SIP proxy

server and acts as the initial point of contact for all SIP signals

that enter the VOCAL system. The MS provides authentication,

forwarding and billing functions.

Redirect Server The Redirect Server (RS) is a combined implementation of the

SIP redirect, registration and location servers. The RS stores

contact and feature data for all registered subscribers and a

dialling plan to enable routing for off-network calls.

Call Detail Record Server The Call Detail Record (CDR) server receives call data from the

Marshal Servers and formats it into data that can be transmitted to

third party billing systems for invoicing.

Voice Mail Server The Voice Mail server provides unified messaging whereby voice

mail messages can be distributed as .wav files attached to e-mail

messages.

Feature Server The Feature Servers are another implementation of the SIP proxy

server. These servers are scripted in Call Processing Language

(CPL) and provide basic system features such as Call Forward

and Call Blocking.

Provisioning Server The Provisioning Server (PS) stores data records about each

system user and server module, and distributes this information

throughout the system via a subscribe-notify model. The PS

provides a web-enabled graphical user interface to permit

technicians and system administrators to manage the system.

Heartbeat Server

The Heartbeat Server monitors the flow of signals emitted by the

other servers, and provides information about to the flow of

heartbeats to the Simple Network Management Protocol (SNMP,

RFC 1157) GUI. This information helps the System

Administrator know if the server modules are up or down.

Table 2 VOCAL server modules

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

14 5.1.4. Support for IPv6 Mbone tools in Vocal SIPSet User Agent

SIPSet is a SIP User Agent (UA) used for making and receiving phone calls from a Linux PC. The application consists of a GUI front end that interacts with the Vocal SIP stack.

SIPSet includes support for audio and video communication using a simple device plugin architecture. There are three device classes as standard; Audio, Video and a Null Device for testing call control:

The Audio device is a simple interface between the soundcard and the RTP stack. RTP data received is sent directly to the soundcard and audio captured from the soundcard is passed to the RTP functions.

The Video device uses an external MPEG library to render video data. Call configuration

details (addresses, port numbers) are extracted from the SIP packet and the data is written into the users home directory, as a configuration file for the MPEG library. A window is created within the current user interface to accommodate the video display and calls are made to the external MPEG library. This dynamically loads the MPEG library which reads in the configuration file.

The Null device is an empty class which just outputs the status of the call - i.e. "connect", "disconnect" etc.

A configuration file is read on startup for selecting which audio hardware to use and whether to use the MPEG video library. Video support is only available if SIPSet has been built to include the MPEG header files.

UCL has started a three phased project to make the SipSet application capable of starting and configuring the IPv6 versions of the UCL MBone tools, VIC and RAT. This will complete the work on making the Vocal system IPv6 and enable users to make IPv6 audio and video calls.

Phase one adds a new External-Media device that starts the Mbone tools when a call is

initiated. The device interacts with the SIP stack to extract call configuration details from the SIP packet. This information is then used to start the appropriate media tool with the remote address of the caller and the remote/local ports for sending/receiving the RTP data. When a call ends the tool is terminated. Configuration of which media tool to execute can be done in either the SIPSet configuration file or through the user interface. This phase has successfully been completed and patches are being compiled for submission to the Vocal project.

Phase two improves on the configuration of the media tools, so as to support extra parameters within the SDP (such as redundant transmission, interleave audio etc). This will be done by implementing SDP parsing into the UCL Mbone tools. The whole SDP packet will then be passed from SIPSet to the tool, which will then extract the relevant parameters for

configuration.

Phase three will use an inter-process communications channel, such as the Mbus [14], for

configuring the media tool. This has the advantage that if any format changes occur during the call, the media tool can be easily re-configured without the need to restart it with updated parameters.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

15 In addition to the above work we have also been conducting tests using the Cisco 7960 IP phones and the UCL audio tool RAT. Using the phones to make a call, RAT is started by the SIPSet application with the correct configuration. RTP Audio data is then sent from the Cisco phone to RAT for playout. Unfortunately the Cisco phones do not send RTCP control data alongside the RTP data and therefore RAT did not play the received packets. We have fixed this by adding an RTP promiscuous mode to RAT, that plays received RTP packets without first waiting for source identification from the corresponding RTCP packet.

5.1.5. VOCAL porting

The VOCAL package was ported by the University of Southampton to support IPv6. VOCAL as a whole is a complex package. The porting work done focused on the core

network stack, the SIP stack and the SIPSet user agent, i.e. enough of the system to get user-to-user SIP-based VoIP calls working.

The Vovida SIPSet is actually a standalone package SIP User Agent with a GUI front end that works with the Vovida SIP stack. You can use the SIPSet as a soft phone, to make and receives phone calls from your Linux PC.

The ported components were:

Network Stack:

?

IPv6 support added to the UDP stack (used much more widely than TCP). Amounted to a near total re-write

? Use of IP-independent data structures to store addresses, not integers

? Tries to store names rather than addresses for IP-independence

? Making it less likely to pass an IPv6 address to an IPv4 client SIP Stack:

? Extensively changed to support IPv6

?

Parsing issues

o Mainly the use of ‘:’s as a port separator—the solution was to use RFC2732-style delimiters, i.e. ‘[’, ‘]’ around the literal IPv6 address.

? Rewrite new IP-independent API calls to resolve DNS, and retrieve AAAA and A

records.

? Support extensions of the SIP protocol to allow support IPv6 addresses, and embed

them in the packets.

? API changes kept minimal to ensure changes were as transparent as possible. SIPSet:

? Modified to properly parse, display and accept IPv6 addresses.

The porting process highlighted a few implementation-specific issues. For example, there are some subtleties between platforms, in terms of how they handle binding to IPv4 and IPv6

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

16 simultaneously. The new IPv6 API’s, in particular the IP-independent calls such as getaddrinfo(), may not be present.

Some classic porting issues were encountered. Properly written network code would have been easier to port. The passing of IP addresses as integers forced API changes. The format of IP addresses (dotted quad) is assumed in many places; thus the code for parsing IP addresses would have better been centralised. Porting involved repeatedly changing inet_aton statements.

SIPSet is working, both in dual-stack and in IPv6 or IPv4 only environments. The code is integrated into the v1.5 release of VOCAL.

However VOCAL as a whole is not so well supported. In particular the "all-in-one" configuration script relies on Perl, which is currently lacking IPv6 support. Other components will need updating, however this should be restricted to UI input checks and parsing. Among items remaining to be done is the TCP Stack, which was undergoing substantial

changes while the porting work was in progress. Some improvements with regards to protocol selection would be desirable; this is currently DNS based, i.e. it assumes IPv6 enabled if AAAA record is present (which is not a great assumption!). Clean fallback mechanisms are required, e.g. if IPv6 fails attempt IPv4.

We will test further application layer IPv4-IPv6 SIP gateways for interoperability between protocols. We also plan to integrate ENUM in IPv6 VOCAL. As for the rest of VOCAL, other components may be partially IPv6 enabled "for free" as a result of using the SIPSet and SIP and Network Stacks.

The user agent has been tested between partners in 6NET informally at the time of writing. It was demonstrated at IST2002 in late 2002. In the 6WINIT 2 IST project review demonstration in early 2003 the VOCAL IPv6 code was shown to interoperate with the Bonephone IPv6

application for SIP-based VoIP. In addition, the SIP gateway developed by the TZI Institute at the University of Bremen 3 also allowed calls to be placed to a UMTS endpoint from a VOCAL client. This was a collaboration between TZI, Ericsson and UoS. The full

demonstration included VOCAL, Bonephone, a Cisco 7960 and Microsoft Messenger. The TZI gateway is written in Java (v1.4). It also allows bridging of SIP-H.323 and IPv4 to IPv6. It is available from the 6NET applications database 4.

5.2. SIP Express Platform

The SIP Express Platform includes support for registrar, proxy and redirect mode. Further it acts as an application server with support for CPL, instant messaging and presence (IM&P) including a SMS gateway, a call control policy language, call number translation, private dial plans and accounting, authorization and authentication (AAA) services. The SIP Express platform runs on Sun/Solaris, PC/Linux, IPAQ/Linux platforms and supports both IPv4 and IPv6. 2

506e8d01de80d4d8d15a4f44/ 3 http://www.tzi.de/ 4 506e8d01de80d4d8d15a4f44/apps.phtml?appID=43

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

17 5.2.1. SIP Express Router (SER) 506e8d01de80d4d8d15a4f44’s SIP Express Router (SER ) is a high-performance, configurable, free SIP ( RFC 3261 ) server which was implemented in C and ported to Linux (PC, IPAQ), BSD (PC) and Solaris (Sun). Originally developed for IPv4 only, today support for IPv6 is included.

The IPv6-ability of the SER was achieved as part of FhG’s framework of 6net activities. The following IPv4 code constituents were mainly affected and had to be modified resp. extended:

?

IP addresses and socket handling: o Change of internal SER ip address and sockaddr representation to handle both IPv6 and IPv4 addresses o As portability was a major goal, SER+IPv6 works on linux, solaris, freebsd, netbsd and open BSD both on 32 bit and 64 bit architectures. ?

name resolution: o Internal name resolution functions were changed to handle AAAA records (records containing IPv6 addresses). ?

parsing: o Header parsing and URI parsing functions were changed to handle IPv6 address references (literal address syntax 5) or normal IPv6 addresses (canonical form) as necessary. E.g. IPv6 addresses must be generally specified as IPv6 address references (to avoid ambiguity when determining the port number) with the exception of the IPv6 address in the "received" VIA parameter which must not be a reference. ?

message modifications / construction: o IPv6 addresses are added to VIA, VIA received parameter, Record-Route etc. ? IP address realm transitions:

SER is able to forward messages between different address realms, i.e. from IPv4 to IPv6 and from IPv6 to IPv4. o In the VIA header always the outgoing interface address is used (so "our" VIA will always contain the proper address realm).

o Double record-routing is used: We add 2 record route headers when we detect an address realm transition. One will contain the address in the origin realm

(e.g. IPv4), and the other the address in the other realm (e.g. IPv6). This will

ensure that all the other messages in the dialog will pass through our proxy,

which will take care of the realm transition. The double record routing solution

doesn't involve keeping any state (of course record routing must be enabled in

the .config file).

The SER can act as registrar, proxy or redirect server. SER features an application-server interface, presence support, SMS gateway, SIMPLE2Jabber gateway, RADIUS/syslog

5

A literal IPv6 address in a URL is the address enclosed in square brackets. For example, to reach

506e8d01de80d4d8d15a4f44 at 2001:610:148:dead:210:18ff:fe02:e38, the URL is http://[

2001:610:148:dead:210:18ff:fe02:e38]/. The use of the IPv6 literal address syntax is described in RFC 2732

[11].

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

18 accounting and authorization, server status monitoring, FCP 6 security, etc. A web based user provisioning, serweb 7 is also available.

Its high performance allows it to cope with exceptional operational burdens, such as broken network components, attacks, power-up reboots and rapidly growing user populations.

SER's configuration ability meets needs of a whole range of scenarios including small-office use, enterprise PBX replacements and carrier services.

SERv4 has been successfully tested with SIP products from other vendors such as Microsoft, Cisco, Mitel, snom, Pingtel, and Siemens. Specific IPv6 based interoperation tests had been performed as described in section 6 “Interoperability of SIP implementations”.

With the help of a mailing list it is possible to obtain additional help from the SER

community. To participate in the mailing list, subscription at the following web address is required: 506e8d01de80d4d8d15a4f44/mailman/listinfo/serusers .

Discussion of development, new features and SER status as on CVS takes place at the following mailing list: 506e8d01de80d4d8d15a4f44/mailman/listinfo/serdev.

5.2.2. Mini SIP Proxy (MSP)

The Mini SIP Proxy 8 (MSP) receives SIP messages, modifies them, installs UDP mappings for RTP communication and forwards the SIP messages to another proxy. The MSP depends on two outbound proxies: one for IPv4 and one for IPv6 targets, as it does not route requests itself. If a SIP request message is received by an IPv4 interface, it is sent out to the IPv6 proxy and vice versa. SIP response messages are routed by their second via header. Only the following parts of a SIP message are modified:

a) Contact header :

This is modified by replacing the original contact header with the URI of the SIP-

PGW with an additional parameter reflecting the original contact address (“real_uri” parameter). A peer that sends subsequent requests (e. g., BYE) must send them to this modified contact header, i.e., the SIP-PGW with the real_uriparameter.

b) Request URI :

This is modified only if the Request URI has a real_uri-parameter. It is then replaced by the original URI represented by the real_uri.

c) SDP-headers :

Located in the body:

- originator (o=)

- contact (c=)

- media description (m=)

They hold IP-Addresses or ports and must be modified to match the target protocol family. The addresses included in the SDP part are allocated by sending a mapping request to the UFWDD.

6

506e8d01de80d4d8d15a4f44/fcp/

7 developer.berlios.de/projects/serweb/ 8 The MSP is still under development. Software and instructions can be obtained from 506e8d01de80d4d8d15a4f44 in case of eager demand.

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

19 d) Content-length :

When the body (SDP) is modified, the content length needs to be recalculated.

e) VIA :

A via header is inserted in request messages and removed from response messages. As an integration mechanism for enabling the communication between an IPv4 only capable device and an IPv6 only capable device we chose the protocol translator approach. This

allows for simple end devices and networks that only need to support one of the IP versions.

Figure 5 SIP gateway for heterogeneous environments (PGW)

This protocol translator called the SIP Protocol Gateway (PGW) is intended to be located on the borderline between pure IPv6 and pure IPv4 clients. It runs on a dual-stack machine to be able to speak and listen to both protocol-families. It can be considered as a proxy, which modifies the SIP messages sent by an IPv4/IPv6 host to be understood by an IPv6/IPv4 host. The SIP-PGW consists of three components:

1. MSP

2. UDP-forwarding daemon (ufwdd):

This entity manages the IPv4 and IPv6 address spaces of the gateway and acts as a

network address translator. Packets received on the IPv4/IPv6 side are sent to an

IPv6/IPv4 host using a sending address and port number allocated from the IPv6/IPv4 address and port space of the gateway.

3. Control protocol :

For requesting the allocation of addresses and mapping between the protocol families, both the MSP and FWDD communicate via UDP messages. This also allows both

components to reside on different machines. This is done in a fashion similar to the middlebox architecture of the IETF.

Besides the gateway, Figure 5 shows two SIP proxies. Each proxy represents the SIP provider in one side of the heterogeneous network. I.e.—for the example of a SIP provider such as 506e8d01de80d4d8d15a4f44 requests originating from the IPv4/IPv6 network and destined for subscribers of 506e8d01de80d4d8d15a4f44 should be directed to the 506e8d01de80d4d8d15a4f44 proxy located in the IPv4/IPv6 network. In case the proxy in the originating network, e.g., IPv4, is incapable of locating the user, it forwards

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

20 the request to the gateway, which forwards the request further to the proxy of 506e8d01de80d4d8d15a4f44 in the IPv6 network after translating its content. While the functionalities of both proxies could also have been integrated into the SIP-PGW this would have increased the complexity of the gateway and would increase the load on the gateway as it would need to process a higher number of SIP messages and possibly execute some services such as CPL or similar besides translating and routing the data. This distribution further allows the gateway provider to be an independent provider concentrating on the translation of signalling and media packets and relieves the SIP service provider from having to deal with media packets as well.

5.3. Bonephone

The bonephone application was developed in order to integrate the telephony service into the PC. The application utilizes voice over IP (VoIP) [3] to carry digital voice data over the internet to another VoIP capable application or to a traditional phone through a translating gateway.

To be ready for the future, this application is based upon the latest international standards. These are the internet protocol (IP) [1], the internet protocol version 6 (IPv6) [5], the user datagram protocol (UDP) [16], the real time transport protocol (RTP) [20], the real time transport control protocol (RTCP) [20] and the session initiation protocol (SIP) [20]. Besides of supporting the newest standards the architecture of the application has been designed in an open and extendable manner. The design, for example, allows the easy extension of the tool with other media like video or other types of communication like conferencing. On the other hand, to allow for easy customization and personalization of the tool to the specific needs of a user or a vendor the tool supports easy replacement of the entire graphical interface with a new one. Finally, the tool was designed and implemented in a portable and scalable manner allowing its usage over different hard- and software platforms. Bonephone was implemented allowing for easy extension of the functionality of the application and replacement of the GUI.

To provide for adequate replacement of high-end phones the tool is able to deal with parallel calls at the same time, maintain call logs and provides callback features in addition to phonebook functionalities.

The software was implemented as a distributed program with components communicating over the message bus (MBus). In this way it is possible to add new media engines, and even use media engines that do not reside on the same machine.

Bonephone provides different configuration options (cf. bonephone manuals for installation and usage 9) . There is one for the phonebook, which holds names of people and their

associated SIP address. There is one for the general information like the executable image of the media image, whether to use IP or IPv6, etc. In a third configuration file new profiles for data communication can be defined.

9

506e8d01de80d4d8d15a4f44/products/bonephone/bonephone-user-guide and

506e8d01de80d4d8d15a4f44/products/bonephone/bonephone-installation-guide

32603 Deliverable D5.7 Report on Integration of SIP and IPv6

21 5.3.1. General Architecture The bonephone VoIP application consists of the following components shown in Figure 6:

?

an instance that manages RTP/RTCP communication for audio data transport ?

a SIP capable user agent which utilizes a SIP protocol stack ?

a graphical user interface to interact with the user ?

an instance that coordinates the media engine, which does not interact with the signalling itself, with the SIP user agent ? a phonebook

Three already existing open source software products could be used for the IP phone but had to be redesigned in parts. These are:

5.3.1.1 Media engine

The media engine is responsible for the audio communication. It reads samples from the audio device of the PC, encodes them and sends them through the internet using the RTP/RTCP protocols. It is also responsible for the reverse process, i.e. it must be able to receive encoded audio samples via RTP/RTCP, decode them and write them to the audio device for play back. It provides an interface allowing the control of the following parameters:

?

The remote IPv6 address and port number to which the RTP/RTCP data will be sent as well as the local port number where it receives audio data, and

? the audio encoding algorithm to be used for sending audio data.

? The interface allows the modification of runtime parameters like volume or active

output channel number.

? Finally, the control interface allows for reporting status information either periodically

or on demand.

本文来源：https://www.bwwdw.com/article/acal.html