There might be a misunderstanding in your question:
In a MVC architecture, how I model this?
MVC is not an architecture. It is a user interface design pattern. With respect to web applications, controllers do not typically interact or send messages to each other. Since the user interface has a network between itself and the controller, communication from the view to the controller or models is done using HTTP requests.
When the model-view-controller design pattern was first created, the assumption was the application was more like a traditional desktop application. Components could be running in separate threads and communication was done primarily through events to promote separation of concerns.
This is an architectural question, but the problem lies with applying a design pattern to the architecture of an application. Architecture is must bigger in scope than a design pattern. The MVC design pattern does not address your question, especially for web applications. Typically the "M" in MVC (the Model) is a very poorly defined area. Depending on specific frameworks, the Model could be considered a View Model, which is separate from the Domain Model (or Business Model).
Once a web form has been submitted, the controller will process that POST back to the server. From there, the controller typically delegates control to some sort of "business" layer, making appropriate data conversions from information in the request to what the business layer needs. The business layer is a different set of classes that specialize in enforcing the business rules.
There is no persistent Model in web applications, at least not in the same sense as a desktop application. The Model is persisted in a database instead of an object graph in memory on the web server. Data is fetched as needed, manipulated, and then saved back to the database at the end of the request. Each HTTP request to a web application essentially initializes and tears down the application (although some frameworks persist configuration between requests).
The interaction between students and volunteers would happen in the controller. Parameters in the request would be passed down to some business objects that the controller might fetch from the database or initialize as new objects, depending on the use case.