SipDroid works perfectly here : Android 2.1 or 2.2, with CUCM 7.1.3. Our users are LDAP integrated, so here's what I did : In Call Manager : 1. Create a new SIP phone using the X-Lite instructions up top of this thread.  I had one-way audio until I enabled a Media Resource Group. 2. In that phone put the "Owner ID" and "Digest User" to my LDAP username. 3. Edit my user's digest credential to a password of my choice.  I went for something like "TestingNow". 4. Give my phone an extension.  In my case, I gave it the same number as my desk phone so that whenever someone calls me on my extension, my Android will ring too. 5. Give it a SIP profile which requires Digest authentication.  I copied the non-secure SIP device, then ticked the digest box and called it "Android SIP devices". Then in SIPDroid itself, go to SIP account settings and put : 1. Authorization username = LDAP username (without any domain prefix - just the username).  THIS IS CASE-SENSITIVE!!!  Crazy, eh? 2. Password = Digest Credential 3. Server or Proxy = Call Manager (publisher or subscriber - up to you). 4. Domain = leave it empty 5. Username or CallerID = extension associated with your user 6. Port = 5060, I didn't touch this. 7. Protocol = UDP, I didn't touch this.  Both UDP and TCP work in my environment. If it works, SipDroid will go green.  Once it's green, you should be able to see a registered status in CUCM phone status, although I've never managed (or bothered) to get it to be anything other than "untrusted". Now, in Sipdoird if you leave "Preferred Call Type" as "SipDroid when available", you just leave SipDroid running as a background service and use your phone dialer as normal.  If you place a call while SipDroid can "see" the Call Manager, when you press the dial button, it will transparently kick in SipDroid to place the call.  When your desk phone rings, so will your Android. ... View more

I think I've been hit by the oldest trick in the book here. The Audiotext Applications article you referred me to put me onto the fact that a given call handler had three states. I was working on the "standard" state, but for some reason, the default behaviour for a new handler enables both the "alternative" and "Closed" states also. After I switched those states off, my call transferred as expected. And yes, I do get "please wait while I try to transfer you", but this isn't a problem. I saw a post about replacing this prompt with three seconds of silence if you want rid of it, but I don't think it'll be a problem. Thanks for all your help. ... View more