02-15-2010 11:42 AM
Hi, I've recently released a music streaming application into the wild. In doing so, I've been contacted by a number of international users (outside of the US) and been informed that they are having difficulties streaming songs with my app. I've done the basic homework that we all go through when it's time to connect our software to the outside world (read Peter's post, reverse engineered the diagnostic utility, looked at the public domain HTTP connection factory), and I've settled on using a slightly modified version of the HTTP connection factory in my code.
This seems to work fairly well for users in the US (a few complaints aside), but I'm having almost no success over networks such as Telstra, Vodafone, Wind Mobile, etc. I've been Googling around and heard a few people mention that they needed to connect via Direct TCP with custom APN to operate over certain networks. Has anyone taken the approach of iterating over APN credentials and trying them one at a time when all else fails or is this a bad idea? Would I be better off making them manually enter an APN? I'm under the impression that Direct TCP uses the phone's default APN if no credentials are specified. Is this true, and if so, how reliable are these defautls?
I've talked to RIM about getting on BIS-B; however, they've indicated that it's not practical for my app due to the large amount of bandwidth it consumes. My feelings on the topic at this point would best be characterized as desperate... Please help.
Solved! Go to Solution.
02-15-2010 01:04 PM
Please expand on what you mean by "almost no success"?
1. Is your application unable to connect to your streaming source? Is the stream choppy, jitterry, dropped at some point?
2. Since you're streaming over HTTP, are you using chunked encoding or simply returning a huge Content-Length field?
3. Are you using Direct TCP or WAP? Have you checked whether the issue is caused by the network stack connecting via WAP 2.0 instead of Direct TCP (known issue, occurs for some carriers, such as Vodafone UK, causes lots of grief for connection stability)?
02-15-2010 01:14 PM
Sorry, I should have clarified "almost no success". What I mean is that without going over Wifi, I have no reports of the app being able to connect to our service. I'm fully aware of the necessity to break streams into small chunks to avoid the dreaded HTTP 413 error, and I do so via a custom data source. Currently, my HttpConnectionFactory tries to connect in this order of preference.
Wifi, BES, BIS, Direct TCP, Wap2
Thanks for the response.
02-15-2010 01:37 PM
Most BlackBerrys don't have any APN settings configured for Direct TCP (or HTTP) under Options -> Advanced Options -> APN. If you want your app to work over Direct TCP you need to ask your users to configure the APN settings for Internet access (e.g., APN = "internet" and no username or password for Vodafone UK).
To make matters worse, many users have data plans that do not have non-BlackBerry (meaning non-BIS/BES) Internet access. In such cases, there are no APN settings that will make Direct TCP work. You need to make your users contact their carrier and find our whether they have non-BlackBerry Internet access and which APN they should be using for that.
02-15-2010 03:29 PM
I really appreciate you taking the time to help me with this. I'm getting a much clearer picture for how this will all need to work (I think). I guess the most logical route (pun pun) at this point will be to do as much discovery up front as possible and then prompt the user for APN settings when all else fails. If anybody has a better idea, I'm open to suggestions, but I suppose this will have to do for now.
02-15-2010 04:05 PM - edited 02-15-2010 04:06 PM
P.S. You should also be aware of the "WAP 2.0 instead of Direct TCP" issue. Some carriers (such as Vodafone UK) can mark something on a SIM card as a result of which their WAP 2.0 Service Book Record is considered the default way to connect to the Internet. When this happens, the BlackBerry network stack uses the WAP 2.0 protocol to establish TCP connections and/or make HTTP requests instead of using proper end-to-end TCP/IP. When WAP 2.0 is used, all the traffic may go via the carrier's WAP gateway which may introduce unwanted side-effects (such as content filtering, assorted unexpected disconnections, transfer limits). Moreover, APN settings provided in Options -> Advanced Options -> TCP and also as parameters to Connector.open URL are ignored. The upside is that it will appear as though Direct TCP works even on BlackBerrys that don't have TCP/IP APN settings configured. The downside is that your application won't be able to use proper non-WAP Internet connectivity, event if it's available.
To force Direct TCP instead of WAP TCP you need to append ";connectionhandler=none" to the Connector.open URL. Note that this workaround only works for socket:// and http:// URLs, and does not work for ssl://, tls://, and https:// URL.