An application can set the reliability policy globally by using the ReliableProvisionalResponsePolicy property on the real time endpoint. The type of this property is ExtensionFeatureSupport, an enumerated type that can have one of three possible values: Unsupported, Supported, or Required. The reliability policy applies globally for every session created, both outgoing and incoming. The application can override the reliability policy on an individual session by resetting this property on the session. For example, to apply a different policy for dealing with incoming sessions, the application can set this property on all incoming sessions in the application's SessionReceived handler for the endpoint.

If the application sets this policy on the endpoint globally, the platform will automatically add the 100rel SIP extension to the list of SIP extensions supported by the endpoint. If the application sets the policy to Unsupported, the platform will automatically remove the extension from the list of SIP extensions supported by the endpoint. Any incoming INVITE messages with a Require header field indicating a SIP extension that is not in this list of supported SIP extensions are automatically rejected with a 420 (Bad Extension) response. If an application supports 100rel, incoming INVITE messages with Supported or Require header fields for the 100rel SIP extension are exposed to the application. If the application does not support 100rel, incoming INVITE messages with Require header fields for 100rel are automatically rejected with a 420 response. Note that incoming INVITE messages with Supported header fields for 100rel are still exposed to the application as there is no requirement to support this extension even though the inviter supports it. When the application sends any INVITE message, the platform will automatically add Supported or Require header fields for 100rel depending on the reliability policy set for the session.

ReliableProvisionalResponsePolicy is also applied in an interaction with an incoming session. This policy determines whether the local party is interested in receiving PRACK messages for provisional responses sent.

The application should set this property to indicate the support policy for 100rel. The generic method AddSipExtension on the endpoint cannot be used to add 100rel as a supported extension.

An application can send provisional responses on an incoming session only before it accepts the session. After the application has accepted the session, it cannot send provisional responses. Provisional response codes indicate the status of the session, and are in the range 100 through 199. For example, the response code 180 indicates “Ringing”.One of the main reasons for supporting reliable provisional responses is to enable “early media” scenarios. This is done by exchanging Session Description Protocol (SDP) information in the provisional or PRACK messages. The platform supports two ways to send a provisional response.

• SendProvisionalResponse
  
  SendProvisionalResponse is a synchronous method that enables the application to send a provisional response. This method does not add a header requiring 100rel and hence will not wait for or even expect a PRACK message for the response. This method provides an option to send SDP to support “early media” scenarios. If the remote requires 100rel, using this method is highly discouraged. If the local party does not support 100rel, this is the recommended method for sending provisional responses.
  
  
• BeginSendReliableProvisionalResponse
  
  BeginSendReliableProvisionalResponse is an asynchronous method that enables the application to send a reliable provisional response, if possible. If the remote or local party does not support 100rel, PRACK is not expected and the method will complete synchronously. This method also provides an option to send SDP to support “early media” scenarios. This is the recommended method for an application that is designed to support 100rel for incoming sessions because it acts correctly in terms of dealing with whether PRACK is expected or not.
  
  

  Note:
  By the requirements of RFC 3262, an application cannot send a reliable provisional response 100 using this method. 100 responses are sent hop-by-hop only. The reliability mechanisms described in this topic are end to end.

  There can be at most one pending BeginSendReliableProvisionalResponse operation when a PRACK message is expected. To send a provisional response in this situation the application can call SendProvisionalResponse as long as the remote does not require 100rel. Also, the session cannot be accepted until a pending reliable provisional response operation that includes SDP completes.