HiDef Radio 3 through Naim Favourites not working

Chris, what time? At 12.30am this morning I was getting 320kbps  AAC stream on 'highdef' R3 on Naim favourites. I have just checked now, still 320kbps AAC.

I am using an NDX and using BTInternet.

If you are Internet technical savvy, you might want to check whether your ISP has a peering relationship with the BBC by looking up its AS number. If you haven't a direct peer, you will understand it could be a lottery whether you get enough sustained TCP throughput if your ISP peering routes are busy / congested for a particular address route to the BBC.

The BBC internet services AS number is AS2818 

Simon

Thanks Simon

This morning but it's been like this for a few weeks. Tuneln on my IPad finds the full 320k; I'll dig out my old Squeezebox and see what that does.

Chris

Chris, good news, you have the bandwidth, you can do sleuthing if you are so inclined? Are you in Europe?

The BBC has private peering points 

http://www.peeringdb.com/view.php?asn=2818

You will see primary peering/distribution  points in TeleCityGroup, Amsterdam/London and Telehouse, London. These places are primary internet peering points with massive, massive routers. Good ISPs  will also tend to private peer here, if so you will have a very efficient route to the BBC, otherwise you will have additional, possibly traffic vulnerable hops.

Interesting observation about traffic and so called gigabit home LANs, the entire BBC global web Internet services output is at 20~50Gbps......

But to your point, it appears the URL in your Naim is somehow wrong. Can you not copy the URL from a device that works, and save into your web radio favourites via NStream?

Simon

Simon, I'm in the Czech Republic.

Actually, I'm beginning to wonder if Tuneln really is delivering the 320k bitstream or just attempting to get it and playing a lower bitrate stream. The Squeezebox did what the Naim does and delivered a 56k AAC stream.

It's rather looking like the BBC has limited the HD stream to UK ISP's. They've done this for ages for the IPlayer streams but the R3 and 4 HD streams were an exception and were available anywhere.

Can anyone else outside the UK confirm whether the 320k streams still work for them?

Chris

Chris, interesting, that would require geolocating your source IP address which in Europe can be quite unreliable to accurately determine the correct country - especially western continental Europe. Somewhat easier to detect non UK, but not fool proof. (there is no global standard way of doing this, and it varies from differentaddressing domains as I recently discovered for a client..)

Be interesting to see what others expierience. But I do note that the BBC reserves the right to offer different prefixes on thier peering agreement based on peer location. So you might be experiencing that.

If you  wanted to and you know what i am talking about we could compare a Traceroute list using the same hidef R3 URL from your location and mine , and see if end up at the same server :-), and then would confirm its internet routing management as opposed to bandwidth related.

Simon.

For the IPlayer, the BBC say they have a database of UK ISP's and the UK-only content only goes to these. Occasionally, they don't work for UK ISP's and there is a procedure for these ISP's to apply to be added. So, I don't think they are doing anything very clever to identify the UK ISP's automatically.

Chris, indeed, as I said its easier to detect non UK but not fool proof, the area which are troublesome  here can be mobile and satellite (but there is very little of the latter). Also it's quite valid to have an ISP based in the EU and give  EUwide dynamic addresses within a prefix, ie ranges not permanently linked to a location. This is more common for commercial organisations, and an ISP database would not work there, and so the entire prefix would need to be opened up which would allow others in Europe to get that content if they were on that prefix... It's all a bit hit and miss, but I guess it works for the vast majority so they use it.

Simon

Chris I am getting 320k in US and listen almost continuously. After a lot of experimentation it seems the only way to guarantee  R3HD is to start the http session with a connection to a router port that is enabled, presumably because the ISP using those ports is registered in the UK, so what Simon says seems accurate. The only challenge is to find any router connected to a UK registered ISP that can turn on port forwarding, that way you will have the same access to the ISP that the router doing the port forwarding has. There may be restrictions in ISP agreements that prevent this being done by a freind for example but port forwarding is completely legitimate and needed to build a private corporate network for example, regardless who does the peering

Hopefully with some googling will discover one of the port forwarding services that are available at different price points, even the cheapest of these should work for 320kbps streaming with minimal interruption. I find the most common interruption is when I overload my own network after which the internet stream needs to be restarted.

Hi Jeremy, I don't think you mean port forwarding which is used across a network boundary such as Internet router for ports.  What you need here and I think what you are referring to  is a proxy server which relays IP addresses (not ports). The problem with public proxies they areusually slow, but there are subscription ones that are faster. That way you can completely legitimately bypass any geo location type efforts.

Simon

So, are you saying that, if you access it by normal means, you don't now get the 320k?

I know there is the possibility of using a UK proxy server but I'm trying to discover if it's really necessary.

Hi Jeremy, not that it really matters, but geolocation of source addresses is purely performed on the source IP address and physical geographic  address registered with the naming authority (or commercial third party) for that address or prefix. Their is  also a definition of PA (provider aggragated) addresses for  the ISPs in the countries of the world. Ie countries are defaulted to specific address ranges for thie prefix accesses to the Internet. But it is a guideline and not mandated.

However Ports are simply a mechanism for different applications on a host machine to share the same ip address, and again there are standard ports like 80 for web and 67,68 for DHCP and there are also many user defined ports. A TCP/IP connection as you say  is actually a binding of the IP address and Port number and transport protocol (UDP/TCP).

The problem is when you are going from a home consumer LAN to a single Internet address via your Internet router, a system of PATing is used, ie port address translation. This allows Mutiple people and applications on your LAN to share a single Internet address. But each user's app is given its own port, or series of ports, otherwise for example somebody else on your LAN browsing might appear on your web browser.

Now some applications can't have thier ports remapped and still work and therefore they need to be statically defined at the router going to the single Internet address. This is called Port Forwarding.

This is purely for own use and convenience on your LAN and has no bearing on geolocation...

Proxy servers are designed for security, and arguably more important than ever now. They map your source address to a transient or proxy source address using a trusted third party. A bit like withholding CLI on your phone or using a seperate presentation CLI if your are a business. Proxies are pretty much the norm  in global commercial setups. Most domestic users can't afford to set up your own proxy in global regions, so luckily you can hire proxy services from commercial organisations if you areconcerned about being anonymous to a web site to prevent some of the web personalisation and content targeting used on the web, or source address monitoring (ie fraudsteers can use source addresses to target a geographic area with bogus calls about selling security or products or services associated with a source address acessing a particular web  site )

Jeremy,  if your not using a proxy source IP addressing then the BBC has no problem routing R3 to your part of the world. You are sorted..

Simon, out of interest, do you frequently find that the BBC streams tend to buffer after a few hours and eventually stop? I seem to notice this problem frequently. It is even more frequent on Absolute 80's!

Hi, I think I have seen it once after I left on for a day or so, but not recently... I put it down to my ADSL resynced and reset the TCP connection. But perhaps the BBC has a session timer? Interesting to hear if others expierience this...

Which ISP do you use? If there is congestion it could reset the TCP connection? Does the reset happen more in the evenings and weekends?

Or perhaps someone is telling you somewhere to forget the 80s

Simon

ISP Virgin, 30Mb service - I suspect demand (for some stations) is probably higher than 'supply' can cope with... It is definitely station dependent as I can leave Radio Paradise, for example, connected for days without dropouts - and that's being sourced from the US (not London!).

It's difficult to identify a pattern, but I'd say daytime streaming is more problematic than evenings...

I would be interested to hear other members experience of BBC Radio and Absolute Radio streams... especially from UK listeners.

It's a pity, because when Internet Radio works it really is a great medium, but too often it appears unreliable for any long term listening period. Frustrating :-)

David.

I'm also on Virgin with a 30Mb service - with actually returns speeds of around 31MBs most of the time.

Absolute Radio always works fine. No drop-outs, no problem connecting.

Radio 3HD is a hit and miss affair. Daytime seems the most problematic but as I don't have an issue with any other connections to the internet at any time I'd say the problem's at the BBC's end and not my home.

Simon,

Sorry, I am not sure of the point you are trying to make. No argument with your network definitions and so on but I find the reasons you give for different bits of the network a bit misleading especially in this context.  You appear to be saying that a proxy web server is required to replace your source IP address and a proxy is a good idea for increased security. Unless I misunderstood, neither of these statements are true. A proxy is particularly lousy at providing security.

There are a great many ways to publicly or privately route packets between internet services. Back to the BBC iplayer, according to the BBC it uses ports 80, 443, 1947, 1948, 4000, 5000 and 8888. 

I have been successful streaming R3HD using the following:

1. Enabling port forwarding of port 80 and port 443 on the UK router

2. Enabling http and https (ie ports 80 and 443) on a commercial proxy service in the UK that I direct all my traffic to

3. Layer 2 tunneling using a virtual network in the UK

The third method has definitely been the most successful.

Jeremy, my point of the proxy server was a suggestion to get round any possible geolocation filtering the BBC do on the streams. A proxy simply  obviscates your source address as a security measure, a bit like a reverse firewall. As i say proxied internet access in conjunction with ASA firewalls is  common in commercial setups with mutiple Internet accesses especially where there is one to one address mapping between public/public and public/private addresses, we do it all the time... Otherwise you could get google in Japanese on your corporate WAN when you are in Australia 

I am not sure the relevance of your list of TCP ports.. That's unrelated to access filtering and filtering??? Your tunnel simply is being used to access the proxy solution.. And yes depending on the solution you may need to map ports of your proxy if you don't have a unique address mapping.  And of course 443 is the default https and encrypts the payload but the source and destination addresses are clear so again doesn't help with geolocation, just makes it harder for people to snoop.

However if the BBC are not geolocation filtering then this clearly adds no benefit. Reading the Beebs peering policy it does appear they do reserve the right to offer different routing prefixes to different parts of the world. Do they do this on Radio 3 hidef, I don't know, I offered to do a trace route and compare the UK with a other part of the world... That might show.. Unless the Beeb filter source address by using a reverse proxy on its streaming servers.

Simon

Hi Chris,

If I'm not wrong I've tried this with my UQ some time ago and I think I got the 56k stream. Haven't tested it anymore but will check it tonight as I'm at home, however I think your assumptions could be right...

just to confirm that I can receive BBC 3 and 4 in 56kbps only - I'm in Austria

Thanks Okli; it's a bit disappointing but I was a bit surprised it was available for so long. Maybe, it will become available as a subscription service outside the UK in a similar way to the BBC IPlayer television stuff.  

Simon,

Maybe we're thinking of different definitions for a proxy.

Agree that sending my port 80 and port 443  to the proxy server is a way to ensure the return traffic is routed to the proxy and not directly to my network. Also agree the port forwarding and nat host is acting as a proxy in the port forwarding solution. But specifically in this context routing my traffic to a proxy server for ports 80 and 443 so the return traffic sees the proxy instead of my address is a solution but a flaky solution for bbc iplayer in my experience. However if I create a tunnel I don't see there would be any address translation so no proxy.

Below is my traceroute. There is no proxy - please correct me if I am wrong - just regular routing because I am sending and receiving correctly encapsulated packets whether iplayer or ping over each hop and there are no unreachable non-uk addresses that need hiding.

traceroute to www.bbc.net.uk (212.58.246.91), 64 hops max, 72 byte packets

 1  10.200.10.1 (10.200.10.1)  163.146 ms *  729.373 ms

 2  gw64-fastest.uk2.net (77.92.68.1)  165.450 ms  163.271 ms  163.210 ms

 3  inx.as13213.net (83.170.70.137)  163.154 ms  163.619 ms  163.706 ms

 4  bbc-gw1-linx.prt0.thdoe.bbc.co.uk (195.66.236.103)  163.206 ms  163.553 ms  162.965 ms

 5  * * *

 6  ae0.er01.cwwtf.bbc.co.uk (132.185.254.93)  165.187 ms  215.563 ms  165.365 ms

 7  132.185.255.165 (132.185.255.165)  176.592 ms  165.146 ms  165.325 ms

 8  bbc-vip012.cwwtf.bbc.co.uk (212.58.246.91)  164.449 ms  164.925 ms  164.703 ms

Thanks Jeremy

I have now and it works reliably so far.

For anyone else interested, I agree with Jeremy that it is really easy and it doesn't require any technical knowledge to achieve it.

Chris

Hi Jeremy, interesting - it would appear to me you are tunnelling thorugh to an ISP operated by UK2, so in essence your are using it as a proxy or as a  hybrid VPN  - ie you are being assigned an address provided by Uk2 (or an orngainzation using UK2 infrastructure) which is registered with a UK physical address, and that is being tunnelled to your client where ever you are, where you will have the tunnel termination interface.

But what is interesting when you go via the tunnel, you are going via the public Linx peering point, where as when you go directly you are go via a private peering point at Telehouse, London. The latter I would expect give you better perfromance if the BBC were not filtering.

As far the BBC peer, there is the same routing path, therefore the BBC is either using a reverse proxy or or application filtering based on the ipaddress look up rather than relying on specific advertised prefixes( from what I can see)

This is my trace coming in from East Anglia in the UK via BT broadband.

Tracing route to bbc-vip112.telhc.bbc.co.uk [212.58.244.67] over a maximum of 30 hops:

1     1 ms     1 ms     1 ms  192.168.2.129  

2    33 ms    33 ms    32 ms  esr7.ilford5.broadband.bt.net [217.47.23.146]  

3    34 ms    33 ms    33 ms  217.47.23.125  

4    35 ms    35 ms    36 ms  213.1.69.210  

5    34 ms    33 ms    33 ms  217.41.168.53  

6    41 ms    34 ms    44 ms  217.41.168.107  

7    36 ms    35 ms    35 ms  acc1-10GigE-0-0-0-6.l-far.21cn-ipp.bt.net [109.159.249.90]  

8    35 ms    39 ms    39 ms  core1-te0-0-0-5.faraday.ukcore.bt.net [109.159.249.43]  

9    46 ms    35 ms    35 ms  213.131.193.34  

10    38 ms    56 ms    36 ms  acc1-10GigE-0-5-0-4.l-far.21cn-ipp.bt.net [109.159.254.104]  

11    36 ms    37 ms    36 ms  194.74.65.42  

12     *        *        *     Request timed out.  

13     *        *        *     Request timed out.  

14    35 ms    36 ms    36 ms  ae0.er01.telhc.bbc.co.uk [132.185.254.109]  

15    38 ms    36 ms    37 ms  132.185.255.148  

16    36 ms    37 ms    37 ms  bbc-vip112.telhc.bbc.co.uk [212.58.244.67]

Trace complete.

Simon