SIP Delayed Media Inbound - 3PCC

The 2020 2020 supports Third Party Call Control (3PCC) which is the establishment of a session between two Participants. Establishment of this session is accomplished by a Third Party referred to as the Controller. The Controller is typically an application server or Session Border Controller which allows the 2020 IMG to integrate with services such as auto attendant, conferencing, and unified messaging. (See Diagram Below)

The role of the 2020 IMG is to be a Participant and not the Controller. 3PCC is implemented to provide the controller to have flexible control over the 2020 IMG. Consequently, this enables it to be part of a larger service set in network solutions.

Delayed Media

The Dialogic platform supports delayed media to allow interworking with third party call control applications (3PCC) in accordance with RFC 3725. Delayed media is implemented for inbound calls and is used in some cases when the caller may not know the set of media formats. This is the case when the caller is actually a gateway to another protocol which performs media format negotiation after call setup. When this occurs, a caller MAY issue an INVITE with a session description that contains no media lines (m=). The 2020 IMG accepts INVITE and RE-INVITE messages with or without SDP or with a held SDP. The 2020 IMG accepts SDP in the SIP ACK message.




There is no configuration needed for 3PCC feature. Delayed media is to be enabled at all time.

Additional Information

RFC 3725 Recommendations 2020 IMG Support
Offers and answers that contain a connection line with an address of Yes
Re-INVITE requests that change the port to which media should be sent Yes
Re-INVITEs that change the connection address Yes
Re-INVITEs that add a media stream Yes
Re-INVITEs that remove a media stream (setting its port to zero) Yes
Re-INVITEs that add a codec amongst the set in a media stream Yes
SDP Connection address of zero Yes
Initial INVITE requests with a connection address of zero Yes
Initial INVITE requests with no SDP Yes
Initial INVITE requests with SDP but no media lines Yes
Re-INVITEs with no SDP Yes
The UPDATE method (RFC 3311) Yes
Reliability of provisional responses (RFC 3262) Yes (No SDP)
Integration of resource management and SIP (RFC 3312) No

SIP 3PCC Call Flows

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

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, 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

Note: A and B are assumed to be 2020 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 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  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.