SIP終端設備移動性在IPv4和IPv6網路之間的應用

國

立

交

通

大

學

資訊科學與工程研究所

碩

碩

碩

碩

士

士

士

士

論

論

論

論

文

文

文

文

SIP 終端設備移動性在 IPv4 和 IPv6 網路之間的應用

SIP Terminal Mobility between IPv4 and IPv6 Networks

研 究 生：葉哲華

指導教授：林一平 教授

吳坤熹 教授

中

中

中

中 華

華 民

華

華

民

民 國

民

國

國 九

國

九

九 十

九

十 五

十

十

五

五 年

五

年

年 七

年

七

七 月

七

月

月

月

SIP 終端設備移動性在 IPv4 和 IPv6 網路之間的應用

SIP Terminal Mobility between IPv4 and IPv6 Networks

研 究 生：葉哲華

Student：Che-Hua Yeh

指導教授：林一平

Advisor：Yi-Bing Lin

吳坤熹 Quincy Wu

國 立 交 通 大 學

資 訊 科 學 與 工 程 研 究 所

碩 士 論 文

A Thesis

Submitted to Institute of Computer Science and Engineering

College of Computer Science

National Chiao Tung University

in partial Fulfillment of the Requirements

for the Degree of

Master

in

Computer Science

July 2006

Hsinchu, Taiwan, Republic of China

SIP 終端設備移動性在 IPv4 和 IPv6 網路之間的應用

學生：葉哲華

指導教授：林一平 教授

吳坤熹 教授

國立交通大學資訊科學與工程學系（研究所）碩士班

摘

要

摘

摘

要

要

摘

要

Session Initiation Protocol (SIP)支援應用程式層的移動性。在這篇碩士論

文中，我們將會介紹 SIP 終端設備移動性(SIP Terminal Mobility)在 IPv4 和

IPv6 網路之間的應用以及其實作。我們在兩個 SIP 通訊軟體中實作了 SIP 終

端設備移動性，並且在純 IPv4 網路、純 IPv6 網路以及 IPv4 和 IPv6 之間作

其效率測試。實驗結果證明 SIP 終端設備移動性是可以充分有效應用在 IPv4

和 IPv6 網路之中。

SIP Terminal Mobility between IPv4 and IPv6 Networks

Student：Che-Hua Yeh

Advisors：Prof. Yi-Bing Lin

Prof. Quincy Wu

Institute of Computer Science and Engineering

National Chiao Tung University

ABSTRACT

Session Initiation Protocol (SIP) supports application layer mobility. In this

thesis, we will investigate SIP-based mobility across IPv4 and IPv6 networks.

The architecture designs based on two SIP libraries for SIP terminal mobility are

described, and the performance of SIP User Agents are measured from empirical

experiments in IPv4-only, IPv6-only and IPv4/IPv6 networks. The results show

that SIP terminal mobility across IPv4 and IPv6 networks can be efficiently

supported.

Acknowledgment

This thesis is the result of two years of work whereby I have been accompanied and

supported by many people. It is a pleasant that I have now the opportunity to express my

gratitude for all of them.

I would first like to thank Prof. Yi-Bing Lin (林一平) and Prof. Quincy Wu (吳坤熹) for

their guidance, insight and support throughout the preparation of this thesis.

I would like to thank Dr. Whai-En Chen (陳懷恩), Shiang-Ming Huang (黃祥鳴), and

Chia-Yung Su (蘇家永) for the helpful discussions about the design of SIP terminal mobility.

I would also like to thank my master committee members, Prof. Phone Lin (林風) and Prof.

Shun-Ren Yang (楊舜仁) for their helpful comments and suggestions.

My colleagues of Laboratory 117 all gave me the feeling of being at home at work. Many

thanks for being your colleage.

Finally, I would like to thank my families and all my friends who ispire me or make me feel

confidence to accomplish this thesis.

Che-Hua Yeh

July 2006

Contents

摘 要 …… ……… …… ………… ……… …… ………… ……… …… ………… ……… i

ABSTRACT……….…………ii

Acknowledgment………iii

Contents………iv

List of Figures………vi

List of Tables………vii

Chapter 1

Introduction………1

1.1 SIP……….1

1.2 SIP Terminal Mobility………..6

1.3 SIP Terminal Mobility between IPv4 and IPv6 Networks……….7

1.4 DAD in IPv6 Networks………..10

Chapter 2

Two SIP Terminal Mobility Implementations………12

2.1 eXosip Implementation………13

2.2 RADVISION Implementation……….16

Chapter 3

Performance Evaluation and Comparison………..20

3.2 Interoperability………25

Chapter 4

Conclusions……….28

Bibliography………30

Appendix A The SIP Mobility Module Program in the eXosip Implementation…………32

A.1 AddressChange.h………32

A.2 AddressChange.cpp………33

A.3 CSIPUACore.h………35

A.4 CSIPUACore.cpp (partial code)……….39

Appendix B The SIP Mobility Module Program in the RADVISION Implementation…47

B.1 NTP_sipmobility.h………47

List of Figures

Figure 1. SIP terminal mobility procedure….……….……….……….….3

Figure 2. SIP INVITE message and re-INVITE message……….…..……….5

Figure 3. Network configuration for SIPv6 Translator………. ……….9

Figure 4. NCTU SIP UA architecture………13

Figure 5. Dual-Stack SIP UA architecture………17

Figure 6. The delays for switching a RTP session from one AP to another AP…………21

List of Tables

Table 1. D3 and D4 delays for RADVISION, eXosip, and NDDS implementations…….23

Table 2. D3 and D4 standard derivations for the RADVISION implementation…………24

Table 3. D3 and D4 delays between NCTU SIP UA and other SIP UAs………27

Chapter 1

Introduction

Nowadays many users have two independent communication systems on their desktops –

a telephony network and a computer network. With an effort to converge these two

traditionally independent services, many service providers begin promoting the Voice over

Internet Protocol (VoIP) technology, which enables us to make telephone calls using a

broadband Internet connection instead of a regular telephone line. In VoIP industry, Session

Initiation Protocol (SIP) developed by Internet Engineering Task Force (IETF) is emerging

and widely adopted as the signaling protocol of VoIP. Meanwhile, as VoIP technology is

applied to both fixed and mobile users, it becomes an important issue to allow computers and

communication devices to maintain connection in a mobile environment. In this thesis, we

will investigate SIP-based mobility across IPv4 and IPv6 networks. The architecture design

on the protocol stack for SIP terminal mobility is described, and the performance of SIP User

Agents are measured from empirical experiments.

1.1 SIP

Session Initiation Protocol (SIP) is an application-layer signaling protocol for Internet

multimedia session establishment, modification, and termination [1]. All SIP messages are

either requests or responses. Six basic methods of SIP are defined in [1]: INVITE, ACK, BYE,

ACK method is used to confirm that the client has received a final response to an INVITE

request. The BYE method is used to terminate a call. The CANCEL method is used to cancel

a pending SIP request before the final response is received. The OPTIONS method is used to

query the capabilities of SIP servers. The REGISTER method is used to register IP address

information to a SIP Registrar. Meanwhile, SIP has the following response codes: 1xx for

informational responses, 2xx for successful responses, 3xx for redirection responses, 4xx for

client failure responses, 5xx for server failure responses, and 6xx for global failure responses.

Figure 1 illustrates the SIP registration and call setup procedure in Steps 1-8. Suppose

that a Mobile Host (MH) locates in Network A, and a SIP multimedia session is established

between the MH and the Correspondent Host (CH), where both the MH and the CH are SIP

User Agents (UAs).

The SIP Proxy, which also acts as a SIP Registrar here, can accept the

REGISTER requests, record the IP addresses of SIP UAs, and forward SIP messages to

registered IP addresses of destination SIP UAs. In the figure, the host names of the MH, the

CH and the SIP Proxy are “pc1.club.tw” (IPv4 address: 1.1.1.1), “pc2.club.tw” (IPv4 address:

2.2.2.2), and “sip.club.tw” (IPv4 address: 3.3.3.3), respectively. The details of Steps 1-8 are

described as follows.

Steps 1 and 2. The CH registers its IP address to the SIP Proxy with a REGISTER

request, and the SIP Proxy replies a 200 OK response to indicate the registration is

successful.

Step 3. The MH sends an INVITE request via Network A to the SIP Proxy. Figure 2 (a)

shows the INVITE message format with the Session Description Protocol (SDP)

content. The request URI in the message is “sip:[email protected]” (Figure 2 (1)). The

username part of the request URI (“CH”) is used by the SIP Proxy to retrieve the CH’s

registered IP address.

Figure 1. SIP terminal mobility procedure

Steps 4-6. The SIP Proxy sends a 100 Trying response to notify the MH that the SIP

Proxy has received the INVITE request and is processing the request. The SIP Proxy

then forwards the INVITE request to the CH. After receiving the INVITE request, the

CH alerts the called party and sends a 180 Ringing response to the MH through the

SIP Proxy.

Steps 7 and 8. The CH answers the call and sends a 200 OK response to the MH

through the SIP Proxy indicating that the call is accepted. The IP address of the CH is

sent back to the MH through the 200 OK message

so that a media session is

established between the MH and with CH. In this way, during the signaling process

both the MH and the CH learns the IP address of each other, so the MH can contact the

CH directly in the subsequent SIP messages and media sessions. The MH sends an

ACK message to the CH to confirm the media session establishment.

After Step 8, the media session is established between the MH and the CH without

involving the SIP Proxy, and the SIP basic call setup procedure is finished. Steps 9-12 in

Figure 1 are the SIP terminal mobility procedure, which will be described in next section.

INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=8653 To: <sip:[email protected]>

Call-ID: [email protected] CSeq: 20 INVITE

Via: SIP/2.0/UDP 1.1.1.1:5060;branch=z9hG4bK6608 Contact: <sip:[email protected]:5060>

Max-Forwards: 5

User-Agent: Lab117-PoC-VoIP-UA/0.0.1 Subject: test

Expires: 120

Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, REFER, SUBSCRIBE, NOTIFY, MESSAGE

Content-Type: application/sdp Content-Length: 217 v=0 o=userX 20000001 20000001 IN IP4 1.1.1.1 s=A call c=IN IP4 1.1.1.1 t=0 0 m=audio 9000 RTP/AVP 0 8 18 3 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 (a) INVITE (b) re-INVITE (IPv4)

INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=8653 To: <sip:[email protected]>;tag=10651 Call-ID: [email protected]

CSeq: 21 INVITE

Via: SIP/2.0/UDP 4.4.4.4:5060;branch=z9hG4bK41 Contact: <sip:[email protected]:5060> Max-Forwards: 5 User-Agent: Lab117-PoC-VoIP-UA/0.0.1 Subject: test Content-Type: application/sdp Content-Length: 217 v=0 o=userX 20000001 20000002 IN IP4 4.4.4.4 s=A call c=IN IP4 4.4.4.4 t=0 0 m=audio 9000 RTP/AVP 0 8 18 3 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 SIP headers SDP content SIP headers SDP content

4

1

2

3

6

7

INVITE sip:[email protected] SIP/2.0 From: <sip:[email protected]>;tag=8653 To: <sip:[email protected]>;tag=10651 Call-ID: [email protected]

CSeq: 21 INVITE

Via: SIP/2.0/UDP [2001:5:5:5::5]:5060;branch=z9hG4bK12b85 Contact: <sip:MH@[2001:5:5:5::5]> Content-Type: application/SDP Content-Length: 283 v=0 o=rv-test-app 20000001 20000002 IN IP6 2001:5:5:5::5 s=A call c=IN IP6 2001:5:5:5::5 t=0 0 m=audio 9000 RTP/AVP 0 8 18 3 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:18 G729/8000 a=rtpmap:3 GSM/8000 (c) re-INVITE (IPv6) 10

9

SIP headers SDP content

8

12

5

11

1.2 SIP Terminal Mobility

SIP supports four types of mobility, i.e. terminal mobility, session mobility, personal

mobility, and service mobility [2]. Terminal mobility is the capability to keep a session alive

after the terminal device moves to a different IP subnet. Session mobility is the capability to

maintain a session while the user is changing the terminal device. Personal mobility allows a

user to become reachable at different terminal devices by the same logical address. Service

mobility is the capability to access the user’s services (e.g. address book, speed dialing, buddy

lists) while the user is moving or changing devices and network service providers.

Figure 1 illustrates the SIP terminal mobility procedure in IPv4/IPv6 networks. Steps 1-8

is the basic SIP registration and call setup procedure described in the previous section. Steps

9-12 are the SIP terminal mobility procedure and the details are described as follows.

Step 9. During the SIP multimedia session, the MH moves from Network A (IPv4) to

another Network B (IPv4). The MH acquires a new IP address 4.4.4.4 through, for

example, Dynamic Host Configuration Protocol (DHCP) in Network B.

Step 10. The MH sends a re-INVITE request to the CH. The format of the re-INVITE

message is shown in Figure 2 (b). In this message, the request URI, “sip:

[email protected]” (Figure 2 (5)), is the contact address of the CH which is known by

the MH at Step 4. Note that the header fields “From” (indicating the calling party),

“To” (indicating the called party), and “Call-ID” (the call session identifier) must be

the same as those in the INVITE message (see Figure 2 (2) and Figure 2 (6)). The

header field “Contact” is updated to the MH’s new IP address (from 1.1.1.1 to 4.4.4.4;

see Figure 2 (3) and Figure 2 (7)). This new address will be used by the CH to contact

the MH. The SDP content is also updated in the re-INVITE message. Specifically, the

connection address field (“c=”) is changed to the MH’s new IP address (from 1.1.1.1

to 4.4.4.4; see Figure 2 (4) and Figure 2 (8)).

In the above procedure, the re-INVITE message notifies the calling party to change

media transmission parameters. Its format is exactly the same as the INVITE message. Steps

11-12 are the same as Steps 7-8 except that the messages pass through Network B instead of

Network A.

1.3 SIP Terminal Mobility between IPv4 and IPv6

Networks

In the previous studies (see [2] and [3]), SIP terminal mobility was discussed in

IPv4-only or IPv6-only networks. This thesis elaborates SIP terminal mobility between IPv4

and IPv6 networks. The performance results measured from empirical experiments will also

be investigated.

To support SIP terminal mobility between IPv4 and IPv6 networks, the MH must be

equipped with the dual-stack SIP UA which supports both IPv4 and IPv6 SIP protocols. On

the other hand, the CH can be IPv4-only, IPv6-only, or dual-stack.

Suppose that the MH connects a SIP session with a dual-stack CH through Network A

(IPv4). Standard SIP call setup procedure is executed as described in Section 1.1. The MH

activates the SIP terminal mobility procedure after moving to Network B (IPv6). In this

network, the MH is assigned an IPv6 address through IPv6 address autoconfiguration [4].

Since the CH is able to receive both IPv4 and IPv6 SIP messages, the CH receives the

re-INVITE message sent from the MH through Network B (IPv6). The message flow is

exactly the same as that shown in Figure 1 except that messages in Steps 10-12 are

transported by IPv6. Figure 2 (c) shows the re-INVITE message in IPv6. The request SIP URI

in the re-INVITE message is “sip: [email protected]” (see Figure 2 (9)) which is the contact

address of the CH. Because the CH is located in an IPv4/IPv6 dual-stack network, an IPv4

address and an IPv6 address are assigned to the host name, “pc2.club.tw”. Therefore the MH

can query the Domain Name Service (DNS) server to obtain the CH’s IPv6 address through

this host name and the re-INVITE can be sent to the CH correctly through IPv6 network (i.e.,

Network B). The connection address (see Figure 2 (12)) of the re-INVITE message is now an

IPv6 address. The header fields “From”, “To”, and “Call-ID” in the re-INVITE message (see

Figure 2 (10)) must be the same as those in the INVITE message (see Figure 2 (2)) as

described in the previous section. The header field “Contact” is updated to the MH’s new

IPv6 address (see Figure 2 (3) and Figure 2 (11)).

Consider another scenario where the CH is located in an IPv4-only network. The simple

SIP terminal mobility procedure described above will not work in that case. After the MH

moves from Network A (IPv4) to Network B (IPv6) and activates the SIP terminal mobility

procedure, the re-INVITE message will not reach the CH because IPv4 routing system is

independent from IPv6 routing system. To resolve this issue, SIPv6 Translator was suggested

[5]. The SIPv6 Translator consists of two components, NAT-PT (Network Address Translation

and Protocol Translation) for IP layer address translation [6] and SIP ALG (Application Level

Gateway) for SIP layer address translation [7]. The SIPv6 Translator supports communication

between an IPv4 SIP UA and an IPv6 SIP UA. Figure 3 shows how the SIPv6 Translator is

configured in this scenario. After the MH moves to Network B (IPv6), the MH activates SIP

terminal mobility. Since the CH is in an IPv4 network, the MH sends the re-INVITE request

to the SIPv6 Translator. The SIPv6 Translator replaces the IPv6 address information in the

re-INVITE message with its own IPv4 address, and the re-INVITE message is sent to the CH.

After the CH accepts the re-INVITE request, the 200 OK response is sent back to the SIPv6

Translator. Similarly, the address information in the 200 OK response is replaced by the IPv6

address of the SIPv6 Translator. After the MH sends the ACK message, the MH and the CH

send RTP packets to the SIPv6 Translator, and the SIPv6 Translator forwards the packets to

the CH and the MH respectively. Thus, the RTP session between MH and CH is re-established

through the SIPv6 Translator.

Figure 3. Network configuration for SIPv6 Translator

Details of SIPv6 translator is out of the scope of this thesis and can be found in [5]. In

this thesis, we will focus on dual-stack CH such that SIP terminal mobility between IPv4 and

IPv6 networks can be supported by modifying the SIP UA of the MH only. In this scenario, no

network node (such as SIPv6 translator) is required, and the SIP UA of the CH needs not be

modified.

1.4 DAD in IPv6 Networks

The IPv6 stateless autoconfiguration feature, which enables a host to automatically

configure its interfaces with new IPv6 addresses [4]. The automatic configuration of a host

interface is performed without the use of a server, such as a DHCP server, or manual

configuration. During the procedure of the automatic configuration, Duplicate Address

Detection (DAD) is an algorithm to ensure that all configured addresses will be unique on a

given link before assigning them to the local network interface. In this section, we will

describe the IPv6 stateless autoconfiguration procedure and how DAD is executed.

The automatic configuration of a host interface works in the following way: when a host

moves to an IPv6 network, the host will receive the Router Advertisement (RA). The RA is

either periodically sent by the IPv6 router, or be delivered to an IPv6 host as the IPv6 router

received a Router Solicitation (RS) from the IPv6 host. After receiving the RA the host is

allowed to generate its own IPv6 addresses (referred to as the tentative address) according to

the prefix information contained in the RA. In [4] an algorithm is described on how to

automatically compute the IPv6 address of an IPv6 host. For example, if the Ethernet card of

a host has the MAC address 00:11:5B:3A:71:E8, then when it moves to a subnet with prefix

2001:238::/64, its 48-bit MAC address will be converted to IEEE EUI-64 format

[8], which is

a 64-bit interface identifier 0211:5BFF:FE3A:71E8. The IPv6 address

2001:238::0211:5BFF:FE3A:71E8 is (temporarily) assigned to the host. Since the tentative

address may be duplicated, the DAD algorithm is executed to ensure there is no address

confliction before the host can send packets via this IPv6 address. In the DAD process, after

constructing the IPv6 address according to the received IPv6 subnet prefix, the host

broadcasts a Neighbor Solicitation (NS) message on the local link. If no response is received

within a pre-determined period, this address will be assigned to the network interface. The

average DAD delay ranges from 1 to 2 seconds if there is no address confliction [4].

Chapter 2

Two SIP Terminal Mobility

Implementations

To implement SIP terminal mobility in a SIP UA, an extra component is added into the

SIP UA. The component must support the following functions: (1) It can detect the

modification of local IP addresses, retrieve local IP addresses, select new local IP address, and

(2) instruct the SIP UA to send the re-INVITE message. In our implementations, the Winsock

API and IP Helper API provided by Microsoft platform are utilized to implement these

functions.

There are several choices of SIP libraries for SIP programmers, such as eXtended osip

(eXosip [9]), sipX [10] , RADVISION SIP Toolkit [11], Signalware SIP [12], jSIP [13], and

JAIN-SIP [14]. Among these SIP libraries, eXosip, sipX, RADVISION SIP Toolkit, and

Signalware SIP are written in C and C++, while jSIP and JAIN-SIP are written in Java.

Moreover, RADVISION SIP Toolkit and Signalware SIP are commercial products, while the

others are free softwares. All these SIP libraries support both Unix-based and Win32

platforms, so it is convenient for programmers to develop their applications on various

platforms. In our study, we implemented

SIP terminal mobility based on eXosip and

RADVISION SIP Toolkit. In the eXosip implementation, SIP terminal mobility is

implemented for homogeneous IPv4-only or IPv6-only networks. In the RADVISION

implementation, SIP terminal mobility is implemented for heterogeneous IPv4/IPv6 networks.

2.1 eXosip Implementation

The eXosip library is an open-sourced library based on the GNU osip library [15], which

provides software developers an easy and powerful interface to implement SIP applications.

The eXosip library provides a high-level API for using the osip library to support SIP

multimedia session establishment. In the SIP UA designed and implemented in National

Chiao Tung University (NCTU) [16], eXosip is utilized to implement the SIP protocol stack.

However, due to the limitation of current version of eXosip, at any single moment eXosip can

only bind either an IPv4 address or an IPv6 address to send/receive SIP messages. Therefore

the NCTU SIP UA can only support SIP terminal mobility for homogeneous IPv4-only or

IPv6-only environments.

Figure 4 illustrates the software architecture of the NCTU SIP UA. In this figure, gray

boxes represent the SIP UA components we implemented, and white boxes are open-sourced

libraries, Winsock and IP Helper APIs, and network protocols provided by the operating

system.

In the SIP Core module (Figure 4 (a)), eXosip is utilized to implement the SIP protocol

stack. The SIP Core module supports SIP communication with other SIP UAs. This module is

invoked by the Call Control module (Figure 4 (b)) to execute the call setup or teardown

procedure following the standard SIP protocol. The Call Control module instructs other

NCTU SIP UA modules to handle call related activities such as call establishment, call answer,

call rejection, etc. The RTP Core module (Figure 4 (c)) utilizes the oRTP library [17] to

implement Real-time Transport Protocol (RTP) stack under GNU Lesser General Public

License (LGPL). This module builds RTP sessions between SIP UAs. The Multimedia

Control module (Figure 4 (d)) supports audio functions such as wave input and output. This

module plays the received voice data, and converts the user voice into RTP packets through

the RTP Core module. The User Interface module (Figure 4 (e)) supports interfaces for

interactions between a user and the SIP UA. The SIP Mobility module (Figure 4 (f)) supports

the SIP terminal mobility. It detects the modification of local IP address by receiving an event

from Winsock module, retrieves IP addresses through IP Helper API, selects new local IP

address and instructs the SIP Core module to send the re-INVITE message.

Figure 4 illustrates the interaction between NCTU SIP UA modules during SIP terminal

mobility. At the startup of NCTU SIP UA, the SIP Mobility module invokes the Winsock

function WSAIoctl( ) with parameter "SIO_ADDRESS_LIST_CHANGE" to subscribe to

the notification event for local address list modification. This list includes all IP addresses

assigned to the host. Through function WSACreateEvent( ), the SIP Mobility module names

the notification event as Address-Change. Through function WSAEventSelect( ), it

requests the Winsock module to trigger this event when any of the local IP addresses are

modified, added, or deleted. With a polling mechanism, the SIP Mobility module detects the

Address-Change event.

Suppose that an IPv6 SIP multimedia session is established between the MH and the CH.

The local address list of the MH contains an IPv6 address initially. When the MH moves to

another IPv6 network, the MH obtains a new IPv6 address, and the previous IPv6 address

becomes no longer available. When the local address list is modified by the operating system,

the Address-Change event is triggered and detected by the SIP Mobility module. Then the

following steps are executed.

Steps 1 and 2. When the SIP Mobility module detects the Address-Change event, it

invokes GetAdaptersAddresses( ) in IP Helper API to retrieve the local address list.

If the current address bound by the SIP UA is not in the list, then another address from

the list is selected as the new address of the SIP UA. Since the MH moves to another

network and is assigned a new IPv6 address, the new IPv6 address is selected as the

new local address.

Step 3. At the startup of the NCTU SIP UA, the eXosip library will create a UDP socket

for SIP signaling [9]. The socket is bound to the local IP address. After the IP address

is changed, the SIP Mobility module modifies this socket with the new IPv6 address

through the function eXosip_modify_ip( ) provided by the SIP Core module.

event SIPCore_IPCHANGE_NEWIP_NOTIFY to notify the Call Control module.

Steps 5 and 6. The Call Control module sends the re-INVITE request to the CH using

the new IPv6 address through the SIP Core module. Then the MH receives the IPv6

200 OK response from the CH indicating that the CH accepts the re-INVITE message.

Steps 7 and 8. The MH sends an IPv6 ACK message to the CH to confirm the media

session establishment. The Call Control module instructs the Multimedia Control

module to suspend the RTP session and then resume the RTP session with the new

IPv6 address.

After Step 8, the RTP session between the MH and the CH is re-established.

The above example shows the procedure for IPv6-only SIP terminal mobility. For

IPv4-only SIP terminal mobility, the message flow is the same, except that the SIP messages

are sent and received through IPv4.

2.2 RADVISION Implementation

The RADVISION SIP Toolkit is a commercial solution for SIP implementations.

Compared with the eXosip library, the RADVISION SIP Toolkit provides more powerful

functions, such as SIP signaling compression and the ability of delivering SIP messages over

SCTP and TLS. One important feature is that the RADVISION SIP Toolkit supports IPv4 and

IPv6 dual-stack, and it can bind IPv4 and IPv6 addresses concurrently for sending/receiving

SIP messages. (This feature is not supported in current eXosip library.) Therefore, we utilize

the RADVISION SIP Toolkit to implemented SIP terminal mobility for heterogeneous

IPv4/IPv6 networks.

Figure 5 illustrates the dual-stack SIP UA architecture. In this figure, gray boxes

represent the SIP UA components we implemented based on the RADVISION SIP Toolkit.

The components with white color are Winsock API and network protocols provided by the

operating system.

Figure 5. Dual-Stack SIP UA architecture

Compared with Figure 4, the Call Control module (Figure 5 (b)), the Multimedia Control

module (Figure 5 (d)), the User Interface module (Figure 5 (e)) and the SIP Mobility module

(Figure 5 (f)) provide the same functions as those described in the NCTU SIP UA. The SIP

module and the RTP module also provide the same functions as the SIP Core module and the

RTP Core module described in the NCTU SIP UA, but here RADVISION SIP Toolkit is

utilized to implement these two modules. Compared with the NCTU SIP UA, the main

differences include: (1) In the Call Control module, a flag “addrTypePrefer” indicates the

available. (2) In the SIP module, the function GetAdaptersAddresses( ) in IP Helper API

used to retrieve local IP addresses is replaced by the function WSAIoctl( ) with parameter

“SIO_ADDRESS_LIST_QUERY” in Winsock API. Therefore the IP Helper API is not

needed in this dual-stack SIP UA. (3) The function WSAIoctl( ) with parameter

“SIO_ROUTING_INTERFACE_QUERY” is invoked in the SIP Mobility module to select

the new local address. This function can select a proper source address from local address list

to connect to the destination address. Therefore, we can use this function to automatically

determine the new local address and need not manually select it.

Figure 5 illustrates the interaction between dual-stack SIP UA modules during SIP terminal

mobility. At the startup of dual-stack SIP UA, the SIP Mobility module invokes the Winsock

function WSAIoctl( ) with parameter "SIO_ADDRESS_LIST_CHANGE" to subscribe to

the notification event for local address list modification. The details are the same as described

in Section 2.1.

Suppose that an IPv4 SIP multimedia session is established between the MH and the CH.

The local address list of the MH contains an IPv4 address initially. When the MH moves to an

IPv6 network, the MH obtains an IPv6 address through IPv6 address autoconfiguration, and

the previous IPv4 address becomes no longer available. When the local address list is

modified by the operating system, the Address-Change event is triggered and received by

the SIP Mobility module. Then the following steps are executed.

Step 1. When the SIP Mobility module detects the Address-Change event, it invokes

WSAIoctl( ) with parameter “SIO_ADDRESS_LIST_QUERY” to retrieve the local

address list.

If the current address used by the SIP UA is not in the list, then WSAIoctl( )

with parameter “SIO_ROUTING_INTERFACE_QUERY” is invoked to select another

address from the list as the new address of the SIP UA. Suppose that the IPv6 address

acquired from the IPv6 network is selected as the new local address.

Steps 2 and 3. The SIP Mobility module instructs the Call Control module to add the new

address to send SIP messages and remove the old address. Then the Call Control module

requests the Multimedia Control module to suspend the RTP session.

Steps 4 and 5. The Call Control module sends the re-INVITE request to the CH using the

new IPv6 address through the SIP module. Then the MH receives the IPv6 200 OK

response from the CH indicating that the CH accepts the re-INVITE message.

Steps 6 and 7. The MH sends an IPv6 ACK message to the CH to confirm the media

session establishment. The Call Control module instructs the Multimedia Control

module to resume the RTP session with the new IPv6 address.

Chapter 3

Performance Evaluation &

Comparison

This chapter investigates the performance of SIP terminal mobility. As shown in Figure 6,

the delays for switching a RTP session in a wireless LAN environment can be divided into the

following parts [18]: D1 is the delay for radio link switching from one Access Point (AP) to

another. D2 is the delay for detecting a new router and a new IP subnet after switching AP,

where the MH detects that it has moved to a new subnet by detecting the IP addresses change

of the host or by listening to the IPv6 Router Advertisement. D3 is the delay between when

the MH activates the SIP terminal mobility procedure and when it receives the 200 OK

response for the re-INVITE request. D5 is the delay between when the MH receives the 200

OK message and when the media transmission is resumed. Note that depending on the SIP

implementations (to be elaborated later), the RTP session suspension is conducted in either D3

or D5. In [18], D1, D2, D3 and D4=D3+D5 are also utilized to measure the performance of

SIP terminal mobility. Since both D1 and D2 are link-layer and IP-layer delays, they can be

independently evaluated without affecting the application-level performance for SIP terminal

mobility. This thesis will focus on D3, D4, and D5.

Figure 6. The delays for switching a RTP session from one AP to another AP

3.1

Performance Evaluation in IPv4 and IPv6

Networks

Figure 7 illustrates the IPv4/IPv6 experimental environment in our study. The MH and the

CH are our SIP UA implementations. Two IPv4/IPv6 dual-stack routers (Router A and Router

B) running FreeBSD version 6.1 are connected directly through an Ethernet cable. Router A

connects to the CH through Subnet 1. Router B connects to two 802.11b APs (D-Link

DWL-1000 APs) through Subnet 2 and Subnet 3, respectively. Initially, the MH in Subnet 2

establishes a SIP session with the CH in Subnet 1. Then the MH moves from Subnet 2 to

Subnet 3. SIP terminal mobility delays (i.e., D3 and D4) during the MH’s movement are

measured.

Figure 7. The experimental environment

Table 1 shows the measured D3, D4, and D5 delays for our SIP terminal mobility

implementations based on RADVISION SIP Toolkit and eXosip. This table also shows the

delays for SIP terminal mobility in Columbia University’s SIP UA reported by N. Nakajima,

A. Dutta, S. Das and H. Schulzrinne [18], which is indicated as NDDS in the table. In the

table, Scenario 1 is SIP terminal mobility for IPv4-only networks, where the MH moves from

one IPv4 network to another. Scenario 2 is SIP terminal mobility for IPv6-only networks,

where the MH moves from one IPv6 network to another. In Scenario 2, (a) is the scenario

without DAD and (b) is the scenario with DAD. Scenario 3 is SIP terminal mobility between

IPv4 and IPv6 networks. In Scenario 3, (a) is SIP terminal mobility where the MH moves

from an IPv4 network to an IPv6 network without DAD, (b) is the scenario for the MH moves

from an IPv4 network to an IPv6 network with DAD, and (c) is SIP terminal mobility where

the MH moves from an IPv6 network to an IPv4 network.

For the RADVISION implementation, we observe that Scenarios 1, 2(a), 3(a), and 3(c)

have almost the same D4 performance. In Scenario 2(b) and 3(b), the D3 delays are about

1.25 seconds longer than those measured in Scenario 2 (a) and 3(a). This extra delay is

contributed by DAD. Therefore if the DAD procedure is not executed, the delays for

IPv4/IPv6 scenarios are close to those for the IPv4-only and IPv6-only cases. Table 2 shows

the standard derivations for D3 and D4 in the RADVISION implementation. The standard

derivations for all scenarios except for those with DAD are roughly the same. From the above

discussion, we conclude that SIP terminal mobility implementation between IPv4 and IPv6

networks can be as efficient as those for IPv4-only and IPv6-only networks.

Table 1. D3 and D4 delays for RADVISION, eXosip, and NDDS implementations

Scenario Implementation D3 (ms) D5 (ms) D4 (ms) RADVISION 102.5 11.2 113.7 Scenario 1 : IPv4-only eXosip 58.1 173.6 231.7 RADVISION 102.4 10.7 113.1 eXosip 55.2 168.2 223.4 Scenario 2 (a) : IPv6-only (without DAD)

NDDS 161.6 257.0 418.6 RADVISION 1346.6 10.6 1357.2 eXosip 1310.6 168.4 1479.0 Scenario 2 (b) : IPv6-only (with DAD)

NDDS 3932.2 255.5 4187.7 Scenario 3 (a) : IPv4 to IPv6 (without DAD) RADVISION 102.0 10.2 112.2 Scenario 3 (b) : IPv4 to IPv6 (with DAD) RADVISION 1345.0 10.6 1356.4 Scenario 3 (c) : IPv6 to IPv4 RADVISION 102.1 11.1 113.2

Table 2. D3 and D4 standard derivations for the RADVISION implementation

Scenario Standard derivation for D3 (ms)

Standard derivation for D4 (ms)

Scenario 1 : IPv4-only 19.4 20.2 Scenario 2 (a) : IPv6-only (without DAD) 18.0 19.6 Scenario 2 (b) : IPv6-only (with DAD) 147.5 147.5 Scenario 3 (a) : IPv4 to IPv6 (without DAD) 20.6 21.4 Scenario 3 (b) : IPv4 to IPv6 (with DAD) 146.9 146.9 Scenario 3 (c) : IPv6 to IPv4 19.5 20.4

Table 1 also shows that the D3 delays for the eXosip implementation are shorter than those

for the RADVISION implementation. On the contrary, the D4 delays of the eXosip

implementation are longer. This is due to the different ways in resetting the RTP connection.

The SIP UA based on RADVISION resets the RTP connection before sending the SIP

re-INVITE message (see

in Figure 6) so its overhead is included in D3. On the other

hand, the SIP UA based on eXosip resets RTP connection after sending the re-INVITE

message (see

in Figure 6) so its overhead is included in D5. In other words, if we

consider the overall delay D4, the RADVISION implementation is better than the eXosip

implementation.

Now let us take a look at the NDDS implementation. N. Nakajima, A. Dutta, S. Das and H.

Schulzrinne (NDDS) evaluated the performance of SIP terminal mobility in IPv6-only

networks. The configuration of the NDDS experimental environment is the same as that

illustrated in Figure 7 except that the routers are IPv6-only routers. The MH and the CH are

Columbia University’s SIP UAs running on Linux [18]. Table 1 shows the results of NDDS

experiments. In NDDS Scenario 2 (a), D3 is 161.6ms and D5 is 257.0ms. These delays are

higher than those in both our RADVISION and eXosip implementations. These long delays

may be due to the fact that the Columbia University’s SIP UA was implemented by Tcl/Tk

that provides a friendly programming environment with higher object code execution

overhead [19].

In NDDS Scenario 2(b), D3 is 3932.2ms and D5 is 255.5ms. In this scenario, there is an

extra delay from Neighbor Unreachability Detection (NUD) in Linux [20]. With NUD

mechanism, when the MH moves to a new subnet, the MH still tries to send the packets

through the old access router until the unreachability of the old router is detected. The delay

from the NUD contributes 3770.6 ms to D3. In our experiments (for both RADVISION and

eXosip implementations), the SIP UAs are running on Windows XP instead of Linux, so NUD

is not executed. Therefore, our experiments show shorter delay compared with NDDS

implementation on Linux.

The D3, D4, and D5 delays in NDDS scenarios show the similar variation as those in our

eXosip experiments. Therefore it is reasonable to conclude that the results of both studies are

consistent for the IPv6-only scenarios.

3.2 Interoperability

In this section we shall show the experimental results between the NCTU SIP UA and other

SIP UAs. The test is not performed on the RADVISION implementation since most SIP UAs

do not support IPv4/IPv6 dual-stack. In this experiment, we use the eXosip-based NCTU SIP

UA as the MH, and select one SIP UA (softphone or hardphone) to be the CH. The MH and

CH are connected to the same 100Mbps switching hub. Initially, the MH establishes a SIP

session with the CH in the same subnet. Then the MH changes its IP address and SIP terminal

mobility is executed. Table 3 shows those SIP UAs and their experimental results. Among

those UAs, NCTU SIP UA, Windows Messenger, and X-Lite UA are sofphones. Snom200,

Cisco 7940, InnoMedia video phone, and Pingtel are hardphones. Notice that even though the

MH is always NCTU SIP UA, the delay of D3 is quite different for different CH. The reason

is that after receiving a re-INVITE request, each SIP UA requires different time to handle the

request and then generates the SIP 200 OK response.

From Table 3, the results of NCTU SIP UA and Windows Messenger 5.1 are very close,

and the X-Lite UA is a little longer (about 11% for D4). In the results of hardphones, the delay

is obviously longer than those sofphones. We consulted the engineers in InnoMedia

Corporation, and they believe that it is caused by the time spent on SDP parsing in the

protocol stack. Because InnoMedia video phone supports both video and audio transmission

during SIP conversation, the SDP contents contain video media description. Therefore this

extra complexity increases the delay slightly. We also perform the same experiment on Cisco

7940 SIP hardphones with different firmware versions. In firmware version 7.5, the delay of

sending 200 OK response is longer than that in firmware version 5.3. The reason is that the

newer version applies more rigorous rules in checking the SDP contents. For example, in

firmware version 7.5 when the re-INVITE is received, the SDP version in session identifier

field (the third field in the “o=” line) must be verified to see whether it is incremented by 1.

Certainly this increases the delay, too.

Table 3. D3 and D4 delays between NCTU SIP UA and other SIP UAs

Devices Under Test

SIP UA Version

D3 (ms) D4 (ms) Media resumption delay (D4) compared to NCTU SIP UA NCTU SIP UA (IPv4) 1.1 38.2 214.4 100.00%

Windows Messenger 5.1.0680 38.2 214.3 99.95% X-Lite UA 2.0 build 1103 50.2 238.4 111.19% Snom 200 hardphone 1.16x 4904 94.8 270.9 126.35% Cisco 7940 hardphone 5.3 151.3 340.2 158.68% Cisco 7940 hardphone 7.5 230.2 404.4 188.62% InnoMedia video phone 2.4.17 173.1 356.1 166.09% Pingtel hardphone 2.1.11.24 195.0 370.6 172.85%

Chapter 4

Conclusions

This thesis investigates SIP terminal mobility and its implementations. In previous

studies, SIP terminal mobility was discussed and implemented for homogeneous IPv4-only or

IPv6-only networks. In this thesis, we introduce SIP terminal mobility for heterogeneous

IPv4/IPv6 networks and its implementation. The designs of protocol architecture and the

implementations based on two popular APIs, eXosip and RADVISION, are described. Their

performance is also measured from empirical experiment. In IPv6-only network with DAD, it

takes 1479.0ms for the eXosip implementation and 1357.2ms for the RADVISION

implementation during the SIP terminal mobility procedure, so this may be short enough to

support daily conversations. Furthermore if the DAD procedure is not executed, the delay is

reduced to 223.4ms and 113.1ms respectively. It is obvious that the delay from the DAD

procedure becomes the bottleneck for SIP terminal mobility in IPv6 networks.

In the eXosip implementation, the interoperability testing of SIP terminal mobility

among SIP UAs is demonstrated. The results show that the delay of SIP terminal mobility

does not only depend on the MH, but also on the CH. After receiving a re-INVITE request,

each SIP UA needs a period of time to run some internal processing (e.g. SDP parsing) before

it replies a 200 OK response, so the delay of SIP terminal mobility differs divergently. The

information provided by the manufacturer shows that one of the major factors is the

The performance of SIP terminal mobility between IPv4 and IPv6 networks is also

measured in the RADVISION implementation. The delays for IPv4/IPv6 scenarios are close

to those for the IPv4-only and IPv6-only cases. These results show that the performance of

IPv4/IPv6 SIP terminal mobility can be as efficient as those for IPv4-only and IPv6-only

networks. From the above observations, it shows that SIP terminal mobility can be efficiently

supported not only in IPv4-only and IPv6-only networks, but also between IPv4 and IPv6

networks.

Bibliography

[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M.

Handley, and E. Schooler , “SIP: Session Initiation Protocol”, IETF RFC 3261, June

2002.

[2] H. Schulzrinne and E. Wedlund, “Application-layer mobility using SIP”, ACM

SIGMOBILE Mobile Computing and Communications Review, Vol. 4, Number 3,

pp.47-57, July 2000.

[3] C.-H. Yeh, Q. Wu, Y.-B. Lin, "SIP Terminal Mobility for both IPv4 and IPv6", The 8th

International Workshop on Multimedia Network Systems and Applications (MNSA) in

IEEE 26th International Conference on Distributed Computing Systems (ICDCS 2006),

Lisbon, Portugal, July 4-7, 2006.

[4] S. Thomson and T. Narten, “IPv6 stateless address autoconfiguration”, IETF RFC 2462,

December 1998.

[5] J.-H. Weng, “Design and Implementation of SIPv6 Translator”, master’s thesis, National

Chiao Tung University, Department of Computer Science and Information Engineering,

July 2005

[6] G. Tsirtsis and P. Srisuresh, “Network Address Translation - Protocol Translation

(NAT-PT)”, IETF RFC 2766, February 2000.

[7] W.-E. Chen, Q. Wu, and Y.-B. Lin, “Design of SIP Application Level Gateway for IPv6

Translation”, Journal of Internet Technology (JIT) Special Issue on IPv6. Vol. 5 No. 2,

2004.

[8] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64) Registration Authority",

http://grouper.ieee.org/groups/msc/MSC200407/OnlineTutorials/EUI64.htm, March

1997.

[9] The eXtended osip library, http://savannah.nongnu.org/ projects/exosip/

[10] The sipX libraries, http://www.sipfoundry.org/sipX/index.html

[11] The RADVISION SIP Toolkit, http://www.radvision.com/

[12] The Signalware SIP library, http://www.ulticom.com/html/products/signalware-sip.asp

[13] The jSIP library, http://jsip.sourceforge.net/

[14] The JAIN-SIP library, https://jain-sip.dev.java.net/

[15] GNU oSIP library, http://www.gnu.org/software/osip/

[16] L.-Y. Wu, M.-H. Tsai, Y.-B. Lin, and R.-S. Yang, “A Client-Side Design and

Implementation for Push to Talk over Cellular Service”. Accepted and to appear in

Wireless Communications and Mobile Computing Journal.

[17] oRTP – a Real-time Transport Protocol stack under LGPL, http://linphone.org/ortp/

[18] N. Nakajima, A. Dutta, S. Das, and H. Schulzrinne, “Handoff Delay Analysis and

Measurement for SIP based Mobility in IPv6”, IETF International Conference on

Computers and Communications, Anchorage Alaska, USA, May 2003.

[19] Tcl/Tk, http://www.tcl.tk/

[20] T. Narten, E. Nordmark, and W. Simpson, “Neighbor Discovery for IP version 6 (IPv6)”,

IETF RFC 2461, December 1998.

Appendix A

The SIP Mobility Module Program in

the eXosip Implementation

Appendix A lists the source code of the SIP Mobility module program in the eXosip

implementation. The SIP Mobility module is implemented as a C++ program, which consists

of the header files AddressChange.h (Appendix A.1), CSIPUACore.h (Appendix A.3),

and the program files AddressChange.cpp (Appendix A.2), CSIPUACore.cpp

(Appendix A.4). In CSIPUACore.cpp, only the portion for SIP Mobility module is listed.

In AddressChange.cpp, a class CAddressChange is implemented which utilizes the

function WSAIoctl( ) in Winsock API to detec the Address-Change event.

A.1 AddressChange.h

01 #if !defined(AFX_ADDRESSCHANGE_H__088D2025_6860_4E36_A3BA_B39C8F03295F__INCLUDED_) 02 #define AFX_ADDRESSCHANGE_H__088D2025_6860_4E36_A3BA_B39C8F03295F__INCLUDED_ 03 04 #if _MSC_VER > 1000 05 06 #include <winsock2.h> 07 #include <windows.h> 08 //#include <iphlpapi.h> 09 #include <tchar.h> 10 11 #include "CriticalSection.h" 12 using ADDRESSCHANGE::CAddressChangeCriticalSection; 13 14 #include <vector> 15 16 using namespace std; 17 #pragma comment(lib, "ws2_32.lib") 18 #pragma comment(lib, "iphlpapi.lib") 19 #endif // _MSC_VER > 1000 20

21 namespace ADDRESSCHANGE 22 {

23 24 25 typedef vector<TCHAR*> STRINGVECTOR,*PSTRINGVECTOR; 26 typedef vector<TCHAR*>::iterator STRINGVECTORIT,*PSTRINGVECTORIT; 27 typedef vector<DWORD> DWORDVECTOR,*PDWORDVECTOR; 28 typedef vector<DWORD>::iterator DWORDVECTORIT,*PDWORDVECTORIT; 29 30 typedef void(*NotifyFunction)(void *pri); 31 typedef struct 32 { 33 NotifyFunction func; 34 void *pri; 35 }CallbackEntry, *PCallbackEntry; 36 37 38 class CAddressChange 39 { 40 private: 41 static CAddressChangeCriticalSection m_cs; 42 static HANDLE m_ipthreadv6; 43 static vector<CallbackEntry> m_IpChangeNotifyVector; 44 static int m_ipthreadstopflag; 45 static ULONG __stdcall Ipv6ChangeNotifyThread(void* pri); 46 public: 47 CAddressChange(); 48 49 static int StartIpChangeNotify(); 50 static void StopIpChangeNotify(); 51 52 static void AddIpChangeNotify(CallbackEntry cbEntry); //Not multi-thread safe 53 static void RemoveIpChangeNotify(CallbackEntry cbEntry); //Not multi-thread safe 54 virtual ~CAddressChange(); 55 }; 56 57 } 58 59 #endif // !defined(AFX_ADDRESSCHANGE_H__088D2025_6860_4E36_A3BA_B39C8F03295F__INCLUDED_)

A.2 AddressChange.cpp

001 #include "AddressChange.h" 002 003 namespace ADDRESSCHANGE 004 { 005 006 /////////////////////////////////////////////////////////////////////

007 // Static members implementation 008 //////////////////////////////////////////////////////////////////////

009 CAddressChangeCriticalSection CAddressChange::m_cs; 010 HANDLE CAddressChange::m_ipthreadv6 = NULL; 011 vector<CallbackEntry> CAddressChange::m_IpChangeNotifyVector; 012 int CAddressChange::m_ipthreadstopflag = 0; 013 014 ////////////////////////////////////////////////////////////////////// 015 // Construction/Destruction 016 ////////////////////////////////////////////////////////////////////// 017 018 CAddressChange::CAddressChange() 019 { 020 021 } 022 023 CAddressChange::~CAddressChange() 024 {

026 } 027 //////////////////////////////////////////////////////////////////////

028 // Static methods implementation 029 ////////////////////////////////////////////////////////////////////// 030 031 int CAddressChange::StartIpChangeNotify() 032 { 033 DWORD dwid; 034 035 m_cs.Lock(); 036 if(NULL == m_ipthreadv6) 037 { 038 039 m_ipthreadv6 = CreateThread(NULL,NULL,Ipv6ChangeNotifyThread,NULL,CREATE_SUSPENDED,&dwid); 040 041 if(NULL == m_ipthreadv6) 042 { 043 return 0; 044 } 045 046 m_ipthreadstopflag = 0; 047 ResumeThread(m_ipthreadv6); 048 } 049 050 m_cs.Unlock(); 051 052 return 1; 053 } 054 055 void CAddressChange::StopIpChangeNotify() 056 { 057 m_cs.Lock(); 058 if(NULL != m_ipthreadv6) 059 { 060 m_ipthreadstopflag = 1; 061 WaitForSingleObject(m_ipthreadv6,INFINITE); 062 DeleteObject(m_ipthreadv6); 063 m_ipthreadv6 = NULL; 064 } 065 m_cs.Unlock(); 066 } 067 void CAddressChange::AddIpChangeNotify(CallbackEntry cbEntry) 068 { 069 m_cs.Lock(); 070 m_IpChangeNotifyVector.push_back(cbEntry); 071 m_cs.Unlock(); 072 } 073 void CAddressChange::RemoveIpChangeNotify(CallbackEntry cbEntry) 074 { 075 m_cs.Lock(); 076 for(vector<CallbackEntry>::iterator it = m_IpChangeNotifyVector.begin(); 077 it != m_IpChangeNotifyVector.end() ; 078 it++) 079 {

080 if(it->func == cbEntry.func && it->pri == cbEntry.pri)

081 { 082 m_IpChangeNotifyVector.erase(it); 083 break; 084 } 085 } 086 m_cs.Unlock(); 087 } 088 089 ULONG CAddressChange::Ipv6ChangeNotifyThread(void* pri) 090 { 091

092 int err; 093 SOCKET socketHandle; 094 unsigned long param; 095 int inBuffer; 096 int outBuffer; 097 DWORD outSize; 098 WSAEVENT NewEvent; 099 WSADATA wsaData; 100

101 102 err = WSAStartup( MAKEWORD( 2,2 ), &wsaData ); 103 104 while(!m_ipthreadstopflag) 105 {//1ST loop bracket 106 107 socketHandle = socket( AF_INET6, SOCK_DGRAM, IPPROTO_UDP ); 108 109 param = 1; 110 err = ioctlsocket( socketHandle, FIONBIO, &param ); 111 112 113 inBuffer = 0; 114 outBuffer = 0; 115 err = WSAIoctl( socketHandle, SIO_ADDRESS_LIST_CHANGE, &inBuffer, 0, &outBuffer, 0, &outSize,

NULL, NULL );

116 117 NewEvent = WSACreateEvent(); 118 err = WSAEventSelect( socketHandle, NewEvent, FD_ADDRESS_LIST_CHANGE ); 119 120 while(!m_ipthreadstopflag) 121 { 122 123 if ( WaitForSingleObject(NewEvent, 100) == WAIT_OBJECT_0 ) 124 { 125 for(vector<CallbackEntry>::iterator it = m_IpChangeNotifyVector.begin(); it != m_IpChangeNotifyVector.end();it++) 126 { 127 it->func(it->pri); 128 } 129 ResetEvent(NewEvent); 130 break; 131 } 132 else 133 {//time out 134 135 } 136 } 137 } 138 return 0; 139 } 140 141 142 }//End namespace

A.3 CSIPUACore.h

001 #ifndef __CSIPUACore_H__ 002 #define __CSIPUACore_H__ 003 004 #include<interCommunicationClass.h> 005 #include<eXosip/eXosip.h> 006 #include<eXosip/eXosip_cfg.h> 007 008 #include<windows.h> 009 #include<time.h> 010 011 typedef struct IPAddresses{

012 char *IPAddr; 013 int INETType; //0 for IPv6; 1 for IPv4

014 int scope; //0 for Global; 015 //1 for Global -6to4 (IPv6 only);

016 //2 for Site-Local and IPv4 private addr.; 017 //3 for Link-Local 018 int preferOrder; //set by IPSelection() or IPSelectionWithDestination() for sorting convenience

021 struct IPAddresses *next; 022 }IPAddresses; 023

024 typedef enum natTraversalType{ 025 AUTO_DETECT_NAT, 026 NO_NAT, 027 USE_UPNP, 028 USE_STATIC_ASSIGN 029 }natTraversalType; 030

031 typedef enum internetFamily{ 032 AUTO_DETECT_INET, 033 USE_IPV6, 034 USE_IPV4 035 }internetFamily; 036 037 typedef unsigned char flag; 038

039 typedef enum SIPCoreEvent{ 040 SIPCore_THREAD_CREATE_FAILED, //0 041 042 SIPCore_EXOSIP_INITIATE_FAILED, //1 043 044 SIPCore_REGISTRATION_NEW_OK, 0//2 045 SIPCore_REGISTRATION_NEW_FAILED_NEED_AUTHENTICATION, //3 046 SIPCore_REGISTRATION_NEW_FAILED_CHECK_CONFIGURATION, //4 047 SIPCore_REGISTRATION_REFRESH_OK, //5 048 SIPCore_REGISTRATION_REFRESH_FAILED, //6 049 SIPCore_UNREGISTRATION_OK, //7 050 SIPCore_UNREGISTRATION_FAILED, //8 051 052 SIPCore_SEND_INVITE_FAILED_INIT, //9 053 SIPCore_SEND_INVITE_FAILED_UNKOWN, //10 054 SIPCore_SEND_INVITE_FAILED_CALLEE_BUSY, //11 055 SIPCore_SEND_INVITE_FAILED_CALLEE_NOTFOUND, //12 056 SIPCore_SEND_INVITE_FAILED_TIMEOUT, //13 057 SIPCore_SEND_INVITE_FAILED_NO_CODEC_SUPPORT, //14 058 SIPCore_SEND_INVITE_FAILED_CANNOT_SEND_ACK, //15 059 SIPCore_SEND_INVITE_RINGING, 5//16 060 SIPCore_SEND_INVITE_200OK, 6//17 061 062 063 SIPCore_RECV_INVITE_NEW, //18 064 SIPCore_RECV_INVITE_ACK, //19 065 SIPCore_RECV_INVITE_CANCEL, //20 066 SIPCore_RECV_INVITE_TIMEOUT, 2//21 067 SIPCore_RECV_INVITE_SEND_180_FAILED, //22 068 SIPCore_RECV_INVITE_SEND_200_FAILED, //23 069 SIPCore_RECV_INVITE_FAILED_NO_CODEC_SUPPORT, //24 070 071 SIPCore_TERMINATE_CALL_OK, //25 072 SIPCore_TERMINATE_CALL_FAILED, //26 073 SIPCore_CALL_TERMINATED, //27 074 075 SIPCore_SEND_INFO_OK, //28 076 SIPCore_SEND_INFO_FAILED_INIT, //29 077 SIPCore_SEND_INFO_FAILED_UNKNOWN, //30 078 SIPCore_RECV_INFO_NEW, //31 079 080 SIPCore_SEND_MESG_OK, //32 081 SIPCore_SEND_MESG_FAILED_INIT, //33 082 SIPCore_SEND_MESG_FAILED_TIMEOUT, //34 083 SIPCore_SEND_MESG_FAILED_UNKNOWN, //35 084 SIPCore_RECV_MESG_NEW, //36 085 086 //========================================================== 087 //add by chyei 088 SIPCore_RECV_REINVITE, //37 089 SIPCore_IPCHANGE_NOIP_NOTIFY, 090 SIPCore_IPCHANGE_NEWIP_NOTIFY, 091 SIPCore_IPCHANGE_ORGIP_NOTIFY //? 092 //========================================================== 093 //... 094 }SIPCoreEvent; 095 096 unsigned __stdcall backgroundProcess( void *argument );

097 /* a thread that runs in background, 098 * it's responsible for receiving events and do registration refresh 099 */ 100 unsigned __stdcall tryToReceiveForTesting( void *argument );

101 /* a temporary thread that is for tesing if there's SIP service on a remote ip address 102 */ 103

104 class CSIPUACore :public CInterCommunicationClass{ 105 private:

106 #ifdef BEAN_DEBUG 107 void ( __cdecl *m_cb_event )( const SIPCoreEvent );

108 #else 109 // HWND m_hWnd; //lywu's window (UI) handle 110 // replaced by callControlPointer; 111 #endif 112 CRITICAL_SECTION cs__callControlPointer; 113 CRITICAL_SECTION cs__floorControlPointer; 114 CRITICAL_SECTION cs__GLMSControlPointer; 115

116 CInterCommunicationClass *_callControlPointer; //lywu's call control pointer 117 CInterCommunicationClass *_floorControlPointer; //tsaimh's floor control pointer

118 CInterCommunicationClass *_GLMSControlPointer; //stephon's GLMS control pointer 119 char *_GLMSSipuri; //stephon's GLMS sipuri

120 121 natTraversalType _natTraversalType;

122 internetFamily _internetFamily; 123 flag forceINETFlag;

124 flag forceNATFlag; 125 char *sipuri; //sip:[email protected] 126 char *outboundProxy; //yyy.zzz 127 int sipPort; 128 //information for one call 129 flag isUACFlag; //if is a caller in the existing call 130 char *rtpLocalIP, *rtpRemoteIP; 131 int rtpLocalAudioPort, rtpNatExternalAudioPort, rtpRemoteAudioPort;

132 int rtpLocalVedioPort, rtpNatExternalVedioPort, rtpRemoteVedioPort; 133 int rtpRemotePayloadType; //number of payload type is referencing to RFC-3551, '-1' for no support or

init

134 135 int callID, dialogID;

136 137 struct registerInfo{

138 int registerID; 139 int expireTime;

140 time_t registerTime; 141 char *ToHeader; //<sip:[email protected]> 142 char *registra; //sip:yyy.zzz 143 int numberOfRegisterTimes; //how many times this registerID have sent REGISTER 144 }registerInformation; 145 146 char *hostIPAddress, *natExternalIPAddress; 147 int hostSIPPort, natExternalSIPPort; 148 // int hostRTPPort, natExternalRTPPort;

149 //what follows are for static assignment of NAT Traversal 150 int hostRTPPortBegin, natExternalRTPPortBegin;

151 int hostRTPPortEnd, natExternalRTPPortEnd; 152

153 HANDLE threadHandle; 154 char *_subject;

155 char *_callerURI;

156 157 internetFamily detectINET( void ); 158 natTraversalType detectNAT( void ); 159 int getRTPLocalAudioPort( void ); 160 int getRTPLocalVedioPort( void ); 161 IPAddresses *getAllHostIPAddresses( const int INET, const int scope ); 162 IPAddresses *getAllRemoteHostIPAddresses( const char *IP, const char *port ); 163 void aCallTerminatedVariablesReset( void ); 164 int doUPnPGetAPort( const int internalPort, int *externalPort );

165 int doUPnPDeleteAPort( const int externalPort ); 166 int doIPSelection( char *IPAddress, const int size );

167 int doIPSelectionWithDestination( const char *destination, char *sourceIPAddress, const int sourceSize, char

*destinationIPAddress, const int destinationSize );

168 int notAnIPv4Address( const char *IPAddress ); 169 int notPrivateIPv4Address( const char *IPAddress );