He is usually visiting friends in the company or outside smoking.
I don't think it's your personal responsibility to talk to that guy about it, as long as he attends the mandatory meetings and follows the Scrum process. It is your responsibility to support the development team to talk about improvements in the retrospective though.
In the retrospective, I don't think it's very productive to talk about this in abstract terms. If you tell somebody that in theory, if they were at their desk more, they could get more work done, all they have to do to prove you wrong is to sit at their desk and be even lazier than the sprint before. Next sprint, your argument has been disproven and you are even worse off than before.
There are at least two very real problems that pop up. We used those two to focus on real issues to fix. It's a little bit like Stack Exchange: you need a real problem to get a real solution.
The first problem we had as a team was that people would come by and ask for him and we had no idea where he was or when he'd be back. That made us look stupid, like we did not know what the other people on the team do. So we brought that up, we said "Hey, listen, when people come in and ask for you and we don't know where you are or how long you'll be gone, that makes us look really bad, like we are not a team or don't care. How can we fix that?" We agreed that anybody leaving the room for more than a short toilet or coffee break would simply say where they went. "Hey team, Bob from Beta Team called, he needs help with a database problem, I'll be downstairs for a while." Should be enough. No red tape, no procedure or system, just plain communication. That fixed a real problem for us and it raised the awareness for people not being "there". Nobody objected.
The second real problem we had was too many tasks outside the team. That's more of a PO's problem, because inside the organisation he got the budget for a X people team, but only (X-?) people work on his tasks, with ? people working basically on tasks of other teams. We fixed that by using more transparency, posting a little post-it to a wall with a note saying what we did and for how long. After a sprint we would collect them and decide what to do about it. Maybe other teams need education, maybe we are missing a task in our team or maybe somebody needs to be told "no" once in a while. Whatever the solution is, make sure people write down what they do for others. That guy that is constantly away should produce a lot of those. Remind him if he forgets. Work on reducing that number of "out-of-scope" work. Don't target him specifically, target the problem: work done for others.
So to summarize: the team should improve and go tackle the real problems that exist. The person in question is a part of the team and should have a say in this. This is not about him, or his behavior, it's about solving the problems. His absence will sooner or later be reduced automatically when the problems get solved. Your job as a Scrum Master is to help the team do that.