SIP Delayed Media Inbound - 3PCC

The IMG 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 IMG 2020 to integrate with services such as auto attendant, conferencing, and unified messaging. (See Diagram Below)

The role of the IMG 2020 is to be a Participant and not the Controller. 3PCC is implemented to provide the controller to have flexible control over the IMG 2020. 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 IMG 2020 accepts INVITE and RE-INVITE messages with or without SDP or with a held SDP. The IMG 2020 accepts SDP in the SIP ACK message.

Diagram

Open

Configuration

There is no configuration needed for 3PCC feature. Delayed media is enabled at all times.

 Additional Information

• If INVITE with no SDP is received, the 200 response is to include the SDP offer. The SDP overlap logic is executed as if the offer contained a call hold.

• If INVITE with no SDP is received, the 180 response from the IMG 2020 will include the SDP offer, when the 180 with SDP feature is implemented. There could be a need to enable/disable the SDP in the 180 if the application server does not handle early media. Particularly the ring tone. This configuration option is to apply to any external gateway, not specifically to 3PCC.

• If INVITE with no SDP is received, then the ACK must contain an SDP. Otherwise the SDP overlap failure will trigger a call teardown with a BYE method.

• If INVITE with no SDP is received, then the ACK must contain a syntactically correct SDP. Otherwise the SDP overlap failure will trigger a call teardown with a BYE method. The SDP parsing rules are the same as for a normal SIP transaction.

• If an INVITE with a media IP of 0.0.0.0 on the c= line is received, continue with its existing behavior (pre-3PCC) with the SDP overlap logic. Call Flow 2 below.

• If an ACK is received with a media IP of 0.0.0.0 on the c= line, then continue with existing behavior (post-3PCC) and execute the SDP overlap logic. Call Flow 3 below.

• If an INVITE with no media is received then a 200 OK with no media is sent. Call Flow 4 below.

• The local SDP parameters are to be acquired, as long as the remote SDP that was received did not omit its m= line. If the remote SDP omitted its m= line, then the local capabilities are not required until either the IMG 2020 receives no SDP in a message or a full SDP.

• If an INVITE with a SDP is received, then receives an ACK also with a SDP, the IMG 2020 will trigger a call teardown with a BYE method.

  • Fax negotiation after a 3PCC transaction will occur as in the case of a normal SIP call. It is up to the media layer to detect and trigger data and fax events. In practice, it is believed that both parties controlled by an AS would need to be connected before fax negotiation occurs.

SIP 3PCC Call Flows

The IMG 2020 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 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

For more details on this call flow see RFC 3725.

Open

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.