I've been working in distributed teams - either working remotely, or as part of a dev team split across multiple offices - for the last eighteen months. In that time I've had enough remote meetings to have formed some opinions about how to take them seriously.
Here are some things to keep in mind when dealing with meetings that span offices or timezones. There are plenty of pain points involved in this kind of development environment around communication in general which I'm not even going to try and address today. Meetings are just one facet of this problem, but they're surprisingly easy to do in a way that is horribly inefficient and frustrating.
Remote meetings suffer from the same problems as local meetings, but the consequences are exacerbated. If you don't take them seriously it'll waste your time, and it'll waste other people's time.
Show up to meetings on time
Meetings should start when they say they're going to start. This doesn't mean they should be called to order immediately, though - if you want to spend a couple of minutes to catch up and be sociable it can be a nice way to break the ice and get comfortable.
In my experience this works better when everyone has connected separately with their own headsets, rather than when it's groups connecting from meeting rooms - but your mileage will vary depending on how big the group is and how well the participants know each other.
This should really go without saying, but if you're not going to make it, let somebody know as far ahead of time as possible. As a developer, there's nothing worse than planning time in your day for something that falls through at the last minute.
Know what you're going to talk about
It sounds really stuffy and bureaucratic to call this "putting together an agenda" but I often find that stopping to think about what I want to accomplish with a meeting can help bring together my thoughts on the topic. In some cases, I've discovered that really I just need to talk to one person, or that I don't really need to have a meeting at all. It's much better to discover this before you've got everyone on a call together talking about the weather.
It can be a really good idea to publish this agenda beforehand, especially if it's a regular team meeting and not just a one-off about a specific topic. This gives people a chance to get in the right frame of mind, research the problems or topics if they're unfamiliar, and start thinking about contributions or questions if they don't already have them.
If you've got documents or links you're going to want to refer to, it's really important to prepare these ahead of time. Links to wiki pages, JIRA tickets, relevant bits of code - it's better to spent a few minutes collecting these things before you start rather than awkwardly searching for things in the middle of a conversation.
Finally, as a developer of software, I know that it's really easy for me to go down technical tangents in conversations - especially when those conversations are with other developers. Don't be afraid to park questions for a 1-on-1 later if they're not relevant to the task at hand, just remember to actually follow up.
Timezones, like relationships, are about compromises
You might be lucky enough that all your remote groups live in the same timezone, but it's more probable that you're separated by a couple of hours. Even a difference of two or three hours can have a huge impact on your ability to schedule meetings. A leisurely 10 AM meeting in New Zealand is an 8 AM start for most of the year in Australia; likewise, an afternoon meeting in Eastern Australia is dinner time for San Francisco.
You should ideally try to rotate the responsibility for starting early or staying late, and it's much easier to do this when everyone is remote. Generally you're going to be beholden to wherever the largest group is. If you're in the situation where all the meetings are at your convenience, show some sympathy for whoever had to get up early or stay late and refer to the points above to make it as easy on them as possible.