Sprint Rollover Reasons

There is no rollover because the Scrum framework doesn't permit it. The notion of rolling unfinished work from one Sprint to the next doesn't exist. Consider this statement from the Scrum Guide:

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Instead of simply rolling from one Sprint to the next, the undone work is placed back into the Product Backlog, ordered among all of the other work, and becomes available for the team to consider at the next Sprint Planning session. In some cases, the undone work may end up ordered at the top of the Product Backlog and would likely be selected at the next Sprint Planning. In other cases, finishing the work may no longer be as valuable as unstarted work and would be ordered lower in the Product Backlog. However, the fact that it was started does not require that the team accept and continue it in the next Sprint.

All of that said, the work selected for the Sprint should be something that is likely to be completed. If the team doesn't have the information needed to complete the work or if there are dependencies that are not likely to be resolved within the Sprint, then perhaps the work is insufficiently refined or its too risky to plan on delivering it within the Sprint. The team should consider not starting the work until it's sufficiently understood and there's a clear path to Done.

If, as you describe, external stakeholders are essential to getting the work Done, you may want to invest time and find ways to decouple the delivery of the work from these stakeholders and allow the team to deliver within their Definition of Done without needing to wait on external dependencies to be available.

Almost every time the reason why a sprint rolls over is because of non-response or lag from a customer, who requested the story

I'll bet you it isn't. There might very well be the lag you describe, but the reason a supposed "roll-over" is happening is because the Developers have lost sight of the Sprint Goal. That goal ought to be their commitment and very purpose for doing the work and for sprinting at all.

When a Sprint Goal is weak or absent, the Sprint Backlog is just a pile of wood they are sawing away at. There is no particular coherence to the batch they have chosen, and, therefore, no reason not to "roll over" any which is unfinished. Without a Sprint Goal worth aiming for, there is no rationale for the Sprint in the first place and the Sprint boundary can be eroded.

The concept of roll-over does not exist in Scrum because the Sprint Goal is either met or it isn't. Any unfinished work is merely re-estimated on the Product Backlog and the Product Owner will then order it appropriately. Bear in mind that business conditions can change overnight, and he or she might now have bigger fish to fry and may no longer even care about that work being finished. The artifice of "rolling work over" would effectively disempower the PO from making such decisions.

You didn't mention what kind of response you are waiting on.  Is it a response to say:

1. this is what I asked you to build or
2. is it a response to provide additional details that will enable the Developers to finish their work.

I ask because to me those are two completely different situations.

For situation 1, if your Definition of Done is achieved, an increment is born and that work is complete. If you removed the stakeholder acceptance from the Definition of Done there is no reason for the item to be in limbo.  

For situation 2, this is not an uncommon situation, even in commercial situations. Often time, the stakeholders are external to the organization and will not respond timely.  In this situation, if the feedback is not given, then the item is not done and will be returned to the Product Backlog for consideration at a different time when the needed information has been obtained.

@Thomas and @Ian have provided you very good answers. Everything that they said should be considered.  But also consider the effectiveness of the Definition of Done.  The Scrum Guide provides a description of the Definition of Done in the section that describes the Increment.

The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.

My usual advice is that it be focused on the work that is being done and not on external conditions such as stakeholder acceptance. It should encompass things that the Scrum Team has within their control because it is a method of communicating outwards. 

Also inspect the Sprint Review for effectiveness.  It is meant to be a time where the stakeholders can review the work done and provide feedback that will be used for future work or adjustments. It should not be the only time that the stakeholders are involved but it is a key point of inspection.  If you are including the appropriate stakeholders in each Sprint, then you can be assured that feedback will be received at least once per Sprint.  If the stakeholders do not see the value of the Sprint Review, you need to help them understand it. 

There is no rollover because the Scrum framework doesn't permit it. The notion of rolling unfinished work from one Sprint to the next doesn't exist. 

In some cases, the undone work may end up ordered at the top of the Product Backlog and would likely be selected at the next Sprint Planning.

You described roll-over, a thing that does exist and happens often.

Technically, yes @Thomas described it.  But if you read carefully, he did not describe rolling unfinished work from the current Sprint into the next one. He explains that unfinished work from the current Sprint should be returned to the Product Backlog.  There is should be re-evaluated and ordered appropriately.  I have seen many times that "unfinished" work has been returned to the Product Backlog and never reintroduced to a Sprint because the needs have changed based upon the work that has been delivered in the increments from each Sprint. I have also seen the work pulled into the next Sprint as well being pulled into <next sprint> + N.

I believe the real intent of his statements were to say that you do not automatically move unfinished work from the current Sprint into the next Sprint.  There were reasons it was unfinished so use that new found information to reassess and adjust as empiricism inspires.

Daniel is correct. In my experience, when people talk about "rollover" or "rolling work over", they mean that unfinished work is, without any further thought, pulled into the next Sprint's Sprint Backlog. That's not the ideal scenario. The team needs to take the time to consider the work and if it still makes sense to do it. One factor to consider is if the work has been started and how close to completion it is, but that's not the only factor to consider. The team should consider the value of the work and the value of spending time on other things leading up to and at Sprint Planning.

Sprint rollover occurs when planned tasks do not get completed during a sprint for a variety of reasons, including unexpected issues, team member availability, task complexity, new priorities, learning curves, and feedback-driven changes. It is similar to adjusting your race plan based on unexpected hurdles during a sprint.