建立服務導向平台之家用數位監視系統之研究

全文

(1)國立臺灣師範大學資訊工程研究所碩士論文. 指導教授：. 黃文吉. 博士. 建立服務導向平台之家用數位監視系統之研究. Implementation of Service Oriented Home Networking Surveillance System. 研究生：吳. 韋. 德. 中華民國九十七年六. 撰月.

(2) 致謝首先，感謝黃文吉老師在這兩年來不辭辛勞的指導和啟發，讓我無論是在專業上或者是待人處事都獲益良多。研究所這兩年間，許多的學習與體驗，是我人生中一次重要的成長，老師非常感謝您！同時，感謝已畢業的學長一志、守庭、威智、瑞鴻、映男及汶錫，還有其他許多的學長姐們，謝謝你們的指導，很榮幸能當你們的學弟，也很感謝祜琦、凱富、正岳、永隆、定寬、智傑，實驗室的所有同窗和學弟妹們，一路走來的歡笑甘苦是我一生美好的回憶。而我也想謝謝一群親愛的好朋友們，雨農、柏諺、楊公、宜倡、建富，勇杕，大婕，佑子和仲憶，有你們的陪伴和鼓勵，讓我研究所的生活更多彩多姿。另外，我想特別謝謝嘉涓，擔任我研究所兩年來的特別指導，讓我不斷的成長和變的更好，謝謝妳，妳是我生命中的一位天使。最後要感謝我的家人們，一直以來是我最大的支持，在我求學期間不斷地給我關懷和力量，也因為有你們，我才希望我能成為一位更好的人，繼續的努力下去，謹將此篇論文獻給最親愛的你們。.

(3) 中文摘要. 中文摘要本研究提出一個完整的架構，使得遠端存取家用數位監視系統的過程變的簡單而方便，同時也大量簡化使用者在家庭中佈署監視系統所需的工作，達到真正所謂隨插即用(Plug-and-Play)的功能。本研究採用 Session Initiation Protocol (SIP) 結合 Zero Configuration (Zeroconf) 組成的 Service Trade Discovery Protocol (STDP) 做為主要的基礎網路協定，達到遠端存取區域網路中服務的目標，並在 IP-Camera 上整合了 Universal Plug-and-Play (UPnP) ，解決了家庭網路服務均會面臨的 network address translator (NAT) 穿透問題，達成 IP-Camera 隨插即用的目標。在本研究的基礎架構下，人們若有意願於家庭環境中部署數位監視系統，將不再需要龐大的成本和專業的知識。這將為人們帶來極大的方便，也提高居家生活的安全性和便利性。. i.

(4) Abstract. Abstract This thesis proposes a compact architecture, which is effective for accessing our surveillance system from the public network. This architecture eliminates the pre-configuration requirement to deploy the surveillance system in residential environment by providing a novel mechanism of plug-and-play. We apply Service Trade Discovery Protocol (STDP), a SIP-and-Zeroconf based framework, as our basic network transmitting protocol. The STDP enables the remote access of surveillance system over wide area networks (WANs). Besides, to solve the network address translator (NAT) traversal problem encountered in many home network applications, we integrate Universal Plug-and-Play (UPnP) solution into the IP-Camera. The UPnP make the surveillance system accessible behind NAT. With the architecture, people can set up the surveillance system in the residential environment without complex pre-configuration and professional skill about network. That will provide more convenience for people who have will to deploy the surveillance system. In the meanwhile, the architecture improves the security and convenience in our daily life.. ii.

(5) Content. Content 中文摘要...............................................................................................................................i Abstract ...............................................................................................................................ii Content .............................................................................................................................. iii List of Figures ....................................................................................................................iv. Chapter 1. Introduction ........................................................................................... - 1 -. 1.1. BACKGROUND ...........................................................................................................................- 1 -. 1.2. THE ORGANIZATION OF THIS THESIS .........................................................................................- 4 -. Chapter 2. Basic Methods........................................................................................ - 5 -. 2.1. SIP.............................................................................................................................................- 5 -. 2.2. ZEROCONF .................................................................................................................................- 8 -. Chapter 3. STDP..................................................................................................... - 11 -. 3.1. STDP PROTOCOL .....................................................................................................................- 11 -. 3.2. STDP MESSAGE FORMAT ........................................................................................................- 15 -. 3.3. SERVICE TRADER .....................................................................................................................- 17 -. Chapter 4 4.1. System Framework ............................................................................. - 19 -. STDP WITH NAT TRAVERSAL ..................................................................................................- 19 -. 4.1.1. NAT Traversal for IP Camera ........................................................................................... - 21 -. 4.1.2. SIP Connection behind NAT.............................................................................................. - 25 -. 4.2. SYSTEM ARCHITECTURE ..........................................................................................................- 27 -. Chapter 5. Experimental Result............................................................................ - 32 -. 5.1. EXPERIMENTAL SETTING .........................................................................................................- 32 -. 5.2. RESULT ....................................................................................................................................- 38 -. Chapter 6. Conclusion and Future Work............................................................. - 43 -. References .................................................................................................................... - 45 iii.

(6) List of Figures. List of Figures 1 Basic application of SIP for IP CAM ......................................................................... 5 2 A simple SIP-based framework for remotely accessing IP CAM .............................. 7 3 Publication operations of Zeroconf ............................................................................ 9 3.(A) ADDRESS SELECTION ................................................................................................................... 9 3.(B) NAME SELECTION ........................................................................................................................ 9 3.(C) SERVICE STARTUP ........................................................................................................................ 9 3.(D) SERVICE PUBLICATION ................................................................................................................. 9. 4 Service query and discovery in Zeroconf................................................................... 9 4.(A) QUERY BY SERVICE TYPE ............................................................................................................. 9 4.(B) RESPONSE .................................................................................................................................... 9. 5 The query for domain name, port and IP address in Zeroconf................................... 9 5.(A) REQUEST DOMAIN NAME AND PORT FOR INSTANCE NAME ............................................................ 9 5.(B) RECEIVE DOMAIN NAME AND PORT .............................................................................................. 9 5.(C) REQUEST IP ADDREE FOR DOMAIN NAME ..................................................................................... 9 5.(D) RECEIVE IP ADDRESS ................................................................................................................... 9. 6 The protocol stack of STDP-based networks ............................................................11 7 STDP topology ......................................................................................................... 12 8 STDP protocol messages.......................................................................................... 14 8.(A) COMMUNICATION BETWEEN TRADER AND PROVIDER................................................................ 14 8.(B) TRADERS COMMUNICATION....................................................................................................... 14 8.(C) COMMUNICATION BETWEEN TRADER AND REQUESTER ............................................................. 14 iv.

(7) List of Figures 9 Extensions of SUBSCRIBE/NOTIFY messages for STDP service subscription and notification........................................................................................................ 15 9.(A) SUBSCRIBE MESSAGE FOR SERVICE SUBSCRIPTION................................................................. 15 9.(B) NOTIFY MESSAGE FOR SERVICE NOTIFICATION......................................................................... 15. 10 Operation flowchart of a trader .............................................................................. 18 11 Schema of NAT ...................................................................................................... 19 12 Three-way hand shaking of TCP............................................................................ 22 13 NOTIFY message with incorrect address information........................................... 22 14 NAT traversal with UPnP IGD ............................................................................... 23 15 NOTIFY message with correct IP address and port ............................................... 24 16 Incorrect SIP message ............................................................................................ 25 17 Correct SIP message After SIP ALG...................................................................... 26 18 A simple system overview:There is only one IP CAM deployed in this example . 27 19 The message flow of the proposed system depicted in Fig.18............................... 30 19.(A)IP CAM REQUESTS NAT B TO OPEN A TUNNEL FOR TCP CONNECTION VIA UPNP IGD MESSAGES. ............................................................................................................................... 29. 19.(B) TRADER A AND TRADER B REGISTER TO SIP SERVER WITH THE PRIVATE ADDRESSES. THAT FOLLOWS A SERIES OF MODIFYING ADDRESS BY SIP ALG......................................................... 29. 19.(C) TADE A AND TRADER B FIND THEIR OWN SERVICE PROVIDERS AND SERVICE REQUESTER .......... 30 19.(D) TRADER A AND TRADER B ESTABLISH THEIR CONNECTION VIA SUBSCRIBE/NOTIFY MESSAGES. THE CONTACT HEADER FIELD WILL BE REWRITTEN WITH REQUESTER’S SOURCE ADDRESS AND PORT BY SIP ALG............................................................................................. 30. 20 The basic scenario for our experiment ................................................................... 32 v.

(8) List of Figures 21 The IP CAM with its IEEE 802.3 and IEEE 802.11b interface ............................. 34 22 The camera for capturing video streaming............................................................. 34 23 All the services of type _http. _tcp discovered in LAN B without the employment of STDP............................................................................................ 35 24 The service trader executing on Windows platform............................................... 36 25 The specifications of the routers used in the experiment ....................................... 37 26 All services of type _http._tcp in the LAN A discovered by Bonjour without the employment of STDP............................................................................................ 38 27 All services of type _http._tcp in the LAN B discovered by Bonjour without the employment of STDP............................................................................................ 39 28 Trader A sends SUBSCRIBE messages to trader B without SIP ALG. 40............. 39 29 All services of type _http._tcp in LAN A after the deployment of SIP ALG: All services in LAN B have been transmitted to LAN A. But this web page is still the service information page provided by the printer in LAN A ................... 40 30 The service of IP CAM in LAN A without the deployment of UPnP IGD ............ 41 31 The service of IP CAM in LAN A with the UPnP IGD solution............................ 42. vi.

(9) Chapter 1 Introduction. Chapter 1 Introduction 1.1. Background. An IP camera (IP CAM) is a video camera that contains a hardware video encoder and an embedded processor with a TCP/IP interface. It is a stand alone unit that can be directly connected to the internet without the need for a separate computer. It also has a built-in web server, which provides the ability for accessing digital images and configuring the camera. Its digital output allows the camera easily integrated with a wide range of applications, including e-surveillance, web attractions and remote monitoring. In these applications, IP CAMs are usually deployed in the environments with dynamic locations. Without static IP address information, accessing the web server associated with the IP CAMs is difficult. In addition, for a service consumer, it is not possible to always have a complete overview over these applications and their availability. The dynamics of recent networks make this process even more complex. One way to solve the problem is by the employment of service discovery protocols, such as Service Location Protocol (SLP) [5], Jini [7], Universal Plug-and-Play (UPnP) [3], and Zero Configuration (Zeroconf) [6], [19]. In the service discovery environment, IP CAMs and other devices advertise themselves, supplying details about their capabilities and the information one must know to access the service (e.g., the IP address). Nevertheless, existing service discovery protocols are limited only to local area networks (LANs). For many IP CAM applications, remote access with network address translator (NAT) [16] traversal is required. An effective protocol for remote service of IP CAMs is therefore desired for these applications. This thesis extends a novel Session Initiation Protocol (SIP)-and-Zeroconf based. -1-.

(10) Chapter 1 Introduction framework, termed Service Trader Discovery Protocol (STDP) [23], for the remote accesses of IP CAMs. SIP [8] is a protocol developed by IETF to assist in providing advanced telephony services across the internet. Basically it is a signaling protocol used for establishing sessions in an IP network. In the SIP, location of clients are maintained and updated in the registrar server. The IP address of the target node can be obtained by a query to the server. Although a direct deployment of SIP to an IP CAM is possible for accessing digital images, a number of modifications are desired. For many home network applications, costly manual pre-configurations should be avoided. However, the deployment of SIP requires the assignment of a unique pair of SIP URI and password to each IP CAM. This may result in a high manual pre-configuration cost when the number of IP CAM is large. On the contrary, there is no pre-configuration cost for the existing service discovery protocols permitting accesses only to LAN. The goal of STDP therefore is to simplify/eliminate the administration efforts associated with the remote access protocols for IP CAM applications. The STDP protocol is a hybrid combination of the Zeroconf and SIP protocols. The Zeroconf protocol is a light weight protocol supporting service discovery in a LAN. As compared with other service discovery protocols, it imposes minimal implementation cost for an embedded system. IP CAMs using the Zeroconf protocol can be deployed with simple plug-and-play. Consequently, the hybrid combination allows the remote accesses of IP CAM while enjoying low pre-configuration cost. To implement the STDP, the SIP is required to be deployed only on a single node, termed trader, in the LAN. This assures the minimal pre-configuration cost for the system. The trader is responsible for collecting the service information provided by all the other nodes in LAN via the Zeroconf protocol. A remote access to any IP CAM in the LAN can be accomplished by first retrieving the service information from the trader using the SIP.. -2-.

(11) Chapter 1 Introduction Based on the information, the IP address of any IP CAM in the LAN can be found. A remote node can then access the web server associated with the target IP CAM based on the retrieved service information. Note that, for the applications where the IP CAM, traders, and/or remote client nodes are behind the NAT, the proposed basic STDP protocol may fail to deliver correct address information for service discovery. Therefore, in the thesis, the UPnP Internet Gateway Device (UPnP IGD) protocol [21] and SIP Application Level Gateway (SIP ALG) [22] are also incorporated in the STDP for NAT traversal. Both UPnP IGD and SIP ALG are light weight software imposing limited overhead for STDP implementation. The STDP protocol has been implemented in a dynamic network environment. Physical tests reveal that the IP CAMs supporting only simple Zeroconf protocols can be easily accessed by a remote host. The STDP protocol is therefore beneficial for a wide range of IP CAM applications requiring dynamic deployment.. -3-.

(12) Chapter 1 Introduction. 1.2. The Organization of This Thesis. The remaining part of this thesis is presented as follows. In the chapter 2, the basic methods, SIP and Zeroconf, are described in detail. Chapter 3 presents the SIP-andZeroconf based framework, STDP. Chapter 4 integrates the UPnP IGD, SIP ALG with STDP. The experimental results of the proposed STDP with NAT traversal for IP CAM applications are included in chapter 5. Finally, concluding remark and future works are presented in chapter 6.. -4-.

(13) Chapter 2 Basic Methods. Chapter 2 Basic Methods 2.1. SIP. SIP is a signaling protocol used for establishing sessions in an IP network. The user agents and servers are the major components of the protocol. A user agent is an end-user device. A user agent client (UAC) issues a request and a user agent server (UAS) responds to the request. When the SIP is applied for the remote access of IPCAM, in the simplest form the UAC is a viewer and the UAS is the IP-CAM, as shown in Figure 1. In this case, the location of the IP-CAM should be fixed, and should be known to the viewer.. Fig.1 Basic application of SIP for IP CAM. To support the mobility for the IP CAM, the employment of SIP servers are necessary. Commonly used SIP servers include the registrar and proxy server. A SIP registrar handles registration messages. It is associated with a databases (termed location server) containing user agent locations. A SIP proxy server can be viewed as the router in the SIP level that forward SIP requests and responses. In addition, it provides functions for authentication and authorization. Figure 2 shows a simple example, which uses proxy, registrar and location servers with the INVITE message for session establishment. As shown in the figure, an IP CAM first registers its location in the location server. A SIP proxy server then accepts an -5-.

(14) Chapter 2 Basic Methods INVITE request made by a UAC and queries location server to find UAS location. Based on the address received from the server, the proxy server forwards the INVITE message to the UAS. The session will then be established after the acknowledgements from UAS are received. It can be observed from the example that the viewer does not have to know the IP CAM location prior to a connection establishment. In addition, the UAS is allowed to change its location without informing the UAC. Only a registration request to the registrar server for location updating is required. In addition to supporting the user mobility, the SIP offers the event notification framework [1], [11], which uses SUBSCRIBE/NOTIFY messages for subscribing to, and receiving notifications of, SIP-related events within SIP networks. The ability to request asynchronous notification of events proves useful in many services for which cooperation between devices is required. Examples of such services for IP phone applications include automatic callback services (based on terminal state events), buddy lists (based on user presence events) and message waiting indications (based on mailbox state change events). The SIP allows the remote access of IP CAM with mobility support and event notification. To use the SIP, however, each IP CAM should be associated with a pair of SIP URI and password. The high manual pre-configuration cost and administration efforts for the deployment of IP CAMs are therefore necessary. This is undesirable for many IP CAM applications.. -6-.

(15) Chapter 2 Basic Methods. Fig.2 A simple SIP-based framework for remotely accessing IP CAM. -7-.

(16) Chapter 2 Basic Methods. 2.2. Zeroconf. Zeroconf is a protocol for discovering services available in a local network. A Zeroconf network is one that can exist without a central control component, and works without any kind of manual pre-configuration. Zeroconf can directly be adopted for discovering IP CAM in the LAN. It involves address assignment, name translation and service discovery without central servers. The address assignment for a node in Zeroconf network can simply be accomplished by randomly selecting an address in the range of 169.254.1.0 to 169.254.254.255. The node then does an ARP probe for the address. If there are any responses, the node chooses another IP address at random, and tries the ARP probe again. The name translation in Zeroconf network is solved by the multicast DNS (mDNS) [12] standard, which eliminates the requirement for DNS server. In the standard, all the nodes in the LAN listens to a specific IP multicast address. A node wish to publish a name will broadcast the selected name to this multicast address. Other nodes having the same name then reply to the requesting node. The name translation can be accomplished in a similar fashion. Instead of using fully qualified domain name (FQDN), a node name in the .local name space is used for mDNS. Another standard, termed DNS Service Discovery (DNS-SD) [4] can be used for the service discovery in Zeroconf. DNS-SD works particularly well with mDNS, since it also uses DNS records. Three basic operations are included in the DNS-SD: publication, discovery and resolution. The goal of publication is to advertise a service. The discovery operation is used to browse for available service. Based on the results of discovery operation, the resolution operation is adopted for translating service names to addresses and port numbers.. -8-.

(17) Chapter 2 Basic Methods. Fig.3 Publication operations of Zeroconf. Fig.4 Service query and discovery in Zeroconf. Fig.5 The query for domain name, port and IP address in Zeroconf. -9-.

(18) Chapter 2 Basic Methods Figures 3, 4 and 5 show a simple example of these DNS-SD operations for a local network consisting of an IP CAM. The publication operations of Zeroconf are shown in Figure 3, which consists of address selection (Figure 3.(a)), name selection (Figure 3.(b)), service start up (Figure 3.(c)) and service broadcast (Figure 3.(d)). In Figure 3.(a), the IP CAM randomly selects the IP address 169.254.0.1, and announces it to the network. Because no devices respond to the announcement, the IP CAM takes the address as its own. In Figure 3.(b), it starts up its own multicast DNS responder, requests the host name ipcam.local., verifies its availability, and takes the name as its own. In Figure 3.(c), the IP CAM starts up a video service on TCP port 80. Finally, in Figure 3.(d), it publishes the service instance, of type _http._tcp, under the name ipcam, in the .local domain. It should be noted that the service type (i.e., _http._tcp) contains two fields: the first field (i.e., _http) is service dependent, and the second field (i.e., _tcp) indicates the transportation protocol used by the service. The service type will be used for service browsing and discovery. The instance name (i.e., ipcam) is device dependent. That is, devices sharing the same service type will have different instance names. The service instance therefore can be used for the query of port and IP address of a device. Figure 4 depicts the service query and discovery in the Zeroconf network. In this example, the service type queried by the viewer shown in Figure 4.(a) is _http._tcp. The service instance discovered from the network is ipcam._http._tcp.local, which represents an IP CAM. Based on the service instance, the viewer can further query for the port, domain name and IP address of the IP CAM using resolution operation, as shown in Figure 5. Although Zeroconf requires no pre-configuration cost, it has the major drawback that the protocol can only be used in a local network. For IP CAM applications, however, remote accesses are usually desired.. - 10 -.

(19) Chapter 3 STDP. Chapter 3 STDP 3.1. STDP protocol. The goal of STDP is to eliminate the drawbacks of accessing IP CAMs based only on SIP or Zeroconf protocols. It provides remote access of IP CAM with minimal pre-configuration cost. As shown in Figure 6, the STDP is an application layer control protocol that utilizes both SIP and Zeroconf. A STDP-based network contains three basic components: service provider, service requester, and service trader. In our design, the service provider and requester are an IP CAM and a viewer, respectively. Although the primary goal of the STDP is for the design of IP CAM systems, the STDP apply equally well to the broader group, where the service provider and service requester can be any networked appliances demanding low pre-configuration cost and efficient remote access.. Fig.6 The protocol stack of STDP-based networks. The service traders are the nodes used for the delivery of service information over WAN. A service trader provides two functions. It can be adopted to collect/discover service information from service providers in a local network, and deliver the information to a remote node (which is also a trader) upon requests. Alternatively, it can also be used to subscribe and receive the service information from other traders in remote sites, and - 11 -.

(20) Chapter 3 STDP publish the service information to the service requesters within its local domain. A trader can be implemented in an independent device such as a computer. It can also be implemented in an IP CAM (or a viewer). In these cases, the device supports multiple roles as a trader and a service provider (or a requester). The communications between two service traders are based on SIP protocol, as shown in Figure 7. Each trader can be an UAC and/or an UAS. Each local network needs only one service trader. Each of the service providers and requesters talk to its trader in the same LAN for the delivery of local service information. From Figure 7, we observe that the Zeroconf is adopted for the communication between a trader and a service requester (or a provider). Therefore, in our design, the service provider and requester need to support Zeroconf protocol.. Fig.7 STDP topology. To obtain information from a service provider to a service requester, both the SIP and Zeroconf protocols are used. The STDP provides a mechanism for the service information exchange between the SIP and Zeroconf. Based on the acquired service information, the viewer then can access the IP CAM using the HTTP protocol.. - 12 -.

(21) Chapter 3 STDP To discuss the STDP protocol in more detail, we divide the protocol into three parts, as depicted in Figure 8. The first part concerns with the communication between a trader and a service provider. It can be observed from Figure 8.(a) that the trader will receive service information published by an IP CAM. The trader can also actively discover the service provided by an IP CAM. All the publish and discovery operations are based on Zeroconf protocol, which are illustrated in Figures 3-5. However, it should be noted that the address assignment scheme shown in Figure 3.(a) will be adopted in our design provided that NAT traversal is possible. This is because the address selected by Zeroconf is valid only for local access. The NAT traversal issues will be presented in detail in section 4.1. The second part of the STDP protocol focuses on the interactions between traders. This part of the protocol is based on the SIP. Service traders accompanied by service providers are the UASs in the SIP. An UAS discovers/collects local services available, and delivers the service information to other UACs upon request. An UAC is the service traders accompanied by service requesters. It sends subscription requests to UASs for acquiring the service information. Once the UAC obtains service notifications from UASs, it publishes the service information to its own service requesters. The final part of STDP describes the communications between a trader and a service requester, which is also based on Zeroconf. It can be observed from Figure 8.(c) that the trader will then publish the service information collected from other traders to the service requester. The service requester may also actively discover the service information from the trader.. - 13 -.

(22) Chapter 3 STDP. Fig.8 STDP protocol messages. Three parts of the STDP protocol depicted in Figure 8 may operate independently. That is, the SIP and Zeroconf protocols are not required to operate at a pre-specified order in the STDP.. - 14 -.

(23) Chapter 3 STDP. 3.2. STDP Message Format. In the STDP, the SIP SUBSCRIBE/NOTIFY messages are used for the service information delivery between an UAC and an UAS, as shown in Figure 8.(b). In the SIP, the original goal of SUBSCRIBE/NOTIFY messages is to provide the SIP related events subscriptions and notifications. The STDP extends the usage of SUBSCRIBE/NOTIFY for the service subscription and notification.. Fig.9 Extensions of SUBSCRIBE/NOTIFY messages for STDP service subscription and notification To use the SUBSCRIBE message for service subscription, the type of services desired should be specified in the message header. Here we augment a field (termed - 15 -.

(24) Chapter 3 STDP Zeroconf) in the header of SUBSCRIBE message for specifying the service type. The format of service type follows the DNS-SD format as _http._tcp, as depicted in Figure 9.(a). NOTIFY messages are sent to inform traders of the service available for which the traders have a subscription. Subscriptions are established using the SUBSCRIBE method described above. Sending a NOTIFY message does not terminate the corresponding subscription. A single SUBSCRIBE request may trigger several NOTIFY messages. In each NOTIFY message, the list of services and the IP address of the corresponding service providers are carried. We also augment two fields (termed Zeroconf and eX-Contact) in the header of NOTIFY message to achieve this objective. It can be observed form Figure 9.(b) that the Zeroconf field indicates the service type this message response to. The eX-Contact field contains 5 items: action, service instance, host name, port number and IP address. The action item instructs how the service instance included in field should be handled. There are three actions: addition (denoted by Add), deletion (denoted by Del), and updating (denoted by Upd). The addition action instructs the target service trader to add the service instance to the service list. The deletion action informs the target service trader to remove the service instance. The update action directs the target trader to update the attributes of the service instance. The attributes considered here include the video coding standard adopted by the IP CAM, frame size and frame rate. Use Figure 9.(b) as an example, the NOTIFY message instructs the target trader to add the service instance ipcam._http._tcp.local, with host name ipcam.local, port number 80, and IP address 140.122.184.235, to its service list. It should be noted that the service instance and domain name should also follows the DNS-DS format in the STDP.. - 16 -.

(25) Chapter 3 STDP. 3.3. Service Trader. The service trader plays a major role in STDP as shown in Figure 7. It connects different local networks, and operates in back-to-back mode. It acts as a SIP user agent on one side, and as a Zeroconf end device on the other side. A trader has 4 operations. To further elaborate these operations, Figure 10 depicts their flowchart in detail. The first operation is to send Discovery or Publish messages. In this operation, the trader acts as a Zeroconf end device searching or publishing the services available. In the second operation, the trader acts as a SIP UAC, and send SUBSCRIBE message for triggering the SIP event notification mechanism. After sending the SUBSCRIBE message, the trader will then waits and receives one or more NOTIFY messages for updating the service list. The trader behaves as a SIP UAS in the third operation, which receives the SIP SUBSCRIBE message. The trader will then send one or more NOTIFY messages to the subscribing node. The fourth operation receives the Discovery or Publish messages, where the trader functions again as a Zeroconf end device. This operation and the first operation are essential for a trader to acquire the service available from the service provider, or deliver the service to the service requester.. - 17 -.

(26) Chapter 3 STDP. Fig.10 Operation flowchart of a trader. Note that the SIP is required to be installed in the service traders because of the operations of SUBSCRIBE/NOTIFY. Only one node in a local network needs to be the service trader. For the other nodes, only the implementation of Zeroconf is necessary. The employment of Zeroconf protocol can effectively reduce the pre-configuration efforts, because the protocol allows the simple plug-and-play. By contrast, the SIP devices require the assignments of SIP URI and password. For the stand alone embedded systems such as IP CAMs, the assignments may require considerable efforts especially when the number of IP CAMs is large. The STDP therefore provides an effective approach for lowering pre-configuration cost and providing remote access.. - 18 -.

(27) Chapter 4 System Framework. Chapter 4 System Framework 4.1. STDP with NAT Traversal. As mentioned earlier, the STDP is considered suitable for remote access of services, but there usually exists NAT traversal problem as a result of lots of services located in the residential environment. NAT can translate IP address and port number of network packet when establishing a connection between private and public network. This allows the limited numbers of public IP addresses shared by many network devices in the private network. The Figure 11 shows the general case that how NAT handles the outgoing network traffic.. Fig.11 Schema of NAT. Nevertheless, in addition to the convenience of NAT, there is a drawback of using NAT in the residential environments. The host behind NAT can not establish a real end-to-end connectivity because it has been assigned a private IP address, as shown in. - 19 -.

(28) Chapter 4 System Framework Figure 11. The private IP address can only process hosts routing in the private network. Some services require initiation of TCP connection from the public network or UDP connection between two ends. The network traffic will be disturbed by NAT since the IP address and the port number in packet header is private. In the proposed system, the STDP service trader and IP CAMs probably are located in the residential environment behind a NAT. Thus the NAT traversal problem needs to be solved by our surveillance system. The following sections will explain the NAT traversal problem for STDP protocol and the connection of IP CAMs in the residential environment. Meanwhile, the solutions for these problems will also be depicted.. - 20 -.

(29) Chapter 4 System Framework. 4.1.1 NAT Traversal for IP Camera For a surveillance system, it is important to keep the IP CAMs reliable. Thus, the video streaming from an IP CAM to the client end has to be guaranteed reliability and quality. To achieve this objective, almost all existing digital surveillance systems use HTTP to transmit of video streaming. HTTP is constructed above TCP, which is connection oriented network protocol and can guarantee the data validity. The advantage of TCP is that it can provide a stable quality of service for the surveillance system. In addition, it is convenient for the users to access the digital surveillance system at home by using web browser, since the web technology based on HTTP is so popular. However, TCP is a good solution for transmission of video streaming, but it is not a friendly solution for NAT traversal [20]. The basic problem of establishing TCP through NATs is that with TCP, normally one host listens while the other host initiates the connection (with a SYN packet). Unfortunately, NAT requires that there be an outgoing packet to request the NAT port mapping (punch a hole) before any incoming packets can be received. A listening host never sends such a packet, and therefore can never receive the SYN from the initiating host. As shown in Figure 12, the three-way hand shaking for initiating TCP connection will fail. In the proposed system, if a client wants to make a directly TCP connection to a IP CAM, the IP address of the IP CAM should be transmitted by service trader first. However, if the IP CAM is deployed in the residential environment behind a NAT, the information contained in STDP messages would be incorrect since the IP address of the IP CAM is private address. Figure 13 shows the incorrect NOTIFY message transmitted by service traders between two LANs.. - 21 -.

(30) Chapter 4 System Framework. Fig.12 Three-way hand shaking of TCP NOTIFY SIP URI of Trader B From: SIP URI of Trader A To: SIP URI of Trader B Contact: SIP URI of Trader A Call-ID: call identifier CSeq: sequence number NOTIFY Event: presence Subscription-State: active;expires= seconds until SUBSCRIBE expires Allow-Events: presence, refer Zeroconf: Response _http._tcp. eX-Contact: Add0 ipcam._http._tcp.local. ipcam.local. 80 192.168.0.2 Content-Length: … (SDP not show). Fig.13 NOTIFY message with incorrect address information. Regarding the problem, this thesis applies UPnP solution into the proposed system. UPnP is a technique that is mainly targeted at the integration of residential information appliances (IAs). The UPnP architecture is designed to allow less pre-configuration in residential environment by typical unskilled people. UPnP allows client applications to discover and configure network devices, which are also equipped with UPnP software, automatically. The solution of NAT traversal provided by UPnP is UPnP IGD. It is a standardized device control protocol defined by UPnP, and it is also a simple approach of. - 22 -.

(31) Chapter 4 System Framework automatically configuring port mapping between client applications and NAT. To realize UPnP IGD solution, both NAT and client applications have to support UPnP IGD. In the residential environment, that requirement is not very demanding since almost all the NATs are UPnP IGD-aware nowadays. NAT accepts the port mapping request from client applications and manages the mapping table for all clients.. Fig.14 NAT traversal with UPnP IGD. Figure 14 shows that how UPnP IGD-aware NAT works for NAT traversal. At first, the NAT joins in the multicast group 239.255.255.250 and listens on port 1900 for the request issued by the client application. Then the NAT receives the request and adds the port mapping into its mapping table. The NAT subsequently returns the public IP address and the allocated port to the client application. Given this, the remote host in the public network can connect to the client application directly through the NAT. UPnP IGD is a good solution for the proposed system because it is efficient, simple and supported by many networking device vendors now. In the proposed system, IP CAM initially checks that if it is behind a NAT. Later, it sends a port mapping request to NAT if it is in the private network. Finally, it publishes its service with the port mapping information via Zeroconf. As a result, the STDP messages will be correct as shown in Figure 15, and IP CAM is accessible from the public networks now.. - 23 -.

(32) Chapter 4 System Framework NOTIFY SIP URI of Trader B From: SIP URI of Trader A To: SIP URI of Trader B Contact: SIP URI of Trader A Call-ID: call identifier CSeq: sequence number NOTIFY Event: presence Subscription-State: active;expires= seconds until SUBSCRIBE expires Allow-Events: presence, refer Zeroconf: Response _http._tcp. eX-Contact: Add0 ipcam._http._tcp.local. ipcam.local. 80 140.122.184.26 3000 Content-Length: … (SDP not show). Fig.15 NOTIFY message with correct IP address and port. - 24 -.

(33) Chapter 4 System Framework. 4.1.2 SIP Connection behind NAT Basically, NAT modifies the IP address in UDP/TCP packet header to achieve the translation. Nevertheless, some applications based on UDP/TCP have IP address in their packets payload, for example, multi-media session, file sharing, and on-line game etc., which apply “peer-to-peer” technology. The address information in the payload is not modified by NAT because NAT can only process the packet header of IP network. Therefore, those applications, including SIP, will not function normally with the incorrect address information. In Figure 16, the private IP addresses (e.g., 192.168.0.2/192.168.0.3) are not available in the public networks. In the STDP protocol, the service information is transmitted by SIP. So, the NAT traversal of SIP has to be solved for the proposed system.. SUBSCRIBE sip:[email protected]:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 140.122.185.30:5060 Max-Forwards: 70 From: "geexbox" <sip:[email protected]> To: sip:[email protected] Contact: "geexbox" <sip:[email protected]:5060;transport=UDP> Call-ID: 09a80005336c7d23ee56 …. Fig.16 Incorrect SIP message. Fortunately, there is a technique that can solve NAT traversal of SIP by modifying the IP address in the packets payload of SIP messages, termed SIP ALG. The SIP ALG will check every passed SIP packets. If the IP address in packet header is private IP address, SIP ALG will modify the packet header with correct IP address. When the IP address in SIP messages is the same as the IP address in IP header, the connection between two UAs and the subsequently transmission behind relative NATs can function. - 25 -.

(34) Chapter 4 System Framework normally. Most of the SIP Proxy Server is SIP ALG available now. The following is the information SIP ALG has to maintain.. z. Outmost Via header: It adds two parameters, “received” and “rport”, into “Via” header to record the source address of SIP messages. That helps the corresponding response message returning successfully.. z. Contact header: It keeps the information in “Contact” header correct. The UAs can use the “Contact” to return the subsequent SIP messages.. z. RTP/RTCP in the SDP: If the SIP media stream session is established, SIP Proxy Server will request an address and a port from Media Relay Server to relay the RTP media stream. Besides, SIP Proxy Server modifies the “c=” and “m=” parameters of SDP in INVITE and 200OK to match the allocated address. Subsequently, the media stream session is relayed by Media Relay Server.. In the proposed system, we integrate the SIP ALG into the SIP Server for NAT traversal. It can eliminate the pre-configuration for unskilled people. The SIP server will handle the problem automatically. Figure 17 shows the correct SIP message after SIP ALG helping.. SUBSCRIBE sip:[email protected]:5060;transport=UDP SIP/2.0 Via: SIP/2.0/UDP 140.122.185.30:5060 rport=1407;received=140.122.184.26 Max-Forwards: 70 From: "geexbox" <sip:[email protected]> To: sip:[email protected] Contact: "geexbox" <sip:[email protected]:1407;transport=UDP> Call-ID: 09a80005336c7d23ee56 …. Fig.17 Correct SIP message After SIP ALG - 26 -.

(35) Chapter 4 System Framework. 4.2. System Architecture. The surveillance system consists of IP CAMs, clients, traders, a SIP server, and NATs. The IP CAMs are deployed in the residential environment, the traders are the service trader described in section 3.3, the clients are computers for remote users to access residential IP CAMs, and the SIP server is used to forward the STDP messages. A simple system overview is illustrated in Figure 18.. Fig.18 A simple system overview: There is only one IP CAM deployed in this example.. As shown in Figure 18, the IP CAMs with private IP addresses are only available in LAN B. The IP CAMs have to send the port mapping request to NAT B via UPnP IGD to be accessible from the public networks. NAT B receives the request and subsequently adds the port mapping into its mapping table. As a result, NAT B opens tunnels for each IP CAMs and returns the information of the public address and the ports to IP CAMs. After acquiring the responses from NAT B, remote access of IP CAMs is possible now. It should be noted that the NAT here is usually a router. Further, both IP CAMs and the NAT have to support UPnP IGD in the system. - 27 -.

(36) Chapter 4 System Framework After finishing port mapping, IP CAMs publish services with their public address and ports (e.g., IP address 140.122.184.26, port 3000) in LAN B. This information can also be actively discovered by trader B. Thus trader B can have the complete service information in LAN B by Publish/Discovery operation. Then, trader B, as an SIP UAS, connects to the SIP server and waits for SUBSCRIBE message from other traders. Suppose now accessing IP CAMs in LAN B are desired from the clients in LAN A. Recall that for the basic STDP, Trader A sends SUBSCRIBE to trader B, and then trader B returns NOTIFY for the service information delivery over WAN. For the NAT traversal, both SIP ALG and UPnP IGD are adopted, as shown in Figure 19. At the beginning, the IP CAM sends a port mapping request to NAT B via UPnP IGD messages, and NAT B open a tunnel for TCP connection to the IP CAM, as shown in Figure 19.(a). NAT B will respond the IP CAM with the mapping information. In Figure 19.(b), trader A and trader B register themselves to SIP Server as UAC and UAS. When the SIP Server received the REGISTER messages, it requires the SIP ALG to process all the messages for NAT traversal. Then, in Figure 19.(c), trader A and trader B identify their own service requester and service providers via service discovery/publish operations. Finally, the service information of the IP CAM is delivered from LAN B to LAN A via SUBSCRIBE/NOTIFY messages, as shown in Figure 19.(d). After receiving the service information, trader A then publishes the information to the client. As shown in Figure 19.(d), the client acquires the service information, and it issues directly a service request via HTTP protocol to the IP CAM. Direct video delivery from the IP CAM to the client then follows.. - 28 -.

(37) Chapter 4 System Framework. (a) IP CAM requests NAT B to open a tunnel for TCP connection via UPnP IGD messages.. (b) Trader A and trader B register to SIP server with the private addresses. That follows a series of modifying address by SIP ALG.. - 29 -.

(38) Chapter 4 System Framework. (c) Tade A and trader B find their own service providers and service requester.. (d) Trader A and trader B establish their connection via SUBSCRIBE/NOTIFY messages. The Contact header field will be rewritten with requester’s source address and port by SIP ALG.. Fig.19 The message flow of the proposed system depicted in Fig.18. - 30 -.

(39) Chapter 4 System Framework It should be noted that the NAT traversal problem can be solved using only UPnP IGD. This method achieves NAT traversal by adding a port mapping in NAT such that the NAT can then listen TCP/UDP connection from other hosts in WANs via the assigned port. This method, however, is not secure for the service trader in the proposed system because the IP addresses can be any where any hosts can connect to the trader behind NAT. Hackers may thus illegally intrude service trader and acquire all the service information. As a result, we adopt the SIP ALG method where the original rule of NAT is followed, and the NAT can only accept the authentic connection request, thereby providing sufficient security for the proposed system. Moreover, since the SIP ALG can operate on SIP servers, there is no need to deploy the SIP ALG in the traders. The implementation cost for the NAT traversal can thus be significantly reduced.. - 31 -.

(40) Chapter 5 Experimental Result. Chapter 5 Experimental Result 5.1. Experimental Setting. The basic scenario of the proposed system is shown in Figure 20. The STDP protocol has been implemented in the test-bed. We assume that the service requester in LAN A (e.g., office, school network environment) wants to access the IP CAMs in LAN B (e.g., home network environment) via STDP protocol. Similar to Figure 18, the scenario consists of two local networks (termed LAN A and LAN B in the figure). LAN A consists of a number of laser printers, one IE browser and one personal computer. LAN B contains a NAT, a number of laser printers, one IE browser, one personal computer and two IP CAMs. As shown in Figure 20, the personal computers serve as the service trader in LAN A and LAN B respectively. The IE browser is the service requester in each local network.. Fig.20 The basic scenario for our experiment. - 32 -.

(41) Chapter 5 Experimental Result All the IP CAMs and laser printers are the service providers in both LAN A and LAN B. They are all of the type _http._tcp. Their IP addresses are dynamically assigned by a DHCP [18] server. The service providers publish their service with their unique hostname. Only the traders in relative local networks require the manual pre-configuration, because the assignments of SIP URI and password are necessary to register to SIP server. Note that, in addition to the IP CAMs, the laser printers are included in this scenario. Since the laser printers supports Zeroconf, detecting the service provided by the laser printers in different local networks demonstrates the fact that the proposed protocol can be adopted for the discovery of services provided by various Zeroconf-based devices. We introduce all the components of the proposed system before discussing our experimental result:. z. IP Camera: A reference design kit (RDK) based on a 200-MHz ARM 920 CPU and an MPEG4. encoder ASIC is used for the IP CAM design. The employment of MPEG4 ASIC allows the source video sequence to be encoded in real-time. Figure 21 shows the IP CAM we used in our experiments. Both the wired and wireless LAN interfaces (i.e., 802.3 and 802.11) are also available in the IP CAMs. The operating system of the IP CAMs is Linux. The Bonjour software development kit (SDK) [2] is adopted for the Zeroconf implementation in the IP CAM.. - 33 -.

(42) Chapter 5 Experimental Result. Fig.21 The IP CAM with its IEEE 802.3 and IEEE 802.11b interface. Fig.22 The camera for capturing video streaming. z. Internet Explorer Browser: Since the IE browser is used as the service requester in each LAN, it is necessary for. the browser to support Zeroconf. In our implementation, the Bonjour plug-in is adopted, which is able to discover the services of type _http._tcp. Figure 23 shows all the services of type _http._tcp discovered by the IE browser in LAN B without the employment of STDP. According to Figure 23, we can observe that these services are actually the services provided by the laser printers in LAN B.. - 34 -.

(43) Chapter 5 Experimental Result. Fig.23 All the services of type _http. _tcp discovered in LAN B without the employment of STDP. z. Service Trader: In the STDP protocol, the service traders are responsible for the delivery of service. information over WANs. We adopt the Bonjour SDK and PJSIP [17] library for implementing the service trader. Figure 24 shows the service trader of the STDP protocol, which is a small piece of software executing on Windows. In the service trader, the users need to fill in the SIP URI and password to register to SIP server. Further, the users have to. select. the. function. (e.g.. service. sender/receiver). of. subscription/notification target of the trader should also be specified.. - 35 -. the. trader.. The.

(44) Chapter 5 Experimental Result. Fig.24 The service trader executing on Windows platform. z. NAT: Customarily, the NAT functions are accomplished by a router in the residential. environment. Therefore, we choose the routers supporting UPnP IGD protocol in our experiments. The specifications of the routers are shown in Figure 25. In addition to supporting Ethernet (e.g., IEEE 802.3), the routers also support other protocols (standards), such as DHCP server/client, Point-to-Point Protocol over Ethernet (PPPoE) [10], Point-to-Point Tunneling Protocol (PPTP) [9], and Dynamic DNS (DDNS) [15] network protocol. All the routers can be used to share the Internet connection among multiple PCs in the residential environment.. z. SIP Server: In the STDP protocol, the SIP messages are forwarded and processed by SIP server.. To implement the SIP server, we adopt OpenSER [14] as our solution. In addition, NATHELPER is functioned for NAT traversal of SIP. It is an extra library developed by OpenSER project. We incorporate it into the SIP server. Thus, SIP ALG is created in SIP. - 36 -.

(45) Chapter 5 Experimental Result server so that the NAT traversal of SIP can be achieved by SIP server.. z. IEEE 802.3 and 802.3u 10Based-T and 100 Based-TX. Hardware. z. WAN: One RJ-45 port to connect to any broadband modem. Specification. z. LAN: Four 10/100Mbps RJ-45 ports Ethernet ports. Routing. z. Static Routing. z. Dynamic Routing (RIP I and II). z. NAT. z. NAPT. z. Client Filtering. z. IP/URL Filtering. z. MAC Filtering. z. WAN service: dynamic IP, static IP, DHCP client, PPPoE, PPTP. z. LAN service: DHCP server, DNS proxy. z. UPnP. z. DDNS. Technical Specification. Firewall. Features. Fig.25 The specifications of the routers used in the experiments. - 37 -.

(46) Chapter 5 Experimental Result. 5.2. Result. This section presents the experimental result of the proposed system. We use the network environment provided by National Taiwan Normal University as LAN A, and the home network provided by ISP (e.g., Hinet) as LAN B. The IP CAMs are deployed in LAN B as a home surveillance system. Figure 26 shows that all services of type _http._tcp in LAN A discovered by Bonjour without the employment of STDP. Figure 27 shows the IP CAMs discovered by Bonjour in LAN B.. Fig.26 All services of type _http._tcp in the LAN A discovered by Bonjour without the employment of STDP. - 38 -.

(47) Chapter 5 Experimental Result. Fig.27 All services of type _http._tcp in the LAN B discovered by Bonjour without the employment of STDP. Fig.28 Trader A sends SUBSCRIBE messages to trader B without SIP ALG - 39 -.

(48) Chapter 5 Experimental Result In Figure 28, trader A sends the SUBSCRIBE messages to trader B via STDP without the deployment of SIP ALG. Therefore, it can be observed that the service information can not be transmitted over WANs since that trader B is behind the NAT. After we adopt SIP ALG into our system, the trader A can receive all the service information in LAN B from trader B successfully. Figure 29 shows that all services of type _http._tcp in LAN B are transmitted to LAN A.. Fig.29 All services of type _http._tcp in LAN A after the deployment of SIP ALG: All services in LAN B have been transmitted to LAN A. But this web page is still provided by the service of printer in LAN A.. We assumed that all the services in LAN B are available in LAN A after all service information is transmitted. Nevertheless, the service information published by IP CAMs in LAN B includes their private IP address, which can only be used in LAN B but not in LAN A. As shown in Figure 30, the domain name of IP CAM (e.g., ipcam.local) will be - 40 -.

(49) Chapter 5 Experimental Result resolved as a private IP address (e.g., 192.168.1.6) and that is meaningless for LAN A. We integrate the MiniUPnP IGD client [13] into our IP CAMs and so that they are able to negotiate with NAT via UPnP. The experimental result of integrated scheme is shown in Figure 31. In LAN A, the service of IP CAM would be resolved into a pair, public IP address and port, for the URL (e.g., 218.167.79.227:3002), which is used for IE browser. The URL can be used to access the IP CAM in LAN B directly. .. Fig.30 The service of IP CAM in LAN A without the deployment of UPnP IGD. - 41 -.

(50) Chapter 5 Experimental Result. Fig.31 The service of IP CAM in LAN A with the UPnP IGD solution. - 42 -.

(51) Chapter 6 Conclusion and Future Work. Chapter 6 Conclusion and Future Work A surveillance system realizing remote access and dynamic deployment of IP CAMs without the need of manual pre-configuration is presented in this thesis. The novel STDP protocol, a hybrid combination of the Zeroconf and SIP protocols, is used in the system. In the STDP, the service lists from remote hosts are obtained by SIP SUBSCRIBE/NOTIFY event notification mechanism. The service discovery and publish operation in a LAN are then based on Zeroconf protocol, which is also used for eliminating manual pre-configuration. Besides, the UPnP IGD and SIP ALG are adopted into the proposed system to solve the NAT traversal problem. UPnP IGD allows the remote access of IP CAMs which are deployed behind a NAT, and SIP ALG achieves NAT traversal of STDP messages. The experimental setting and results have been shown in chapter.5. It can be observed that the integration of STDP protocol with NAT traversal solutions achieves more convenience and flexibility of the surveillance system. With the advantages, it will lead to widespread deployment of the surveillance system to any client with a broadband connection. Moreover, we have demonstrated the convenience of choosing the STDP protocol forwarding our surveillance services in residential environment. Therefore, it is possible that some other IAs could also provide their services over WANs via STDP protocol. That is, the proposed architecture is not only suitable for the surveillance system but also other IAs. Despite the advantages, the proposed system is affected by some major limitations, so further research is necessary. First, more complex network environment need to be studied. For example, the IP CAMs are deployed behind multiple NATs in serial. In such cases the IP CAMs can only provide their services to the clients in the same private. - 43 -.

(52) Chapter 6 Conclusion and Future Work network. The remote access of IP CAMs will be unavailable. Therefore, the research for the solution of multiple NATs traversal could be pursued. Second, since the IP CAM is a standalone unit, it is possible integrating the IP CAMs with other IAs for more complex functions. For example, a sensor deployed near the window detects the break-in in the home. It immediately informs the IP CAM to move around to capture and record the video automatically. Then, the IP CAM sends the warning message and the video to the host of the house via STDP protocol. Certainly, that is an intelligent and effective way for our home security and there are many alike use case existed. In the future, researches based on the proposed system can be proceeded for more convenient and wider range of applications.. - 44 -.

(53) References [1] A. Roach. (2002). “Session Initiation Protocol (SIP)-Specific Event Notification.” IETF RFC 3265 [2] Bonjour, http://developer.apple.com/opensource/internet/bonjour.html, lasted visited: (2008) [3] D.-S Kim, J.-M. Lee, W.-H. Kwon, and I.-K. Yuh. (2002). “Design and Implementation of Home Network Systems Using UPnP Middleware for Networked Appliances.” IEEE Trans. Consumer Electronics, 963-972 [4] DNS-SD official website, http://www.dns-sd.org/, last visited (2008) [5] E. Guttman, C. Perkins, J. Veizades, and M. Day. (1999). “Service Location Protocol, Version 2.” IETF RFC 2608 [6] E. Guttman. (2001). “Autoconfiguration for IP Networking: Enabling Local Communication.” IEEE Internet Computing, 81-86 [7] J. Waldo. (2000). “The Jini Specifications 2nd.” Addison-Wesley [8] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler. (2002). “SIP: Session Initation Protocol.” IETF RFC 3261 [9] K. Hamzeh, G. Pall, W. Verthein, J. Taarud, W. Little, and G. Zorn. (1999). “Point-to-Point Tunneling Protocol (PPTP).” IETF RFC 2637 [10] L. Mamakos, K. Lidl, J. Evarts. D. Carrel, D. Simone, and R. Wheeler. (1999). “A Method for Transmitting PPP Over Etherent (PPPoE).” IETF RFC 2516 [11] M. Rahman, D. Braun, and D. Bushmitch. (2005). “A framework to access networked. appliances. in. wide. area. networks.”. Proc.. IEEE. Consumer. Communications and Networking Conference, 261-266 [12] Multicast DNS official website, http://www.multicastdns.org/, last visited (2008) [13] MiniUPnP Project, http://miniupnp.free.fr/, last visited (2008) - 45 -.

(54) [14] OpenSER official website, http://www.openser.org/, last visited (2008) [15] P. Vixie, S. Thomson, Y. Rekhter, and J. Bound. (1997). “Dynamic Updates in the Domain Name System (DNS UPDATE).” IETF RFC 2136 [16] P. Srisuresh, M. Holdrege, Lucent Technologies. (1999). “IP Network Address Translator (NAT) Terminology and Considerations.” IETF RFC 2663 [17] PJSIP official website, http://www.pjsip.org/, last visited (2008) [18] R. Droms. (1997). “Dynamic Host Configuration Protocol.” IETF RFC 2131 [19] S. Cheshire and D.H. Steinberg. (2005). “Zero Configuration Networking: The Definite Guide.” O’Reilly Media, Inc. [20] S. Guha, P. Francis. (2005). “Characterization and Measurement of TCP Traversal through NATs and Firewalls.” Internet Measurement Conference, 199-211 [21] UPnPTM Forum official website, UPnP-Universal Plug and Play Internet Gateway Device v1.0 http://www.upnp.org/standardizeddcps/documents/UPnP_IGD_1.0.zip, last visited (2008) [22] Wen-Kang Jia. (2006). “Session Initiation Protocol (SIP) Methodology Handbook.” Kings information [23] Y.-C. Tung, C.-M. Ou, W.-J. Hwang, and W.-D. Wu. (2008). “Service Discovery of IP Cameras Using SIP and Zeroconf Protocol.” Autonomic and Trusted Computing, 388-402. - 46 -.

(55)