Excluding(?) Team members who miss planning ceremonies

What do team members think is the best way for them to forecast their availability, so they can self-organize and make their preparations accordingly?

What meetings/events are you attempting to plan while people are away?

Why is a team member missing the meeting an issue? You mentioned "there are deliverables/tasks that they need to perform for the current sprint". What does this mean?

Matthew, was the unavailability of this Development Team member discussed during Sprint Planning?

Keep in mind that, when a Development Team agrees to a forecast for the upcoming sprint, that they all have joint ownership of every item in that Sprint Backlog.   The Dev Team needs to self-manage around each item to complete it within the sprint.

Sorry if my question was unclear. My international teams forcast their availability as best they can, but things do come up and as much effort as it takes to finally get everyone on a call, it's not feasible to reschedule.

I'm not planning events while people are away. More often than not, these meetings are planned months in advance so everyone can make arrangements to attend, but unplanned emergencies can and do happen. I was speaking specifically about a high priority backlog item that a SME on the team is the only one who has the knowledge to complete. If they are unavailable for the planning meeting, do we just skip the deliverable and address it with them when they are available? I don't want to create more meetings for an already busy team. And I don't want the tasks to be assigned to them in their absence. I'm not sure how to handle it...

• If requested by the Scrum Team the Scrum Master can serve the team by organising events. To enable the Scrum Master to be successful, goals, constraints, expected output, required inputs etc for such event should accompany such request.  
• No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality; The DT self-organises.
• DT accountability belongs to the team as a whole (i.e. that accountability is not broken down and then allocated to individuals (joint accountability it is a main ingredient for being a real team))

I don’t know enough about your situation but be aware! If the organisation/the teams/you yourself expect the Scrum Master to manage and the Scrum Master reacts to such expectation by starting to manage, then it is unlikely that you will reap the core benefits of Scrum.

If there are dysfunctions (lacking successful integration, items not progressing) then make that transparent and let the team find the cause and the solution.  

I agree with the above answers.

It's the development team's responsibility to organize and manage their availability and to commit to the increment.

So if it was clear that one member is on leave during a sprint, the team should have anticipated. On the other hand if one team member commits to the sprint and doesn't do the work, it's up to the DT to discuss this and take measures. 

As scrum master you should facilitate and coach the DT, so they get the tools/skills they need to work as a team and reach the maturity to deal with the problems you describe.

I agree with the above that the team will adjust/compensate to missing team members if they know in advance. But that's not what I'm talking about. I'm referring to last min emergencies that keep a member of the team joining a planning session where there are Deliverables that only they can completely and successfully task out.

I'm referring to last min emergencies that keep a member of the team joining a planning session where there are Deliverables that only they can completely and successfully task out.

If this happens often enough for it to require a solution, what does that mean for the ability of team members to make a commitment?

I understand your question but honestly, everything that has been said above still applies.  @Ian's questions, as usual, are spot on and should probably asked of the team. Everything said by everyone else justifies those questions with empirical evidence gained from each person's experiences. 

I will add this from my experiences. Why can't the DT members present go ahead with planning of the sprint including that item? If you have done a good job of refining the item in the backlog, all of the team should have some notion of what the "SME" will have to do.  And if that story has already been groomed, is ordered high in the backlog, and the DT (present or missing) felt it should be in the next sprint based on the discussions that have already occurred, then put it in the Sprint Backlog.  If that emergency ends up running longer and jeopardizes the sprint goal, conversations should be occurring with the entire Scrum Team.

I would also recommend that as Scrum Master you might want to initiate a conversation in Retro about how the team feels that there is only one person their team that can do certain work.  I would bet that they aren't thrilled about it and might want to take measures to help remove that silo of knowledge.  I could be wrong about my "bet" but I stand by the part of initiating the conversation.