03-15-14 02:52 AM
123 ... 345
tools
  1. Omnitech's Avatar
    Yes, you fixed it. However, you're now using IMAP instead of Exchange Active Sync with your paid Google apps. Your calendar sync will use Caldav and contacts will sync via Cardav but both are quite inferior to EAS.

    The interesting thing is that I've switched to Outlook.com, also using EAS. And no longer have the problem. It's something with Google. Probably pulling more services. Seems to be their MO these days.

    Microsoft Exchange ActiveSync is a proprietary (but now open, thank you EU) protocol that Microsoft has now publicly documented but charges a fee for implementing.

    When 3rd parties like Google write their own EAS implementations, they often have their own idiosyncracies and do not work precisely like a Microsoft Exchange server works.

    Unfortunately, when you are operating the largest webmail service in the world, even if your EAS implementation is buggy, vendors who want to interoperate with it will have to work around YOUR bugs. Customers will say: "You broke Gmail/Google Apps" when in reality it may have been Google who broke Google Apps, but the rest of the world has to "fix" their own implementation or they will get the blame.



    You could configure it as imap as mentioned above, but will not have push email.

    So, the IMAP connection I'm using seems to have suddenly started doing push. I get notifications seconds after I receive on desktop. No idea how. Anyone else seeing this?


    IMAP does push for new mail notifications, though in some ways it is inferior to EAS. See below.



    Yes, gmail IMAP is push for new mail. Other syncs like reads and deletes are per the schedule you set.

    This is correct. However IMAP is much more vulnerable to network idiosyncracies than EAS is when it comes to making "push" work, so if you're on a home network with a low-end router that closes off persistent TCP sockets very quickly, chances are IMAP push (ie "IMAP IDLE") will die, while EAS may continue working, depending.
    02-15-14 02:30 AM
  2. Omnitech's Avatar
    Never thought they would release this version as "official"

    Neither did I. It has a significant number of issues.

    Luckily, as of yesterday, looks like we have a new bugfix release.



    You didn't read my post I clearly stated NOC is for bbm

    Don't forget the ever-popular "PIN messaging", in addition to BBM.

    Blackberry logo active on display means the tunnel to Blackberry's NOC is active.
    02-15-14 02:34 AM
  3. Omnitech's Avatar
    This bug is finally fixed in the latest 10.2.1.2102 (OS Version 10.2.1.2141) which is rolling out right now from certain carriers!
    I just received the OTA update from my carrier (Three Austria) and you can reply to HTML emails using a paid Google Apps EAS account without any issues as it was on 10.2.0 and lower.

    Excellent news and thanks for the heads-up.
    02-15-14 02:37 AM
  4. John Clark's Avatar
    I can also confirm this is fixed in 10.2.1.2141. Apparently, it was an issue with the OS.
    Devil likes this.
    02-15-14 06:58 AM
  5. ankupan's Avatar
    Yes, with new leak, this issue is resolved now.

    Now i think, this thread should be closed now.
    02-15-14 08:33 AM
  6. Devil's Avatar
    I'm gonna wait for the official.
    So guys, do we setup Google Apps as Microsoft Exchange when we setup the accounts in this new OS to be back on EAS of Google Apps?
    02-15-14 11:10 AM
  7. geodorn's Avatar
    So guys, do we setup Google Apps as Microsoft Exchange when we setup the accounts in this new OS to be back on EAS of Google Apps?
    If you have a paid Google Apps account this is the way to go, yes.
    Devil likes this.
    02-16-14 12:27 PM
  8. Devil's Avatar
    If you have a paid Google Apps account this is the way to go, yes.
    So sorry I just saw this. Thanks for responding.

    I did that, and I have paid apps, yet I see it takes 5-20 mins for the email to come to the phone after it came on the browser. Do I need to enable this somewhere in Google Apps Admin?

    Posted via CB10
    03-11-14 11:32 PM
  9. Omnitech's Avatar
    So sorry I just saw this. Thanks for responding.

    I did that, and I have paid apps, yet I see it takes 5-20 mins for the email to come to the phone after it came on the browser. Do I need to enable this somewhere in Google Apps Admin?

    There are many possible explanations for that.

    The most common one is that you are using home WiFi via an inexpensive WiFi router which does not support email push.
    03-12-14 01:29 AM
  10. Devil's Avatar
    There are many possible explanations for that.

    The most common one is that you are using home WiFi via an inexpensive WiFi router which does not support email push.
    Thanks again!
    But I'm on 4G/LTE 20 hours out of 24. Even if it was WiFi, I have the Cisco provided by Rogers for a modem. It's a docsis.



    Posted via CB10
    03-12-14 08:33 AM
  11. John Clark's Avatar
    Thanks again!
    But I'm on 4G/LTE 20 hours out of 24. Even if it was WiFi, I have the Cisco provided by Rogers for a modem. It's a docsis.
    Every cable modem is some kind of Docsis. Mine's a Docsis 3. That's the cable modem side of it. The router is different, and though they may be in the same physical box in some cases it's still a separate component from the modem.

    My mail is sometimes delayed on my device too (using Outlook.com on EAS) and I don't know why. If I do a manual refresh it comes right in. other times it is delivered right on time. Not really the end of the world but annoying
    Last edited by John Clark; 03-13-14 at 07:55 AM.
    03-12-14 08:50 AM
  12. Devil's Avatar
    John, I receive approximately 400 emails per day and most of them during the 12 hours when we're awake. Some of them are literally a conversation and need to be responded to immediately when I have somebody's attention or vice-versa.

    400 emails might not be much for most of you gurus, but for me, 20% of those emails are very important. What matters is timezone differences and loss of attention spans that could delay things for longer. It could sometimes very well be the end of the world for me lol

    When I do a manual refresh, it comes right in as well. Has Google made any changes to their EAS you think?
    03-12-14 11:40 AM
  13. John Clark's Avatar
    I dumped Google and went to Outlook.com because Google kept dumping features (like EAS for new device setups). However, I have Outlook.com on EAS and it happens to me, as well.
    03-12-14 11:46 AM
  14. ankupan's Avatar
    HI,

    I have three google apps account on three different domain.

    I didn't find any delay issue.

    Are you using new OS that is 10.2.1.2142 ? I am on it, it is really better with HTML composing too.
    03-12-14 06:41 PM
  15. Omnitech's Avatar
    John Clark:

    If you edit a followup so that your new comments are INSIDE of the quote tags, it becomes impossible to followup to your comment via regular methods because they appear to be from the person you are following-up to and are not included in a new followup.

    So I am going to have to manually copy and paste to make THIS reply:

    You wrote:

    My mail is sometimes delayed on my device too (using Outlook.com on EAS) and I don't know why. If I do a manual refresh it comes right in. other times it is delivered right on time. Not really the end of the world.
    First of all, push email should work reliably. If it doesn't, you have a technical problem somewhere. As I stated, this is usually the fault of network issues, either connection reliability issues or architectural problems. My Outlook.com email works very consistently and very quickly.

    Also, dismissing the OP's issue as "no big deal" isn't very respectful. If no one cared about getting timely email notifications, then the protocols to make this possible would never have been developed and deployed as widely as they are.
    03-13-14 02:48 AM
  16. Omnitech's Avatar
    When I do a manual refresh, it comes right in as well.
    That's usually an indication of the kind of network issues I mentioned previously. See below.


    Has Google made any changes to their EAS you think?
    Because EAS is licensed as protocol documents and not actual software, there can and will be "idiosyncracies" with certain vendor's implementation of it. Combined with the fact that Google is infamous for idiosyncratic implementation of "standards", it would not surprise me if their EAS servers are doing "weird things".

    "Push" email over standard TCP/IP protocols typically uses a "long-term open TCP socket" to make it work. There are a variety of reasons why this mechanism can get foiled by network conditions, the most common one is as I mentioned previously, simple home network equipment that by default will not hold open a TCP socket for a long time because of limited RAM and other resources.

    This will cause new email notifications (on IMAP) and other PIM synchronization (on EAS) to revert to the fallback client poll frequency before updating the client, rather than as soon as the server flags a status update.

    So email will take various times to "arrive" depending on how close to the poll-time the email arrives on the server. If the client is polling every 30 minutes and the server receives a new message on minute 31, you won't see a new mail notification for 29 minutes. If the email instead had arrived on minute 29, you would see a new mail notification within a minute. If "push" was working properly, you should see a new mail notification within 1-3 seconds under ideal conditions.

    And wireless carriers are not immune to this issue. One of the Canadian carriers (might have been Rogers), right after the initial BB10 rollout, had their network incorrectly provisioned/configured and it was not properly supporting email push sessions. People complained about this and it was fixed within 1-2 weeks as I recall.

    So it could be some sort of network issue (including if you have spotty signal coverage), and it could be some sort of idiosyncracy or compatibility issue between the EAS implementation between BB10 and Google. But I would place my bet on the network issues.
    03-13-14 03:00 AM
  17. Omnitech's Avatar
    Are you using new OS that is 10.2.1.2142 ? I am on it, it is really better with HTML composing too.

    I'm curious what sort of improvements you have seen with composing emails in HTML mode.

    Personally I'm very happy that I do NOT have to compose emails in HTML mode any more.
    03-13-14 03:08 AM
  18. John Clark's Avatar
    John Clark:

    If you edit a followup so that your new comments are INSIDE of the quote tags, it becomes impossible to followup to your comment via regular methods because they appear to be from the person you are following-up to and are not included in a new followup.

    So I am going to have to manually copy and paste to make THIS reply:

    You wrote:



    First of all, push email should work reliably. If it doesn't, you have a technical problem somewhere. As I stated, this is usually the fault of network issues, either connection reliability issues or architectural problems. My Outlook.com email works very consistently and very quickly.

    Also, dismissing the OP's issue as "no big deal" isn't very respectful. If no one cared about getting timely email notifications, then the protocols to make this possible would never have been developed and deployed as widely as they are.
    Yeah, I'm not very respectful and not very helpful.

    Spare me.
    03-13-14 07:22 AM
  19. Omnitech's Avatar
    Yeah, I'm not very respectful and not very helpful.
    Perhaps, but somehow or other you got the message re: adding text inside the quotation tags so for that I thank you.
    03-14-14 12:02 AM
  20. John Clark's Avatar
    Perhaps, but somehow or other you got the message re: adding text inside the quotation tags so for that I thank you.
    Cursor placement error while posting from the mobile website.
    03-14-14 07:03 AM
  21. Devil's Avatar
    John Clark:

    If you edit a followup so that your new comments are INSIDE of the quote tags, it becomes impossible to followup to your comment via regular methods because they appear to be from the person you are following-up to and are not included in a new followup.

    So I am going to have to manually copy and paste to make THIS reply:

    You wrote:



    First of all, push email should work reliably. If it doesn't, you have a technical problem somewhere. As I stated, this is usually the fault of network issues, either connection reliability issues or architectural problems. My Outlook.com email works very consistently and very quickly.

    Also, dismissing the OP's issue as "no big deal" isn't very respectful. If no one cared about getting timely email notifications, then the protocols to make this possible would never have been developed and deployed as widely as they are.
    Appreciate the help, Omnitech. But in defense of John Clark, he has been more than helpful and straight to the point on multiple occasions. I bet it was some form of an error that his reply became a part of the quote. Mistakes do happen.
    That's usually an indication of the kind of network issues I mentioned previously. See below.




    Because EAS is licensed as protocol documents and not actual software, there can and will be "idiosyncracies" with certain vendor's implementation of it. Combined with the fact that Google is infamous for idiosyncratic implementation of "standards", it would not surprise me if their EAS servers are doing "weird things".

    "Push" email over standard TCP/IP protocols typically uses a "long-term open TCP socket" to make it work. There are a variety of reasons why this mechanism can get foiled by network conditions, the most common one is as I mentioned previously, simple home network equipment that by default will not hold open a TCP socket for a long time because of limited RAM and other resources.

    This will cause new email notifications (on IMAP) and other PIM synchronization (on EAS) to revert to the fallback client poll frequency before updating the client, rather than as soon as the server flags a status update.

    So email will take various times to "arrive" depending on how close to the poll-time the email arrives on the server. If the client is polling every 30 minutes and the server receives a new message on minute 31, you won't see a new mail notification for 29 minutes. If the email instead had arrived on minute 29, you would see a new mail notification within a minute. If "push" was working properly, you should see a new mail notification within 1-3 seconds under ideal conditions.

    And wireless carriers are not immune to this issue. One of the Canadian carriers (might have been Rogers), right after the initial BB10 rollout, had their network incorrectly provisioned/configured and it was not properly supporting email push sessions. People complained about this and it was fixed within 1-2 weeks as I recall.

    So it could be some sort of network issue (including if you have spotty signal coverage), and it could be some sort of idiosyncracy or compatibility issue between the EAS implementation between BB10 and Google. But I would place my bet on the network issues.
    Thank you so much for providing an indepth explanation of this. I have paid more attention to WiFi EAS vs. LTE EAS, and I see the EAS during an LTE connection works better compared to WiFi. Would you be able to shed any light if there is any sort of port forwarding or MTU changes that might be able to resolve this issue on WiFi?


    Yeah, I'm not very respectful and not very helpful.

    Spare me.
    This had me off the chair! Thank you for all the contribution you have made in this thread and helped me find resolutions in many cases.
    03-14-14 11:51 AM
  22. John Clark's Avatar
    Appreciate the help, Omnitech. But in defense of John Clark, he has been more than helpful and straight to the point on multiple occasions. I bet it was some form of an error that his reply became a part of the quote. Mistakes do happen.


    Thank you so much for providing an indepth explanation of this. I have paid more attention to WiFi EAS vs. LTE EAS, and I see the EAS during an LTE connection works better compared to WiFi. Would you be able to shed any light if there is any sort of port forwarding or MTU changes that might be able to resolve this issue on WiFi?




    This had me off the chair! Thank you for all the contribution you have made in this thread and helped me find resolutions in many cases.
    It's OK. I can be blunt now and then. That's all it was but I did understand how it could have been taken.
    03-14-14 11:57 AM
  23. Omnitech's Avatar
    I have paid more attention to WiFi EAS vs. LTE EAS, and I see the EAS during an LTE connection works better compared to WiFi. Would you be able to shed any light if there is any sort of port forwarding or MTU changes that might be able to resolve this issue on WiFi?
    Honestly, on most home network equipment, not likely. On commercial-grade equipment, yes - but then again, modern commercial network equipment typically doesn't suffer from such problems anyway.

    When the world started transitioning from "dumb" packet filters to stateful firewall technology (starting around the 1990s) and also starting around this time as IP address space became increasingly scarce and Network Address Translation became common for usage in home networks, more and more network elements now had to maintain "state tables" for TCP sessions in order for those features to work. Basically this means that when a session or TCP socket is initiated (generally from client to internet), the router or firewall needs to maintain memory buffers for each opened session so that as replies are received, it can respond appropriately. These state tables consume resources, ie RAM.

    In inexpensive home networking products, RAM is limited. In addition, even if RAM is not particularly limited, many devices by default have very low "session timeout" parameters because without the use of other effective countermeasures, leaving sessions open for a long time can make those devices more vulnerable to Denial of Service (DoS) attacks whose aim is to cause the devices to run out of available resources. So these devices will terminate an open TCP session sometimes in as little as 60 seconds, effectively blocking common methods of implementing "push" email over TCP/IP.

    With a NAT router or stateful firewall, the way they are generally configured, communications must be initiated from the trusted network - connection attempts initiated from the untrusted network are typically blocked. What "push over TCP" typically does is initialize a sync session from the client (from the "trusted" network) to the internet (the "untrusted" network), and then after this handshake and initialization, that TCP session can remain open, which is what allows the SERVER side to send timely responses to the CLIENT, since it is not initiating that communication from the untrusted side, but simply continuing it, ie with a "You have 5 new messages" status notification. Periodically the client will timeout this open session and re-establish it, under ideal conditions this typically occurs about once every 30 minutes or so.

    Most commercial layer-3 network products either will hold a TCP session open for at least 30 minutes by default, or they will do so if it matches a rule that pertains to a protocol commonly used for "push" email (ie Internet Message Access Protocol or "IMAP", or Microsoft Exchange ActiveSync or "EAS"), or they can be configured to do so.

    It is rare for a home networking product that suffers from this sort of issue to be configurable in a way that fixes the problem. You could turn off the NAT and stateful firewall, but you probably don't want to do that.

    EAS is more robust in the face of "unfriendly" network elements. With IMAP, a particular server implementation will typically pick a session timeout value - often around 30 minutes - and that is a static value. If push sessions fail because some network element prematurely closed the session before the default timeout value, IMAP push (otherwise known as "IMAP IDLE") will simply fail, and new message notifications and mailbox updates will fall back to the manual client poll time, which could be 30 or 60 minutes or more.

    With EAS, if the server sees a push session (in Microsoft parlance "Direct Push") end prematurely, there is a stepped protocol where it will start lowering the session timeout value (in Microsoft parlance "heartbeat interval") progressively, until it finds a session timeout that works consistently. It will continue lowering the timeout value until it has tried one as short as around 5 minutes or so, and if that does not work, it too will revert to the manual client poll interval for sending/syncing updates. More details:

    Understanding Direct Push: Exchange 2010 Help

    In short, if you have "troublesome" network elements, you are more likely to be able to maintain push capability with EAS than with IMAP, and EAS also has power-saving advantages over IMAP on mobile devices.

    But ideally, you should probably just replace your home router.

    Hope that helps.
    03-15-14 02:52 AM
123 ... 345

Similar Threads

  1. BlackBerry UK is a fine marketing machine
    By BB10user07 in forum General BlackBerry Discussion
    Replies: 10
    Last Post: 11-19-13, 09:15 PM
LINK TO POST COPIED TO CLIPBOARD