I wanted to give you some information on the status of our tests of the Listen Again service in Windows Media. This will be available for UK and International users, as a replacement to the RealMedia offering (which is being deprecated) - and will cover National, Nations and Local radio services.
We are currently in testing stages with the ASX metafiles required to allow the Windows Media Audio files to be linked to correctly. Secondly we need to expose the relationship between our schedule programmes and the ASX files. At the moment the latter is done using our AODFeed which we'll be overhauling in the new year given the feedback we've received, but in the meantime I want to use this in my examples below.
Many eagle-eyed developers spotted our testing in the feeds. However we never announced that this was just testing, we wanted to wait until we were 100% sure that it was all correct and working before we made a proper announcement. Some were eager to get this stuff working on their devices or services but we have found a couple of problems that we're busy trying to address.
Unfortunately the forthcoming holiday period limits our abilities to roll out fixes to the live servers as our annual 'lock down' (change freeze) happens and we really wanted to have this available for the holidays - bad news! However - if you wish to get your hands on the streams, we've worked out a couple of simple ways to reliably work-around the issues - good news!
Getting UK and International stream details
Firstly, as happened with our RealMedia RAM metafiles, the ability to easily get both the UK stream details and the International stream details from one IP address is broken at the moment (or rather - it works too well... we need to protect our rights holders content - this always comes first). If you use the example from the Radio 4 AODFeed. If you request the MediaSelector XML from within the UK you get different results from outside the UK. Try it (if you've got access to an IP address in the UK and outside).
https://www.bbc.co.uk/mediaselector/4/mtis/stream/b00p4jtn - "Today" 9th Dec 2009.
(Note: if you are trying this test after the 16th of December, you'll need to pick your own test MediaSelector request from the AODFeed - as the 7 day availability window will have shut on this example)
If you compare the results of your two requests, you'll see that the reference to the ASX files for this programme are slightly different. Further - requesting those ASX files is restricted in the same way. However - there is a work around until we can address this.
WORK AROUND: and once you get the ASX file contents you'll see that the only significant difference is the server farms and the paths from which you request the underlying streams. (I'm giving the exact details from the example 'Today' programme - note that I've dropped the streaming protocol from the front, I'll come to that in a moment)
For UK users:
For International users:
So, though we know it's not ideal, it is simply a case of requesting the ASX file and then parsing to get hold of the clip filename and then it's easy to tag on the appropriate 'wm' (International) or 'wm-acl' (UK) and then the redundant path ('wms' and 'wms2'). The reason why one farm is called 'wm-acl' is because 'acl' means access control list and, basically, these servers check the IP requesting the stream and only delivers it if the IP is within our database of UK providers. Which is why, if your device or app is distributed inside and outside the UK you either check your users IP address first and then only give them the correct stream, or you list both and highlight the appropriateness (perhaps by adding '[UK]' or '[Intl]' to the end of the stream description).
When is a streaming protocol a deprecated streaming protocol?
Answer - when it isn't a streaming protocol anymore and just a 'moniker', a nickname.
Windows Media Servers offered three flavours of delivering a stream - MMS, RTSP and HTTP. As of Windows Media Services 9 Series, for Windows Server 2003, Microsoft deprecated the MMS protocol in favour if RTSP and HTTP. Whilst that was quite some time ago, we've always found that it takes a while for this to filter through embedded devices or applications that have followed the Microsoft Windows Media SDK and licensing information. There is a particular good Microsoft Technote that covers reasoning why it was deprecated and proposes the best way to handle this. In summary it recommends that broadcasters of streams continue to use the 'mms://', because this will continue to work with client players who have followed the aforementioned SDKs - correctly rolling over to RTSP, then HTTP.
"To support the widest range of streaming Player versions, you should use the MMS URL moniker (mms://) in the connection URL to your streaming content. The MMS URL moniker allows all connecting Players to use protocol rollover to stream the content using the optimal streaming protocol. If you use an announcement to enable the Player to access your content, the MMS URL moniker is used automatically, ensuring that protocol rollover will occur if necessary. Be aware that users can disable protocols in the property settings of the Player. If the Player only supports a single protocol, rollover cannot occur." - Microsoft Technote - 'About protocol rollover'
So, this is the best option than specifying RTSP or HTTP uniquely in ASX files - if you specify RTSP it tells the client to only use RTSP, similar for HTTP.
PROBLEM: In our current ASX for Listen Again - the confusion crept in and the implementation currently has RTSP and HTTP links. We need to change this back to MMS.
WORK AROUND: if you are consuming our feeds, and access the ASX files and are parsing them - we recommend strongly you read the Microsoft Technote and understand the implications for your device, application or solution. At some point in early January we expect to change our ASX output to only list MMS 'moniker' links. [For those interested in what supports which protocols - take a look at another Microsoft Technote called 'Windows Media protocol reference']
Odds and ends
So the other issues are mainly around poor metadata within the ASX file - not a showstopper in terms of delivery, but not how we'd like it. This is a bit more complicated to fix as it's around where data is available and what produces the ASX file dynamically - unfortunately not in the same place. So we have that to fix but it doesn't stop you using things.
ASX dynamic URLs don't have a file extension (.asx), and we've had some test reports about the mime-type not being served correctly. Fairly minor things - hopefully - but we'd like to get it as good as we can.
I hope I've been able to give you an overview of how close we are to launching the Windows Media Listen Again services officially, and that the work arounds for those impatient to get their hands on them are acceptable in the interim (I am just as eager to get this up and running myself!)