Precondition and P-Early-Media Header Support
Â
Â
Feature F-6294 was developed for a customers application and uses the Precondition and P-Early-Media Header functionality. The Precondition and the P-Early-Media Header are used to indicate that resources are allocated. Once the resources are allocated, media streams are available for transmission and reception.
Feature F-6294 introduces Precondition (RFC 3312). Precondition is a set of constraints about a session which are introduced in the offer. The recipient of the offer generates an answer but does not alert the user or proceed with the session establishment until after the preconditions are met. In the case of the IMG 2020, precondition functionality is supported on a limited basis. Precondition only functions on the incoming leg and only functions when PRACK is configured on that leg. This implementation of Precondition only supports the quality of service (qos) preconditions on incoming calls. The qos preconditions specify that the required network resources have been allocated. Refer to the call flow diagram below.
P-Early-Media (RFC 5009) introduces the SIP P-Early-Media Header functionality. The P-Early-Media Header indicates media such as DTMF tones or pre-recorded announcements to be played prior to the call being answered. The P-Early-Media Header was added for this feature only. The IMG 2020 already supports Announcements - Pre-Call - Destination Number separately.
The call flow diagram displays the aspects of precondition that the IMG 2020 supports. Below is an explanation to go along with the call flow above. The explanation assumes the IMG 2020 has been configured as described in the configuration section below. Basically, the SIP profile object linked to the incoming Leg A should have PRACK set to either Supported or Required and the Precondition field of this object must be set to Required.
As displayed in the call flow diagram above, the IMG 2020 receives an INVITE message from Network A. Within the INVITE message the IMG 2020 looks at the following parameters:
Value given to the Require Header
Value given to the Supported Header
Precondition parameter given to the a=des: line.
Table 1 below displays what the IMG 2020 will do for the values received from the network on the incoming leg.
The IMG 2020 receives the INVITE and depending on the values received, will either reject or proceed with the call. If the call proceeds, none of the preconditions or parameters in the Require or Supported Header are passed to the outgoing INVITE. The incoming values are used to determine whether the call proceeds to the outgoing leg or not.
If the correct values are received, an INVITE is generated to the outbound leg.
We receive the 183 Session Progress message from Network B informing the IMG 2020 whether the qos resources required have been allocated or not. If they are, a 183 Session Progress message is then generated on the incoming Network A leg. Within this Session Progress message is the following:
The returned SDP will include the (a=) lines as displayed in the call flow above. The current status for both local and remote sides are send/recv and the desired precondition status of send/recv will be mandatory within the remote network.
The Require Header with its status displayed (Configured in SIP Profile object linked to the External Gateway).
The SIP Entity in Network A then sends back a Provisional Ack (PRACK) back to the IMG 2020. Within this PRACK will be the Require Header of precondition informing the IMG 2020 that it requires precondition.
Early Media is then opened. Tones or announcements can then be played.
After Early Media has been played, the IMG 2020 then sends a 200 OK back to the incoming network. Again, the message returned displays the Supported and Require headers along with the (a=) line and the status of the precondition values.
The table below describes the different combinations that can be received and how the IMG 2020 will respond
Table 1
Require Header =Precondition | Supported Header | Supported Header | Precondition Param. (a=) | Precondition Param. (a=) | Result after response from Network B. |
Yes | Yes | Yes | Yes | D.C. | Precondition Applied to 183 Session Progress sent to Network A |
No | Yes | Precondition Applied to 183 Session Progress sent to Network A | |||
No | Reject call with 580 Precondition Failure | ||||
No | Yes | D.C. | Reject call with 421 Extension Required | ||
No | Yes | Reject call with 421 Extension Required | |||
No | Reject call with 421 Extension Required | ||||
No | Yes | Yes | D.C. | Precondition Applied to 183 Session Progress sent to Network A | |
No | Yes | Precondition Applied to 183 Session Progress sent to Network A | |||
No | Reject call with 580 Precondition Failure | ||||
No | Yes | D.C. | Reject call with 421 Extension Required | ||
No | Yes | Reject call with 421 Extension Required | |||
No | Reject call with 421 Extension Required |
Require Header =Precondition | Supported Header | Supported Header | Precondition Param. (a=) | Precondition Param. (a=) | Result after response from Network B. |
No | Yes | Yes | Yes | D.C. | Reject call with 580 Precondition Failure |
No | Yes | Precondition Applied to 183 Session Progress sent to Network A | |||
No | Precondition Not Applied. Call proceeds | ||||
No | Yes | D.C. | Reject call with 580 Precondition Failure | ||
No | Yes | Reject call with 421 Extension Required | |||
No | Precondition Not Applied. Call proceeds | ||||
No | Yes | Yes | D.C. | Reject call with 421 Extension Required | |
No | Yes | Reject call with 421 Extension Required | |||
No | Precondition Not Applied. Call proceeds | ||||
No | Yes | D.C. | Reject call with 421 Extension Required | ||
No | Yes | Reject call with 421 Extension Required | |||
No | Precondition Not Applied. Call proceeds |
D.C. indicates the result Does Not Change regardless of the value
Precondition Support on IMG 2020
Precondition is accomplished using the (a=) line in the SDP of a received INVITE. The incoming INVITE message will include the a= line with the current and desired status. Before the call can be established, the threshold between the current status and desired status must be surpassed. Precondition is supported on the incoming call leg only. Neither Precondition functionality nor the P-Early-Media functionality will be interworked or passed to the outgoing leg. The tables below describe what is supported when utilizing precondition.
The first table displays and describe the supported attributes of the (a=) line in the SDP
attribute in SDP | Value displayed in SDP | Notes |
current-status | a=curr: | The current status of resources (Are resources allocated?). The current status is displayed in the (a=) line of the SDP. The current status displays the status of the local and remote legs of the call. In the INVITE message of the call flow diagram above, the local status or status of incoming network is sendrecv or there are resources allocated on the local side. The remote status or the status of the IMG 2020 is none. At this point, Network A does not know the status of the IMG 2020 so none is displayed. In the 183 Session Progress message of the call flow diagram, both the local and remote status are set to send/recv which is what will always be returned when this feature is enabled. |
desired-status | a=des: | The status of resource securing required for the establishment of Precondition (Are resources allocated?). The desired status is displayed in the (a=) line of the SDP. The desired status displays the desired status of resources in the local (IMG 2020) and remote (Network A) side of the Network A leg of the call. In the INVITE message of the call flow diagram above, the desired status of the local side of Leg A (Network A) of the call is sendrecv. The desired status of the remote side of Leg A (IMG 2020) is none. In the Session Progress message of the call flow diagram, both the local and remote status are set to send/recv which is what will always be returned when this feature is enabled. |
precondition-type | qos | qos is the only precondition type supported. qos or quality of service is in reference to the allocated resources. If a precondition other than QOS is displayed, unknown is returned. |
strength-type | mandatory, optional, none, failure, unknown | The precondition type values are all supported and are decoded when received. However, only the mandatory or optional values will be sent in the 183 Session Progress message being sent to the incoming network. |
status-type | local, remote | Displays the status of resources on the message transmission and message reception side of a single call leg (From call flow above: Network A vs IMG 2020). |
direction-tag | send, recv, sendrecv, none | Regardless of the condition of the requested strength-type value, the IMG 2020 will always respond with send/recv set in the (a=) direction-tag in the SDP. |
 Call Flows
The Call Flows below display the 3 typical call flows supported when F-6294 has been configured as described in the Configuration section below. Click on each link to access the individual call flows.
Configuration
When configuring the IMG 2020 for feature F-6294, there are three separate functions that need to be configured. The Precondition, Prack, and P-Early-Media functionalities must be configured and linked to the incoming leg. Configuring the combination of the Precondition, Prack, P-Early-Media functionality will allow the IMG 2020 to behave as displayed in the call flow diagrams described in the Call Flows section above. Since precondition is supported on the incoming leg but not on the outgoing leg, the Precondition, Prack, and P-Early-Media functionality only need to be configured on the incoming leg. Refer to the information below.
Before configuring this feature, verify that the required functionality described in the Basic Configurations topic has already been configured. Functionality such as the Physical Nodes, Logical Interfaces, Signaling, Profiles and IP Facilities have already been configured before proceeding. Also, refer to the Configure SIP (Single SIP IP) or Configure SIP (Multiple SIP IP) for information on configuring the SIP stack.
 Configure SIP Profile
Right click on the Profiles object and select New SIP Profiles. The SIP Profiles object is a container or parent object and no configuration is needed within this object. For more information on this object, refer to the SIP Profiles topic.
Right click on the SIP Profiles object and select New SIP Profile. Enter a name the describes the SIP Profile being configured. In this procedure, Inc_Precondition_Prof was entered.
In the PRACK Support field select Required from the drop down menu.
In the Precondition Support field, select Required from the drop down menu.
Initially the Precondition Support field just under the PRACK Support field is shaded green and can't be modified. To be able to modify, the PRACK Support field just above it must first be modified to a value other than disabled. This was described in step 3 above. Once the PRACK Support displays something other than disabled, the Precondition Support field can then be modified.
Refer to the SIP Profile - SGP topic for information on configuring the remaining fields in this object.
Right click on the SIP Profile object just created and select New SIP Headers. In the P-Early-Media Support field select Enabled from the drop down menu.
Refer to the SIP Profile - Headers topic for information on configuring the remaining fields in this object.
Associate SIP Profile with External SIP Gateway
Once the SIP Profile has been configured, it can be linked to the Gateway on the INCOMING leg.
Â
Right click on the Dialogic object and select New External Network Elements. The External Network Elements object is a container object and no configuration is needed here. For more information on this object refer to the External Network Elements topic.
Right click on External Network Elements and select New External Gateways. The External Gateways object is a container object and no configuration is needed here. For more information on this object refer to the External Gateways topic.
Right click on External Gateways object and select New External Gateway. Enter a name that identifies this gateway. In this procedure the gateway was named Precondition_Inc_GW.
Select SIP from drop down menu in the Protocol field.
Select either Gateway IP Address or Gateway Host name from the Address Type field. In this procedure the IP Address will be how the IMG 2020 will communicate with external gateway.
Enter the IP address of the external gateway in the IP Address field.
Select the SIP Profile created earlier from the drop down menu of the Profile field.
Refer to the External Gateway topic for more information on configuring the remaining fields in this object.Â
Configure SIP Channel Group
Configure the External Gateway to communicate with an incoming SIP channel group.
Â
Right click on the Dialogic object and select New Routing Configuration. The Routing Configuration object is a container object and no configuration is needed here. For more information on this object refer to the Routing Configuration topic.
Right click on the Routing Configuration object and select New Channel Groups. The Channel Groups object is a container object for multiple channel groups. No configuration is needed here. For more information refer to the Channel Groups topic.
Right click on the Channel Groups object and select New Channel Group. In the Name field, either except the default name or enter a name that identifies the Channel Group being configured. In this procedure, the channel group was labeled Precondition_Inc_SIP.
Select SIP from the drop down menu in the Signaling Type field.
Select the Incoming and Outgoing IP Profile from drop down menu. Refer to the Channel Group topic for more information on configuring the remaining fields in this object.
Right click on the SIP Channel Group and select New IP Network Element. Select from drop down menu the gateway configured in the Associate SIP Profile with External Gateway section above. This will be the external gateway that the channel group being configured will communicate with. Refer to the IP Network Element topic for more information on this object.
Right click on the External Gateway object and select New Node Association. Select the Node from the drop down menu of the Node field.
Select the Packet Facility group that will be used to communicate between the IMG 2020 and the External Gateway.
Select the SIP Signaling IP Address from the Service IP address field. The IP address selected will control the Media Packet Facility group configured from step 8.
The Channel Groups object will now have an yellow exclamation point displayed in the configuration tree icon. The exclamation point indicates that the configuration has been created but not yet sent to the node. Click on the Channel Groups object and then click on the Download Resource Tables button in the Channel Groups object pane. The configuration will now get sent to the IMG 2020 node and the yellow exclamation point will change to a green check.
The feature has been configured. At this point routing can be configured to route the call through the IMG 2020Â
Additional Information
Feature F-6294 was developed with specific set specifications and should be used as described in the call flow diagrams.
Only the qos precondition will be supported.
By default, the Precondition Support shall be disabled. If the Require or Supported Headers of an incoming INVITE contain the precondition option-tag, the option-tag will be dropped.
When support for the P-Early-Media Header is enabled, the IMG 2020 will include the P-Early-Media header in its 183 Session Progress message being sent to the incoming Network whether or not the P-Early-Media header was present in the initial INVITE message or not.
When an INVITE message is received requesting the Precondition function, if PRACK is disabled in the incoming SIP Profile a response of 421 Extension Required will be returned to the incoming network.
In the case where a Re-INVITE is received from the incoming network but the 100rel is not specified in the Supported Header, Precondition determination is performed as if 100rel is set.
If an UPDATE message is received from the incoming network, it will not be propagated to the outgoing network.