I looked into this in some detail a few years ago and came to the following conclusions (in no particular order):
The outsourcing organisations we looked at (all Indian) had a very strong process base. I don't know if this was cultural or just the way they chose to set themselves up (possibly a bit of both) but we felt this was likely to be a real issue.
They were talking about being a five on the Carnegie Melon Maturity Model (Google it but basically that means they've defined and documented everything up to and including what happens when someone farts), we were typically running around a 1 or a 2 (roughly equating to crossing your fingers and hoping for the best).
Our process level was largely driven by our clients who didn't have any interest in signing off specifications (for good reasons and bad), wanted people who understood their business and would fill in the gaps, and wanted to change their minds three times a day. As much as many of these factors infuriated the programmers in the UK we understood that they were never going to change.
This was possibly our biggest concern - we didn't feel we could come up with a process model that would work for all three groups involved (the clients, the UK based IT team and the Indian based outsource team).
So first thing is - work out what your process is and work out whether you honestly think you can make it work for all parties involved. It's easy to say "we're going to do agile" but how are you going to get that to work when one party is 1000 miles away? Alternatively if you want to go a solid waterfall route, is that realistic given your clients?
Second, understand the ingrained cultural differences within your teams.
My experience (and I obviously generalise here) is that programmers from the US and the UK willingly (sometimes too willingly) question authority and assumptions. Ask them to do something dumb and you're likely to find yourself being told that you've asked them to do something dumb in no uncertain terms and they'll then proceed to tell you what you really want.
That's not the norm globally. Many Indian developers I've worked with don't question things in the same way. That's not to say they aren't as bright, they just apply their intelligence to delivering what you've asked for, assuming that you had a good reason for doing so.
You can make a case for either of these being good / bad (I've lost count of the number of times I've heard developers question what they're told and say how things should be despite not understanding the basics of the industry they were working in), but the important thing is that they're different and they'll clash.
So the answer is likely to be that you're going to need to feel out the teams involved and, based on that, pick out ways of working that are comfortable for both of them.
Yes, get video conferencing set up, get each time to visit the other site (it makes a big difference) and where possible get people talking even when it's not strictly needed in the early stages, but most of all make the effort to understand the groups involved and design a dynamic that works for all of them - imposition of one world view on the other won't work.