D5.11 Realisation of IPv6/IPv4 VoIP Integration Scenarios · 2006. 2. 3. · Mitel, Snom, Pingtel, Freebit, and Siemens. Specific IPv6 based interoperation tests had been performed

IST-2001-32603 Deliverable D 5.11

Realisation of IPv6/IPv4 VoIP Integration Scenarios

Project Number: IST-2001-32603

Project Title: 6net

CEC Deliverable Number: 32603/UCL/DS/5.11/A1

Contractual Date of Delivery to the CEC: 30th January 2005

Actual Date of Delivery to the CEC:

Title of Deliverable: Realisation of IPv6/IPv4 VoIP Integration Scenarios

Work package contributing to Deliverable: WP5

Type of Deliverable*: R

Deliverable Security Class**: PU

Editors: UCL

Contributors: P.O’Hanlon (UCL), S.Varakliotis (UCL), R.Ruppelt (FhG), J.Fiedler (FhG)

* 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: Voice over IP is becoming a very important application, which will coexist on IPv4 and IPv6 for some time. This deliverable describes both Session Initiation Protocol (SIP) and H.323 based systems that have been deployed, tested and demonstrated within the 6net project.

Keywords: VoIP, SIP, H.323, Gatewaying



Final 2

Table of contents 1 Introduction..................................................................................................................................5

2 Overview of deployed IP telephony signalling protocols............................................................5

2.1 SIP........................................................................................................................................5

2.2 H.323....................................................................................................................................6

3 VoIP components.........................................................................................................................7

3.1 Network entities ...................................................................................................................7

3.1.1 SIP Express Router (SER) .......................................................................................7

3.1.2 Mini SIP Proxy (MSP) – IPv6-IPv4 gateway ..........................................................7

3.1.3 Asterisk ....................................................................................................................9

3.1.4 Openh323 MCU.....................................................................................................10

3.2 User agents.........................................................................................................................10

3.2.1 Vocal SIPSet with RAT User Agent......................................................................10

3.2.2 KPhone...................................................................................................................10

3.2.3 GnomeMeeting ......................................................................................................11

3.3 IPv4 Clients........................................................................................................................11

3.3.1 Cisco 7960 .............................................................................................................11

3.3.2 X-Lite Softphone....................................................................................................12

4 Deployed systems ......................................................................................................................12

4.1 UCL....................................................................................................................................12

4.2 Fraunhofer..........................................................................................................................14

4.2.1 Fokus 6net VoIP system environment ...................................................................14

4.2.2 IPv6 enabling of Iptel.org ......................................................................................16

4.3 JOIN...................................................................................................................................16

4.4 Poznan................................................................................................................................16

5 Demonstrated systems................................................................................................................16

5.1 6net Spring 2004 conference..............................................................................................16

5.2 IST2004..............................................................................................................................16

6 Conclusions................................................................................................................................17

Appendix A – Freebit IPv6/v4 hardware phone ................................................................................18

1 FreeBit IPv6 / IPv4 phone manual..............................................................................................18

1.1 Overview and functions .......................................................................................................18

1.2 Rear side...............................................................................................................................18

1.3 Default assignment of function keys....................................................................................20



Final 3

1.4 FreeBit phone setting options ..............................................................................................20

Appendix B – Report on the IPv6/IPv4 SIP gateway ........................................................................23

1 Introduction................................................................................................................................23

1.1 VoIP requirements .............................................................................................................23

1.1.1 Real-time transport and control protocol ...............................................................23

1.1.2 Session description protocol ..................................................................................25

1.1.3 Session Initiation Protocol .....................................................................................26

1.2 IPv6/IPv4 VoIP translation problem analysis....................................................................33

1.1.4 Problem description ...............................................................................................33

1.1.5 Known techniques..................................................................................................36

2 IPv6/IPv4 VoIP translation solution ..........................................................................................47

2.1 Specification.......................................................................................................................47

2.1.1 The SIP proxy ........................................................................................................47

2.1.2 The RTP relay ........................................................................................................50

2.1.3 The mapping protocol ............................................................................................52

2.2 The IPv6/IPv4 SIP proxy ...................................................................................................55

2.2.1 Network module.....................................................................................................56

2.2.2 Message parsing.....................................................................................................56

2.2.3 Request processing.................................................................................................59

2.2.4 Response processing ..............................................................................................59

2.2.5 Contact list .............................................................................................................60

2.2.6 SDP modification...................................................................................................61

2.2.7 RTP relay interaction .............................................................................................62

2.2.8 Message assembly..................................................................................................63

2.3 The RTP relay ....................................................................................................................63

2.3.1 The logging process ...............................................................................................64

2.3.2 The master process.................................................................................................65

2.3.3 The worker process ................................................................................................66

2.3.4 Mapping installation ..............................................................................................67

2.3.5 Packet forwarding ..................................................................................................67

2.3.6 Mapping deletion ...................................................................................................69

2.4 Testing................................................................................................................................70

2.5 Summary and future...........................................................................................................72

2 Parser and logger details ............................................................................................................73



Final 4

2.1 Parser details ......................................................................................................................73

2.2 Logging protocol................................................................................................................74

3 User guide ..................................................................................................................................75

3.1 UFWDD User guide ..........................................................................................................75

3.2 MSP User guide .................................................................................................................77

3.3 The start/stop scripts ..........................................................................................................78

3.4 System requirements ..........................................................................................................78

References..........................................................................................................................................79



Final 5

1 Introduction Voice over IP is becoming a very important application, which will coexist on IPv4 and IPv6 for some time. Within the 6net project both Session Initiation Protocol (SIP) [1] and H.323 [18] based systems have been deployed, tested and demonstrated.

In this document we begin by providing an overview of the deployed VoIP protocols and their basic operation. In section 3 we provide details on the individual components of the deployed system and their setup and usage. In section 4 we describe the VoIP system deployments on a site basis. In section 5 we describe demonstration of the deployed systems.

We also refer the reader to D5.7 in which we previously provided detailed information on IPv6 capable SIP based system components.

In this document we will cover the actual deployed systems, including information on any updates and additional components. In addition, Appendix B provides a full report detailing the design and implementation of the IPv6/v6 SIP gateway.

2 Overview of deployed IP telephony signalling protocols Within the 6net project both Session Initiation Protocol (SIP) and H.323 based systems have been deployed for use on IPv6 and IPv4. Here we provide a brief overview of these protocols.

2.1 SIP Session Initiation Protocol (SIP) is an application-layer control (signalling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, instant messaging, and multimedia conferences.

SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user’s current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP clients are referred to a SIP User Agents, and may make peer-to-peer calls, though usually they register and setup sessions via a SIP proxy – see Figure 1. SIP can run on top of several different transport protocols though it most commonly uses UDP over Internet Protocol.

SIP builds on a number of other protocols used in the Internet utilising a text based approach for requests and responses. 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 Session Description Protocol (SDP) for capabilities exchange, Universal Request Identifiers (URIs) for addressing, Domain Name System (DNS) for service location, and Telephony Routing over IP (TRIP) for gateway call routing. In the case of VoIP typically Real-time Transport Protocol (RTP) [16] is used to transport the actual encoded media streams, which may use such codecs as G.711 or GSM.



Final 6

Figure 1 SIP distributed architecture

SIP is essentially IP protocol independent having the capability to communicate on IPv4 and IPv6. For interoperation between IPv4 and IPv6 typically a gateway such as the MSP (see section 3.1.2, and appendix B) maybe used.

For interoperation between SIP and another signalling protocol, such as H.323 or the Skinny Call Control Protocol (SCCP) [17], a gateway such as Asterisk may be used – see section 3.1.3. This gateway does not currently support IPv6 though by routing calls through and an IPv4-6 gateway in addition to the SIP-H.323 gateway session connectivity may be established.

2.2 H.323

H.323 is another protocol for setting up multimedia sessions which was created originally 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. 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.245 protocols for call setup, and capabilities exchange. Similarly to SIP it utilises RTP for media transport, which is specified in H.225.



Final 7

Figure 2 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.

3 VoIP components The integration of IPv6 and IPv4 systems provides for access to existing operational IPv4 systems. This integration has been possible by using gatewaying devices such as the MSP, along with protocol independent systems such as Openh323 MCU.

3.1 Network entities

3.1.1 SIP Express Router (SER) Iptel.org’s SIP Express Router (SER) is a high-performance, configurable, free SIP [1] 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 details of these changes are covered in D5.7.

The SER can act as registrar, proxy or redirect server. SER features an application-server interface, presence support, SMS gateway, SIMPLE2Jabber gateway, RADIUS/syslog accounting and authorization, server status monitoring, FCP1 security, etc. A web based user provisioning, serweb2 is also available.

SERv4 has been successfully tested with SIP products from other vendors such as Microsoft, Cisco, Mitel, Snom, Pingtel, Freebit, and Siemens. Specific IPv6 based interoperation tests had been performed as described in D5.7.

3.1.1.1 Configuration and use SER is configured through the use of it configuration file which exists in a standard location or may be specified on the command line. The configuration file contains directives to control routing of calls between SIP entities, including the routing to and from other systems such as Asterisk and the MSP gateway for IPv4-6 inter-working.

3.1.2 Mini SIP Proxy (MSP) – IPv6-IPv4 gateway The Mini SIP Proxy (MSP) receives SIP messages, modifies them, installs UDP mappings for RTP communication and forwards the SIP messages to another proxy. A full report on the MSP is included in Appendix B. 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:

1 www.iptel.org/fcp/ 2 developer.berlios.de/projects/serweb/

http://www.iptel.org/ser

http://www.iptel.org/fcp/

http://developer.berlios.de/projects/serweb/



Final 8

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_uri parameter.

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.

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.

msp

ufwdd

Proxy Proxy

UA UA

IPv6IPv6 IPv4IPv4SIP-PGW

RTP

SIP SIP

SIPSIP

RTP

Address-mapping-requests /replies

Figure 3 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. Mini-SIP Proxy (MSP):

This is the main entity which provides the SIP application level gatewaying function between IPv6 and IPv4.



Final 9

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 3 shows two SIP proxies. Each proxy represents the SIP provider in one side of the heterogeneous network. For the example of a SIP provider such as iptel.org requests originating from the IPv4/IPv6 network and destined for subscribers of iptel.org should be directed to the iptel.org 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 the request to the gateway, which forwards the request further to the proxy of iptel.org 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 Call Processing Language (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.

3.1.2.1 Configuration and use Both entities of the SIP-PGW are configured directly via its main shell “start” script. For the MSP proxy component the script requires configuration of the IPv4- and IPv6-side addresses and ports, configuration of log files and packet logs. For the ufwdd module, specific configuration of media port range is required, as well as logfiles and the number of slave forwarding processes that will be made available for media proxying. A Full user guide is provided in Appendix B.

3.1.3 Asterisk Asterisk is a complete software PBX with wide ranging VoIP support. It provides a central switching core, with four APIs for modular loading of telephony applications, hardware interfaces, file format handling, and codecs. Asterisk runs on various Linux flavours and allows for transparent switching between most standards-based telephony equipment using SIP, H.323 and other standard or proprietary protocols. It is currently only IPv4-enabled, but IPv6 development is underway. UCL and 6net will be alpha testers of the software.

Using Asterisk UCL has setup and deployed a number of telephony services, most notably PSTN gatewaying, the MeetMe multi-way audio conferencing (enhanced with conference invitations that can be sent to any PSTN or SIP phone), Interactive Voice Response (with natural or synthetic voice recordings), voicemail (with “message waiting" notifications, or voice attachments via e-mail), Phone Directory, Call Queuing and Music On Hold.

3.1.3.1 Configuration and use Asterisk is configured through its config files which typically reside in /etc/asterisk/. There is a main config file (extensions.conf) to control the activation of services and devices, and to define contexts, dial plans and phone extensions, whilst there is a number of separate config files,



Final 10

one for each supported VoIP protocol, device, or other functionality. The file (sip.conf) is dedicated to the SIP configuration.

3.1.4 Openh323 MCU The OpenH323 project has developed an open source H.323 protocol implementation, which contains both clients and server, and can be used for H.323 videoconferencing. The servers that are available include: a H.323 MCU (Multipoint Control Unit), a H.323 Gatekeeper and a H.323 to PSTN Gateway. The MCU provides for simultaneous IPv4 and IPv6 H.323 video conference participants.

3.1.4.1 Configuration and use Openh323 MCU is configured on the command line, allowing control over the video and conferencing behaviour. The MCU is usually started with a script which sets up the default configuration.

3.2 User agents

3.2.1 Vocal SIPSet with RAT 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 device plug-in 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 Null device is an empty class which just outputs the status of the call - i.e. "connect", "disconnect" etc.

UCL has ported SIPSet to full IPv6 SIP operation in conjunction with UCL RAT for high quality audio in the wide area. The tool now operates in both SIP peer-to-peer mode and via a proxy.

This has resulted in the addition of a new External-Media device that starts RAT tool 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. The work involved a number of changes to the VOCAL subsystems so they fully supported IPv6 proxy operation. In addition RAT required a number of changes so it would interoperate with other SIP phones, including correcting error recovery for mal-formed G.711 audio packets and a more permissive port usage strategy according to RFC3550 [16].

3.2.1.1 Configuration and use SIPSet-rat is usually configured through its GUI, though it is also possible to directly modify its config file (gua.cfg) which typically resides in the hidden directory “.sipset” under the user’s home directory (~/.sipset/gua.cfg). This file allows basic SIP configuration for the SIPSet module operating with rat, such as the SIP proxy, user name, display name, transport, registrar, port range and log files.

3.2.2 KPhone



Final 11

KPhone is a Linux based VoIP telephony application which supports IPv4, and IPv6. It is based on the K desktop environment (KDE) version 3.13 and the corresponding graphics and widget library QT version 3.1. KPhone implements SIP for call signalling and RTP for audio streaming. KPhone is written in the C++ programming language. For more details on kphone see D5.7.

KPhone is basically composed of 4 components: The libdissipate library, the KPhone application itself and the GSM and iLBC libraries.

The libdissipate library holds the basic networking code, i.e. the classes for creating sockets and resolving names to IPv4/IPv6 addresses. It also holds the SIP protocol stack for call signalling.

3.2.2.1 Configuration and use Kphone is normally configured through its GUI. If new SIP proxy is entered the tool needs to be restarted.

3.2.3 GnomeMeeting GnomeMeeting is a Linux based H323 compatible application that interoperates with Windows based H323 clients, thus opening the possibility for a universal conferencing platform. It is based on the OpenH323 platform. Benefits from IPv6 support will be QoS features and security. Features include:

- GUI interface for popular Linux window managers.

- Gatekeeper and directory support.

- Audio only mode.

- Automatic device detection.

3.2.3.1 Configuration and use GnomeMeeting is typically configured through its GUI, though it may also be configured directly via config files. In a typical Linux system these reside in:

- /etc/gconf/gconf.xml.defaults/apps/gnomemeeting/, for system-wide settings,

- ~/.gconf/apps/gnomemeeting, for user-specific settings.

3.3 IPv4 Clients

3.3.1 Cisco 7960 The Cisco 7960 is a hardware based device which provides for professional quality SIP, or SKINNY Call control Protocol (SCCP) [17], VoIP communications. It is fully a functional phone including multiple line support, message handling and hands free operation

3.3.1.1 Configuration and use Cisco 7960 maybe configured through it on-sreen menu system (using the key sequence “**#” to unlock the settings of the phone). For preconfigured operation the phone can be setup using config files:

- A dialplan in XML (dialplan.xml),

3 http://developer.kde.org/build/compile_kde3_1.html

http://developer.kde.org/build/compile_kde3_1.html



Final 12

- SIP default settings (SIPDefault.cnf)

- SIP phone-specific settings (SIPxxxxxxxxxxxx.cnf), where xxxxxxxxxxxx is the MAC address of the Cisco phone.

These files are typically located into a tftp server’s upload directory and allow numerous settings for the phone and the user, the network, lines and extensions, SIP, directory, etc. This configuration method, via tftp, is intended for mass (enterprise-wide) deployment of the new settings.

Alternatively, configuration can be done (for a single phone) via a serial interface, or even remotely over Ethernet if the phone has already been allocated an IPv4 address.

3.3.2 X-Lite Softphone The X-.Lite phone operates under Microsoft Windows and provides for high quality SIP based conferencing. X-Lite may be configured to register with a number of SIP proxy servers. It provides for variety of audio codecs and is also capable of automatically using the STUN protocol [12] to ascertain whether it is behind a Network Address Translator (NAT), and how subsequently to make outbound SIP invitations.

3.3.2.1 Configuration and use X-Lite is configured through its settings GUI. Each SIP ‘line’ is configured by entering the username and password and proxy hostname, after which X-Lite will register with the corresponding SIP proxy. X-Lite will run in the “background” till an incoming call is notified to the user, or the user wished to make an outgoing call.

4 Deployed systems 4.1 UCL

Figure 4 UCL VoIP system architecture

The core VoIPv6 system is based upon the SER and the MSP, in combination with the Asterisk PBX and voice conference server, and Public Switch Telephone Network (PSTN) gateway.



Final 13

The SIP User Agent developed by UCL (SIPSet-rat) is based upon VOVIDA/Cisco’s SIPset SIP agent in conjunction with UCL’s Robust Audio Tool (RAT) to provide for high quality, low latency audio. RAT was also enhanced to provide Dual Tone Multi-Frequency (DTMF) functionality which enabled dial-pad control of certain core system functions, in a similar way to a conventional phone.

Figure 4 shows the SER as the front-end for SIP-based Internet telephony, acting as the SIP proxy for both IPv4 and IPv6. SER provided for the routing of the calls to and from the different entities, including implementing the logic for IPv4-6 translation and redirection of calls to utilise Asterisk’s functionality. UCL designed an integrated IPv4-IPv6 SER call routing architecture, running on a single dual-stack Linux PC, communicating on both protocols. This set-up differs from the design of other VoIP infrastructures using SER, whereby two servers are typically employed, one dedicated to each protocol. This was done for a number of reasons:

a) To allow seamless integration of IPv4 and IPv6 VoIP services.

Using separate SIP proxies would require configuration of two outgoing lines on a hard-phone, or re-configuration of a soft-phone. The end-user does not have to use different outgoing lines to place a call over IPv6 or IPv4. Ideally, users do not need to know - and they should not care - of the existence of two protocols at the network layer.

b) To allow integration of the IP-phone extension numbering scheme to routing.

UCL’s numbering scheme allocates the first digit of the extension to denote the protocol, i.e.: a 4xxx extension will be reached via the IPv4 network, whereas a 6xxx extension via IPv6. This is a particularly useful at the early stage of the VoIP service deployment for the network team to monitor calls and identify any problems related to IPv6 and protocol integration.

c) To maintain centralised control of routing.

Using a single SER means that the routing logic implemented does not get dispersed into a number of configuration files among different servers. This is useful for medium term expansion of the VoIP services, and for possible changes in the integration plan that may arise from service usage feedback.

Asterisk runs on the same Linux PC as the SER and provides SIP-PSTN gateway functionality through an ISDN BRI line, thus allowing mobile phone and residential line users to interconnect with the UCL VoIP infrastructure. It is currently only IPv4-enabled, but IPv6 development is underway. UCL are monitoring the porting effort and through our 6net activities we will be alpha testers of the software.

Using Asterisk UCL has setup and deployed a number of additional telephony services, most notably:

a) Interactive Voice Response functionality (IVR), using pre-recorded and synthesised voice samples, controllable by DTMF tones. Incoming calls via the PSTN are terminated on Asterisk and directed to the incoming IVR profile for extension selection. The IVR menu can also be reached from calls coming via IP, or in any situation where extensions are busy, or not answered.

b) The Asterisk MeetMe multi-way audio conferencing has also been deployed. Conference invitation functionality is available to the Asterisk operators, which may be sent to any PSTN or SIP phone. A conference control service is also available in experimental status, displaying conference participants’ names on the web.



Final 14

c) Furthermore, Asterisk provides for voicemail, with “message waiting" notifications, if these are supported by the SIP UA. Extension owners are notified of waiting messages by e-mail, or may option to receive voice attachments via e-mail.

d) Phone directory. This is an interactive directory service on Asterisk, searchable by the first three letters of the users’ last name.

e) Call queuing and music-on-hold.

Various SIP UAs have been tested on this system. Whilst most user agents perform adequately over the LAN, few of them perform well in the wide area, thus UCL integrated the IPv6-capable RAT with SIPSet to provide good audio quality over the wide area 6net in all the scenarios described below. Kphone, and Linphone have also been used with IPv6, as well as other IPv4 UAs available at our site, such as the Cisco 7960 and X-lite.

Furthermore, H.323 to SIP interconnection has been achieved through Asterisk. This means that H.323 terminals such as GnomeMeeting can now be called either in a one-to-one conversation from an IPv6/IPv4 SIP phone, or to a voice conference via the MeetMe service. As GnomeMeeting and openGK (the H.323 GateKeeper) are both IPv6 enabled, users will be able to place native IPv6 calls between SIP and H.323 terminals when Asterisk is fully IPv6 capable. Currently, the MSP gateway shown in Figure 4 is used for such interconnection as well as for SIP-to-SIP IPv4/IPv6 calls via SER and Asterisk. In these cases, SER’s routing logic directs an IPv6/IPv4 UA to the MSP, and the MSP in turn to the IPv6/IPv4 UA or to the IPv4-only Asterisk.

UCL has also deployed an Openh323 MCU for access over IPv4 and IPv6, which has been used extensively for GnomeMeeting H.323 based meetings between UCL and UoS.

User database registration is now being investigated for authorised access to the VoIP system. This will also facilitate user/extension management, as well as call logging and possibly billing for PSTN usage. We plan to use the system for 6net voice conferences in 2005.

In the future, integration of the IPv6-enabled vic with SIPSet could be investigated to allow interconnection with H.323 videophones via Asterisk. SMS message notification may also be added.

4.2 Fraunhofer

4.2.1 Fokus 6net VoIP system environment For 6net testing a test-bed was set up consisting of components required for IPv6/IPv4 VoIP translation purposes.



Final 15

DFN / 6net

Figure 5 FhG VoIP system architecture

To provide a VoIP solution for heterogeneous IPv4/IPv6 environments a SIP-based VoIP infrastructure was developed by Fraunhofer Fokus consisting of:

VoIP signalling infrastructure: Establishing a VoIP session involves the exchange of signalling messages as well as the authentication and registration of users. A platform widely used in the Internet by various commercial ISPs and ASPs is an open-source project under the name of the SIP Express Router (SER) which is well known for its flexibility and robustness. To support VoIP communication in IPv6 networks, SER was extended by FhG to support IPv6 as well (for further details cf. description above).

VoIP soft agents: To enable a user to actually start a VoIP call, he can either user a dedicated IP-based phone or a software tool running on a PC. To enable IPv6 communication, in the 6net project an open-source VoIP tool called KPhone was extended by FhG to support IPv6 (for further details cf. description above).

Translation mechanisms: As shown in the figure, to support communication between IPv4- and IPv6 users, some means of translating SIP messages between the two worlds is needed. For this reason, a translating gateway (MSP) was developed by Fokus that translates SIP messages so as to allow IP4- or IPv6 SIP devices to communicate with each other without requiring any additional intelligence, and translates the media traffic (RTP) between IPv4 and IPv6 networks (for further details cf. description above). (MSP work description to be appended in the Annex? It’s an excerpt of Jens’ diploma thesis, about 60 pages)

Kphone IPv6

FreeBit IPv6 / IPv4

SER IPv6

PSTN hard- / softphones

PSTN Gateway

H.323 MCU

IPv6

GnomeMeetingVC client

IPv6–IPv4 MSP

Gateway

SER IPv4



Final 16

VoIP hard phone user agent: Besides the soft agents that were developed by FhG Fokus, the 6net VoIP activities were complemented in Q4/2004 by the first IPv6 hardware phones available on the market. Mid 2004 FreeBit Co., Ltd. of Japan, started offering IPv6 centrex service as part of it’s regular FreeBit OfficeOne telephony service4. In order to assess usability, interoperability and performance of the IPv6 telephones used in this service, some telephone sets of this type, which also support IPv4, developed and supplied by Iwatsu Electric Co., Ltd., an industry leader in SIP technology and parent company of Iwatsu America had been deployed within 6net. These phones are used in the context of 6net as VoIP terminals for tests and demonstrations as well as for the communication between the 6net partners (for further phone details see Appendix A).

PSTN-Gateway

Fraunhofer Fokus has also deployed an Openh323 MCU for access over IPv6, which has been used for GnomeMeeting H.323 based meetings (cf. 3.1.4).

GnomeMeeting: An openh323 based H.323 IPv6 client.

4.2.2 IPv6 enabling of Iptel.org Besides the establishment of the Fokus VoIP test-bed mentioned above, which was intended to serve mainly as an environment specifically dedicated to the needs of the 6net project, the popular iptel.org website was also IPv6 enabled in parallel to achieve a wide public exposure. As a public presentation platform, www.iptel.org allows IPv6 users to access a VoIP server, request a VoIP identity and use a number of services such as call logs, voicemail and the like. Using the allocated VoIP addresses, users can utilize the VoIP service from their IPv6 networks.

4.3 JOIN JOIN deployed an IPv6/4 OpenH323 MCU, and gnomemeeting clients, for use in meetings and demonstrations.

4.4 Poznan Poznan deployed an IPv6/4 OpenH323 MCU, and gnomemeeting clients, for use in meetings and demonstrations.

5 Demonstrated systems 5.1 6net Spring 2004 conference At the 6net spring 2004 conference UCL, in conjunction with Fraunhofer Fokus demonstrated a SIP infrastructure slightly different to that described in Section 4.1. In this setup UCL configured separate IPv4 and IPv6 SER servers and used the MSP to provide integration. The client used for the demonstration was kphone, which was found to have some problems on loaded wide area links. Thus this demonstration paved the way for a more tightly integrated demonstration at IST2004.

In an adjoining booth at the 6net Spring 2004 conference JOIN, UoS and other 6net partners demonstrated the OpenH323 MCU with Gnomemeeting clients on IPv4 and IPv6.

5.2 IST2004

4 http://www.freebit.com/english/

http://www.freebit.com/english/



Final 17

At IST2004 in the Hague, UCL, in collaboration with Fraunhofer (FhG) Fokus, demonstrated the SIP based VoIP system described in Section 4.1, showing full IPv6-4 in-operation.

The UCL demonstration showed a number of scenarios in conjunction with three sites: IST2004, FhG and UCL. The scenarios included:

• IPv6-to-IPv6 Point-to-Point Communication

• IPv6-to-IPv4 Point-to-Point Communication, using MSP IP6-4 gateway.

• IPv6 and IPv4 Group Communication, using MSP in conjunction with Asterisk Meetme conference server

• IPv6-to-PSTN Point-to-Point Communication, using MSP in conjunction with Asterisk PSTN gateway

In the “IPv6 home”, at IST2004, JOIN and other 6net partners demonstrated the OpenH323 MCU with Gnomemeeting clients on IPv4 and IPv6.

6 Conclusions The deployed systems have demonstrated the versatility and functionality available from VoIP systems, operating seamlessly between IPv4 and IPv6 environments. The deployed architectures have evolved over the time span of the project to provide a fully integrated multi-protocol environment. These services are already in use within the project and their use is expected to be expanded.



Final 18

Appendix A – Freebit IPv6/v4 hardware phone

1 FreeBit IPv6 / IPv4 phone manual

1.1 Overview and functions

1.2 Rear side



Final 19



Final 20

1.3 Default assignment of function keys

1.4 FreeBit phone setting options



Final 21

Tree level

1 2 3 4 5 Description Config.

Requir.

IP Address IP address of the terminal No Auto IP Set View Prefix Prefix of the terminal No

Stateless IP Set

Auto IP Set Perform DHCP No

Phone IP Address

Stateful IP Set No DNS Svr 1 IP IP address of DNS 1 No DNS Server 1 DNS Server 1 Domain name of DNS 1 No DNS Svr 2 IP IP address of DNS 2 No DNS Server 2 DNS Server 2 Domain name of DNS 2 No

Retry count No Retry Interval No

DNS

Use Cache No Set Phone Number Phone number of the terminal only in digits

(Terminal ID) Yes

Tyme Sync Reg Svr Sync Phone time automatically synchronized to Registrar server

No

SNTP Svr Sync Phone time automatically synchronized to SNTP server

No

No Sync Phone time manually set No Offset Value No

Manual No LAN Port Auto Negotiation No Manual No

Link Mode

PC Port Auto Negotiation No

Basic Setting

Network MTU No Holding Mode No DTMF Mode No Offer Codec G.711 u-law only is supported No QoS VLAN Tag No Number Display No No. Notification No Touchtone No Howler Tone No Select Send Key No Firmware Update Firmware update at start-up of the terminal No Update @Startup Data update at start-up of the terminal No Contrast No HS_KIND No

Optional Setting

Key Appearance No Prxy Server 1 IP

IP address of SIP proxy 1 Yes

Prxy Svr 1 Port#

Port number of SIP proxy 1 Yes

Proxy Server 1

Proxy Server 1 Domain name of SIP proxy 1 No Prxy Server 2 IP

IP address of SIP proxy 2 No

Prxy Svr 2 Port#

Port number of SIP proxy 2 No

Proxy Server 2

Proxy Server 2 Domain name of SIP proxy 2 No Reg Server 1 IP IP address of Registrar 1 Yes Reg Svr 1 Port# Port number of Registrar 1 Yes

Register Server 1

Register Svr 1 Domain name of Registrar 1 No Reg Server 2 IP IP address of Registrar 2 No Reg Svr 2 Port# Port number of Registrar 2 No

Register Server 2

Register Svr 2 Domain name of Registrar 2 No Outbnd Prxy IP IP address of Outbound server (Field not used) No Outbnd Prxy Pt#

Port number of Outbound server (Field not used) No

SIP Setting

Outbound Server

Outbound Server

Domain name of Outbound server (Field not used) No



Final 22

Request Port No Phone Password Terminal password (only in digits) Yes

Registered Time

Registration interval (Initial value = 60min) No

Refresh Refresh interval (Initial value = 30min) No Refresh Failed No

Reg Options

Registration No

SIP URI Display SIP URI No Maint Server IP IP address of Maintenance server No Maint Server Maint Svr Port# Port number of Maintenance server No TFTP Server IP IP address of TFTP server No TFTP Server TFTP Server Domain name of TFTP server No

Maint Setting

Session Time Value of Session timer No Send Ping No Logout No Firmware Update No Erase User Data No

Tools

Restart Phone Restart the phone No



Final 23

Appendix B – Report on the IPv6/IPv4 SIP gateway

1 Introduction This report details the design and implementation of the IPv6/IPv4 SIP gateway used in the 6net project. The report details the protocols specifics and mechanisms relevant to the design and implementation of the IPv4/IPv6 SIP gateway.

1.1 VoIP requirements

1.1.1 Real-time transport and control protocol The real-time transport protocol (RTP) [16] and the real-time transport control protocol (RTCP) are used to realize VoIP communication between participating parties. RTP is the bearer protocol which carries the audio data and RTCP is used for exchanging status information about latency, packet loss, etc. Both are based on the user datagram protocol (UDP), so are unreliable as well.

Audiodata

sender

Audiodata

receiverMicrophone

Speaker /Headphones

RTP

RTCP

Host A Host B Figure 6 RTP / RTCP directions

Data sent by RTP must be encoded using a standardized codec from the audio video profile (AVP) [6] or a custom codec. Codecs can be classified in terms of audio quality, required bandwidth, number of channels (mono vs. stereo) and latency. It is necessary to choose a codec for transmission that fits the communication environment.

When two telephones communicate via RTP/RTCP it is basically not necessary that they encode their audio streams with the same codec. This way it is possible to match the provided bandwidth capacities, which can be asymmetric, i.e. upload and download speed need not to be the same, e.g. asymmetric digital subscriber line (ADSL). Figure 7 depicts the layout of the RTP header.

V CC Payload Type Sequence NumberTimestamp

Synchronization source (SSRC) Identifier

0 1 2 3 4 5 6 7 8 9 10111213141516171819202122232425262728293031

P X M

Contributing source (CSRC) Identifiers….

Figure 7 RTP header

• The RTP header holds a version field (V) which is 2.



Final 24

• The padding bit (P) is 1 if there are padding bits present at the end of the RTP packet. In this case the last padding byte, which is also the last byte in the packet, holds the number of bytes the padding contains and which can be thrown away.

• If the extension bit (X) is set, the static header is followed by an extension header. • The contributing source counter (CC) hold the number of contributing source (CSRC)

header fields in the header. • The marker bit (M) can be used to mark the packet. The semantics for marking packets

depend on the applications and the used payload type. For instance it is used to mark frame boundaries.

• The payload type identifies the format of the audio data following the header and extension headers. There is a default static mapping defined by AVP between payload type numbers and formats, i.e. codecs and parameters. These mappings can be redefined and extended implicitly or by explicit signalling.

• The sequence number is incremented by one for each RTP packet sent. Thus it is the number of the packet in the audio stream. The sequence number is used to detect packet loss. A receiver that gets a packet with a higher sequence number than expected can assume that there is packet loss and can compute the number of lost packets.

• The timestamp indicates to which time point the first byte in the packet body belongs to. Timestamp and sequence numbers are not linear dependant, because in a period of silence the timestamp keeps on increasing while the sequence number does not, as there are no packets transmitted during the silence period.

• The synchronizations source (SSRC) header field identifies the sender of the packet. It is an opaque number which is chosen by the sender which makes sure that it is unique.

• The up to 15 contributing source (CSRC) identifiers name the source identifiers of other sources which have contributed to the media stream. They are also opaque numbers chosen by the contributor.

An instance which mixes multiple audio sources usually receives RTP packets from the original source instances and merges them into one audio data stream. To keep the identities of the originating sources, their SSRC identifiers are transmitted as contributing source identifiers by the mixing entity, because they took part in the creation of the audio data. This allows the receiver of the mixed audio data stream to identify the original senders of the audio stream. The mixer transmits its own source identifier as SSRC. Figure 8 depicts this process.

MixerSSRC=4556

Audiodata

receiver

Audiodata

sender #1SSRC=4123

RTP

Audiodata

sender #2SSRC=56673

Audiodata

sender #3SSRC=31337

RTP

RTP

RTPSSRC=4556CSRC=4123CSRC=56673CSRC=31337

Figure 8 Mixer using SSRC and CSRC

Senders and receivers periodically exchange information about the amount of sent and received data as well as the loss and delay faced by the data.



Final 25

1.1.2 Session description protocol The session description protocol (SDP) [4] is a text based protocol which is used to describe the address and port number where the originator of the message wants to receive audio data and which formats it supports and is able to decode. SDP is defined for IPv4 and for IPv6. SDP messages are composed of text lines. Each line starts with an identifier introducing the function of the following parameters followed by an equality sign. The most important identifiers are:

v= Protocol version number. Must be the first line in the SDP message.

o= This identifies the originator of the message. The first parameter is a username, followed by a session id and a version. If there are multiple SDP messages concerning the same session, the version number must increase to make clear, which of the announcements is the most recent and thus valid. The version is followed by the network type the originator resides in, which is usually “IN” for internet. Then follows the address type identifier, which is either “IP4” for the old internet protocol (IP) or “IP6” for the internet protocol version 6 (IPv6). This defines the protocol by which the originator can be contacted and the format of the following address, which can be an IPv6/IP address or a fully qualified domain name (FQDN).

s= Name of the session or subject of the call.

t= Start and stop time when the session is active. The values are the decimal representation of network time protocol (NTP) [5] time values in seconds.

m= This introduces the definition of a supported media. It is followed by the media type, e.g. “audio”. Then the port number or range is defined. After this the transport method is defined which is usually “RTP/AVP” which means that the following formats shall be transported using RTP and follow the audio visual profile (AVP).

c= This specifies the connection address for media. If it is found before the first m= line, it is valid for all following m= lines. If it is found after a m= line, it is valid only for this media definition. The connection address is specified in the same way as in the originators field, using network type, address type and connection address.

Example of a SDP message:

v=0

o=jfi 2890844526 2890842807 IN IP4 193.175.135.177

s=SIP initiated call

t=2873397496 2873404696

m=audio 9020 RTP/AVP 0

c=IN IP4 193.175.135.177

This SDP example message announces a session coming from the user “jfi” at the host with the address 193.175.135.177 who wishes to receive audio data using RTP at port number 9020 and implicitly RTCP at port number 9021. The format number 0 follows the audio visual profile which states that format number 0 defines the PCMU encoding at 8 kHz sampling rate with one channel (mono).



Final 26

1.1.3 Session Initiation Protocol The session initiation protocol (SIP) [1] is used to negotiate session parameters before media data is exchanged, and to control the modification and termination of the exchange. It exchanges information about the protocol to use to encapsulate media data, the type of involved media, e.g. audio or video or both. It is used to negotiate the number of participants and the encoding of the media data, i.e. which codec to use. It also identifies the unicast or multicast IPv6/IP addresses and port numbers to use for the media encapsulating protocol.

SIP is a text message based protocol. This means that any atomic action is executed by sending a single message. Because of this property, SIP messages are sent using UDP. The problem with this is the unreliability of UDP as a transport protocol. An application which uses SIP over UDP must take care of reasonable retransmission for the case that no answer is received in time. SIP is specified for UDP and for TCP.

SIP messages can be divided into two categories: requests and responses. A request is always the first message sent to initiate a transaction like setting up a call or call termination. Responses are the answers to a request. Responses also acknowledge that the request has reached its target. A request starts a specific transaction like call initiation or termination. The transaction is terminated when a final response is received. There can be any number of provisional responses before a final response is received. It is possible to abort a transaction. For this another request must be issued by the transaction initiator.

SIP uses a special form of unified resource identifiers (URI) [3] to identify a user, his location and worldwide valid name. A SIP-URI starts with the phrase “sip:” followed by a username and a location. The location can be an IPv4 or IPv6 address or a hostname or only a domain-name. The following list shows example SIP-URIs. sip:[email protected]:5060

Specifies “jens.fiedler” as username, “iptel.org” as domain-name and 5060 as UDP port number where SIP messages must be sent to.

sip:82071@[2001:7a0:105:3:18be:8ecb:1a08:affe]:5062

Specifies “82071” as username, the IPv6 address “2001:7a0:105:3:18be:8ecb:1a08:affe” and 5062 as UDP port number for SIP messages.

Each SIP request carries a request method, indicating the purpose of the request, and a request-URI which addresses the recipient of the message. Each response carries the response code and a textual representation of the reason for this response.

Encapsulated in the SIP message there can be small payloads of additional signalling data located in the body of the message. In fact this is the point of interest where negotiation about audio data encoding and the involved addresses and port numbers takes place. SDP messages are located in the body of the SIP messages, carrying the networking information for audio communication.

1.1.3.1 SIP Header fields and request types A SIP message is composed of exactly one head line and an arbitrary number of header fields which serve different purposes. The head line determines the type of the message, to be a request or a response to a request. A request head line holds the method name of the request as well as the recipients SIP-URI, while a response head line holds the three digit response code and a textual phrase describing the reason for the response. The URI in the request head line is also referred to as the request-URI. Every request-URI can hold an IPv6/IPv4 address as host part of it. Table 1 lists



Final 27

and describes the relevant request methods, which are specified in RFC 3261 (SIP) [1]. A header field consists of a header field name, followed by parameters, which are specific to the header field. Table 2 explains the most important header fields.

Method name

Description

REGISTER This request is sent to a registrar to register the user whose SIP-URI is specified in the “To:” and “From:” header fields, which must be the same, with the SIP-URI encoded in the “Contact:” header field (see below), where he is currently available. So this request type establishes the association between a globally unique SIP-URI with a local end device.

INVITE Invite the user in the “To:” field for a session or, if the session is already existing, try to modify session parameters. This is used for establishing a call or e.g. to mute a call. This request type can carry session description information.

ACK Acknowledge the response which was received upon an INVITE-request. This is the only purpose of this request method. It cannot be used to initiate a transaction. This request type can carry session description information when used during a transaction which establishes a session.

CANCEL Abort the transaction this request refers to by its “CallID:”, “To:” and “From:” header fields. This request can only be used within an existing transaction. It cannot be used to initiate a transaction, like call termination.

BYE Shutdown a session; means to terminate a call; to hang up the call respectively. It usually the last request during a SIP session.

Table 1 SIP request methods

Header field name

Purpose

To The SIP-URI of the recipient of the call. This identifies the called party during the ongoing call. The URI in this header field can hold an IPv6/IP address as host part of it.

From The SIP-URI identifying the originator of the message. This must be independent of the currently used end device. So it should contain the users global SIP-URI.

Contact The SIP-URI of the sender, where he wishes to receive subsequent requests concerning this session. This is not necessarily the same as the “From” header field. The Contact identifies the user with his device, he is currently using.

CallID Globally unique identifier which identifies this session.

Record-Route A proxy may insert a “Record-Route” header field to make sure that subsequent requests will also pass this proxy. The parameter is a SIP-URI which identifies the proxy itself. The sequence of such header fields forms the route set which must be used in every subsequent request.



Final 28

Route Route header fields are the results of previously exchanged “Record-Route” header fields. They are shipped with every subsequent request message and hold the list of proxies that have formerly inserted “Record-Route” header fields in order to receive every message of the ongoing session.

Via The “Via” headers record the proxies that a request passes. Responses must be sent the same way back. This is done by adding a top-most “Via” header when forwarding a request and remove it when forwarding a response.

Table 2 SIP header fields

SIP uses registration based user location. Because a caller does not know where the requested user is currently located, it needs to ask someone who knows. This is done by the registrar server of the domain the called user belongs to. In the following the different types of SIP instances are explained.

• Registrars are basically a database which holds the association between the usernames of the domain and the currently valid IP address assigned to the user. This IP address usually belongs to a telephone or other media terminal.

• SIP proxy servers simply forward the request to the address encoded in the requests URI. Proxys return provisional responses while waiting for the response from the host where they sent the request to. They can also cache information about invalid SIP-URIs, for which already a negative response has been seen.

• A SIP redirect server that receives a SIP request for a certain user queries the registrar for that user. But instead of forwarding the request to the URI that was obtained, it replies to the originator of the request with a response, which tells him to re-send the request to the obtained address.

• The SIP user agent is located in end devices like a telephone. It is used by the user to initiate calls, modify and terminate them and to do user registration with a SIP registrar.

• A back to back (B2B) user agent is usually located at the borderline of two administrative domains. It behaves like a normal user agent to both sides of the borderline. It reacts to requests from one side by replying with the necessary responses and issuing new requests to the other side of the borderline. The difference to forwarding the requests and responses is that with forwarding only one transaction and only one call is affected, while the B2B user agent handles two transactions and calls because it terminates the call signalling on the one side and starts a new call signalling on the other side of the borderline.

It is possible that a SIP capable server does more than one of the above described jobs. For instance it is typical that registrar and proxy functionalities are bundled in one instance.

SIP is used exclusively for session management and not for media data transport. Thus signalling messages and media data packets can have different routes through the internet. Figure 9 depicts a typical SIP session initiation message flow and shows that media and signalling data can take different paths through the network.



Final 29

End Users

SIP Proxy

End Users

RouterMedia Packets

Signaling Packets

SIP Registrar

Figure 9 SIP and RTP message flow

1.1.3.2 Sessions, Transactions and Dialogues SIP was designed to set up, manage and terminate arbitrary session, not only VoIP telephony calls using audio or video. Thus SIP could also be used to set up online gaming sessions or similar sessions. So the term “Session” will be used to describe internet telephony calls.

In order to establish, manage and terminate a session, transactions are used. A transaction is a flow of SIP messages which serves the purpose of the specific transaction, like muting or terminating the session. A Transaction consists of at least one request and one response, but can also consist of a large number of messages, depending on the decisions taken by the communication partners.

Thus transactions are more complex than their name might make one think off. That is why transactions are broken down into multiple dialogues. A dialogue in terms of SIP is the simplest message interchange between two SIP entities, while the transaction can involve a larger number of entities and thus dialogues.

Figure 10 shows the dependencies between a session, transactions and dialogues. In this example the user A wants to talk to the user who is registered with phone B and phone C. So user A sends an INVITE request to the proxy, which forwards the request to phone B and C, establishing 2 dialogues. Phone B answers with a negative response, whilst phone C accepts the call. Both dialogues are terminated by the ACK request. All this forms the initial transaction. The session termination follows the same scheme. Phone A issues a BYE request, which is confirmed by phone C. Only one dialogue is involved in this place. Then the session is over.



Final 30

Phone A Phone B

Phone C

Sess

ion

Prog

ress

Proxy

INVITE INVITE

INVITEACK

200 OK

200 OK

403 Forbidden403 ForbiddenACK

BYE200 OK

Figure 10 Dialogues and transactions

1.1.3.3 Loose routing If a proxy wishes to receive all subsequent request messages in an ongoing session it inserts a “Record-Route” header field, which identifies the proxy by a SIP-URI. Every proxy must insert its “Record-Route” before the first already existing “Record-Route” header field. Thereby the receiver of the request gets a list of intermediate proxies in the reverse order by which they were passed by the request. The receiver will then send back all “Record-Route” header fields in the same order to the originator with the next response message. Figure 11 depicts the message flow of a request which is subject to record routing and shows the relevant header fields in a simplified manner and their ordering inside the message.

Phone1 Phone2Proxy1 Proxy2

INVITE user@Phone2 INVITE user@Phone2Record-Route: Proxy1

INVITE user@Phone2Record-Route: Proxy2Record-Route: Proxy1

SIP/2.0 200 OKRecord-Route: Proxy2Record-Route: Proxy1

Proxy2Proxy1

resultingRoute set:

Proxy1Proxy2

resultingRoute setafter turningit over: SIP/2.0 200 OK

Record-Route: Proxy2Record-Route: Proxy1SIP/2.0 200 OK

Record-Route: Proxy2Record-Route: Proxy1

Figure 11 Record-Route message flow

When the originator receives the response to his request, it will find a list of “Record-Route” header fields in the response. It will reverse the list and make it his set of routes for this session. Thus each



Final 31

route set reflects the order in which each phone has to address the intermediate proxies with the next request.

When a phone thereafter sends a new request message, it will insert “Route” header fields into the request message. The “Route” header fields are constructed from the Record-Route set and reflect the same ordering as the route set. Instead of sending to the request URI in the head line, the phone will send the request to the SIP-URI in the first “Route” header field. The proxy will then remove that first “Route” header fields, which identifies itself, and process it in the same way as the phone, which means to forward it to the SIP-URI in the first “Route” header field. Only if there is no such “Route” header field, it will forward it to the request URI. Figure 12 depicts this message forwarding by showing the involved header fields in a simplified way.

Phone1 Phone2Proxy1 Proxy2

BYE user@Phone2Route: Proxy1Route: Proxy2

Proxy1Proxy2

route set:

BYE user@Phone2Route: Proxy2

BYE user@Phone2

Figure 12 Route message flow

This introduced routing mechanism is called “loose routing”. There also exists a method called “strict routing” by which the route set and the request URI are not separated but intermixed. Strict routing demands that each route appears in as request URI, which is the rewritten by the strict routing proxy with the next proxy address or the final request URI, which is stored in the top most “Route” header field. Thus a phone must know whether the next proxy does strict or loose routing, because it needs to set up the request URI and “Route” header fields in a different way.

1.1.3.4 User registration SIP is used to enable users to keep their symbolic addresses as they move from one terminal to another. When starting the telephony application, a user registers with his well known SIP registrar.

The user’s SIP-based application sends a “REGISTER” request to its registrar. It holds the local machines address or name in the “Contact” header field. Both of the “To:” and “From:” header fields hold the users SIP address by which he is known to the rest of the world, e.g. sip:[email protected].

This request is confirmed with an “OK” response from the registrar. From there on any party that queries the registrar for this user can retrieve its current point of availability e.g. for call initiation. The normal mode of operation is then to send “INVITE” requests for that user to its proxy, which then looks up the real contact address and forwards the request to this address. The alternative mode of operation is called “redirect”, which is described above.

1.1.3.5 Call initiation

The “INVITE” request method is used to start a session. The sender of the “INVITE” request waits for an “OK” response from the called party. In this phase he may receive provisional responses from an intermediate proxy, which inform about the state of the transaction. This involves “Trying” responses, which means that the request was forwarded. The called phone may also send



Final 32

provisional responses, before the final response is generated. Then he sends the final “ACK” request which needs no response. The “ACK” request is sent directly to the callee’s phone, as the caller learns the phones address from the “Contact:” header field in the “OK” response from the callee’s phone. The following figure depicts involved peers and messages.

Call initiator Call receiverProxy

“INVITE” request

Forwarded “INVITE” request

Provisional responses

200 OK response

200 OK response forwarded

Final “ACK” request

bidirectional peer-to-peer RTP/RTCP audio communication

Figure 13 Call initiation message flow

The “INVITE” request is forwarded by the call receivers’ proxy. The proxy will modify the request URI in the header to the current valid location of the called user. Upon reception of the “INVITE”, the phone starts ringing. At this stage the called phone generates provisional responses which tell the originator that the phone is ringing and to wait for the receiver to pickup the phone. When the called user picks up the phone, an “OK” response is sent back to the proxy, which forwards it to the originator of the preceding “INVITE” request using the build up “VIA” stack. The session description of the sender, indicating which media to use and where the sender wants to receive it, is encoded in the body of either the “INVITE” or the “ACK” request. The session description of the called party is in the body of the “OK” response. Both use SDP for session description.

1.1.3.6 Call modification After a call has been established, it can be modified by sending another “INVITE” request related to the same call. This type of transaction is also known as “RE-INVITE”, although there is no such method name defined in SIP. This is one way to mute a peer. When one partner wants the other one to stop sending audio data, it simply signals an empty receive address in the SDP body. The empty IPv4 address is 0.0.0.0 and for IPv6 it is ::, which expands to 128 zero bits. The message flow is the same as for initial call set up with the exception that there does not need to be audio communication after the SIP message exchange. This way of muting is called “end-to-end muting” because both parties know about the muting. The opposite is “one-end muting” which does not involve any SIP transactions, because with that method only the local microphone is switched off by the audio driver, thus delivering only digital silence to the application.

1.1.3.7 Call termination To terminate an existing call party A sends a “BYE” request concerning the active call to party B using either the original SIP URI or the contact address obtained from one of the previous responses. The “BYE” request requires confirmation, so party B needs to send back an “OK” response. Figure 14 shows the message flow for the case that party A has defined an outbound



Final 33

proxy, which means that every message from party A must pass this proxy. Because party A has learned the contact address of party B in the previous dialogues, it could also send the “BYE” request directly to party B, bypassing the proxy.

Party A Party BProxy

“BYE” request

Forwarded “BYE” request

200 OK response

200 OK response forwarded

Figure 14 Call termination

1.2 IPv6/IPv4 VoIP translation problem analysis

In this chapter the problem scenario is described in detail, as well as known techniques to overcome the IPv6/IPv4 translation gap. The scenario consists of several entities which are introduced as well as their relations among each other. Overcoming the IPv6/IPv4 barrier means that devices which support IPv4 only can communicate with devices which support IPv6 as their only network protocol. The section about known techniques discusses also the suitability of each technique for SIP based VoIP communication.

1.1.4 Problem description Basically the problem is comparable to two people who speak different languages and need to talk to each other. In terms of SIP and VoIP communication the problem is more complex as also signalling is involved.

1.1.4.1 Scenario and players The usual SIP scenario consists of a number of domains which serve a number of telephones which are used by a number of users. For the purpose of this work it is useful to imagine that such a telephone device can do either IPv4 or IPv6, but not both. This assumption is realistic, because a device that can do both protocols at the same time, also needs two addresses at the same time. It would need an IPv6 address to communicate with IPv6 devices and it would need an IPv4 address in order to talk to IPv4 devices. This would completely abandon one of the greatest benefits of IPv6, which is the large scale of addresses. The need to have an IPv4 address for each IPv6 end device would limit the number of IPv6 devices to the same number of available IPv4 addresses. The idea of supporting both protocols in an end device is thus not suitable. So the scenario has its first two players, an IPv6 based phone and an IPv4 based one.

These phones usually register their users address with their registrar server. This can be the same server, but in order to reflect a real world scenario it is suggested that they might belong to different administrative domains, with each domain having its own registrar. These registrars, which also act as SIP proxy for their phones are the other two players in the problem scenario. A phone can be configured to use a SIP proxy server for all its outbound messages. Some domains insist on using their own proxies for all messages in order to do charging of calls to e.g. PSTN gateways.

So both phones cannot interchange SIP messages directly, because they use different network protocols, and they cannot interchange RTP based audio information for the same reason. The



Final 34

involved communication paths are as follows. When the user at the IPv6 phone wants to call the user at the IPv4 phone he would enter its global SIP-URI to his phone. In this case the IPv6 phone would try to contact the SIP server for the domain of the IPv4 user. This will fail, because they use different network protocols. Even if the IPv6 phone would use its own proxy server to forward the message, the proxy would have the same problem. And even if this would work for some strange reason, then the audio communication between the two phones would fail, as they do not use the same protocol. The audio communication path cannot use the SIP proxies, as SIP cannot transport media streams. The introduced scenario will be very realistic in the near future, because with the upcoming of more and more IPv6 internet service providers (ISP), the number of IPv6 based VoIP phones will rapidly increase. While other users keep their IPv4 devices and ISPs, both groups of users will have the urge to call each other. So this problem is going to be solved, which is the scope of this work. Figure 15 illustrates the initial situation.

IPv6 domain IPv4 domain

Phone Phone

SIP proxy SIP proxy

SIPSIP

SIP SIP

SIPSIP

SIP SIP

SIP & RTPSIP & RTP

Figure 15 Basic scenario

1.1.4.2 Problematic SIP and SDP components SIP makes heavy use of network layer addresses within the SIP messages. As introduced in section 1.1.2, SIP uses various header fields which hold SIP-URIs. Every SIP-URI can consist either of an IPv4 address, an IPv6 address or a symbolic name, which then expands to an IPv4- or IPv6 address. This section shows that certain header fields carry signalling information, which are interpreted by the end devices and proxies to continue communication. In the following each affected SIP component is explained.

1.1.4.2.1 Request URI The request URI is part of the head line of every SIP request message. It identifies the next recipient of the message. So whenever e.g. an IPv4 based phone tries to route a message to an IPv6 based request URI, it will fail to do so.

1.1.4.2.2 “From” header field The “From” header field identifies the originator of the call. Usually the SIP-URI in this header field is a global, symbolic name. SIP messages are never routed directly to this SIP-URI. Thus the contents of this header field is not an IPv6/IPv4 conversion issue. A recipient of a message usually uses this header field to identify the calling person and apply measures in case the user does not



Final 35

pick up. Measures can be to forward the call, or to automatically accept the call and start a kind of answering machine, etc.

1.1.4.2.3 “To” header field The “To” header field identifies the receiver of the call. It holds his global SIP-URI, which is usually a symbolic name. Request messages are never sent directly to the SIP-URI, which is stated in this header field. The receiving phone of the message will check the “To” header field, if the contained SIP-URI specifies a user, that is currently registered at this phone. Thus the “To” header must not be modified by any means while travelling through the VoIP infrastructure, in order to enable the target phone to do its checks.

1.1.4.2.4 “Contact“ header field The “Contact” header field holds the SIP-URI for the current session. So when a phone sends an “INVITE” request to establish a session, it also sends a “Contact” header fields whose SIP-URI identifies the calling phone, so that subsequent request, which are then issued by the called party, can be sent directly to the phone instead of going through the proxies and registrars. So the content of this header field is problematic, as a IPv6 based phone would encode its IPv6 based SIP-URI within this field. A receiving IPv4 phone could never be able to address this phone directly and would break communication.

1.1.4.2.5 “Via” header field The list of “Via” header fields holds the list of SIP proxies that a request message has traversed before it arrived at the recipient. Every SIP instance in the path of massage will insert its own address on top of the other “Via” header fields. So for the routing of the request this is not a problem, but if it comes to the routing of reply messages, it is a problem. An IPv4 phone that somehow received a request from an IPv6 SIP proxy, would try to send the reply to the address in the top most “Via” header field. This would be an IPv6 address and thus not addressable for the IPv4 phone.

1.1.4.2.6 “Record-Route” and “Route” header fields Every intermediate proxy, that wants to have subsequent requests to also pass through it, inserts a “Record-Route” header field to the request before it forwards it. The receiver of the message will then send back all “Record-Route” header fields in the next response and store them as the route set which is associated with this session. Subsequent requests will then carry this list in the “Route” header field, and every proxy that is listed in this route set will remove its own “Route” header field from the message. “Record-Route” headers do not cause problems inside the end devices, because no networking actions are to be taken while turning the “Record-Route” list into the route set. The only thing that needs to be made sure is that the first route, that an end device has its route set, matching the protocol family of the phone itself.

Phone1(IPv6)

Phone2(IPv4)

Proxy1 (IPv6) Proxy2 (IPv4)

INVITE user@Phone2INVITE user@Phone2Record-Route: Proxy1

INVITE user@Phone2Record-Route: Proxy1

Proxy1

resultingRoute set:



Final 36

Figure 16 Problematic Record-Route flow

Figure 16 depicts a scenario where this is going to be a problem. In this case Proxy1 inserts a “Record-Route” header field, while Proxy2 does not do so. As a result Phone2 would have Proxy1 as its only route in its route set and would try to send a subsequent request message to the IPv6 proxy, which will fail.

1.1.4.2.7 The SDP body When setting up an audio call between two phones, SDP blocks are exchanged during the initial call set up transaction. Each SDP block holds a network address where the originator of the SDP block wants to receive audio data. An IPv6 based phone would thereby send its IPv6 address and port number in its outbound SDP block, demanding an IPv4 based phone to send audio to an IPv6 address, what it cannot do.

For instance, the following SDP block could be generated by an IPv6 based phone: v=0

o=jfi 2890844526 2890842807 IN IP6 2003:2334:6be:533a:6bde:871:897:4aec

s=SIP initiated call

t=2873397496 2873404696


c=IN IP6 2003:2334:6be:533a:6bde:871:897:4aec

A phone that cannot do IPv6 will not be able to send audio to this phone. Thus the audio connection would be broken, and the phones would stay quiet.

1.1.5 Known techniques This section will give an overview of existing techniques and ideas on how to overcome the IPv6/IPv4 barrier. Each technique is analyzed for its suitability with SIP based VoIP. None of these techniques can solve the problem by their own. In every case additional components will be necessary to have a complete solution for the problem.

1.1.5.1 Dual stack The “Dual Stack” means that a network instance, like a proxy or phone, can deal with both protocols, IPv4 as well as with IPv6. A user application, that wants to use e.g. UDP, must decide, whether to do this over IPv4 or over IPv6. The benefit from this is that the transport layer protocols are the same for IPv4 and IPv6. Modern VoIP phones will be capable of using a dual stack in order to support both protocols at the same time. Figure 17 shows how the protocol entities fit together in an operating system.



Final 37

IPv4 protocolstack

IPv6 protocolstack

Interface to network layer

Interface to network devices

Interface to hardware

Network deviceDriver

(e.g. ethernet)

UDP TCP

Interface to transport layer

Figure 17 Dual stack

A dual stacked machine has one major drawback, which is the fact, that it needs two network addresses: one for IPv4 and another one for IPv6. So if every phone in the internet must have two addresses, then the limitation of the number of IPv4 addresses would also apply for IPv6, abandoning one of the greatest benefits of IPv6, which is the large scale of addresses. Thus it makes no sense to have a permanent dual stack in every SIP based phone. It makes sense to have a dual stack in such a phone, if only one “half” of the stack is enabled. Such a phone can then be either be in the role of an IPv4 or IPv6 based phone at one time, but not both. Another point of view is to have a dual stack not in the phones, but in the SIP proxies. Because the number of SIP proxies relates to the number of Phones by approximately the factor of 1000, it is affordable to have an IPv4 and an IPv6 address spent for this class of machines. This would not solve the problem, because the end devices must still communicate directly with each other, making the dual stack mandatory for end devices, with the known consequences. Thus, the conclusion is that the dual stack will be involved in the solution of the problem, but it cannot solve it alone.

1.1.5.2 Tunnelling Tunnelling [11] means to encapsulate network layer packets inside of other network layer packets of a different protocol. In this case it means that an IPv6 packet becomes the payload part of an IPv4 packet, which is then transmitted and routed through the internet. This technique allows it to connect “islands” of IPv6 only capable hosts to other remote IPv6 only systems. Figure 18 shows the data encapsulation technique.

IPv6 Header

UDP header

payload

IPv6 Header

UDP header

payload

IPv4 Header

IPv6 Header

UDP header

payload

IPv4 Header

IPv6 Header

UDP header

payload

IPv6 routing totunnel entrypoint

IPv4 routing totunnel endpoint

IPv6 routing tofinal destination

Initial IPv6 packet

Encapsulated packet (IPv6 in IPv4)

Decapsulated packet(initial IPv6 packet )



Final 38

Figure 18 IPv6 over IPv4 data encapsulation

The original IPv6 packet is transmitted to an IPv6 router that is dual stacked and has an IPv6-over-IPv4 tunnel entry point. This router then encapsulates the packet with an IPv4 header and sends this IPv4 packet over the normal internet to a configured tunnel endpoint, which reverses the process and decapsulates the packet, revealing the original IPv6 packet which is then routed to its destination address. Figure 19 illustrates a network situation involving a tunnel.

IPv6 island

Public IPv4 internet

IPv6 island

Tunnel endpoints

Host or router

Tunnel path

Packet source

Packet target

Packet path

Node connection

Figure 19 Network tunnel scenario

It is possible to have multiple tunnels in the path to the final destination. A tunnel is completely transparent to the end devices which interchange the IPv6 packets. Tunnelling is a technique to aid IPv6 communication where it is not available in a native form. This type of tunnel is also called a “configured tunnel”. This means that a system administrator needs to specify the tunnel exit point at the tunnel entry point and vice versa. To extend this inflexibility, a method has been introduced, which allows a tunnel entry point to select a correct tunnel exit point from the IPv6 target address. This method is called “6-to-4 tunnelling” [9]. The basic idea is that an IPv6 island has at least one IPv4 address, which is assigned to the tunnel end point of the island. The IPv6 addresses for all hosts in that island are then build by the following construction scheme.

16 Bit 32 Bit 80 Bit

Network & Host specificIPv4-Address0x2002

128 Bit IPv6 address

6-to-4 Prefix IPv4 address of tunnel endpoint

Bit pattern identifying the host inside the IPv6 island

Figure 20 6to4 address scheme

When a borderline router, which builds the tunnel entry point, receives a packet for an address starting with the 6-to-4 prefix (0x2002), it knows that the tunnel endpoint has the IPv4 address, which is found behind the prefix. This way it can send the packet to the correct tunnel exit point, behind which the hosts with the corresponding IPv6 addresses are located. Every tunnel endpoint must therefore implement a dual stack to be able to utilise IPv4 to the public internet and IPv6 to the island.

Conclusions



Final 39

Tunnelling does not allow an IPv4 based node to communicate with an IPv6 based phone, except for the case when the IPv4 phone would be the tunnel endpoint at the same time. Even is this case, the IPv6 based host would need to know which IPv6 side tunnel entry point it must use in order to reach a specific IPv4 node, because both tunnel endpoints are firmly associated with each other. Even if addressing would not be a problem, the IPv4 tunnel endpoint must deal with IPv6 data packets, as these are encapsulated within the tunnelling protocol, which is IPv4. All this makes tunnelling completely unusable for the problem scenario of this work.

1.1.5.3 NAT-PT The method of using network address translation with protocol translation (NAT-PT) [2] is described in this section. This method is based on the idea that there is a dual stacked instance in the network which can translate IPv6 packets into IPv4 packets and vice versa. On the contrast to tunnelling, no encapsulation takes place, which means that each originator of a data packet can be single stacked with either an IPv4 or an IPv6 protocol stack only. When e.g. an IPv6 packet arrives at the NAT-PT node, it removes the IPv6 header and replaces it with an IPv4 header, which header fields are derived from the header fields in the original IPv6 header. After the replacement of the header, the packet is routed normally to the destination address in the new packet header. A NAT-PT node administrates a pool of IPv4 addresses to dynamically assign to the IPv6 nodes behind the NAT-PT node. Each NAT-PT node features a list of application layer gateway (ALG), which can look into the packet and do modifications to the contained data if necessary. As an example the ALG for the domain name system (DNS) [15] is described here. To fully illustrate the mechanism in a NAT-PT, the two different modes of operation are discussed separately. The first mode of operation is the translation of IPv6 to IPv4 packets and the second one is the opposite, the translation of IPv4 to IPv6 packets.

DNS-ALG When a packet arrives at the NAT-PT node, the packet is presented to an ALG selector, which decides which ALG to apply to the packet. It can do this by its own logic or it can use a special function of each of the ALGs, which should know best, whether the packet needs their treatment or not. The following figure depicts the ALG related packet flow inside the NAT-PT node.

Incoming packet Outgoing packet

DNS-ALG

Headerreplacement

ALGselector NULL-ALG

.

.

.Packet +New header +Old header

mappings

IPv4 address pool

Figure 21 ALG consulting

Figure 21 depicts the data flow and the instances inside a NAT-PT node while consulting ALGs. The purpose of the DNS ALG is to recognise if the packet is DNS query or response and to apply changes to them if necessary. The DNS-ALG recognises DNS related packets from their transport



Final 40

protocols port number, which is 53. If such a packet passes the NAT-PT, it will be modified in the following way. • A query for an IPv4 address (an “A” record) will be replaced with a query for an IPv6 address

(an “AAAA” or “A6” record) for the same hostname. • A response to an “AAAA” or “A6” query is replaced with a response to an “A” query and the

contained IPv6 address is replaced by an address from the address pool. The DNS-ALG also adds a new mapping for the looked up IPv6 address with the IPv4 address to the header field modification module.

• A query for an IPv6 address (an “AAAA” or “A6” record) will be replaced with a query for an IPv4 address (an “A” record) for the same hostname

• A response to an “A” query is replaced with a response to an “AAAA” query and the contained IPv4 address is replaced by an IPv4-mapped IPv6 address for the original IPv4 address.

These operations define the DNS-ALGs behaviour for address lookups. For reverse lookups, where the query presents an address and the result is a hostname, the operations are analogue. This way an IPv6 host can lookup an IPv6 address for a host which is not in the IPv6 network. This address will turn out to be an IPv4-mapped IPv6 address. On the other hand an IPv4 host can lookup an IPv4 address for an IPv6 based node. Of course, the DNS-ALG must feature a kind of cache, so that subsequent lookups for the same hostname will result in the same IPv4 addresses, to minimize the utilisation of the address pool.

IPv6 to IPv4 translation 1. As defined in the Internet Protocol Version 6, there is an IPv6 address for every IPv4 address.

This address can be obtained by prefixing the IPv4 address with the 96 bit prefix ::ffff. So whenever an IPv6 host wants to send data to an IPv4 based host, it knows either the symbolic name, or its IPv4 address. In the first case it will not know that it is an IPv4 based system, because of the DNS-ALG, the lookup will return an IPv4-mapped IPv6 address, which can be used for communication. In the second case, it only needs to extend the IPv4 address by the 96 bit prefix ::ffff, to get the IPv4-mapped IPv6 address of the target system. The latter case is problematic for SIP based VoIP communication, as this requires special knowledge in the IPv6 based phone, in order to interpret IPv4 addresses.

2. The phone can now send the packet, which will arrive at the NAT-PT node. The NAT-PT host will un-map the target address by removing the 96 prefix bits and will then remove the IPv6 header and put an IPv4 header in place, which holds the unmapped IPv4-mapped IPv6 address as its target address and one of the IPv4 addresses from the address pool as its source address. There will also be a mapping installed between this source IPv4 address and the original sender IPv6 address, in case the addressed system sends back IPv4 datagrams. These are then handled by the IPv4 to IPv6 translation mode of operation.

IPv4 to IPv6 translation This way of packet translation is more complex. The IPv4 system that wants to send to an IPv6 system can do this only by looking up a symbolic name for it. This is the only way to establish a mapping inside the NAT-PT node for the target IPv6 address with one of the pool addresses. There is no implicit mapping mechanism as for IPv4 addresses into the IPv6 address space. This makes clear, that the DNS-ALG is essential for a NAT-PT to work. Thus, if an IPv4 packet arrives at the NAT-PT node, it will take a look into its mapping table to find the IPv6 address where this IPv4 address corresponds to according to the previous DNS lookup procedure. If it does not find an entry for this IPv4 address, it will generate an error message and send it back to the sender of the packet. If it does find it, it will replace the IPv4 header with an IPv6 header, storing the retrieved IPv6



Final 41

address from the mapping table as target address. It will then convert the IPv4 source address to an IPv4-mapped IPv6 address and store it in the IPv6 header as source address. This way the target IPv6 machine can respond to this datagram without doing any lookup, or address transformation.

Mappings So far it is clear how address mappings inside the NAT-PT node are established. But how are they removed? A mapping cannot persist forever, as this would cause an address pool exhaustion. On the other hand, it must have a minimum lifetime, as e.g. a TCP communication uses more than only one packet for communication. It is possible to have a module that looks into the data packets to find out when a communication session is over. Even this is not reliable, as hosts can initiate multiple communication session after another without doing host name lookups between them. Thus mappings have a timer that counts the number of continuous seconds, in which this mapping is not used. If this timer reaches a timeout value, the mapping is to be removed, so that the IPv4 address is available again.

Conclusions Obviously this technique cannot map all IPv6 nodes into the IPv4 address space. It can do so for specific hosts at certain times, but not for more machines at the same time than it has IPv4 addresses in its pool. So in case of overload, it cannot provide the requested service, and in case of very low load it is a waste of valuable IPv4 addresses, as there are only m out of n addresses in the pool used.

Nevertheless it can be utilised to solve the introduced problem in a SIP based VoIP environment. In order to solve the problem, there needs to be a SIP-ALG. This would do the following:

• Insert a “Via” header field into request messages, to make sure, that the next hop can correctly interpret the topmost “Via” header field.

• Remove the topmost “Via” header field in responses, if it corresponds to the NAT-PT host. • Replace the “Contact” header field. This is done differently for packets, which are outbound

to IPv4 and for IPv6. For packets, which are going to be sent to an IPv4 host, the SIP-ALG should replace the contact with the symbolic name of the contained IPv6 address, while for packets, which are going to be sent to the IPv6 world, it is enough to replace the IPv4 address in the contact with the IPv4-mapped IPv6 address.

• For media to work, it is necessary to change all IPv4 addresses, which are contained in the SDP block of a message into the corresponding IPv4-mapped IPv6 addresses. The IPv6 addresses in the SDP blocks are replaced with the corresponding IPv4 addresses from the address pool. Those addresses should already be in the mapping table, because either this is a request from the IPv4 side, which is preceded by DNS lookup, which installed the mapping, or it is a request from an IPv6 machine, in which case the mapping for reverse packets must have been installed.

• Remove “Route” headers that correspond to the NAT-PT node in order to enable the next hop to route the message correctly.

• Make sure that a “Record-Route” header field is inserted into requests, holding an address, which matches the protocol of the mangled target address of the packet. This must be done to avoid the problem, which was explained in section 1.1.4.2.6. If there is a “Route” header fields present, then there is no need for the “Record-Route” header field to be inserted, as both ends already have a route set which includes the NAT-PT node address. If a response message is received, the SIP-ALG must look into it to check if there is a “Record-Route” header field that contains the NAT-PT address of the wrong side of the node. It must then remove this header field and insert a new one with the correct side address of the NAT-PT



Final 42

node. If this step is not done, an un-routable route set at the originator of the request would be the result. Figure 22 illustrates such a message flow.

P h o n e 2 ( IP v 4 )IP v 6 P r o x y ( P 1 v 6 ) IP v 4 P r o x y ( P 2 )

I N V I T E u s e r @ P h o n e 2I N V I T E u s e r @ P h o n e 2R e c o r d - R o u t e : P 1 v 6 I N V I T E u s e r @ P h o n e 2

R e c o r d - R o u t e : P 2 v 4R e c o r d - R o u t e : P 3 v 4R e c o r d - R o u t e : P 1 v 6 P 2 v 4

P 3 v 4P 1 v 6

r e s u l t in gr o u t e s e t :

N A T - P T ( P 3 v 6 & P 3 v 4 )

I N V I T E u s e r @ P h o n e 2R e c o r d - R o u t e : P 3 v 4R e c o r d - R o u t e : P 1 v 6

S I P / 2 . 0 2 0 0 O KR e c o r d - R o u t e : P 2 v 4R e c o r d - R o u t e : P 3 v 4R e c o r d - R o u t e : P 1 v 6

S I P / 2 . 0 2 0 0 O KR e c o r d - R o u t e : P 2 v 4R e c o r d - R o u t e : P 3 v 4R e c o r d - R o u t e : P 1 v 6

S I P / 2 . 0 2 0 0 O KR e c o r d - R o u t e : P 2 v 4R e c o r d - R o u t e : P 3 v 4

v 4P 3 v 4

R e c o r d - R o u t e : P 1 v 6

S I P / 2 . 0 2 0 0 O KR e c o r d - R o u t e : P 2R e c o r d - R o u t e : R e c o r d - R o u t e : P 1 v 6

P h o n e 1 ( IP v 6 )

P 1 v 6

P 2 v 4

r e s u l t in gr o u te s e t :

B Y E u s e r @ P h o n e 2R o u t e : PR o u t e : R o u t e : P 2 v 4

P 3 v 4

1 v 6P 3 v 4 B Y E u s e r n e 2

R o u t e : R o u t e : P 2 v 4

H a n g u p

@ P h oP 3 v 4

T h e IP v 6 p r o x y c o u ld n o t a d d r e s s t h eto p m o s t a d d r e s s in th e r o u t e s e t .

Figure 22 “Record-Route” header field in responses

Although all this sounds pretty good, there are two major drawbacks. One is the already mentioned necessity of a pre-allocated address pool. The other one is the not existing portability of such a solution. Because a NAT-PT must interfere in the normal IPv6/IPv4 packet traffic, there must be an interface to the IPv4 and IPv6 protocol stacks. In order to be portable, this interface must be standardised. This is not given, as such interfaces do not exist in every operating system. Operating systems that have such interfaces, have different ones.

This does not weigh more than the benefits of such a solution, which are basically the transparency for the phones and the SIP infrastructure, and the processing speed inside a NAT-PT node, as packets can be processed with kernel priority, which is the highest priority available in every operating system.

1.1.5.4 STUN In the IPv4 world there exists a similar problem to the problem scenario of this work. As a result of the ongoing address exhaustion in the IPv4 internet, many ISPs and private people have established network address translators (NAT) which change the source address of outgoing packets to the address which was assigned by the ISP to the dial up machine. The NAT machine will install a mapping for this private address to be able to route back incoming packets from the internet. As a variant it is also possible to extend the mapping table in the NAT by the port number. This makes it possible to have only one public address at the NAT node, by which it can then masquerade the complete source address and port number of the outgoing packet. The problem with this technique is that a private machine cannot be contacted from the public internet, because there are no initial mappings in the NAT node. A SIP based phone behind a NAT would then issue its private IPv4 address as a ”Via” header field, and the response would never reach the phone, because its private address cannot be routed from the public internet. This is the point, where the simple traversal of



Final 43

UDP through network address translators (STUN) [12] can be used. A STUN server is basically a kind of mirror, that sends back some information about the packet it has received from a NAT shielded client. Figure 23 depicts this scenario for the IPv4 world.

Phone behind NAT

NAT node

STUN server

Phone in the Public internet

Private network

Public internet

Figure 23 NAT and STUN server

The Phone behind the NAT could thereby find out, which address the NAT node is using for it to represent it in the public internet. It could then use this address in all the SIP header fields and the SDP block instead of its own private address.

It is considerable to introduce a similar technique like STUN to solve the IPv6/IPv4 translation problem. As seen in the previous section, a NAT-PT capable node needs to be aware of the higher level protocols of the data packets that pass through it. These protocols include SIP, and so a SIP-ALG needs to be written. Because it is very unlikely, that a NAT-PT is aware of every protocol that exists, one can consider a NAT-PT node to be unable to handle SIP correctly by the means of all consequences, which are e.g. wrong header fields and wrong, thus unusable, SDP blocks.

Another approach to solve the problem scenario is to have that intelligence about SIP in the end devices. They already have a SIP protocol stack and so it should be easy to adapt the header fields and SDP blocks. In order to do so, there must be NAT-PT without a SIP-ALG, which does the IPv6/IPv4 conversion of the packets as described in the previous section. The other component is a server which acts in way similar to STUN. This server is now called “address mirror server”. One address mirror server would reside in the IPv4 network, while another one would reside in the IPv6 network. Each of them is contacted by the phone of the opposite side of the NAT-PT node, so that a request packet must travel through the NAT-PT host, where it gets mangled in the described way. The address mirror server will then put the source address of the request packet into the payload body of the reply packet, which he sends to the address and port number from where the request wa received. This way the originating phone knows the address by which it is represented in the other network. This address can then be used for the problematic SIP header fields and the SDP block. Figure 24 depicts such a scenario.



Final 44

1) Dialogue with

address mirror server

IPv6 network IPv4 network

2) Dialogue between phones

IPv6 Phone IPv4 Phone

IPv6 address mirror server

IPv4 address mirror server

NAT-PT

Figure 24 Address mirror operation

The figure shows the case when an IPv6 based phone initiates a conversation. It retrieves the associated IPv4 address of the NAT-PT node, before it initiates the SIP communication. The IPv6 address mirror server is then used by the IPv4 based phone, if this one needs to initiate requests. The operation is there the same.

Conclusions The problem with this solution is obvious. Every end device must support the feature of an address mirror server. It is not possible to use STUN directly, because it is not standardised for IPv6. That’s why a new standard for this type of address mirror servers would be needed. This means to go trough the time consuming process of internet standardisation before this could be deployed. Even then every end device needs to be updated in order to support the new feature, which means additional effort. Another drawback is that phones need to know if they are behind a NAT-PT or not in order to enable this feature or not. Another issue is the fact that there is still a NAT-PT involved, which is subject to the already mentioned problem of IPv4 address exhaustion or waste of them. If there is a NAT-PT involved, which also support port translation (NAPT-PT), it would not even be possible to use an address mirror server. The reason for this is that the mappings in the NAPT-PT node could include not only an additional port number, but also the outbound target address and port number. The NAPT-PT will then forward only packets back from the original target, but not from other nodes or ports. Thus it is not possible to route SDP defined RTP connections to the phone behind the NAPT-PT. Differing implementations of NAT-PT or NAPT-PT introduce a set of different behaviour. Thus the implementation and support for address mirror servers will be of a very high effort, related to the benefits. This makes the introduced solution idea of this section unusable.

1.1.5.5 Proxy The last method to solve the problem, which is introduced in this work is the proxy solution. For this the assumption is taken, that there is no NAT-PT or NAPT-PT involved at all. SIP has the intention to signalise sessions. That leads to the idea to use proxies for SIP message processing. At least one proxy from the chain of proxies between the end devices must feature a dual stack, which



Final 45

is an affordable price, as it is shown, that there needs to be only one dual stacked machine for signalling. There also needs to be a relay for media. Figure 25 depicts a proxy and relay based situation.

IPv6 phone IPv4 phone

Media relay(dual stack)

SIP proxy(dual stack)

IPv6 domainSIP proxy


SIP

SIP

SIP

SIP

RTP/RTCP RTP/RTCP

Mappingnegotiation

IPv6 linkIPv4 link

Figure 25 Proxy based scenario

This scenario relies on the fact that SIP based phones have a special option, which allows a user to specify a proxy, that will process every request, that the phone sends. This feature is called “outbound proxy”, or “default route”, because this proxy can be considered as the initial route set of the phone. Every SIP based phone has this feature, because it is also needed by the ISP to apply charging plans for calls to other SIP phones.

Request processing If e.g. an IPv6 based phone wants to send a request to an IPv4 based phone, it would either put its IPv4 address or its symbolic name into the request URI. Then the request is sent to the outbound proxy for further processing. The proxy can the decide, whether to forward the packet normally, or to a well known IPv6/IPv4 proxy. It can base this decision upon the fact that the address matches the rules for an IPv4 address or if the symbolic name is not resolvable in the IPv4 domain. The request will then reach the IPv6/IPv4 proxy, which acts like a normal SIP proxy and acts similar to the SIP-ALG from section 1.1.5.3. It would query the media relay for a mapping address for the contained addresses in the SDP block and would change the SDP block. After the modification, the request would be forwarded to the request URIs address, which is either directly an IPv4 address or resolvable from a symbolic name in the IPv4 domain. This way the IPv4 proxy would receive the request and forward it to the final destination, the IPv4 phone.

Response processing

The response from the IPv4 phone would be sent to the address in the topmost “Via” header field, which is the IPv4 proxy. This does the same and sends the response to the IPv6/IPv4 proxy, which acts like a normal proxy and removes its topmost “Via” header field. If the response contains an SDP block, the proxy would again query the media relay for a mapped address and replace it in the SDP body of the response message. After this step, the message is routed the way back according to



Final 46

its “Via” header fields until it reaches the IPv6 based phone. The following is an example for a stack of “Via” header fields in a request that reaches its destination.

Via: SIP/2.0/UDP 193.175.135.190

Via: SIP/2.0/UDP 193.175.135.177

Via: SIP/2.0/UDP [2001:638:806:2001:202:b3ff:fe4d:c8e0]

Via: SIP/2.0/UDP [2001:638:806:2001:207:e9ff:fe3e:d41f]:5060

From bottom to top, these are the IPv6 phone, the IPv6 proxy, the IPv6/IPv4 proxy and the IPv4 proxy. The IPv4 phone is not in the list, because it receives such a message and does not need to insert its own address here.

Media processing The media is always sent to the media relay, because the IPv6/IPv4 proxy has changed the signalling information in the SDP blocks in a way that they now point to the media relay. The media relay can be considered as a programmable UDP packet forwarder, because it does not need to change any contents of the media packets. Its other task is to maintain the mapping list for audio connections. It must always know to which destination a packet needs to be forwarded, that it has received at one of its ports. The media relay can apply various checks for sanity on the source address to make sure that no illegal use of the mappings are made. Mappings in the media relay can either be soft state, which means that they expire if they are not used for a configured amount of time. Another option would be to put more state logic into the IPv6/IPv4 proxy, so that it can remove a mapping when a call is over, which means that a “BYE” request has been received for that session.

Conclusions The proxy method has five big advantages over the NAT-PT solution:

• The first one is portability. A proxy can easily be ported to a different operating system and environment, because it can be implemented a normal user space process.

• The second advantage is the fact, that there is only one IPv4 address used for the proxy and one for the media relay. Both entities, the proxy and the media relay can even reside on the same machine, which would reduce the number of IPv4 addresses needed to exactly one.

• The third advantage is scalability, which means that there could be any number of media relays at several strategic points on the IPv6/IPv4 borderline. These media relays could be used to balance the network load, caused by audio transmissions.

• The fourth advantage is the fact, that it is also superfluous to have a DNS-ALG, which changes DNS queries and replies, as symbolic name resolution is only done in the proxies, which can deal with un-resolvable names in their domain by using the IPv6/IPv4 proxy as a kind of default proxy for the SIP service.

• The fifth advantage is that the SIP part and the media part are logically divided. Thus it is possible to transparently replace one of the components with other software which only need to be able to use the same communication between the two components.

Nevertheless, this solution has a minor drawback, and this is the processing speed inside the IPv6/IPv4 proxy and the media relay. Because these components are usually implemented as normal user space processes, they are not executed at the highest possible priority. Another issue is that each received data packet needs to be copied from kernel address space to the user address space and back to the kernel address space when it is going to be sent out. This is especially noticeable in the audio stream, as there are a lot of RTP packets being processed.



Final 47

2 IPv6/IPv4 VoIP translation solution In the previous chapter several techniques have been discussed, which can help to solve the problem scenario. In this chapter, a software solution is assembled from these techniques. The solution will basically be a SIP proxy server which resides on the IPv6/IPv4 borderline. The media streams will be redirected by the SIP proxy server to a RTP relay which also resides on the IPv6/IPv4 borderline. The next section will specify these two components and the communication protocol between them.

2.1 Specification In this section, the operational behaviour of the SIP proxy and the RTP relay are defined, as well as the communication protocol used to manage the mapping of IPv4 and IPv6 addresses and port numbers. Both software components are to be independent of each other, which means that e.g. the RTP relay my be replaced by another RTP relay, that implements the same communication protocol for address mappings, and which behaves in the same way to the audio communications partners. The same must apply for the SIP proxy server.

2.1.1 The SIP proxy The SIP proxy is responsible for message forwarding between the IPv4 and IPv6 protocol domains. It is the only SIP based instance, which features a dual stack, because it must communicate with the IPv4 domain, as well as with the IPv6 domain. The SIP proxy is realized as a user space process, that receives SIP messages over UDP at a dedicated port number. This port number can be different for IPv4 and for IPv6. The machine that the SIP proxy resides on should have two different network interfaces, to separate IPv4 traffic from IPv6 traffic, but it must also be possible, that only one network device is used, which must then have an IPv4 and an IPv6 address assigned to it. The SIP message processing is split into the forwarding of requests and of responses, which must be treated differently.

Request forwarding SIP requests which are received over the IPv4 interface will be send out over the IPv6 interface and vice versa. As this SIP server shall only serve as IPv6/IPv4 conversion point, it can lack partially the normal SIP behaviour, as long as there is another instance which does that. This instance will be a normal SIP proxy server, which serves as outbound proxy for the IPv6/IPv4 SIP server. There must be one outbound proxy server for IPv4 and another one for IPv6. Nevertheless, some SIP protocol behaviour is necessary. This list defines which SIP protocol actions are to be implemented by the IPv6/IPv4 SIP proxy server.

• “Contact” header field mangling. The “Contact” header field describes where the originator of the SIP message wants to receive subsequent requests. As this could be an IPv6/IPv4 address, this must be changed in order to be addressable by the receiver of this message. The SIP proxy must hold state for this translation, because it must do a reverse translation in subsequent messages.

• Request URI mangling. The request URI can be a URI that resulted from a previous “Contact” header field replacement. If this URI is a translated URI, it must be translated back into the original URI.

• “Via” header field insertion. The proxy must insert a correct “Via” header field. That means it must insert a “Via” header field with its IPv4 address if the request is forwarded to the IPv4 outbound proxy, and it will insert a “Via” header field with its IPv6 address whenever the request is forwarded to the IPv6 outbound proxy. This is part of the normal SIP protocol behaviour.



Final 48

• “Record-Route” processing. If there is no “Route” header field present in the request, the SIP proxy must insert a “Record-route” header field to make sure that the target SIP entity can build a route set, that is usable by it, means that the most recent “Record-route” header field has an address of the same protocol family as the target. This step can be omitted, if the two outbound proxy servers insert a “Record-Route” header field by themselves. Figure 26 depicts this situation.

Phone2 (IPv4)IPv6 Proxy (P1v6) IPv4 Proxy (P2)

INVITE user@Phone2INVITE user@Phone2Record-Route: P1v6 INVITE user@Phone2

Record-Route: P2v4Record-Route: P1v6

P2v4P1v6

resultingroute set:

NAT-PT (P3v6 & P3v4)

INVITE user@Phone2Record-Route: P1v6

SIP/2.0 200 OKRecord-Route: P2v4Record-Route: P1v6SIP/2.0 200 OK

Record-Route: P2v4Record-Route: P1v6SIP/2.0 200 OK

Record-Route: P2v4Record-Route: P1v6SIP/2.0 200 OK

Record-Route: P2v4Record-Route: P1v6

Phone1 (IPv6)

P1v6P2v4

resultingroute set:

Figure 26 Operation without “Record-Route”

In this case the two supporting proxies would route messages in the same way like normal requests. The proxies can have a list of domains, which are known to be in the other protocol domain. The other way is to use DNS to determine the next hop node.

• “Route” header field processing. If the IPv6/IPv4 SIP proxy inserts “Record-Route” header fields, it must also check for the corresponding “Route” header fields and remove them to avoid the loss of the message. Such a situation would arise, if a “Record-Route” header field has been inserted in a message before. The SIP proxy would then route the message to the appropriate outbound proxy, which would try to route the message to the next address in the route set of the message. This address would be of a different address type than the proxy belongs to itself. Thus the message could not be send and would be dropped with an error reply message being send back. Figure 27 illustrates this situation. If no “Record-Route” header fields are inserted, even the processing of “Route” header fields may be omitted, because in this case the two outbound proxies can be used for request routing.



Final 49

Phone2 (IPv4)IPv6 Proxy (P1v6) IPv4 Proxy (P2)

INVITE user@Phone2INVITE user@Phone2Record-Route: P1v6 INVITE user@Phone2

Record-Route: P2v4Record-Route: P3v4Record-Route: P1v6 P2v4

P3v4P1v6

resultingroute set:

IPv6/IPv4 Proxy (P3v6 & P3v4)

INVITE user@Phone2Record-Route: P3v4Record-Route: P1v6

.

.

.

.

BYE user@Phone1Route: P2v4Route: P3v4Route: P1v6

BYE user@Phone1Route: P3v4Route: P1v6BYE user@Phone1

Route: P3v4Route: P1v6

HangupThe IPv6 proxy wouldtry to route the requestto an IPv4 address

Figure 27 Failed “Route” removal

Because of the use of the outbound proxies, the IPv6/IPv4 proxy would not need the ability to route request according to their request URI. This task is done by the outbound proxies. These proxies will also take the decision, whether to route a message from a phone to the IPv6/IPv4 SIP proxy server or to another destination. For this task, the well known “SIP express router” ser5 will be used.

Response forwardingResponse message can be handled more easy as request message, because they do not have a request URI, which needs processing. The next hop of the message is determined from the “Via” header field stack in the message. This list explains the protocol actions, which are required.

• “Via” header field removal. The topmost “Via” header field is check if it represents one of the SIP proxies interface addresses, and is then being removed. The response message is the forwarded to the address and port number which appear in the new topmost “Via” header field. This should be one of the outbound proxies, because the original request is likely to have come from one of them.

• “Contact” header field manipulation. The “Contact” header field of a response represents the address, where the sender of the response, which is the recipient of the corresponding request, wishes to receive subsequent requests. Thus the contents is different from the one in the “Contact” header field of the request message and must be replaced in the same way as in a request message.

• “Record-Route” header field manipulation. If a “Record-Route” header field for the SIP IPv6/IPv4 proxy is found in the message, it must be checked, if it matches the protocol domain of the next hop. If it does so, there is no special action to be taken. If it does not

5 Information about ser can be found at http://www.iptel.org



Final 50

match, then it must be removed and a new “Record-Route” header field must be inserted in order to match the next hops protocol domain.

Figure 28 depicts the target situation according to the SIP message flow. It shows the IPv6/IPv4 proxy, which is specified here and the two outbound proxies as well as several phones whose number is only limited by the network size.

IPv4 phones

SIP proxy(dual stack)IPv6 domain

SIP proxy


SIP

SIP

SIP

SIP

IPv4 linkIPv6 link

IPv6IPv4

IPv6 phones Figure 28 SIP solution scenario

Proxy setup The two outbound proxies must be configured to route request which address systems behind the IPv6/IPv4 borderline through the IPv6/IPv4 proxy server.

Receive the request

Does atopmost „Route“

header field exist ?

Does itrepresent this

Proxy ?

Insert a„Record-Route“

header field

Remove topmost„Route“ header

field

Set next hopaccording to

„Request URI“

Set next hopaccording to topmost „Route“ header field

Is the nexthop of the same

address family asthis proxy ?

Foward message to next hop

Forward message tothe IPv4/IPv6 proxyYes

Yes

Yes

No

No

No

Figure 29 Outbound proxy setup

The SIP proxy software, ser, is highly configurable and can in fact be programmed with a request routing logic. Figure 29 depicts the request routing logic of the external proxies.

2.1.2 The RTP relay The second major component in the solution scenario is the RTP relay. It can be considered to be a programmable UDP packet forwarder. It will be realized as user space process with one or more



Final 51

instances. Its must provide the following features in order to be usable by the IPv6/IPv4 SIP proxy and by the participating phones.

1. The ability to receive UDP packets and send them to another target. This is the basic forwarding functionality of the RTP relay. After a packet is received, it must decide by the means of its mappings, which target address it is to be send to.

2. The ability to install the association between a target and a local port (mappings). When the IPv6/IPv4 SIP proxy receives a SIP message with an SDP block in it, it must query the RTP relay for a mapping for the address and port number in that SDP block. This address and port number is then replaced by the mapping address from the RTP relay. So the RTP relay decides, which address and port number it uses for the mapping.

3. The ability to decide whether to remove a mapping or not. There should be two options for this decision process. First one is an explicit un-mapping by the IPv6/IPv4 SIP proxy, the other one is to use soft state, which means to drop the mapping if it is not used for a certain amount of time (timeout).

4. The option to allocate more than one port with one mapping request. This is necessary, because RTP is often guarded by additional RTCP communication, which takes place over the next higher port number than RTP. Further RTP is always done over an even port number, so this must also be honoured by the mapping installation.

5. The ability to communicate with the IPv6/IPv4 SIP server about the mappings. The RTP relay must use a well defined communication protocol, by which it is queried for mappings and responds about the installation of them to the IPv6/IPv4 server. This protocol is defined in the next section.

6. Configurable range of port numbers to use for mappings. It is required to have the option to use only specific port numbers for mappings, because of the possibility that firewalls are blocking UDP ports. With this it would be possible to match the firewall policies about blocked port numbers. A port range is defined by the minimum port number and the number of ports in the range.

7. Idempotency for mappings. This means that no new mapping must be installed, if there is a request for an already mapped target address and port number. This is mandatory, because SIP “INVITE” requests, which carry SDP blocks with addresses to be mapped, can be re-transmitted by the originating phone. This causes a stateless SIP proxy to re-issue the same mapping request to the RTP relay. This one must then reply with the same address, which has been assigned for this target address before, in order to save resources. Thus before blindly installing a new mapping, the RTP relay must check if a mapping for this target already exists.

In order to achieve a high grade of reusability, the RTP relay will be implemented as general UDP forwarder. This means that not only mappings for forward traversal will be installed, but also for backward traversal in case that packets come back from the target. Figure 30 depicts the possible parties in a RTP communication over the RTP relay, where the target is an IPv6 based node and thus the senders are IPv4 based nodes.



Final 52

UDP Sources(IPv4)

UDP target(IPv6)

RTP relay node

Receivingsocket

Sendingsockets

Figure 30 Source-target relations

For every new source, which sends to a specific port number, the RTP relay must create a new socket in the other protocol domain for sending the packet to the target address and port number. This way the target is enabled to send back UDP packets to the source from which it has previously received a UDP packet. The RTP relay will then process such an answer packet like any other incoming packet. It will look for the appropriate sender socket, which was the receiver socket for the previous packet, and use it to send to the source associated with the socket, by which the answer packet was received. In order to avoid abuse, there must be check whenever such a backward mapping is to be used. The RTP relay must check, whether the sender of the packet is also the target for the corresponding forward mapping. If it is not, the packet must be dropped. This way, only the target node for the mapping may send back UDP packets to the original source nodes on the other side of the RTP relay.

2.1.3 The mapping protocol This section defines the protocol to use for installing and de-installing mappings by the IPv6/IPv4 SIP proxy server to the RTP relay. The protocol must use a transport protocol, which is not local to a node, because it shall be possible to distribute the IPv6/IPv4 SIP proxy and the RTP relay to different machines. UDP comes handy as transport protocol, because it is message oriented and thus matches the scheme of query-and-response of the mapping protocol. The protocol messages should have a human readable format.. The data passed between the IPv6/IPv4 SIP server and the RTP relay are basically quadrupels of four addresses and port numbers. Figure 30 is the basis for these quadrupels. The format of such a quadrupel is:

Address1:port Address2:port Address3:port Address4:port

With “Address” being either an IPv4 address of an IPv6 reference, which is an IPv6 address surrounded by brackets. “Address1:port” stands for the source address and port number of a UDP packet, “Address2:port” stands for the address and port number at the RTP relay, where this packet must be send to, while “Address3:port” stands for the address and port number over which the first sources packets will be send to the target address and port number, which is “Address4:port”. Obviously Address1 and Address2 must be of the same address type as well as Address3 and Address4. On the other hand address types must be different for Address1 and Address4 as well as for Address2 and Address3. By the following, the protocol actions (requests) and results (responses) are introduced.

Mapping request Parameter to a mapping request must be the target address and port number, the number of adjacent ports to allocate and the target address and port number. The quadrupel in this request must only



Final 53

have valid values for the target address and port number. It can be considered of a form that is partially filled in by the sender of the request and by the receiver in the response.

MAP (quadrupel) ports

Example: (spread over three lines for readability) MAP 0.0.0.0:0 0.0.0.0:0

[::]:0 [2001:638:806:2001:207:e9ff:fe3e:d41f]:16332

2

This example demands a mapping for the target IPv6 address 2001:638:806:2001:207:e9ff:fe3e:d41f and port number 16332. Demanded are two adjacent ports, one for RTP, the other one for RTCP. The values for the sender and RTP relay are left empty, which means to fill in the relevant empty address and to set the port number to zero. This message is send by the IPv6/IPv4 proxy to the RTP relay.

Mapping reply The mapping reply is send by the RTP relay to the IPv6/IPv4 proxy server after it has installed a mapping for the preceding “MAP” request. The format is basically the same, but the keyword “MAP” is replaced by “MAPPED” and the two middle address and port pairs, which identify the RTP relay, have been filled in by it.

MAPPED 0.0.0.0:0

193.175.135.177:14000

[2001:638:806:2001:202:b3ff:fe4d:c8e0]:0

[2001:638:806:2001:207:e9ff:fe3e:d41f]:16332

2

The above example reply means that the RTP relay has established a forward mapping for the target IPv6 address 2001:638:806:2001:207:e9ff:fe3e:d41f with port number 16332. The IPv4 address for this target is 193.175.135.177 and port number 14000. The IPv6 address of the RTP relay by which packets will be send out to the target is 2001:638:806:2001:202:b3ff:fe4d:c8e0 with an unspecified port number. The IPv6/IPv4 SIP proxy which receives this reply knows that it has to replace the original IPv6 target in the SDP block by the IPv4 address returned in this reply message.

Negative reply

If the RTP relay cannot establish a requested mapping or there was a request for un-mapping a non-existent mapping, it send back a negative reply of the form: NO RESOURCES

Which means that there are no free resources to establish a mapping or that the resource requested by an "UNMAP" request could not be found.

Unmap request The unmap request serves the opposite purpose of the mapping request. It instructs the RTP relay to remove a forward mapping and all of its backward mappings. The parameters to this request are the original target address and port number and the address and port number of the RTP relay where packets for this target are received as well as the number of ports. The example below shows how the above installed mapping would be unmapped.



Final 54

UNMAP 193.175.135.177:14000

[2001:638:806:2001:207:e9ff:fe3e:d41f]:16332

2

This would stop the forwarding of UDP packets received at 193.175.135.177 port number 14000 to 2001:638:806:2001:207:e9ff:fe3e:d41f port number 16332.

Unmapped reply

After the RTP relay has unmapped the mapping, it answers with an unmapped reply message, which is of the same format as the "UNMAP" request, but with the keyword “UNMAPPED” instead of “UNMAP”. The following gives an example.

UNMAPPED 193.175.135.177:14000

[2001:638:806:2001:207:e9ff:fe3e:d41f]:16332

2

Error reply

If the request message that the RTP relay received was malformed, it replies with this error message which means that the request could not be understood. No mapping has been installed or removed. The format is: ERROR <Reason>

With <Reason> being the descriptive reason phrase, which describes why there was an error detected. Currently only the reason phrase “MALFORMED REQUEST” is defined.

Flow of operations

Figure 31 reflects the flow of mapping requests and replies between the RTP relay and the IPv6/IPv4 SIP proxy. There are basically two interactions: the installation of a mapping and the removal of it. The RTP relay receives the mapping request, installs the mapping and informs the requestor about it by sending back the “MAPPED” reply, which holds the alias address for the target. This one then requests the removal of the mapping, which the RTP relay does, and receives an acknowledgement about the un-mapping by the “UNMAPPED” reply message, which holds the original target address and port number as well as the former alias address and port number.



Final 55

MAP 0.0.0.0:0 0.0.0.0:0[::]:0 [2001:638:806:2001:207:e9ff:fe3e:d41f]:163322

MAPPED 0.0.0.0:0 193.175.135.177:14000[2001:638:806:2001:202:b3ff:fe4d:c8e0]:0 [2001:638:806:2001:207:e9ff:fe3e:d41f]:163322

UNMAP 193.175.135.177:14000[2001:638:806:2001:207:e9ff:fe3e:d41f]:163322

UNMAPPED 193.175.135.177:14000[2001:6 38:806:2001:207:e9ff:fe3e:d41f]:16332

2

RTP relayIPv4/IPv6 SIP proxy

Installmapping

Removemapping

Figure 31 Mapping protocol message flow

2.2 The IPv6/IPv4 SIP proxy This section describes the software solution for the IPv6/IPv4 SIP proxy server. Its architecture and functional blocks are explained in detail. This component is realized as a program, written in the programming language “C” [7]. The choice of “C” as programming language appears appropriate, because other SIP software is also written in “C”. Thus the integration with other SIP software is more easy for subsequent projects. Other options for the programming language would have been “C++” [8] or “Java” [10]. “Java” achieves a higher level of portability, but lacks sufficient “C” interfaces. “C++” would have been an option, but the object oriented programming model of “C++” interferes with the structure of normal “C” programs. This would mean a raised level of integration complexity, when merging components from “C” and “C++” based programs.

Networkingmodule

Messageparser

Requestprocessing

Responseprocessing

SDPmodification

Messageassembly

Contactlist

RTP relayinteraction

Figure 32 Functional blocks

Figure 32 depicts the functional blocks of the IPv6/IPv4 proxy server. A message is initially received by the networking module and marked with the senders address and port number. The



Final 56

message is then parsed for the relevant header fields. After parsing, the message is processed either as a request message or as a response. During this step the header fields are processed. If an SDP block exists in the message, a mapping for it is negotiated with the RTP relay before the message is re-assembled and send out to the outbound proxy.

2.2.1 Network module The network module is the point where SIP messages are received and being send to other nodes. It maintains two network sockets, one in each protocol domain. It binds explicitly to an IPv4 address and an IPv6 address. The UDP port it uses can be different for both addresses. The network module is also used by the RTP relay interaction, because the communication with the RTP relay is realized over UDP too.

The network module can be configured to show different operational behaviour. It is possible to define a file, where received and transmitted SIP messages are logged to. This feature helps to find out about the correctness of the participating SIP instances like phones and proxies. The logging of packets can be turned on and off by demand.

Another configuration option is to control, whether the network module will send out real network packets over one of its sockets, or to omit this step in order not to confuse other SIP instances during the phase of development and testing.

Figure 33 illustrates the data flow inside the network module.

Send a message Receive a message

Real or simulated sending

IPv6 socketIPv4 socket

logging

Other modules

Figure 33 Data flow inside the network module

2.2.2 Message parsing After a message has been received, it must be parsed. The data packet, which is basically a sequence of bytes, must be examined for its contents, whether it holds a SIP message or something else. Parsing then means to change the representation of the contained information from the human readable SIP syntax into a machine readable, structured binary form.

SIP is defined by an augmented Backus-Nauer form (ABNF) [13]. This means there exists a set of rules which define the language for SIP messages. These rules must be used to construct SIP messages from raw binary data, and they are reverse used to transform SIP messages into the binary form. Parsing is usually a very time consuming process, because many different rules must be tested whether a specific part of the SIP message matches or not.



Final 57

The ABNF basically defines how rules are constructed from basic operations. These are “sequence”, “alternative”, “repetition” and “grouping”. The following list shows the notation for these operations.

Sequence: rule1 rule2

Alternative: rule1 / rule2

Grouping: ( rule )

Repetition: min*max rule

An example is the definition of a decimal number that can have between 1 and 5 digits, followed by a space and the word “SIP” or “SIPS”: DIGIT = “0” / “1” / “2” / “3” / “4” /

“5” / “6” / “7” / “8” / “9”

NUMBER = 1*5DIGIT %x32 ( “SIP” / “SIPS” )

The ABNF for SIP specifies the format of headlines, header fields and their components by a very large number of rules which are constructed in the same way as the above example. The RFC for the ABNF also specifies some basic characters and character sequences, like the CRLF, which terminates lines.

In the case of SIP the ABNF specifies that the group of headline and header fields are separated from the body of the message by two successive appearances of the CRLF sequence. By this it is easily possible to separate the body of the message from the header fields and headline. The parser must simply search this sequence in the message to find the beginning of the body. If this sequence is not found, then there is no body in the message.

In a similar way it is possible to separate header fields from each other and from the headline. The ABNF defines that each header field and the headline have to end with the CRLF sequence, which must be followed by either the name of the next header field or the end of the message. Thus the header fields and the headline can be split from each other for further analysis by the parser by looking for this pattern.

Header fields may be folded. This means that a header field can be distributed over more than one adjacent lines. In this case, the next line must begin with a white space character. Line folding may be reversed, which means that each line folding CRLF may be removed.

Message

Headlineand

header fields

Body

Headline

Body

Header field(folded)

Header field

Header field(folded)

Header field

Header field

Headline

Header field

Header field

Header field

Header field

Header field

Hea

ders

/ B

ody

split

ting

Hea

der s

epar

atio

n

Hea

der u

nfol

ding

Body



Final 58

Figure 34 Message pre-processing

So before the parser starts to analyse the header fields, these three steps are taken to simplify and pre-structure the message. Figure 34 illustrates the pre-processing steps.

After the pre-processing, the headline and the header fields are parsed. The headline is examined for the presence of the word “SIP” at the beginning, which indicates that the message is a response. If this word is missing, the headline belongs to a request message. Response headlines are examined for their response code, while request headlines are examined for their method name and their request-URI.

The next step is to parse the header fields. Not all header fields which are standardised need to be parsed. Only the header fields, which will be modified or whose data is used for further processing of the message are parsed into data structures.

• The first “Via” header field must be parsed in responses. It holds the next hop address where this response needs to be send to. In a request message, the position of the first “Via” header field must at least be identified, because the IPv6/IPv4 SIP proxy must insert its own “Via” header field at the appropriate point in the message in order to be the new first “Via” header field.

• The “Contact” header field must also be parsed, because its contents will be modified by another module.

• The “Content-Length” header field is parsed too. Its value is the number of bytes of the body of the message. The body, if one exists, is an SDP block which holds addresses, which are modified. This means that the body will change its size during the message processing, thus the “Content-Length” header field will have to be changed.

• The “Content-Type” header field is parsed, because it must be checked, if it contains the string “application/sdp”. This is a sanity check to make sure that the body really contains an SDP block.

The remaining header fields, which are not parsed remain in their human readable encoding state. This saves time and processing cycles later, when the modified message is to re-assembled for transmission, because they do not need to be encoded. When the header fields are parsed, the body comes next. The parser transforms only SDP entities which are of meaning for the further processing. These are:

• The contact lines. They hold the addresses where the sender wishes to receive audio data. There can be multiple contact lines for different media streams. The can be a global contact line, which may be overridden by subsequent contact lines.

• The media lines. It holds the port number for the address on the contact line. A media line begins a media definition inside the SDP block. It may be followed by a contact line, which then overrides the global contact line. Such a local contact line must be present, if there is no global contact line.

• The originator line. It holds a description for the originator of the SDP block, which contains a username and the address from where this SDP block was issued. The originator address and the contact address are usually the same. It is possible that a user wants to have e.g. a video stream at a different address than the audio stream. In such a case, addresses would be different.

The remaining SDP lines are left untouched. They do not need to be represented by a data structure as they are not interpreted or modified by any means.



Final 59

After the parsers work is done, the relevant portions of the SIP message are represented by a “C” data structure, which can now be processed by other components, and the remaining header fields are preserved in their original human readable state

2.2.3 Request processing

After the message has been parsed, it is either processed as a response or as a request. In case it is a request, request processing module does its work. This involves several steps.

• If the request message was received over the IPv4 interface, it is assumed that it will be forwarded to the IPv6 outbound proxy and vice versa. Thus the first step is to determine the next hop by the receiving socket and by this also the socket for the network module to use for sending the packet.

• The next step is to insert an appropriate “Via” header field. For this the request processing facility uses the address to which the socket for sending is bound to. This is information gained from the previous step.

• The “Contact” header field is modified next. This header field holds the address of the originator of the message where it wants to receive subsequent requests. Because an IPv4 phone would issue its IPv4 address in this header field, it must be modified. A contact is basically a SIP-URI. Thus it contains a username and an address followed by an optional port number. The original contact is replaced with a new contact. The new contact is composed from the address of the IPv6/IPv4 SIP proxy and its port number and a virtual username, which is associated with the original contact and stored in the contact list together with the original contact. By this the contact is addressable for the receiver of the message, and the association with the original contact still exists within the IPv6/IPv4 SIP proxy.

• The request-URI is examined, if it exists in the contact list and thus is a formerly modified contact from a “Contact” header field.. In this case it is replaced by its original contact from the contact list. This way the correct recipient of the message is restored.

The examination and modification of the request-URI and the “Contact” header field are the most important tasks of the request processing facility. A phone that receives a SIP message containing a “Contact” header field must send its subsequent requests to this address. It would use this SIP-URI as the request URI for the next request. The IPv6/IPv4 SIP proxy would then replace the request URI with the original one.

2.2.4 Response processing

If a message has been identified to be a response message, it is processed by this facility. The typical operations for general response processing are done as well as actions, which are related to the IPv6/IPv4 translation of contained information. The operations are:

• The first “Via” header field is examined, if it represents the address of the proxy, over which

this message was received. It is then removed. The destination address of the message is then determined from the next, now the first, “Via” header field. The address of the target must reside in the other protocol domain than the one of the sender of the message.

• According to the next hop, which was determined in the previous step, the response facility selects the appropriate socket for the network module, over which this message must be send out.



Final 60

• The “Contact” header field is processed in precisely the same way as in a request message. The contact is replaced by a new contact representing the IPv6/IPv4 proxy. Figure 35 illustrates the “Contact” header field and request URI modification by the example of a call initiation message flow.

INVITE sip:[email protected] SIP/2.0Contact:

<sip:jfi@[2001:638:806:2001:207:e9ff:fe3e:d41f]

INVITE sip:[email protected] SIP/2.0Contact: <sip:[email protected]>

SIP/2.0 200 OKContact:

<sip:USER59750200@[2001:638:806:2001:250:4ff:fe56:196b]>SIP/2.0 200 OKContact: <sip:[email protected]>

ACK sip:USER59750200@[2001:638:806:2001:250:4ff:fe56:196b] ACK sip:[email protected]

IPv6 side IPv4 side

1

2

sip:jfi@[2001:638:806:2001:207:e9ff:fe3e:d41f <-> sip:[email protected]

sip:[email protected] <-> sip:USER59750200@[2001:638:806:2001:250:4ff:fe56:196b

12

Contact list

Figure 35 Contact mapping

The message flow starts with an “INVITE” request, which carries a “Contact” header field, which represents the SIP phone, in this case an IPv6 based phone. The IPv6/IPv4 SIP proxy replaces this contact with a new one and stores this association as the first entry in the contact list. The request is then forwarded to the outbound proxy and travels its way to the IPv4 phone. The IPv4 phone then answers with a “200 OK” response, which signals, that the user has accepted the call. This response also carries a “Contact” header field identifying the IPv4 phone. It is also replaced by a new contact which is stored in association with the original contact as the second entry in the contact list. To finish the transaction, the IPv6 phone send the final “ACK” request. This “ACK” request carries the SIP-URI as its request-URI, which has been learned from the previous response, the replacement contact from the IPv6/IPv4 SIP proxy. This one looks into the contact list and finds that the request-URI is a replacement URI from a previous message. The original URI is looked up from the contact list and replaces the request URI in the “ACK” request.

So basically the username in the new contact serves as a key to do the lookup into the contact list. It must be unique. The purpose of this is that subsequent request messages with the same “Contact” header fields must be treated in the same way. This means that the same original contacts must result in the same virtual contacts to avoid resource exhaustion by establishing unused associations.

2.2.5 Contact list The contact list is a small data base, which stores the original and virtual contact associations. It also provides the functionality to create new virtual contacts on demand. If a requestor demands a virtual address for an original address, the contact list module checks first, if there already is a



Final 61

virtual contact for this original contact, and if so, it returns the stored virtual address. If there is no virtual address, it creates one with a new, unique username and stores the association with this virtual contact in the list. The second functionality is to do lookups. By this a module can retrieve the original contact for a known virtual contact URI. This is used by the request processing when examining the request-URI. Figure 36 depicts the layout of the contact list module.

virtual original

URIURIURIURIURIURIURIURI

Get virtual Get original

Lookup virtual

Lookup original

Store virtual:originalCreate virtual

List with associations

Contact list module

requestor module

Figure 36 Layout of the contact list module

2.2.6 SDP modification This module examines the parsed structures, which describe the media, contact and originator lines of the received SDP block. Because a single SDP line does not describe a complete address and port number pair, it is necessary to create the list of target addresses and port numbers as an intermediate list before starting the installation of the mappings. Figure 37 gives an example, which illustrates this.

Address 195.37.78.128 Port 19234Address 193.175.135.177 Port 9020

v=0o=jfi 2890844526 2890842807 IN IP4 193.175.135.177c=IN IP4 195.37.78.128s=SIP initiated callt=2873397496 2873404696m=audio 9020 RTP/AVP 0c=IN IP4 193.175.135.177m=audio 19234 RTP/AVP 2

Figure 37 Intermediate list

In this example the first address and port pair is derived from the global contact and the last media line, because this media part does not have a local contact line. The address for the originator is also replaced by the mapping for the global contact, although it is not the same. This is possible, because there will be no audio or video data send to the originator address. The second address and port number pair is formed from the first media line and its local contact line.



Final 62

For each of these address and port number pairs a mapping will be installed using the RTP relay interaction module. For each address and port pair there is a back reference stored to find the SDP lines to which they belong when replacing the addresses with the data from the mapping. The following is the SDP block from the above example after alteration using the results from the RTP relay. v=0

o=jfi 2890844526 2890842807 IN IP6 2001:638:806:a21:220:bf:fe4d:c8e0

c=IN IP6 2001:638:806:a21:220:bf:fe4d:c8e0 3. s=SIP initiated call

t=2873397496 2873404696


c=IN IP6 2001:638:806:a21:220:bf:fe4d:c8e0


The first mapping that was installed is between the IPv6 address and port number [2001:638:806:a21:220:bf:fe4d:c8e0]:16000 and the IPv4 address and port number 195.37.78.128:19234 while the second mapping is between [2001:638:806:a21:220:bf:fe4d:c8e0]:16002 and 193.175.135.177:9020. Each mapping includes two adjacent ports, because RTP and RTCP are being expected to flow between the phones. The modified SDP lines are still hold in a data structure. They are re-encoded as human readable at a later stage when the complete SIP message is assembled for sending.

2.2.7 RTP relay interaction The RTP relay interaction modules is responsible for the communication with the RTP relay. It implements the mapping protocol from section 2.1.3 and provides a function to install a mapping, which returns the mapped address and port number. Figure 38 reflects the actions taken by this module.

Setup themapping request

Send the request to

the RTP relay

Wait for the RTP relay to

answer

Was there atimeout

?

Has a mapping been

installed?

Return anerror

Return themapping

No

No Yes

Yes

Figure 38 RTP relay interaction operation

The first action is to construct a mapping request for the target media address and port number. This request is then send to the RTP relay as a UDP packet. The module then waits for the RTP relay to reply with a mapping response indicating the mapped address for the target and its port number. It can happen that the RTP relay does not respond. This ma be due to the fact that it is not running or



Final 63

that a network error occurred. In this case the module returns an error message. Otherwise the reply is examined for an error message, in which case also an error is returned by the module. If a mapping has been installed, it is returned as the result to the SDP modification module.

2.2.8 Message assembly

After all previous stages of processing, the message is nearly ready to be send out to the outbound proxy server. Before this can be done, the message must be re-assembled from the internal data structures into a SIP message as described by its ABNF definition. Thus message assembly can be considered to be the opposite of message parsing. The construction of a message from data structures is more easy than parsing a message, because the data comes in a machine readable form and is encoded directly from the structure to the output buffer, which is then send over the network.

Because not all SIP header fields have been parsed, only those header fields, that have been parsed must be encoded into the buffer. All other header fields are simply copied into the buffer.

The same happens for the body. The SDP lines that have been modified are encoded from data structures, while the SDP lines which stay untouched are simply copied from the original message.

Message assembly must also change the “Content-Length” SIP header field in order to reflect the new size of the body. The length of the body is computed by simply counting the bytes in it. So the operations taken by the message assembly module are as follows.

1. Assemble the body part of the message.. 2. Determine the size of the body. 3. Change the “Content-Length” header field of the SIP message. 4. Assemble the head line of the message. 5. Look at each header field entry if it is a data structure or an unparsed header field.

If it is an unparsed header field, it is simply copied into the output buffer. If it is a data structure, the appropriate encoding function is called which encodes the specific header field from the data structure.

6. Attach the body behind the header fields

After these steps the message is in the form how it can be transmitted to the next hop. This is then done by the network module.

2.3 The RTP relay The RTP relay is the second component in the solution scenario. Its purpose is to forward UDP packets between SIP based VoIP phones. The forwarding information is being set by the IPv6/IPv4 SIP proxy server. Thus the RTP relay implements the mapping protocol from section 2.1.3. The RTP relay is implemented in the programming language “C”. Because due to the fact that a large number simultaneous calls will be forwarded by it, the RTP relay is potentially a very busy entity. Thus it is necessary to take performance as an objective. Programs written in “C” feature a very fast execution speed, because of the fact that the data structures and types are very close to data types which are native to the microprocessor.

The RTP relay is implemented as a number of user space processes. For every process there is a maximum number of open files that it can have. For the operating system Linux [14], this number is 1024. Thus not more than 1024 sockets, each of it occupies a file descriptor, can be owned by a single process. To virtually extend this limit, several processes work together to be able to have more open sockets than one process could own.



Final 64

Because of the fact that several processes are running at the same time, the RTP relay has its own logging process. This orders the logging information of the other processes.

It is possible to configure the RTP relay to use only a specified range of UDP port numbers. This configuration is done in a configuration file, which is read at start-up by the RTP relay. The RTP relay has two sides. One is the IPv4 side, the other one is the IPv6 side. The interface addresses used are set in the configuration file.

Masterprocess

Workerprocess

Workerprocess

Workerprocess

Workerprocess

Loggingprocess

MappingLogging

Logging

Media forwarding

IPv4/IPv6 SIP proxy

Log file

Figure 39 Process interaction

Figure 39 depicts the single processes of the RTP relay and their interaction. The processes interchange information using standard pipes, which are a very fast type of inter-process communication. Each process has a different task. Together they form the RTP relay which forwards media stream packets between the IPv4 and the IPv6 network domains.

2.3.1 The logging process The logging process has the task to receive logging requests from the other processes and to write them in an ordered way to the main log file. The communication pipe is inherited from the master process. The logging process does additional formatting of the information being logged by the other processes. It gives each logging a timestamp and marks the it with the originator, its process id and a severity level before a new line is added to the log-file. The logging process is the only process that writes directly into the log-file.

Figure 40 shows some typical logging output by the logging process during the start-up sequence of the RTP relay. After each write access, the log-file’s buffer is flushed, so that other processes which monitor the RTP relay could analyse the log-file in realtime.



Final 65

Fri Jul 2 15:12:01 2004 (26649) MASTER LOG : V4: 193.175.135.177Fri Jul 2 15:12:01 2004 (26649) MASTER LOG : V6: 2001:638:806:2001:250:4ff:fe56:196bFri Jul 2 15:12:01 2004 (26649) MASTER LOG : accepting requests at UDP-port 4699Fri Jul 2 15:12:01 2004 (26649) MASTER LOG : using UDP ports 12000-12199 for media.Fri Jul 2 15:12:01 2004 (26649) MASTER INFO : Initializing tables.Fri Jul 2 15:12:01 2004 (26649) MASTER LOG : Spawning 4 processes.Fri Jul 2 15:12:01 2004 (26652) WORKER INFO : worker #0 fds=1024Fri Jul 2 15:12:01 2004 (26653) WORKER INFO : worker #1 fds=1024Fri Jul 2 15:12:01 2004 (26654) WORKER INFO : worker #2 fds=1024Fri Jul 2 15:12:01 2004 (26655) WORKER INFO : worker #3 fds=1024

Timestamp ProcessID (PID)

Origin Severitylevel

Log message

Figure 40 Logging output

2.3.2 The master process

When the RTP relay is started, the master process is the first process. At first it will read the configuration file, before it creates all the processes of the relay and establishes the pipe connections between them. The master process is the only process, which communicates over UDP with IPv6/IPv4 SIP proxy to accept mapping requests and send back replies about the installed or removed mappings. The major task of the master process is to act as a dispatcher between the IPv6/IPv4 SIP proxy and the worker processes. The master process does not hold any information about mappings itself. The reason for this is that mapping information can change due to packet transmissions. If e.g. a forward mapping is used by a new source, then a new sender socket is created and associated with this source (see also section 2.1.2). Thus only the worker process knows which mappings it has installed and it does so only for its own mappings, not for the mappings of other worker processes.

Masterprocess

Workerprocess #1

Workerprocess #2

Workerprocess #3

Workerprocess #4

ReceiveMAP request

1) ASK ...NO

2) ASK ...NO

3) ASK ...NO

4) ASK ...NO

5) MAP ...NO RESOURCES

6) MAP ...NO RESOURCES

7) MAP ...MAPPED ...

SendMAPPEDresponse

Figure 41 Mapping interaction

To achieve idempotency of mapped addresses with their sources, the master process must “ask” all the worker processes if such a mapping exists. If they all respond with “No”, then the master process will choose one of the workers to install the mapping. The worker then does so and replies with a message to master about the replacement address and port number for the requested target



Final 66

address and port number in the same format as specified in the mapping protocol in section 2.1.3. The worker can also respond with the “NO RESOURCES” message, if it cannot establish the mapping because there are no more file descriptors available. If the master receives such a negative response, it queries another worker to install the requested mapping. If all workers respond with “NO RESOURCES”, the master will also forward this reply to the IPv6/IPv4 SIP proxy.

Figure 41 depicts the interaction between the master process and the worker processes when receiving a request to install a mapping. In this example all the workers do not have a mapping for the requested target, so the master process tries to install the mapping in one of the workers. Workers number one, and two cannot install the mapping but number 3 can and did so. Thus the master process can send back the “MAPPED” response from worker number three.

When the master process receives an “UNMAP” request, the procedure is similar. It forwards the request to all of the workers, until one of them responds with an “UNMAPPED” reply, which is then send back to the IPv6/IPv4 SIP proxy. If none of the workers has the mapping installed, they all will give a negative answer, which then returned to the IPv6/IPv4 SIP proxy.

2.3.3 The worker process The worker processes are the part of the RTP relay, where the forwarding of media data and the maintenance of mappings is realized. Each worker process uses a complex data structure to ensure efficiency when forwarding UDP packets, installing and removing mappings.

Lookup table

Receiver

Target addressReceive socket

Link to senders

TimestampFlag

Link to next senderSending socketSource address

Senders



Figure 42 Data structures

These data structures consist basically of three things:

• Receivers. They hold the target address for packets which are received over the socket

which is contained in the receiver. They also hold a list of senders, which are to be used for packet forwarding. The flag in the receiver signals if it is allowed to create new senders, means to accept new source addresses or not. This distinguishes forward mappings from backward mappings. The timestamp represents the last time that this receiver received a packet for forwarding. It is used to determine whether a timeout occurred or not.



Final 67

• Senders. They hold a socket which is to be used for sending, if a packet arrived from the source address, which is also contained in the sender. Senders are organised as a list and thus have reference to the next sender in the list for the original receiver.

• The lookup table. This table associates sockets with receivers. It is indexed by a file descriptor for a socket. Figure 42 depicts the relations between the three data structures.

2.3.4 Mapping installation Before any packet can be forwarded, a mapping must be installed. The worker receives a “MAP” request from the master which contains the target address and port number. The worker creates a receiver from these data. The flag is set to allow new sources. This must be, because in the state of creation, there are no sources known, thus there are no senders yet. The timestamp is set to be the current time, as the creation of a receiver is considered to be a usage of it. The worker creates a socket for the receiver, where media sources are expected to send data to. The address and port number of this socket are set to the local accept address and port (refer to section 2.1.3). The local sending address is then set to be the address of the other side of the RTP relay, which is of a different protocol domain. The final step is to put a link to the receiver into the lookup table.

Lookup table

Receiver

Target addressReceive socket

Link to senders

Timestamp = now

Flag = yes

No senders

Figure 43 New mapping

Figure 43 depicts the state of the data structures after a mapping has been installed. Basically only the receiver has been set up. If the mapping request demands e.g. two adjacent ports with the first port being even, two matching sockets are created and for each of them a receiver is created.

2.3.5 Packet forwarding Packet forwarding is the main purpose of the worker processes. After the mapping has been installed, the RTP relay is ready to forward packets to the target node. If a packet arrives at one of the worker processes, it must do several steps in order to send it to the correct target node.

• Use the lookup table to find the receiver for this mapping. If there is no receiver, the packet has been received as a result of a failure in the sending node and will dropped, means it will not be processed any further.

• When the receiver is known, it is checked, if it has a timeout situation. For this the actual time will be compared to the timestamp in the receiver. If a timeout occurs, that packet will be dropped and the mapping will be deleted.

• The next step is to search the list of senders of that receiver for a sender which is associated with the sender of the packet.



Final 68

• If the sender has been found, it will be used. If the source node has never send any packet before, there will not be a sender. In this case, a sender is created and associated with the source address if the receiver has its flag set. If the receiver does not allow the creation of senders, the packet will be dropped. This happens if a foreign node sends a packet to a socket which is associated with a sender. When a new sender is created, there is also a new receiver created for the socket of the sender. This receiver will then get exactly one sender, which is associated with the socket of the original receiver. The new receiver will not be allowed to create new senders. This is the backward mapping.

• The last step is to update the timestamp of the receiver to the actual time.

Lookup

table

ForwardReceiver

Target address

Receive socket

Link to senders

Timestamp

Flag = Yes

Link to next senderSending socket

Source address

ForwardSenders

BackwardReceiver

Target address

Receive socket

Link to senders

Timestamp

Flag = NoLink to next sender

Sending socket

Source address

BackwardSender

1

1

2

2

3

4

3

4

Figure 44 First packet traversal

Figure 44 depicts the status of the data structures after the first packet has been processed. The new backward receiver will have the forward senders source address as its target address and use the same socket for receiving that the forward sender uses for sending.

The backward sender will have the same address as its source, that the forward receiver has as its target address and use the same socket as the forward receiver.

So when now a packet arrives back from the original target, the backward receiver will be triggered. The source address of its sender will match the source address of the back sending node and thus it will be used to send the packet to the target address in the backward receiver.

UDP source UDP target

RTP relay node

[2001:6aeb::24]:1200

2001:6aeb::17

195.37.78.128:8100

193.175.135.177

IPv4 side IP

v6 s

ide



Final 69

Figure 45 RTP relay example scenario

Figure 45 depicts an example scenario to illustrate the creation of receivers and senders during the traversal of an initial packet. The IPv4 source sends from its port number 8100 and the IPv6 target receives at its port number 1200. The input port number which is used by the RTP relay is determined when the mapping is installed and the output port number when the first packet is processed. Figure 46 illustrates the data structures of sender and receivers after the initial mapping installation and after the first packet has been processed.

Lookup

table ForwardReceiver

Target address:[2001:6aeb::24]:1200

Receive socket:193.175.135.177:18002

Link to next sender

Forward Senders

BackwardReceiver

Target address:193.37.78.128:8100

Receive socket:[2001:6aeb::17]:18004

Link to sendersTimestamp

Flag = No

Link to next sender

Sending socket:193.175.135.177:18002

Source address:[2001:6aeb::24]:1200

BackwardSender

Source address:193.37.78.128:8100

Sending socket:[2001:6aeb::17]:18004

Link to senders

TimestampFlag = Yes

Figure 46 Example data structures

2.3.6 Mapping deletion If a mapping is not used anymore, it can be explicitly deleted by an “UNMAP” request. In this request, the target address and port and the address and port of the RTP relay, where packets are received, are the parameters to the request. The worker process will then search all the receivers for the matching target address and receive socket. If it is found, a sanity check is performed to make sure the receiver was installed by a “MAP” request. This can be determined by looking at the flag. If it is set, the receiver is allowed to create new senders and this is only allowed to requested mappings. Then the resources of the receiver are released. The list of senders is examined next. From each sender, the sending socket is taken and a lookup is performed in the lookup table to find the backward receiver. The backward receiver’s resources are then released too and the backward sender is also released. The socket from the backward sender does not need to be closed, because it has already been closed when the forward receiver was released. This is done for every forward sender.

If the “UNMAP” request involves more then one adjacent port, the above procedure is executed for the named address and port and then for the subsequent port numbers too.

For every deleted receiver, its entry in the lookup table must be removed, to avoid dangling references to non-existing data structures.



Final 70

After all involved receivers and senders have been released, the worker will send an “UNMAPPED” reply to the master process, which forwards it to the IPv6/IPv4 SIP proxy.

2.3.6.1 Automatic mapping expiration Mapping can expire, if the timestamp in a receiver gets too old. This timeout is configurable in the configuration file. There is no thread that checks periodically for the receivers to have a timeout, as this would be a waste of processing power. There a re two situations, when receivers are checked for timeouts:

• The first one is in the phase of packet processing. If a packet is being received, one of the stamps is to check for the packet to have a timeout.

• The second one arises, if a mapping request could not be processed because of too many open sockets. In this case timeout checking is done to obtain free resources and install the requested mapping.

Automatic mapping deletion works different than explicit mapping deletion as described in the previous section, because here it is possible that a backward mapping is concerned. For instance if a backward mapping has never been used, because the target never sends back any data, it will be subject to automatic deletion. In such a case, the sockets of the backward receiver and the backward sender are not closed, because they belong also to the forward mapping, which can still be active. The entry in the lookup table will be removed and the backward receiver and sender structures are released.

If a forward mapping expires, it is removed in the same way as if it was removed explicitly, because it is assumed that the backward mapping will also be unused, when the forward communication stops.

2.4 Testing The software components, the IPv6/IPv4 SIP proxy server, and the RTP relay have been tested in a heterogeneous network environment, which features IPv4 driven links using IPv6. Both network parts do not overlap, which means that a link is never used by both protocols.


IPv6 Proxy & Registrar IPv4 Proxy & Registrar

IPv4/IPv6 SIP Proxy &RTP relay

EthernetHub

SwitchedEthernet

Figure 47 Testing network

Figure 47 depicts the test network environment. The IPv6/IPv4 SIP proxy and the RTP relay reside on the same machine, which has two network cards installed, one for the IPv6 and one for the IPv4 network. The IPv6 network consists of an Ethernet hub, by which the IPv6 proxy and registrar server, the IPv6 phone and the IPv6/IPv4 SIP proxy and RTP relay are connected. The IPv4 side



Final 71

uses a switched Ethernet, by which the second interface card of the IPv6/IPv4 SIP proxy server and RTP relay are connected to the IPv4 phone and the IPv4 SIP proxy and registrar server.

The IPv6 phone is a softphone called “KPhone”. It is run under Linux and features a graphical user interface (GUI). The machine is a desktop PC with the symbolic name “durin.mobis.ip6”. Its IPv6 address is “2001:638:806:2001:207:e9ff:fe3e:d41f”. The SIP user who registers with the registrar is “72222”.

The IPv4 phone is a hardware phone from Cisco. Its symbolic name is “dhcp21.fokus.fraunhofer.de” and its IPv4 address is “195.37.78.21”. The SIP user who registers with the IPv4 registrar is “72220”.

The machine which will serve as an IPv6 proxy and registrar has the symbolic name “ser.lab6.fokus.fraunhofer.de” and the address “2001:638:806:2001:202:b3ff:fe4d:c8e0”. It administrates contacts for the same SIP domain as its own symbolic name. There is no authentication necessary to register with this server. The routing logic is set up to route requests for the domain “oxany.fokus.fraunhofer.de” to the IPv6/IPv4 SIP proxy.

The machine which will serve as IP4 proxy and registrar has the symbolic name “oxany.fokus.fraunhofer.de” and the address “193.175.135.190”. It administrates contacts for the same SIP domain as its own symbolic name. There is no authentication necessary to register with this server. The routing logic is set up to route requests for the domain “ser.lab6.fokus.fraunhofer.de” to the IPv6/IPv4 SIP proxy.

The machine used for the developed components has the name “xhosa.fokus.fraunhofer.de”, which is resolvable to the IPv4 address “193.175.135.177” and is not resolvable to any IPv6 address. The machine has also the symbolic name “xhosa.mobis.ip6”, which is resolvable to the IPv6 address “2001:638:806:2001:250:4ff:fe56:196b” and is not resolvable to any IPv4 address.


IPv6 Proxy & Registrar IPv4 Proxy & RegistrarIPv4/IPv6 SIP Proxy &

RTP relay

193.175.135.177

193.175.135.190oxany.fokus.fraunhofer.de

[email protected]@[2001:638:806:2001:207:e9ff:fe3e:d41f]

2001:638:806:2001:202:b3ff:fe4d:c8e0ser.lab6.fokus,fraunhofer.de

2001:638:806:2001:250:4ff:fe56:196b

Figure 48 Testing communication paths

Figure 48 illustrates the communication paths between the components of the testing scenario and the addresses of the components. Testing is done by six transactions. They include the initiation of a call from each phone and termination of the session by each phone in each call. Thus each call is established twice. For the first call, the call initiator will terminate the call, while for the second call the callee will terminate the call. Thus four calls are made. Table 3 lists these calls.



Final 72

Call initiator Call terminator

72222@[2001:638:806:2001:207:e9ff:fe3e:d41f] [email protected]

(callee)

72222@[2001:638:806:2001:207:e9ff:fe3e:d41f] 72222@[2001:638:806:2001:207:e9ff:fe3e:d41f] (caller)

[email protected] 72222@[2001:638:806:2001:207:e9ff:fe3e:d41f] (callee)

[email protected] [email protected]

(caller)

Table 3 Testing calls

All calls have been established and terminated successfully. The calls were repeated in random order to ensure the stability of the system. After the successful testing session, the Cisco hardphone was removed from the network. It was replaced by an IBM laptop with the Linux operating system and another KPhone installed on it, which has been configured to do IPv4 only. The above tests have been repeated and turned out to be successful. The same tests have then been performed with an ACT hardphone as IPv4 phone.

2.5 Summary and future In this work a solution for overcoming the gap between IPv4 and IPv6 for SIP based voice-over-IP communication has been developed. Existing techniques and ideas, like the dual stack, NAT-PT and STUN, for solving the problem have been analysed and discussed in detail. From these techniques, a solution scenario has been developed by splitting the problem into the one of signalling and of audio streaming. To this end two applications have been realized. The applications have been named “Mini SIP Proxy” (msp) and “UDP Forwarding Daemon” (ufwdd) and come with the open source license. They are both written in the programming language “C”.

The “msp” changes relevant information in the SIP messages, so that IPv4 phones can interchange signalling information with IPv6 phones. It also alters SDP information, so that audio communication over the IPv6/IPv4 borderline is possible. The “ufwdd” acts as an intermediate instance in the way of audio streams and shifts audio data containing UDP packets between the different protocol domains. Both applications interact over a well designed protocol.

The applications were implemented as independent programs to assure the re-usability of each component and to assure that they can be replaced transparently. Both programs have been designed in a way that processed data packets remain only for a short time in the network node before they are send out. The “ufwdd” is designed to be able to manage many concurrent audio connections. The “msp” is designed to be independent of the state of a call or transaction.

The applications are highly configurable by command line options as well as by a configuration file.

By using and implementing standards from the internet engineering task force (IETF), the applications are highly interoperable with products from other vendors. Because IPv6 is fully supported by “msp” and “ufwdd”, they are ready for the future of the internet.

The interoperability of the “msp” and “ufwdd” to other SIP devices was intensively tested and evaluated against different commercial SIP hard- and softphones. Furthermore, the “msp” and “ufwdd” have been tested and deployed in the European community project “6net”.



Final 73

During the realization of this work it became obvious that there are several possibilities for further features and future development.

In order to support more than one RTP relay, it would be useful, if the “msp” and “ufwdd” would communicate on a TCP basis, as TCP is proof against packet loss, which is an issue when “msp” and “ufwdd” do not reside on the same node.

Currently the RTP relay (ufwdd) is designed to handle one-on-one calls only. It is considerable to extend this to support conferencing over multicast.

Other additional functionality could be: • Own request routing for the “msp”. This way requests could bypass one SIP proxy after passing

the “msp”. It would also achieve a higher independency against a possible misconfiguration of the SIP proxies.

• “Record-Route” and “Route” processing, which is currently done by the SIP proxies, could be done by the “msp”.

• The functionality of changing SIP header fields and the SDP body could be integrated into existing SIP servers. By this only one SIP protocol stack must be maintained instead of two. A platform for this could be ser, because it features a modular architecture.

2 Parser and logger details

2.1 Parser details

The parser that has been implemented in the IPv6/IPv4 SIP proxy consists of four basic parsing functions, which are derived from the architecture of the ABNF. The ABNF features sequences, alternatives, repetition and alphabetical elements. Thus a rule which is defined by an ABNF can be reverse applied to a piece of the message to check whether this piece matches the rule and if so, to transform it into the internal data representation. As an example the parsing of the “Content-Length” header field is illustrated. The ABNF rule for this header field is:

( “Content-Length” / “l” ) HCOLON 1*DIGIT

This means that the string “Content-Length” or “l” is followed by a pattern which matches the HCOLON rule followed by a pattern which matches one or more repetitions of the DIGIT rule. To apply this rule to a message, the parser would first apply the parser function for alphabetical elements to check for the string “Content-Length” and if that fails, use the same parser function to check for the string “l”. If both checks fail, the message element cannot match the complete rule and the parser would try another rule to check for a different header field. Thus, the above rule can be written in a functional way: Function Parse_Content_length =

Parse_sequence (

Parse_alternatives (

Parse_string ( “Content-Length” ) ,

Parse_string ( “l” )

) ,

Parse_HCOLON () ,

Parse_repeat (1, UNLIMITED, Parse_DIGIT () )



Final 74

)

The function Parse_sequence gets a list of parsers, which must all succeed in order to make Parse_sequence succeed too. As soon as one of the parsers fails, the result will also be a failure.

The function Parse_alternatives gets a list of parsers, from which at least one must succeed in order to make Parse_alternatives succeed too. As soon as one of the parsers succeeds, the result will also be a success.

The function Parse_repeat gets a minimum, a maximum count and a parser. This function succeeds, if it can apply the parser at least the minimum number of times. It will try to apply it up to the maximum number of times. It fails if it cannot apply the parser at least the minimum number of times.

The function Parse_string gets a character string, and succeeds if the presented message starts with this string, else it fails.

The functions Parse_HCOLON and Parse_DIGIT have been constructed in the same way and realize the parsing for the appropriate rules.

Each constructed parsing function stores the obtained data in a structure, which has been set up by it, and returns it together with the information whether the parser succeeded or not. This way the structure is filled with data by each called parsing function.

Because “C” does not feature a function model like described above, it has been simulated by a hierarchical tree of function pointers and parameters to them. The following lines show the above example as part of the “C” data structure definition.

s_parser pse_cl[] = { { parse_string_nocase, "content-length", NULL }, { parse_string_nocase, "l", NULL }, { NOPARSER } } ; s_parser pse_clmain[] = { { parse_alternatives, pse_cl, NULL }, { parse_HCOLON, NULL, trigger_erase }, { PARSE_DIGITS, PARSE_DIGITS_PARA, trigger_cl }, { NOPARSER } } ; #define PARSE_CONLEN parse_sequence #define PARSE_CONLEN_PARA pse_clmain The first data set defines the parameters for the alternatives parser, while the second one defines the parameters for the sequence parser. The NOPARSER entry terminates the list. The “define” statements are giving a name to the newly constructed parser and its parameters for use in other parser definitions. The trigger functions do the conversion into the internal data representation. The trigger_cl function converts the returned data of its parser into a number for the value of the content length, while the function trigger_erase does not do any conversion, but simply erases what has matched so far.

2.2 Logging protocol

Logging of messages in the RTP relay is done by a separate log daemon, which is forked by the master process. The master then inherits its pipe to the logging process to the worker processes. Thus the master and the worker processes share the same pipe end to the logging process. This



Final 75

features a simple n-to-one point communication, as the operating system guarantees that messages are delivered in an atomic way, means that message boundaries are preserved.

Logging features include a log level, an originator type, the process id of the sender and the message to write to the log file. This information must be passed through the pipe to the logging daemon.

0x00Origin PIDLevel Message text

0 1 2 3 n4 . . . . . Byteoffset -1

Figure 49 Logging data format

Figure 49 depicts the format in which data is send through the pipe to the logging process. The level is the first byte, followed by an identifier for the originator type, which is either “Master” or “Worker”. The next two bytes are the process ID (PID) of the sender. This is then followed by the message text. The message text is terminated by a zero byte, because otherwise the reader process could not determine the end of the message.

3 User guide

3.1 UFWDD User guide

The UPD forwarding daemon (ufwdd) must be started before the IPv6/IPv4 SIP proxy in order to be ready for accepting mapping requests as soon as possible. It is launched from the command line and reads it configuration files. It is possible to name the path to a configuration file on the command line by placing an option, “-f”, followed by the filename on the command line. The synopsis for invoking ufwdd is:

ufwdd [-l<level>] [-f cfgfilename]

The log level can also be set on the command line, using the “-l” option which is followed by the number of the log level, which is between zero and five inclusive. A log level of zero means to stay completely quiet during all operations, while 5 means to show all log messages, including debugging messages.

The first configuration file which is being read is system wide, global configuration file “/etc/ufwdd/ufwdd.cfg”. After this, ufwdd tries to read the configuration file “ufwdd.cfg” in the current working directory. The named configuration file is read last and overrides the settings from the previously read configuration files. The configuration file is a text based file, which can be edited with any text character based editor program. The file consists of lines, which hold pairs of the name and value of a configuration option. The configuration options are as follows:

ADDR4 = <IPv4-address>

Example: ADDR4 = 193.175.135.177



Final 76

This defines the IPv4 address of the IPv4 side of the RTP relay. This address must exist and be bound to an existing network device, which is not the loopback device. The port range for media streams will be applied to this address.

ADDR6 = <IPv6-address>

Example: ADDR6 = 2001:638:806:2001:250:4ff:fe56:196b

This defines the IPv6 address of the IPv6 side of the RTP relay. This address must exist and be bound to an existing network device, which is not the loopback device. The port range for media streams will be applied to this address too.

CONTROLPORT = <port-number>

Example: CONTROLPORT = 4699

This option specifies the UDP port number at which the ufwdd accepts mapping requests. This port number applies to both, IPv4 and IPv6, because the RTP relay resides on a host with a dual stack, it cann accept mapping requests over IPv4 as well as over IPv6. The ufwdd binds with this port number to the empty IPv6 address, which enables it to receive message from all interfaces, including IPv4 interfaces. This is a special feature provided by the Linux kernel. PROCS = <number>

Example: PROCS = 4

This sets the number of worker processes that are created by the master process. The number of sockets that a worker can open is operating system dependent and varies between 64 and 1024. Thus this value adjusts the maximum total number of sockets owned by the RTP relay. For small environments even one worker can be enough, while in an environment where only 64 sockets are allowed per process this number can be around 16 to achieve the same number of sockets. The number of sockets also depends on the port number range, as it makes no sense to have e.g. more ports than possible open sockets.

PORTS = <first-port>:<number-of-ports>

Example: PORTS = 12000:200

This option defines the port range to use for media forwarding and applies to the IPv4 side as well as to the IPv6 side of the RTP relay.

To shut down the RTP relay, the following command has to be used, which kills all ufwdd related processed : “killall –9 ufwdd”



Final 77

3.2 MSP User guide

The IPv6/IPv4 SIP proxy (msp) is started from the command line. It does not use any configuration file, but reads all configuration options from the command line. Configuration options are being set by placing the name of the option on the command line followed by the value for this option. The options are as follows:

plog <filename>

Example: plog logs/packets.log

This option set the name of the packet log file. All received and transmitted SIP messages will be stored in this file. If this option is omitted, no logging of SIP messages is performed.

ufwdd <IPv4-address | IPv6-referenc>:<port-number>

Example: ufwdd [::1]:4699

The “ufwdd” option defines the address and port number where the RTP relay accepts mapping requests. The port number must match the RTP relays setting for the control port. Either an IPv4 or an IPv6 based address can be used. The example depicts the case when both software components reside on the same host.

proxy <host>:<port-number>

Example: proxy oxany.fokus.fraunhofer.de:5060

proxy ser.lab6.fokus.fraunhofer.de:5060

This option names the outbound proxys and must be issued twice, once for the IPv4 outbound proxy and once for the IPv6 outbound proxy. listen <IPv4-address | IPv6-referenc>:<port-number>

Example: listen 193.175.135.177:5062

listen [2001:638:806:2001:250:4ff:fe56:196b]:5062

The “listen” option sets the address and port where SIP messages are received. This option must be issued twice, one for the IPv4 side and once for the IPv6 side.

The following gives an example for a complete command line, which is broken down into multiple lines for readability.

msp plog packets.log

ufwdd [::1]:4699

proxy oxany:5060



Final 78

proxy ser.lab6.fokus.fraunhofer.de:5060

listen [2001:638:806:2001:250:4ff:fe56:196b]:5062

listen 193.175.135.177:5062

After start up, the msp will show its settings and wait for incoming SIP messages. The following lines illustrate an example output: msp version 1.0.9 starting. localhost = 127.0.0.1 localhost = ::1 packets will be logged to logs/packets.log ufwdd will be contacted at [::1]:4699 Using IPv4 outbound proxy oxany:5060

(193.175.135.190:5060) Using IPv6 outbound proxy ser.lab6.fokus.fraunhofer.de:5060

([2001:638:806:2001:202:b3ff:fe4d:c8e0]:5060) Listening on UDP [2001:638:806:2001:250:4ff:fe56:196b]:5062 Listening on UDP 193.175.135.177:5062

3.3 The start/stop scripts

In order to simplify the start up process of both software components, a start script has been developed, which concentrates configuration information by setting several environment variables for e.g. the IPv4 and IPv6 address to use, the control port for the ufwdd, etc. It then creates a configuration file for the ufwdd and starts both, the ufwdd and the msp with the appropriate options in the correct order. The script has lots of comments and is self explanatory.

In order to shut down both services, a script has been written to do this. It simply issues the “killall –9 ufwdd” and “killall –9 msp” commands to stop the processes.

The scripts are named “start” and “stop”. They can both be edited with any text based editor

3.4 System requirements

Hardware: The hardware platform should be a normal PC with an Intel x86 compatible CPU, which is clocked with at least 900MHz. There should be two network interface cards installed, one for the IPv4 connection, and one for the IPv6 connection. It is also possible to have only one network interface card installed, but it is not recommended as it would increase the latency in the media streams. There should not be less than 256 MB of system memory installed and about two Megabytes of hard disc space are required for installation.

Operating System: The system, which will host the IPv6/IPv4 SIP proxy and RTP relay must be a Linux based system with the Linux kernel version 2.4.20 or higher. The Linux kernel must be compiled with IPv6 support and the IPv6 kernel module must be loaded.



Final 79

Software: In order to compile the software components from source, a “C” compiler must be installed. It is recommended to use the “GNU C compiler” (gcc)6 version 3 or higher.

References

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, E.Schooler, “SIP: Session Initiation Protocol,” RFC 3261, IETF, June 2002

[2] G. Tsirtsis, P. Srisuresh, “Network Address Translation – Protocol Translation,” RFC 2766, IETF, February 2000

[3] T. Berners-Lee, R. Fielding, L. Masinter, “Uniform Resource Identifiers (URI): Generic Syntax,” RFC 2396, IETF, August 1998

[4] M, Handley, V. Jacobson, “SDP: Session Description Protocol,” RFC 2327, IETF, April 1998

[5] D. Mills, “Network Time Protocol (Version 3) Specification, Implementation,” RFC 1305, IETF, March 1992

[6] H. Schulzrinne, “RTP Profile for Audio and Video Conferences with Minimal Control,” RFC 1890, IETF, January 1996

[7] B.W. Kernighan, D.M. Ritchie, “The C Programming Language,” Prentice Hall, 1988, ISBN 0-13-110362-8

[8] B. Stroustrup, “The C++ Programming Language,” Addison-Wesley, 1997, ISBN 0-201-53992-6

[9] B. Carpenter, K. Moore, “Connection of IPv6 Domains via IPv4 Clouds,” RFC 3056, IETF, February 2001

[10] A. Newman, “Java: Referenz & Anwendung,” Que Publishing, 1997, ISBN 3-8272-1001-1

[11] R. Gilligan, E. Nordmark, “Transition Mechanisms for IPv4 Hosts and Routers,” RFC 2893, IETF, August 2000

[12] J. Rosenberg, J. Weinberger, C.Huitema, R. Mahy, “STUN – Simple Traversal of User Datagram Protocol (UDP) Through Network Address Translators (NATs),” RFC 3489, IETF, March 2003

[13] D. Crocker, Ed., P. Overell, “Augmented BNF for Syntax specifications: ABNF,” RFC 2234, IETF, November 1997

[14] M. Welsh, L. Kaufman, “Running Linux,” O’Reilly, 2002, ISBN 0596002726

[15] P. Mockapetris, “Domain Names – Concepts And Facilities,” RFC 1034, IETF, Nov 1987

[16] Schulzrinne H., Casner S., Frederick R., Jacobson V., “RTP: A Transport Protocol for Real-Time Applications,” RFC 3550, IETF, July 2003

[17] SCCP (Skinny Call Control Protocol), http://www.cisco.com/en/US/tech/tk652/tk701/tk589/tech_protocol_home.html

[18] H.323, International Telecommunications Union (ITU), http://www.itu.int/itudoc/itu-t/rec/h/

6 The GNU "C" Compiler can be obtained from http://www.gnu.org

http://www.cisco.com/en/US/tech/tk652/tk701/tk589/tech_protocol_home.html

http://www.cisco.com/en/US/tech/tk652/tk701/tk589/tech_protocol_home.html

http://www.itu.int/

Documents

D5.11 Realisation of IPv6/IPv4 VoIP Integration Scenarios · 2006. 2. 3. · Mitel, Snom, Pingtel, Freebit, and Siemens. Specific IPv6 based interoperation tests had been performed