Re: UPnP Base Driver issue Was: FW: Information about Cyberlink 1.80

["Jackson, Bruce" <br...@qualcomm.com>]

Further to my previous investigations, I have now located what I believe to be the source of the problem we are seeing when using the UPnP stack as a ContentDirectory for the Xbox 360.

During the discovery phase, the Xbox sends out SSDP:discover messages as expected to the well known multicast address and port.
The UPnP base driver/cyberlink stack reponds correctly to this by sending out a UDP response to the source IP address and port that sent the request to the multicast channel (see UPnP Device Architecture 1.0, section 1.2.3 Discovery: Search: Response).

However, this response does not appear to be acknowledged by the Xbox, because it did not originate from port 1900. We've taken a look at other UPnP implementations which do work with the Xbox, and all of these have this in common: they use port 1900 for all outbound UDP messages. Now, I realize that the UPnP specification does not mandate this, but it appears to be something which has been widely adopted, and Cyberlink should follow suit.

Any thoughts?


On 30/06/2008 13:47, "Stefano Lenzi" <ki...@interfree.it> wrote:

Jackson, Bruce wrote:
> Hi Stefano
>
> I'll post the XML on Monday, but in answer to your question:
>
> Looking at the code the id should never be empty, because the function
> is called as follow:
>         String localId = new
> StringBuffer(id).append("/device/").append(i).toString();
>          buildDevice(localId,devUPnP,aux[0]);
> and as you can see the localId can't be an empty String.
>
> ... The point that I was making was that if you follow this function back:
>
> public static Device createCyberLinkDevice(ServiceReference sr)
>     private static Device buildRootDeviceNode(Node root,ServiceReference sr)
>         addDevices("",devUPnP,sr);
>
> You find that the empty string is passed in whenever a new root device is created. Is this correct?

Yes, it is

> This means that every device will have a localId  starting /device/

Yes it's true but it will happen only for the embeeded device not for
the root device, because it is constructed without invoking the method
buildDevice(...) in fact the description URL of the root device has the
following format "http://" + <hostname> + ":" + <portnumber> "/gen-desc.xml"

>
>