in preferred embodiments , a manual means of guid exchange in order to allow further ptp / ip communication , also known as “ device pairing ”, is provided . this exchange mechanism is particularly suited to usage scenarios for digital cameras and associated network printers . however , as may understood by those skilled in the art , alternative forms of exchange mechanisms may be used to support alternative embodiments . two particular device embodiments permit ( i ) a legacy ptp camera to be connected to a ptp / ip enabled pictbridge printer and ( ii ) a legacy pictbridge printer to allow connections to be created with ptp / ip enabled digital cameras . as such , a device in accordance with a preferred embodiment provides tcp / ip network compatibility for legacy media devices such as ptp cameras and pictbridge printers . advantageously , pictbridge functionality may be extended to a tcp / ip network by replacing the ptp / usb transport with ptp / ip , even when devices do not support a common physical tcp / ip network link . referring now to fig2 , devices d 1 and d 2 are preferably paired before ptp / ip communication across a network takes place . in accordance with a preferred embodiment , a protocol based on an exchange of messages contains pairing information ( guid and friendly name ) between two devices placed in a pairing mode ( or pairing state ). in general , messages employed by the protocol are preferably as shown in fig4 . each packet part of this protocol starts with a 16 byte field representing a guid of the protocol — a value specially generated for this protocol . the guid used by the ptp / ip pairing mechanism of the preferred embodiment is ofdb8efb - 6968 - 4734 - a0cf - 48694382a3d7 . this guid is basically a protocol identifier for ensuring that the received udp packets will not be wrongfully interpreted . the protocol guid field is followed by a type field having one of the following values ( two byte field ): this in turn is followed by a payload which comprises a variable size content , differing according to the type of the packet . preferably , a user causes a device to enter pairing mode by interaction with a suitable actuator . in a general purpose computing device running an application which communicates using ptp / ip , such actuation can include pressing a keyboard key or actuating a pointer switch . on less complex or more dedicated devices described later , however , actuation can be through a simple button . for simplicity , however , we will refer to these generally as the pairing actuator . preferably , the protocol is such that the chances that the pairing will be done successfully are larger if the pairing actuator on both devices which are to be connected is pressed at or about the same time . in the preferred embodiment , when placed in pairing mode , the ptp / ip device sends out a series of device info messages and starts listening on udp port 15740 for any device info messages from remote devices . when in pairing mode , the device sends one device info message per second and the expiry time of pairing mode is set to 5 seconds . fig5 presents a preferred layout for a device info packet : device guid — is a device identifier ( guid ) device friendly name — null - terminated unicode string that contains a human readable name for the remote device . the information in this field is generally used for application user interface purposes . reserved data — 0 or more bytes reserved for the expansion of the protocol . the maximum value is limited by the mtu ( maximum transmission unit ) of the used underlying network . this can be used for manufacturer specific data of the sending device . the device info message is sent multiple times , with a time interval between them , to compensate for the fact that the two devices involved in the pairing procedure need not be put in pairing mode at exactly the same moment in time . preferably , device info messages are sent at the above interval until a confirmation message is received or until the expiry time . once a peer device receives a device info message , it will cache it and send out confirmation messages . each confirmation message contains the information about both the originating and confirming device ( guids ). to maximize the chances that the confirmation message will not be lost , it is preferred that a device send out three such messages at a time interval of 100 ms . again confirmation messages are preferably uni - cast on port 15740 udp . more specifically , they may have the format presented in fig6 , where : own device guid — is a device identifier ( guid ) received device guid — is a device identifier ( guid ) received via a device info message from the peer device . preferably , if a device involved in pairing receives device info messages from multiple devices when in pairing mode , it may fail the pairing procedure . thus , the device preferably receives device info messages from only one peer device when in pairing mode to complete a successful pairing procedure . this is a practical limitation and it is based on an assumption that a user would usually wish to pair only two devices . thus , receipt of more than one device info message would be indicative of an erroneous , insecure or undesirable operating environment . likewise , a device should receive a confirmation message from no more than one peer device when in pairing mode for the same reason . the states that a ptp / ip device has to traverse in order to achieve a successful pairing are presented in fig3 . as explained above , a device on entering pairing mode sends its own device info message and then waits for device info messages from peer pairing devices . upon a defined time period ( time_period ), the device resends its own device info information . if upon a defined time out ( time_out ) period no peer device info is received , the device gives up and declares the pairing procedure failed . if the device receives device info message from a peer device , then it sends its own confirmation message and waits for a peer confirmation message . upon receipt of the peer device confirmation message matching the previous information received via peer device info message , the pairing session is completed successfully . if a confirmation message is not received upon the defined timeout ( time_out ) the pairing procedure is declared failed . if other device info messages are received from other devices than the one received initially , then the pairing procedure is declared failed . if other confirmation messages from other devices than the one received initially are received , then the pairing procedure is declared failed . nonetheless , it will be seen that once pairing has been completed between , e . g ., a local device and a remote device , then in certain cases it can be possible to have the local device pair with one or more subsequent devices and to maintain connections to multiple remote devices in separate virtual sessions . the features described herein in accordance with preferred and alternative embodiments find utility in many different types of devices where application software communicating through ptp / ip runs . these include , for example , general purpose computing devices , printers and digital image acquisition devices , e . g ., digital cameras . these features can also be implemented in more dedicated devices such as hardware translators or indeed in software translators . as explained above , there are two ptp transports already used in devices : 1 ) usb — which was the first adopted ptp transport and is currently widely supported in digital still cameras and recently in pictbridge printers ; and 2 ) ptp / ip — which is a relatively new transport and which will become available soon in some wifi cameras . having adopted those transports , users will encounter the situation when it is desirable to have a “ legacy ” usb - ptp device communicate with a ptp / ip device . in a particular embodiment , a translator may be used when it is either not possible or inconvenient to directly connect an initiator to a responder , e . g ., because they are using different transports , i . e ., hardware interfaces . an example would be where a usb camera ( ptp responder ) is to be connected to a pc ( ptp initiator ) via wifi . in the context of the present specification , a ptp translator is a device or a software module that indirectly connects a ptp initiator with a ptp responder , where initiator and responder usually ( but not necessarily ) use a different type of transport ( e . g . usb , tcp / ip , etc .). the function of the translator is to repeat the ptp communication from one transport to another , as it would be if the initiator and responder were connected directly . a feature of such translators is that they don &# 39 ; t fully implement ptp or application level protocols ( i . e . pictbridge ). in general , there are at least two ways for such ptp translator to translate ptp communication traffic : acting as a gateway to perform translation , interpret ptp commands and also generate simple ptp protocol elements ( i . e . implement opensession , closesession , etc .) to deal with multiple sessions on one side and single session on the other side ( i . e . ptp gateway ). that means that the device should know the semantics of ptp commands , and in particular ptp commands used by the pictbridge protocol and being relayed by the translator . a disadvantage can be that it is difficult to implement a generic gateway , because a device may use vendor commands for which the semantics are not known . in general , a gateway can be vendor specific or alternatively allow just standard ptp commands ( for which the semantics are defined ). acting as a bridge to pass - through a ptp command from one end to another using a common translation procedure that converts the packets of one transport protocol to another transport protocol . an advantage is that a generic bridge can be opaque for a ptp device that maintains vendor features . some useful cases of translators , which will be described in more detail later , are as follows : ptp camera adapter — internal or external ptp / usb to ptp / ip device that network enables an existing usb digital camera . in particular , when implemented externally , the adapter can take the form of a dongle . the camera only runs ptp protocol over usb , while the ptp adapter acting as either a bridge or a gateway runs the communication protocols that make the camera a ptp network camera . one end of the adapter acts as a usb - initiator and is connected to the camera , and another end is a ptp / ip - responder and is connected to a ptp / ip initiator . ptp printer adapter — internal or external ptp / ip to ptp / usb device that network enables an existing usb pictbridge ™ printer . again , when implemented externally , the adapter can take the form of a dongle . the printer runs pictbridge ™ over usb , while the ptp adapter , running as a gateway , has the communication protocols to make the printer look like a network pictbridge ™ printer . in this case , one end of the adapter is a usb - responder and is connected to the printer , and another end is a ptp / ip - initiator and is connected for example across a wlan to a wifi camera . such a translator allows a currently available standard pictbridge printer to talk with ptp / ip cameras that will soon appear on the market . ptp pc adapter — ptp / ip to ptp / usb device that network enables an existing pc that works with standard usb ptp cameras . the pc runs a standard ptp / usb initiator ( i . e . windows xp wia or mac osx ica ), while the adapter acts as a standard ptp responder every - time it detects a peer ptp / ip responder , making it look to the pc as it would be directly attached via a usb cable . referring now to fig7 ( a ), a convention ptp compliant digital camera 702 is connected via a usb connection 635 to a ptp camera adapter 701 b according to a preferred embodiment . in this case , the camera ptp responder 690 communicates across a wireless lan via a driver 694 , although it will be seen that it can be arranged to communicate across any network — wired or wireless — using any required transport . it should be noted that in a conventional ptp compliant camera , the ptp responder 611 will in general not allow multiple ptp sessions — because a usb slave 689 was only connectable with one usb host 620 at a time . however if the features of the ptp camera adapter are extended , then the adapter 701 b be used in at least two different scenarios : to allow the camera to implement pictbridge ™ client ; and / or to allow the camera to implement a ptp generic responder . where the camera implements a pictbridge ™ client 606 , then an adapter with a single ptp session is enough and a ptp bridge 686 implementation within the adapter will suffice . the protocol for selecting the ptp device with which the camera communicates during this session is as described in relation to fig2 to 6 and is implemented within a device discovery layer 696 which is responsive to a user actuating a pairing actuator ( not shown ) on the adapter 702 b and the printer 650 within the required time out period and without interference from other pairing devices . where the camera implements a ptp generic responder , then it is natural for this responder to work with multiple initiators in the network . in order for the ptp camera adapter to support multiple ptp sessions , the adapter supports a feature called “ virtual sessions ”. with virtual sessions the adapter serializes ptp traffic from multiple remote devices including ptp initiators 660 to one usb slave 689 . each remote initiator is paired in sequence with the adapter as described with reference to fig3 to 6 , so limiting the connections to the camera 702 . in relation to virtual sessions , a unit of serialization normally is a ptp transaction . in most cases , the standard ptp commands are stateless — so allowing one ptp transaction at a time will do for simple scenarios . however , in general there are standard and as well as vendor commands that work in a specific sequence and are not stateless . in that case the adapter would utilizes further semantics of such commands and a more complex serialization of transactions , e . g ., so that one initiator 660 will not break an atomic command sequence of another initiator . additionally , some commands involve more actions than just passing - through : e . g . a deleteobject command involves sending objectremoved event for each virtual session than the current one . for this reason , a ptp gateway 686 implementation is more appropriate for implementing virtual sessions and for ensuring an ordered processing of transactions between sessions for devices paired through the adapter . in one implementation of the adapter , both bridge and gateway are implemented . most of the time , the adapter works in bridge mode ( while only one session is active ). if multiple initiators want to work with the camera , then the adapter switches into ptp gateway mode , allowing virtual multiple sessions . referring now to the example illustrated at fig7 ( b ), the printer adapter 701 a of this embodiment has two interfaces : a wifi interface 694 and usb slave interface 689 . its primary function is to transform a standard usb pictbridge ™ printer 601 into a wifi pictbridge ™ printer , available on a wireless local area network 645 . such an adapter preferably connects only to pictbridge ™ clients ( ptp / ip responders that advertise their application protocol to be pictbridge ™, or their intent to print ). it will be seen that the adapter 701 a can in practice only be implemented with a gateway layer 686 rather than with more basic bridge functionality . one reason is that the legacy printer side usb transport ( unlike ptp / ip ) does not carry enough self - descriptive information about the command being transported , so it does not allow the ptp printer adapter ( or a ptp pc adapter ) to be implemented as a ptp bridge . another reason is that a ptp bridge does not allow a virtual session approach to be implemented safely in all cases . it will be seen that the ptp printer adapter transforms a bus based protocol ( usb ) into a networking protocol ( ip ). as shown in fig8 , this ptp protocol translation from one transport ( ptp / usb ) to another transport ( ptp / ip ) is performed only when a ptp / ip device is detected and a successful ptp / ip connection is established , e . g ., as described in relation to fig3 - 6 and again performed by the device discovery layer 696 . then , if this is the first session to be established , the usb slave 689 of fig7 ( b ) attaches to the printer &# 39 ; s usb bus 620 , causing the enumeration and usb connection . the initiator ( printer ) starts the communication with the remote ptp device , for example , a ptp / ip camera 650 as it would if the remote device were connected locally . the usb attach and detach is performed by programmatically connecting / disconnecting a 1 . 5m pull up resistor ( see usb bus specifications ) used by usb standard for detection of a usb 12 mbps device connected to the bus . since only one remote device 650 connected to the ptp printer adapter 701 a prints to the actual printer at a time , the printer adapter deals with multiple paired ptp / ip devices in sequence beginning with the first paired device for which print intent has been detected . once the printing is done with this device , the dongle looks for more paired ptp / ip devices ( with print intent ). if more devices are detected , the printer chooses one and initiates the connection to them . due to the ptp / usb transport specification limitations ( i . e not knowing the next phase of a ptp command ), the translation that takes place between ptp / usb and ptp / ip can &# 39 ; t be done just at the transport level . the device will need to be a ptp gateway , in the sense that it will interpret the ptp payload to figure out what command is in progress . in this way , the translator will be able to associate a command with a known data - phase ( by maintaining a lookup table with the associations ). this device is not generally designed to work with vendor specific commands , and so , for each vendor command to be supported , the translation table would be updated with vendor specific information . referring to fig7 ( c ), pc adapter 625 works in a very similar manner as the ptp printer adapter of fig7 ( b ). a difference is that it can establish a connection with a ptp generic responder application instead of a pictbridge ptp responder . this device , due to usb limitations , will be either connected with only one ptp / ip responder , for example , within a ptp / ip camera 650 , either at any time or it would establish virtual sessions for each ptp / ip responder . the present invention is not limited to the embodiments described above herein , which may be amended or modified without departing from the scope of the present invention as set forth in the appended claims , and structural and functional equivalents thereof . in methods that may be performed according to preferred embodiments herein and that may have been described above and / or claimed below , the operations have been described in selected typographical sequences . however , the sequences have been selected and so ordered for typographical convenience and are not intended to imply any particular order for performing the operations . in addition , all references cited above herein , in addition to the background and summary of the invention sections , are hereby incorporated by reference into the detailed description of the preferred embodiments as disclosing alternative embodiments and components .