[asterisk-dev] GMail Support

[Marc Smith]

On Thu, Jul 17, 2008 at 6:03 PM, John Todd <jtodd at digium.com> wrote:
> At 2:32 PM -0500 2008/7/17, Mark Michelson wrote:
>>
>>Marc Smith wrote:
>>[snip]
>>Thanks for the detailed e-mail. My responses are in-line below
>>
>>>  Using imap.gmail.com (GMail / Google Apps) for the IMAP server has a
>>>  few problems (app_voicemail w/ IMAP storage). I'm pretty sure these
>>>  issues are more likely with Google's IMAP implementation, not c-client
>>>  or asterisk; when I change the IMAP server setting to a dovecot IMAP
>>  > server, it works perfectly.
>>>
>>[snip]
>>
>>The idea of having to explicitly state the IMAP server in use (and furthermore
>>have to code for each specific one's quirks) seems like a really bad
>>idea to me.
>>   It will make what is already ugly code much worse. If at all possible, it
>>would be better to place in extra statements which should work for any IMAP
>>server implementation, even though they may not be absolutely
>>necessary on all.
>>The search problem with GMail seems like a flat-out bug to me in GMail's
>>implementation, and I have no idea how to get around that.
>
>
> This is a perennial decision with Asterisk - does the project flex
> around broken implementations by either auto-sensing "broken"
> responses or employing user-generated configuration file options on a
> per-service basis?  Or does Asterisk remain rigid to the standards?
>
> The answer is that both have been applied.  There are certainly
> circumstances for SIP that I've seen that have gone both ways, as an
> example - flexibility on some SIP UA clients, but rigidity on broken
> ITSPs who don't follow the standards.  However, the preference has
> certainly been towards not making exceptions for individual broken
> implementations if at all possible.
>
> Have there been questions on this behavior raised on the Gmail
> technical forums?  Not by others, but I'm talking about specifically
> for this Asterisk-related issue.  Has anyone tried reaching someone
> at Google to either ask about this behavior as a bug or intended
> response?  If the answer is 'Yes' to both questions, and there is
> still no reply then perhaps it may be worth examining one of the two
> "ugly" ways to solve it within Asterisk.  If all else leads to no
> response, I may be able to follow a trail inside of Google to the
> right engineer, but that would be a very long road - the "normal
> channels" would be preferred.
>
> Using Gmail as a storage mechanism for Asterisk is a great concept,
> and I'd be very interested in making sure that is viable as part of
> Asterisk's standard distribution.
>

I am willing to post to the GMail Google Group to get the ball
rolling, but I figured I would do a little bit of digging first (with
Google of course).
I found an interesting article talking about GMail's IMAP implementation:
http://weblog.timaltman.com/archive/2008/02/24/gmails-buggy-imap-implementation

Lots of good comments at the bottom too, and there are also a couple
other links off that page:
http://mail.google.com/support/bin/answer.py?answer=77657
This page is Google's own description of its quirks... One that I've
already noticed is when the delete flag is set, it doesn't actually
delete the message or move it to the trash, it "archives" (Google
lingo for moving it out of the inbox) it, moving it into [Gmail]/All
Mail.
Not a huge disappointment, and there could definitely be a work
around, but this sounds more like a Google "feature" than what they
would call a bug.

Another article with Mark Crispin (IMAP god?) talking about GMail's
IMAP implementation.
http://www.wired.com/software/webservices/news/2007/10/imap

In addition to the few work arounds I've been using with GMail,
asterisk dumps quite frequently when connected to GMail IMAP.
These are pretty common after asterisk being up for just a little bit:
IMAP Warning: Unexpected tagged response: 0000004b OK Success
That response IS expected (or should be)! The tag matches up with the
last IMAP string (command) sent. Luckily it doesn't block forever
after this; someone recently added those imap*timeout settings.
Ends with:
[Jul 18 15:12:27] ERROR[24916]: app_voicemail.c:8913 mm_fatal: IMAP
access FATAL error: Unlock when not locked
Or:
"[CLOSED] IMAP connection broken (server response)"

While these are not really asterisk problems, they come from c-client
which is caused by Google's buggy IMAP. I'm sure the UW folk aren't
gonna want to even touch that. I'm using a pretty recent version (I
think) of UW IMAP: imap-2007b


--Marc


> Interesting concept of the day: EC2 Asterisk instances plus Gmail for
> VM storage (avoiding S3 VM rewrites.)
>
> JT
>
> --
> --
> John Todd
> jtodd at digium.com        +1-256-428-6083
> Asterisk Open Source Community Director
>
> _______________________________________________
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> AstriCon 2008 - September 22 - 25 Phoenix, Arizona
> Register Now: http://www.astricon.net
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> !DSPAM:1,487fc35565662805344949!
>
>
>