When an end user places an outgoing call, they expect to hear a ringback tone in return, to signify that the call is in progress. If the line is quiet, the end user might think the call has failed and might hang up although the call is actually ringing at its destination.
Such situations have been observed when certain VoIP equipment is unable to generate a ringback tone (for example, due to overload). To ensure that a ringback tone is delivered to the call originator, PortaSwitch generates a local ringback tone.
Let’s see how this works in SIP. When a caller makes a call from a SIP user agent, an INVITE request is sent to the called party. When the called party’s phone begins to ring, it sends back an 18x Ringing response. The 18x Ringing message may or may not include the Session Description Protocol (SDP) which is used to set up a one-way media stream for conveying RTP media packets with a ringback tone to the caller.
PortaSwitch analyzes the 18x Ringing message received. If it doesn’t contain the SDP, PortaSwitch immediately generates its own ringback tone and sends it to the caller. If the 18x Ringing message is received with the SDP, PortaSwitch waits for the RTP media packets. If they are not received within a predefined timeout, PortaSwitch generates its own ringback tone for the caller.
Ringback tone generation is controlled via the call_progress_notification, call_progress_filter and early_media_ timeout service policy options (you can find their description in the table below). Besides ringback tone generation, these service policy options also control early media relaying. Early media is a powerful aspect of SIP that allows two endpoints (user agents) to communicate before a call is actually established. In terms of SIP, this means relaying media prior to 200 OK is sent in response to an INVITE request.
| Option | Description |
|---|---|
| call_progress_notification |
|
| call_progress_filter |
|
| early_media_timeout | This defines a duration during which PortaSwitch waits for the RTP media packets upon receiving an 18x Ringing response with the SDP from the called party. If they are not received within the predefined timeout, PortaSwitch generates its own ringback tone for the caller. |
Let’s have a closer look at how a call with ringback tone generation and early media relaying is established.
- A caller makes a call from a SIP UA that arrives at the B2BUA. The B2BUA verifies if there is a service policy dynamically matched by the User-Agent header field.
- The B2BUA sends an authorization request to the billing engine. The billing engine checks if the caller is allowed to send the call to the desired destination and provides the B2BUA with the routing. The authorization response also includes information about the service policies configured for both participants of the call.
- For each tried route, the B2BUA analyzes the following service policy options:
- The call_progress_notification option from the dynamically matched service policy.
- The call_progress_notification option from the service policy assigned to the Calls from Vendor connection or the authorized account.
- The call_progress_filter option from the service policy assigned to the Calls to Vendor connection or the called account.
- The early_media_timeout option from the service policy assigned to the Calls to Vendor connection or the called account.
- The B2BUA receives an 18x call progress response from the called party. The resultant behavior (whether to generate a local ringback tone or just re-send all 18x call progress responses, relay, or prohibit early media) depends on the service policy options configured for both participants of the call. For more detailed information please refer to APPENDIX E.
- The B2BUA starts a new route, without the interruption of the ringback tone initiated on the previous step.
- Steps 4 and 5 are repeated for each route tried until 200 OK is received.
- The B2BUA connects the caller with the called party.
Note that PortaSwitch does not generate ringback tones if a user makes calls through IVR applications (e.g., in scenarios such as Prepaid card calling, Pass-through-IVR, call queues, etc.). In these cases, the user hears the media configured within the corresponding IVR application (ringing tones or music on hold).
For callback calls, however, PortaSwitch generates ringback tones for call leg A – the initiating call to the access number.
