We have learned that SER does not keep the state of a dialog, but just transfers SIP messages (as part of transactions) between two user agents. The consequence is that SER cannot be a peer in a dialog.

But, if you want to play a voice prompt saying that the user is not available or provide voicemail capabilities, you will need something that can act as a user agent and be a peer in a SIP dialog, so that a session is actually set up between the calling user agent and that something playing the voice prompt. Modules or third party applications can provide this back-end user agent functionality, and SER will be in the middle. Again, SER is used in its stateful processing to enable these back-end applications.

NOTE: To add to the confusion, when SER is used in stateful processing to enable back-end user agent functionality, it is said to act as a stateful user agent server.

Also, if you want to implement a pre-paid service, you have a problem because SER cannot terminate the call when no money is left! In this scenario you need a third party in the SIP dialog (and quite possibly in the session). This third party will act as the middle man both in the SIP messages and in the audio. Thus, each user agent will only talk to the middle man and not know about the remote user agent. This middle man is what you probably have seen referenced as a B2BUA (Back-to-Back User Agent) on the serusers mailing list. A B2BUA can handle SIP messaging only or both SIP and RTP.