1

Windows Media Connect Device Compatibility Specification

WinHEC 2004 Version - April 12, 2004 - Windows Digital Media Division

Abstract

Microsoft has developed an application called ”Windows Media® Connect” for delivering audio, video, and photo content to digital media receivers on a home network. The application is based on public standards such as UPnP and HTTP. However, certain aspects of this application might be Microsoft specific.

This document provides a detailed technical description on how to make a device compatible with Windows Media Connect.

Disclaimer

This is a preliminary document and may be changed substantially prior to final commercial release of the software described herein.

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.

Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.

Unless otherwise noted, the example companies, organizations, products, domain names, e-mail addresses, logos, people, places and events depicted herein are fictitious, and no association with any real company, organization, product, domain name, email address, logo, person, place or event is intended or should be inferred.

© 2004 Microsoft Corporation. All rights reserved.

Microsoft, Windows, Windows Media, and Windows NT are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.

The names of actual companies and products mentioned herein may be the trademarks of their respective owners.

Table of Contents

1Introduction

1.1Overview

1.2References

1.3More Information

2Baseline Technologies and Interoperability Stack

3Network Configuration

3.1IP Addressing

3.2DHCP

3.2.1PC with Internet Connection Sharing

3.2.2Home Gateway/Router with DHCP (NAT)

3.3Non-DHCP

3.3.1Hub with Manual or Auto IP Address Configuration

3.3.2Direct Connection with Crossover Connection

3.3.3Direct connection with a Wireless Ad Hoc Network

4Discovery and Authorization

4.1Authentication

4.1.1UPnP Media Renderers

4.1.2Control Points

4.1.3UI Considerations

4.2SSDP NOTIFY

4.3SSDP M-SEARCH

4.4Universal Resource Locators

5Format Support

5.1Audio

5.1.1Playlists

5.2Video

5.3Photo

5.4Using the Connection Manager For Format Information

5.5Format Transcoding

5.5.1Inter-Format Transcoding

5.5.2Intra-Format Transcoding

6Streaming

6.1Discovering Streaming Capabilities

7Accessing the Server

7.1Container Hierarchy

7.2Device UI Considerations

7.2.1Accessing relevant Content

8Appendix A – Supported Metadata

9Appendix B - Supported UPnP Media Server Features

1Introduction

1.1Overview

Microsoft has developed an application called ”Windows Media® Connect” for delivering audio, video, and photo content to digital media receivers on a home network. The application is based on public standards such as UPnP and HTTP. However, certain aspects of this application might be Microsoft specific.

This document provides a detailed technical description on how to make a device compatible with Windows Media Connect. This document is broken into seven sections: this overview, interoperability stack, network configuration, discovery and authentication, format support, streaming, and accessing the media.

1.2References

This document provides information on making device compatible with Windows Media Connect. Much of the technology described is officially defined in the references listed below.

  • UPnP Device Architecture v1.0, available at
  • UPnP MediaRenderer:1 Specification, available at
  • UPnP MediaServer:1 Specification, available at
  • UPnP AV Architecture:0.83, available at
  • IETF RFC 1945, Hypertext Transfer Protocol – HTTP/1.0, T. Berners-Lee, R Fielding, H. Frystykm May 1996
  • IETF RFC 2616, Hypertext Transfer Protocol – HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee June 1999

1.3More Information

This document is meant to provide a technical introduction to Windows Media Connect and building a compatible device. For further information and a complete set of requirements please send email to:

2Baseline Technologies and Interoperability Stack

Windows Media Connect is based on a specific set of network protocols, codecs and other technologies. The baseline set of technologies required for interoperability is listed in Table 1. Please note that the codec technologies are recommendations based on codecs supported by Windows Media Connect.

Table 1: Baseline technologies

Layer / Protocol/Technology
Codecs / Audio: WMA, MP3, PC
Video: WMV, MPEG-1, MPEG-2
Photos: JPEG, GIF , BMP
Content Protection / Microsoft Link Protection (with MS UPnP extensions)
Control, Discovery, and Eventing / UPnP A/V 1.0 (with MS UPnP extensions)
UPnP 1.0
Audio Video Transport / HTTP
Network Protocols / TCP/UDP/IP

3Network Configuration

Fjord only supports five possible network configurations. The reasons for this are primarily for security. Specifically, we wanted to ensure all control points, renderers, and servers on the network have either a private 192.168.X.X IP address or an auto-IP address in the range of 169.254.x.x.

3.1IP Addressing

For security reasons, Fjord only supports two address ranges. Fjord will not operate if the hosting PC does not have an address in one of the supported ranges. In addition client devices must be on the same subnet. The supported IP address ranges are listed in Table 2.

Table 2: Supported IP addresses

IP Address Type / Range
Private IP addresses / 192.168.x.x
Auto IP addresses / 169.254.x.x

3.2DHCP

3.2.1PC with Internet Connection Sharing

The first configuration involves a PC with Internet Connection Sharing (ICS) and a dual Network Interface Card (NIC). ICS will act as a Dynamic Host Configuration Protocol (DHCP) service in this case, providing private IP addresses. Devices can either connect directly to one of the network ports on the PC or the computer can be connected to a hub if more than one device needs to be connected to the PC.

3.2.2Home Gateway/Router with DHCP (NAT)

The second configuration involves using a Home Gateway/Router with DHCP. Any home gateway product that can distribute 192.168 addresses using DHCP will enable Windows Media Connect to work. All devices and PCs must be connected to the Gateway/Router.

3.3Non-DHCP

3.3.1Hub with Manual or Auto IP Address Configuration

The third configuration covers the situation when there is no DHCP server and an IP address is set either manually or through auto-IP. In this scenario the PC and devices connect to a hub or router.

3.3.2Direct Connection with Crossover Connection

The fourth configuration involves devices directly connected to a PC with a crossover cable

3.3.3Direct connection with a Wireless Ad Hoc Network

The final configuration is based on a PC and device directly connected through a wireless ad hoc network. In this instance the IP address of the device would either be an auto-IP address, or a manually assigned IP address in the 192.168.x.x range

4Discovery and Authorization

4.1Authentication

Windows Media Connect requires each DMR to be authorized by the user before it can access content or metadata. The first time a UPnP Media Render, UPnP Media Renderer/Control Point combo, or Control Point announces itself or tries to connect to the server, Windows Media Connect will notify the user with a balloon message similar to below.

The user then must authorize the device by taking some action like clicking a check box as shown in the sample UI below.

Devices are identified through their MAC address. Any request or notification from a new MAC address will initiate the above mentioned authorization process.

4.1.1UPnP Media Renderers

UPnP Media Renderers are discovered by the normal SSDP notification or searches (see section 4.2). When Windows Media Connect first acquires a notification or receives a response to a search, the new device balloon will appear.

4.1.2Control Points

UPnP control points are discovered the first time they try to invoke an action on the UPnP Media Server of Windows Media Connect. The first time a control point invokes an action, Windows Media Connect returns the following error:

<UPnPError xmlns="urn:schemas-upnp-org:control-1-0">

<errorCode xmlns="">801</errorCode>

<errorDescription xmlns="">Access Denied</errorDescription>

</UPnPError>

Note that Windows Media Connect does not support the scenario where the rendering device has a different MAC address from the control point, unless the rendering device is a UPnP Media Renderer.

4.1.3UI Considerations

When a device receives the 801 error code, it should consider displaying a message informing the user to authorize the device on the server.

4.2SSDP NOTIFY

Windows Media Connect sends out SSDP NOTIFY messages every 15 minutes. Each message is sent two times. Sample messages are given below. Certain fields give in the messages below will have different values depending on the machine hosting Windows Media Connect.

NOTIFY * HTTP/1.1\r\n

Host:239.255.255.250:1900\r\n

NT:urn:schemas-upnp-org:service:ConnectionManager:1\r\n

NTS:ssdp:alive\r\n

Location:

USN:uuid:224e2bb9-6961-4d79-b05f-f72cb415dc6c::urn:schemas-upnp-org:service:ConnectionManager:1\r\n

Cache-Control:max-age=1800\r\n

Server:Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0\r\n

\r\n

NOTIFY * HTTP/1.1\r\n

Host:239.255.255.250:1900\r\n

NT:urn:schemas-upnp-org:service:ContentDirectory:1\r\n

NTS:ssdp:alive\r\n Location:

USN:uuid:224e2bb9-6961-4d79-b05f-f72cb415dc6c::urn:schemas-upnp-org:service:ContentDirectory:1\r\n

Cache-Control:max-age=1800\r\n

Server:Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0\r\n

\r\n

NOTIFY * HTTP/1.1\r\n

Host:239.255.255.250:1900\r\n

NT:urn:schemas-upnp-org:device:MediaServer:1\r\n

NTS:ssdp:alive\r\n

Location:

USN:uuid:224e2bb9-6961-4d79-b05f-f72cb415dc6c::urn:schemas-upnp-org:device:MediaServer:1\r\n

Cache-Control:max-age=1800\r\n

Server:Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0\r\n

\r\n

NOTIFY * HTTP/1.1\r\n

Host:239.255.255.250:1900\r\n

NT:upnp:rootdevice\r\n

NTS:ssdp:alive\r\n

Location:

USN:uuid:224e2bb9-6961-4d79-b05f-f72cb415dc6c::upnp:rootdevice\r\n

Cache-Control:max-age=1800\r\n

Server:Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0\r\n

\r\n

4.3SSDP M-SEARCH

Windows Media Connect also does an SSDP M-SEARCH for Media Renderers. The M-SEARCH message is listed below.

M-SEARCH * HTTP/1.1\r\n

Host:239.255.255.250:1900\r\n

ST:urn:schemas-upnp-org:device:MediaRenderer:1\r\n

Man:"ssdp:discover"\r\n

MX:3\r\n

\r\n

Windows Media Connect will respond to a properly formatted M-SEARCH with the following:

HTTP/1.1 200 OK\r\n

ST:urn:schemas-upnp-org:device:MediaServer:1\r\n

USN:uuid:224e2bb9-6961-4d79-b05f-f72cb415dc6c::urn:schemas-upnp-org:device:MediaServer:1\r\n

Location:

Cache-Control:max-age=1800\r\n

Server:Microsoft-Windows-NT/5.1 UPnP/1.0 UPnP-Device-Host/1.0\r\n

Ext:\r\n

\r\n

4.4Universal Resource Locators

It should be noted that Windows Media Connect URLs can be large. Devices must be capable of handling URLs with a maximum size of 256 bytes. Device description URLs are in the form:

Where a GUID takes the form of:

XXXXXXXX-XXXX-XXXX-XXXX-XXXX-XXXXXXXX

Control, eventing, and presentation URLs will be in the form:

control=uuid:<guid>+<service id>

A typical device description URL for Windows Media Connect is listed below.

5Format Support

Windows Media Connect supports the distribution of audio, video, and photos. The following section discusses the formats supported for each content type

5.1Audio

Windows Media Connect supports the following audio formats.

Table 5: Supported Audio Formats

Format Type / File Extension / MIME Type
Window Media Audio / .WMA / audio/x-ms-wma
MPEG-2 Layer 3 / .MP3 / audio/mp3
WAV / .WAV / audio/wav
PCM / N/A / audio/L16
MPEG-1 / .MPG / audio/mpeg

5.1.1Playlists

Windows Media Connect supports the following Playlist formats.

Table 6: Supported Playlist Formats

Format Type / File Extension / MIME Type
Windows Media Play Lists / .WPL
M3U / .M3U

Playlists are supported as UPnP containers. As described in section 7.1, there is a top-level playlist container under the music container. Each M3U or WPL playlist file will appear as a subcontainer under the playlist container. Each subcontainer will contain the individual music tracks associated with a given playlist file, presented as UPnP objects with proper network URLs.

5.2Video

Windows Media Connect supports the following video formats.

Table 7: Supported Video Formats

Format Type / File Extension / MIME Type
Window Media Video / .WMV / video/x-ms-wmv
MPEG-2 / .MPEG, .MPG / \video/mpeg
MPEG-1 / .MPG / Video/mpeg
AVI / .AVI
DVR-MS

5.3Photo

Windows Media Connect supports the following image formats.

Table 8: Supported Photo Formats

Format Type / File Extension / MIME Type
JPEG / .JPG, .JPEG / image/jpeg
GIF / .GIF / image/gif
PNG / .PNG / image/png
BMP / .BMP / image/bmp
TIFF / .TIF, .TIFF / image/tiff

5.4Using the Connection Manager For Format Information

The UPnP A/V ConnectionManger service supports an action called “GetProtocolInfo”. Control points and Media Renderer/CPs can use this action to inquire about the format support capabilities of Windows Media Connect. This function will allow devices to filter out content supported by Windows Media Connect and not supported by the device.

The GetProtocolInfo message looks as follows:

When GetProtocolInfo is invoked, Media Connect will return the following in a comma separated list:

http-get:*:video/mpeg:*

http-get:*:audio/mpeg:*

http-get:*:audio/wav:*

http-get:*: audio/x-ms-wma*

http-get:*:video/x-ms-wmv:*

http-get:*:video/avi:*

http-get:*:audio/L16:*

5.5Format Transcoding

Windows Media Connect offers two types of transcoding, intra-format and inter-format. Intra-format transcoding deals with transcoding parameters within a given format, such as MP3 bitrate. Inter-format transcoding deals with transcoding between two formats, such as MP3 and WMA.

5.5.1Inter-Format Transcoding

Inter-format transcoding is handled by providing multiple resource elements. Each available resource element will specify a URL for an available format. One URL can be used to retrieve the content in the original format, while the other URL can be used to retrieve the transcoded content. The virtual URL is created using a parameterized URL. The parameter for the URL is:

format = “name of desired format (see table below)”

Example:

The following packet shows an item returned that offers inter-format transcoding and hence has multiple resource elements.

<DIDL-Lite xmlns:dc=" xmlns:upnp="urn:schemas-upnp-org:metadata-1-0/upnp/"

xmlns="urn:schemas-upnp-org:metadata-1-0/DIDL-Lite/">

<item id="239C" restricted="true" parentID="4">

<dc:title>(Da Le) Yalleo</dc:title>

<res size="5659039" duration="0:05:53.600" bitrate="16000" protocolInfo="http-get:*:audio/mpeg:*"

sampleFrequency="44100" bitsPerSample="16" nrAudioChannels="2">

<res duration="0:05:53.600" protocolInfo="http-get:*:audio/L16:*" sampleFrequency="44100" bitsPerSample="16"

nrAudioChannels="2">

<upnp:class>object.item.audioItem.musicTrack</upnp:class>

<upnp:genre>Rock</upnp:genre>

<upnp:artist>Santana</upnp:artist>

<upnp:author>Santana</upnp:author>

<upnp:album>Supernatural</upnp:album>

<upnp:originalTrackNumber>1</upnp:originalTrackNumber>

<dc:date>2003-3-31</dc:date>

</item>

</DIDL-Lite>

The following table lists supported inter-format transcoding

Starting Format / Transcoded Format
WMA / PCM
MP3 / PCM
JPEG / YUV
GIF / YUV
BMP / YUV

5.5.2Intra-Format Transcoding

Intra-format transcoding is handled through parameterized URL. A single URL is provided for a given resource and a client device can pass back what values are necessary in the parameters. An example of a parameterized URL is:

6Streaming

Fjord only supports HTTP 1.1 and HTTP 1.0 streaming.

Any and all trick play occurs using the Range header defined in the HTTP 1.1 specification (RFC 2616). To rewind or fast-forward, devices need to send an HTTP-GET request with a range header for the data you seek. Because HTTP-GET is a client-pull streaming model, the speed of rewind and fast forward may be limited by network traffic and the speed at which the host can send data.

6.1Discovering Streaming Capabilities

As with Formats discussed in section 4.4, the streaming mechanisms used by Media Connect can be acquired using GetProtocolInfo. Windows Media Connect always returns http-get for this function.

7Accessing the Server

Content on the Fjord server can be found through the UPnP browse or search command. The key to providing a quality user experience is to understand how Fjord structures its containers and what filter and sort variables are supported. This information is presented in the following section.

7.1Container Hierarchy

The Fjord container hierarchy is show in the figure below.

7.2Device UI Considerations

The UPnP specification does not provide a normative section describing the container hierarchy for content directory services. For this reason it is not possible for a device to make an association between container hierarchy and UI because other UPnP media servers may choose a different hierarchy. For this reason we suggest devices define their UI based on classes supported by UPnP and Microsoft extensions, and then create UI components that enable you to search on that class.

7.2.1Accessing relevant Content

The best method for accessing relevant content is to use a search command to search for the classes that are relevant. For example if a device supports audio and has a genre button, clicking on the genre button could initiate the following search:

Search(“0”, “upnp:class = “object.container.genre.musicGenre””, “*”, 0, 0, “”)

8Appendix A – Supported Metadata

This section lists all the metadata parameters supported by Windows Media Connect. For information on how to search, browse, and sort on these metadata fields, please see the UPnP section. Although Windows Media Connect supports all of these metadata fields, they are only provided when that information is available for a given piece of content.