in UPnP are regarded as a UAC and a UAS in SIP. Therefore, straight mapping a UPnP advertisement request message to a SIP REGISTER message and a UPnP search message to an INVITE message is available. However several issues remain. A method to discover interesting devices and services is different between UPnP and SIP. In searching for an interesting device and service in UPnP, multiple search requests can be issued using HTTP/MU. Each request contains not only the specific device and service, but an interested type of defines and services. In SIP, a UAC specifies the single search target in an INVITE message, not the type of devices. To solve the above problem, first, we utilize multiple contact URIs in the contact field in a REGISTER message. In a contact field, search target candi- dates including the particular device uid, types of the device, and services are specified and registered to the register server. Second, when an INVITE mes- sage is issued to search for interesting devices and services, we extend the a field in the SDP to add such search target information to the INVITE message. This extension is reasonable since SDP specifies information for connecting to a target. Allowing multiple search targets in the contact headers can provide abstract home services. For example, if a control point requires an abstract TV program recording service, then actual devices such as a DVD or PC in the contact headers can be registered as suitable concrete providers of the abstract service. A SIP registry server can then select a recording device based on the contact information. 7.5 Redesigning UPnP Middleware In this section, we describe how discovery functionalities in UPnP may be implemented with SIP functionalities, while preserving UPnP API specifica- tions. In the following, we show a mapping between UPnP messages and SIP messages*. 7.5.1 Discovery: Advertisement In the discovery advertisement phase of UPnP, a device multicasts a NOTIFY message as shown below, thus advertising to control points its participatio