The controller is the boss in the MVC pattern. It is responsible for delegation whilst doing minimal work itself ;).
A request comes in and the boss looks at it and thinks "Hrm... there is a lot of work involved here. I need to get some data from my database. Luckily I have subordinates! Hey model, come over here. I need you to go off and get all the information form the DAL."
Think of the model as a developer. Does all the real hard work, gets his hands dirty, and without the model, the whole system would come crashing down. It goes off and does all the business and domain logic. It then runs back to the boss and hands in all his hard work. "Here you go gov".
The boss then needs to return the data to the user. Again - too much work for him. So he gets a stupid junior dev aka the view to do it. (Not all juniors are stupid, but it works for this example!). The view knows nothing. It doesn't care how the data came to be, just that it's there and works. The boss may make some minor alterations to the data as we don't want the view having more responsibility than it needs, then the view goes off and displays the data. Depending on the work load, the boss may recruit multiple views for the job.
Basically the controller controls all flow in the MVC pattern. It decides what models to call, and what views to render, and what data from the model to pass to the view (ViewModels).
"other controller should assume controlother controller should assume control"
You can call other controllers from a controller. If you have a search box on your homepage for example, when a user hits search, it can call the index function on the search controller. In my metaphor above, it would be akin to one department passing a job to another department. Then this whole process starts again, with the boss recruiting the staff he needs for the current request.