IMG 1010 - SIP 3PCC Call Flows

Owned by Kelli Higdon
Last updated: Mar 04, 2024
5 min read

The IMG supports the following call flows for SIP 3PCC.

RFC Recommendations

Call Flow 1 represents the simplest and the most efficient flow.  This flow SHOULD be used by a controller if it knows with certainty that user B is actually an automata that will answer the call immediately.  This is the case for devices such as media servers, conferencing servers, and messaging servers, for example.

Since we expect a great deal of third party call control to be to automata, special casing in this scenario is reasonable. For calls to unknown entities, or to entities known to represent people, it is RECOMMENDED that Call Flow 4 be used for third party call control. Call Flow 3 MAY be used instead, but it provides no additional benefits over Call Flow 4.  However, Call Flow 2 SHOULD NOT be used, because of the potential for infinite ping-ponging of re-INVITEs.

Several of these flows use a "black hole" connection address of 0.0.0.0. This is an IPv4 address with the property that packets sent to it will never leave the host which sent them; they are just discarded.  Those flows are therefore specific to IPv4.  For other  network or address types, an address with an equivalent property  SHOULD be used.

In most cases, including the recommended flows, user A will hear silence while the call to B completes.  This may not always be ideal. It can be remedied by connecting the caller to a music-on-hold source while the call to B occurs.

Copyright (C) The Internet Society (2004).  All Rights Reserved

Call Flow 1: Call setup with Delayed Media via Third-Party Call Controller

This flow is simple, requires no manipulation of the SDP by the controller, and works for any media types supported by both endpoints.  However, it has a serious timeout problem.  User B may not answer the call immediately.  The result is that the controller cannot send the ACK to A right away.  This causes A to retransmit the 200 OK response periodically.  As specified in RFC 3261 Section 13.3.1.4, the 200 OK will be retransmitted for 64*T1 seconds.  If an ACK does not arrive by then, the call is considered to have failed. This limits the applicability of this flow to scenarios where the controller knows that B will answer the INVITE immediately.

Copyright (C) The Internet Society (2004).  All Rights Reserved

A and B are assumed to be IMG gateways.

For more details on this call flow see RFC 3725.

 Call Flow 2: Call Setup with Hold

An alternative flow, Flow II, is shown <below>.  The controller first sends an INVITE to user A (1).  This is a standard INVITE, containing an offer (sdp1) with a single audio media line, one codec, a random port number (but not zero), and a connection address of  0.0.0.0. This creates an initial media stream that is "black holed", since no media (or RTCP packets [8]) will flow from A. The INVITE causes A's phone to ring.

Copyright (C) The Internet Society (2004).  All Rights Reserved

 For more details on this call flow see RFC 3725.

 

Call Flow 3: Call Setup and Subsequent Hold with Delayed Media

This flow has many benefits.  First, it will usually operate without any spurious retransmissions or timeouts (although this may still happen if a re-INVITE is not responded to quickly).  Secondly, it does not require the controller to guess the media that will be used by the participants.

There are some drawbacks. The controller does need to perform SDP manipulations.  Specifically, it must take some SDP, and generate another SDP which has the same media composition, but has connection addresses equal to 0.0.0.0.  This is needed for message 3.  Secondly, it may need to reorder and trim SDP X, so that its media lines match up with those in some other SDP, Y.  Thirdly, the offer from B (offer2) may have no codecs or media streams in common with the offer from A (offer 1).  The controller will need to detect this condition, and terminate the call.  Finally, the flow is far more complicated than the simple and elegant Call Flow 1.

Copyright (C) The Internet Society (2004).  All Rights Reserved

For more details on this call flow see RFC 3725.

Call Flow 4: Call Setup with SDP but no media line

Call Flow 4 shows a variation on Flow III that reduces its complexity. The actual message flow is identical, but the SDP placement and construction differs.  The initial INVITE (1) contains SDP with no media at all, meaning that there are no m lines.  This is valid, and implies that the media makeup of the session will be established later through a re-INVITE [4].  Once the INVITE is received, user A is alerted.  When they answer the call, the 200 OK (2) has an answer with no media either.  This is acknowledged by the controller (3).

The flow from this point onwards is identical to Call Flow 3.  However, the manipulations required to convert offer2 to offer2', and answer2' to answer2, are much simpler.  Indeed, no media manipulations are needed at all.  The only change that is needed is to modify the origin lines, so that the origin line in offer2' is valid based on the value in offer1 (validity requires that the version increments by one, and that the other parameters remain unchanged).

There are some limitations associated with this flow.  First, user A will be alerted without any media having been established yet.  This means that user A will not be able to reject or accept the call based on its media composition.  Secondly, both A and B will end up answering the call (i.e., generating a 200 OK) before it is known   whether there is compatible media.  If there is no media in common, the call can be terminated later with a BYE.  However, the users will have already been alerted, resulting in user annoyance and possibly resulting in billing events.

 

Copyright (C) The Internet Society (2004).  All Rights Reserved

For more details on this call flow see RFC 3725.

Return to Documentation Home I Return to Sangoma Support