Welcome!

Welcome to the official BlackBerry Support Community Forums.

This is your resource to discuss support topics with your peers, and learn from each other.

inside custom component

Java Development

Reply
Highlighted
Developer
Posts: 71
Registered: ‎03-10-2009
My Device: Not Specified

Operator dependent connection problems

Hi,

 

 

I seem to have operator dependent connection (HttpConnection) problems on two distinct applications with two distinct operators. I browsed the forums and the web, read the KB articles that usually turn up in the responses (the "Network Diagnostic Tool" and the "Differen ways to make HTTP Connection..." ones), but I still don't get it.

 

I have created a pretty simple connection tester that just tries to fetch some data over HTTP both using a domain name and an IP address in the URL. It tries both with and without deviceside=true. Now my current problem is that I have a customer in Canada using a 3G Bold. His operator is Rogers. My test application, if run by him failes with an IOExeption and the message is "Tunnel failed". This is for both deviceside=true and also without. As he downloaded the app from my server with his BB browser he must have MDS connection set up (which is the default when omitting the deviceside parameter). He also has e-mail and gtalk working on his phone. The test app is a MIDlet and is not signed. However the 'real' app that I was tring to debug and which is alsonot able to establish a connection is a signed 'native' (.cod format) blackberry app.

 

What could the problem be?

 

Actually I suspect that it's some operator trickery, and this possibility is not mentioned in any of the above KB article, because I had similar problems with a French client (i.e. in a totally different network). In that case we found that other apps were also failing, yet he was able to make a connection using the built-in browser (that's how the app was installed). Also we found an application called viigo (from viigo.com) that did actually work. My guess is that they have signed up with RIM for BIS, but I'm of course not sure.

 

In that case if my app tried to create a network connection with deviceside=true then we got a 'firewall' warning saying that the app "tried to create a connectionboth inside and outside the firewall". (Which was actually not the case, it justtried to create a single connection...) Without deviceside=true we've got "Failed to transmit" as the detail message for the IOException. This device was a 8100, thismay be the cause of the difference between the error messages, but may be not. In this case  the operator admitted that they had 'firewalled' clients (even though it's not a firewall at all) and resetting the device (which causes the loss of all data) removed the restriction. This is OK for testing purposes but it's clearly not acceptable for our product. The operator also said something like we have to have the application accepted either by RIM or by them, which is pretty strange and clearly is a no-go (at least the operator).

 

As far as I can see the two cases are related, but I don't know how I, from the application, can initiate a connection without having to intruct the user to do weird things to their phones. Can anybody advise me on these?

 

Thanks,

Laszlo

 

Developer
Posts: 4,764
Registered: ‎07-21-2008
My Device: Not Specified

Re: Operator dependent connection problems

[ Edited ]

You are going to have to read that paper "different ways to make HTTP connection". It explains that you will need additional data in your connection parameters to connect via various carriers.

 

For example, I imagine that if you include the Rogers network APN info in your ";deviceside=true" parameter, then your Bold customer will be able to connect.

 

Optionally, your customer could set the APN info for Rogers in the appropriate place in Options:

 

Go to Options->TCP

APN: internet.com

Username/password is blank

 

Message Edited by RexDoug on 03-25-2009 12:06 PM
Developer
Posts: 71
Registered: ‎03-10-2009
My Device: Not Specified

Re: Operator dependent connection problems

Thanks, but I have read the paper. I understand that the TCP APN might not be set up on the Bold, however the MDS is, so it should work, at least according to the paper we're talking about. We know that MDS works because the browser works and e-mail works and also some additionally installed applications (e.g. gtalk) work. Stil, if I create an HttpConnection with Connector open without any deviceside magic, then it fails. (Now in the other case I mentioned, the deviceside magic resulted in a SecurityException or whatnot complaining about the firewall. No mention of a firewall in any of these documents.)

 

So what am I doing wrong if I have a working MDS connection (OK, at least a working browser) and still a simple Connector.open fails?

 

Thanks,

Laszlo

Developer
Posts: 19,636
Registered: ‎07-14-2008
My Device: Not Specified

Re: Operator dependent connection problems

[ Edited ]

I'm not sure you have grasped all the points made in the article and video.

 

On a BIS device, there is no MDS.  If you review the Transport video again, you will see that MDS is only applicable for BES devices.  In fact MDS sits on the other side of the BES and provides access to the world through the corporate network.

 

The Firewall applies to all connection methods.  With the RIM security model, before doing anything potentially dangerous, the device will ask the user.  Nothing you can do about this.  Just make sure your users Allow the connection.  If not, then you can reset the Firewall and the users will be asked again.

 

So if you are using deviceside=true, you must code APN details either on the device or in your connection string.  Alternatively, follow the instructions in the KB article and use WAP 2.  Or become an Alliance member and use BIS-B.  These are all explained in the KB article and video.

 

Remember that RIM is an Alliance member, so the Browser could be connecting using BIS-B, which could explain why it works when your connections methods don't.

 

Edit: Fixed a few typos and just noted the spilt-pipe problem that you have reported.  Remember that if you connect without a connection suffix, or with ";deviceside=true" then you are making a BES/MDS connection and this is inside the firewall.  As soon as you do this, regardless of whether it will actually work or not, it seems that the application is marked as working inside the firewall.  Then if you try to connect externally (any other connection method), the OS will assume that you have collected some data from inside the firewall and are potentially going to send it to an external IP - i.e. you are potentially bridging the corporate firewall.  This could be a security exposure, so you are not allowed to do this.  Doe this help?

Message Edited by peter_strange on 03-25-2009 07:00 PM
BlackBerry Development Advisor
Posts: 15,727
Registered: ‎07-09-2008
My Device: BlackBerry PRIV
My Carrier: Bell

Re: Operator dependent connection problems

Developer
Posts: 71
Registered: ‎03-10-2009
My Device: Not Specified

Re: Operator dependent connection problems

[ Edited ]

Peter,

 

Thanks for the reply. Actually I didn't notice that there was a video, but I watched it know. It contained the information that I found missing from the documents. Well, almost... the docs say how I would use the different connection types and the video tried to say when and why I would choose them. However it only got to describing the network architecture, which is nice and needed, but didn't tell anythign beyond what I could figure out.

 


peter_strange wrote:

 

On a BIS device, there is no MDS.  If you review the Transport video again, you will see that MDS is only applicable for BES devices.  In fact MDS sits on the other side of the BES and provides access to the world through the corporate network.

 


 

Well, the video said that the BIS is basically a RIM hosted BES like service and it falls in the MDS category. It said there are two categories of connections: MDS and (device side) TCP ones. I thought that the MDS converts the legacy non-TCP native blackberry protocol to TCP. Based on the video it does a bit more, but there must be a network component (it may not be called MDS, I don't know) that a BB device without TCP AP settings connect to.

 

I thought if the browser (and the e-mail and some other non-RIM apps, etc.) work then somehow my application can also connect using the same 'bearer' (AFAIK that's how these things are called in the GSM world). But as you say it may be that the browser (and also gtalk?) uses the BIS infrastructure. However when these devices connect to my machine for downloading an application then they show up with an IP number that belongs to the mobile operator (rogers and bouygues telecom respectively) and not RIM.

 

Based on my observations I thought that the mobile operators run their own BES to provide a service to their blackberry user customers. My operator for example has a separate data plan for blackberries, which I do not use because it's insanely expensive compared to a 'normal' mobile data plan. So is this plan is just to let the  non-TCP traffic flow to the BIS which only the built-in apps and the signed up partners can use?

 

This whole thing is pretty alien to me. Does it mean that by default a blackberry device bought from an operator with a data plan is not able to run networked applications unless the apps do some trickery themselves? (Which of course also rule out all non-blackberry aware midlets.) So the non-TCP blackberry connection if it's not on a corporate network connected to a corporate BES will only work with BIS which requires an approval from RIM? If it's so then RIM is even more control freak than Symbian Smiley Sad, though on the surface they looked a lot better with their simple and liberal code signing procedure. It would also explain why the BBs seem to come without a TCP AP setting, while all phones purchased today will be delivered set up with all the APs (for wap and normal net access). Also tells  why RIM don't run a service like Nokia do, where you can request the AP settings for any model on any network in SMS.

 

But it sounds too stupid, so I might be missing the point somewhere.

Message Edited by atleta on 03-25-2009 11:29 PM
Developer
Posts: 4,764
Registered: ‎07-21-2008
My Device: Not Specified

Re: Operator dependent connection problems

[ Edited ]

To clarify:

 

If the device is on a BES, you can eliminate the connection parameter and it will work (the suffix added to your URL).

 

If the device is not on a BES, here are your options:

 

1. BIS-B: this is used by RIM Alliance partners to connect to the the service known as "public MDS". It requires a special connection parameter released to RIM partners with approved apps. If you are not an alliance partner, you cannot connect via this service.

 

(the rest of these are ";deviceside=true" + some parameters).

 

2. WAP2: Better than TCP because you retrieve the required parameter from the service book,. This is covered in the "Making HTTP connections" document.

 

3. WAP1.1: Requires that you add the WAP gateway parameters to the URL

 

4. Direct TPC: requires APN info

 

 

 

 

Message Edited by RexDoug on 03-25-2009 10:49 PM
Developer
Posts: 71
Registered: ‎03-10-2009
My Device: Not Specified

Re: Operator dependent connection problems

Thanks for the clarification. My false assumption had been that the operators also run a (semi) public MDS service and this is what lets the browser through. I based my assumption on the fact that operators have a separate data plan for blackberry users, at least mine has one. Also that I've seen devices not having a BES connection (not being part of a corporate network) connecting to my web server and showing up with an  IP number that belongs to their mobile carrier.

 

It may be that at least a part of the BIS-B infrastructure (including the exit nodes) is hosted with/by the operators. Do you know if this is the case?

 

I haven't find a document that describes the actual network layout used. The video is overly sloppy about this issue, it doesn't say anything from the operator side just plots the cell towers and the internet and then details the BIS & BE suggesting that the phone will normally be able to go to the internet, while this is far from the truth. The key components for understanding these problems are between the cell towers and the internet. The phone may access the BIS&BES infrastructureover the internet but there is some service that will alllow this and that will not do it for other applications running on the phone. I think this should be clarified in some the official documentation, because I feel that it's the root of most of these questions (I've seen a few before posting mine).

 

Also it would be nice to know which connection can we expect (or assume) to be there 'by default'. As for 'normal' phones you can expect that the operator has already set up the wap and tcp access points and these will be used by the installed applications and the built-in applications of these phones. So everything either works or doesn't.

 


2. WAP2: Better than TCP because you retrieve the required parameter from the service book,. This is covered in the "Making HTTP connections" document.

 

Does it mean that this will more probably be present, i.e. will be set up/pushed by the mobile carrier? BTW coming from the j2me & symbian world I don't understand why the 'tcp' and the wap APs are handled differently. On a symbian phone both is just an AP with very similar settings. You can set up the user name & pw if needed (usually it's not) and the access point name and maybe a few other settings (like a proxy, nameserver, but some of these are just used by the built-in browser) At least in the GPRS/3G world.

Developer
Posts: 4,764
Registered: ‎07-21-2008
My Device: Not Specified

Re: Operator dependent connection problems

Prior to becoming an alliance partner, we struggled with this also. We had all of the WAP gateways tabled up in the application and the customer was required to manually designate which network he was on so that we could retrieve the required parameters. Network issues used to be a large percentage of our support. This is still in our code and we use it as the "court of last resort" when we have the occasional user who does not have BES and is on a network that cannot connect to BIS-B.

 

Currently, we have connection huersitics that uses CoverageInfo to determine what the user has, the tries each connection type in turn, starting with BES, then BIS-B, then WAP2, etc. Although still not 100% foolproof, our incidence of "failed to connect" is probably 2%, rather than 20% (like it used to be).

 

 

Developer
Posts: 71
Registered: ‎03-10-2009
My Device: Not Specified

Re: Operator dependent connection problems

It doesn't sound too promising and I really don't understand how the 'always on' blackberry can afford it to have these issues. Unless, of course, the allience partnership (along with the special blackberry data plans) make up for a large percentage of their income. In this case they seem to seel an intentionally crippled platform (devices) that the customers are not able to use as they would expect. Aslo they claim to be MIDP compliant, but the networked midlets won't work on most devices by default while they happilly will on the ones manufactured by their competition. (Well, it's actually more like the CLDC part of the j2me spec, where the first C stands for connected....)

 

So if I want BIS-B then do I as a developer sign up with blackberry or do I instruct (and help) my customer to have their application go through? I read somewhere that there is a BIS-B key partners and/or accepted applications can use. Is it per application or per alliance partnership or both? Also what expenses can we expect in both cases? The page about the partner ship just says 'get in contact' which usually means "we're awfully expensive".

 

 


RexDoug wrote:

We had all of the WAP gateways tabled up in the application and the customer was required to manually designate which network he was on so that we could retrieve the required parameters. 

 


 

It sounds crazy! Including this info in every application is a lot of extra effort (OK, who cares, we earn money with this) and a lot of redundance which will show up the user as some of the applications not working (maybe after a certain period when their carrier change  something on the network). It also gives extra work for the user requiring them to set up the connection for each individual app. Though as far as I can see the app can determine which network it is running on by extracting the MNC from the IMSI.

 

OK, so ending the ventillation: I can expect the users to have at least a WAP2 access, right? (This would be normal with non-blackberry phones, and should work with berries as well unless the operators tend to cripple the berry users' data plan.) But I cannot count on the WAP2 settings being present in the service book? Where did you get your wap setting parameter table?