This documentation is archived and is not being maintained.

Extending the Call Class

This content is no longer actively maintained. It is provided as is, for anyone who may still be using these technologies, with no warranties or claims of accuracy with regard to the most recent product version or service release.

By default, Unified Communications Managed API 2.0 Core SDK provides call controls for the audio and message media types. These call controls are, respectively, the AudioVideoCall and InstantMessagingCall classes. A developer can extend the UCMA 2.0 Core SDK platform by creating a custom call control for an additional media type. Adding a custom call control entails creating new classes that inherit from the Call, MediaProvider, and MediaFlow abstract classes, as well as creating implementations of the factory classes that are used to generate instances of the new Call and MediaProvider subclasses. Much of the functionality of the abstract base classes is inherited by the new derived classes and can be reused and exposed publicly without further modifications. This topic describes the abstract properties and methods that must be defined in a Call subclass.

The Call base class handles Session Description Protocol (SDP)-based offers and answers. When a call (created locally, and represented by a Call subclass instance) is established, an SDP offer is sent that describes the nature of the call. The SDP offer contains a global section and one or more media sections. Each media section indicates the media type described in that section. For example, an SDP offer might include two media types, audio and video, and would therefore have two media sections, as describe in RFC 3264, An Offer/Answer Model with the Session Description Protocol (SDP). When the remote endpoint accepts the offer, it sends an SDP answer that contains the same media sections, but adds a description of the remote endpoint’s capabilities or preferences. For example, a media section might describe the codec formats that are supported. The set of media types supported by the call also should be supported by the media provider that is bound to the call. The Conversation associated with the call assists the call in selecting the appropriate media provider instance, which is obtained from the platform.

When an incoming INVITE message is processed, the SDP in the INVITE is also processed to determine the set of media types. These media types are used to create the call. When a call is accepted or established but the call does not have a provider, a media provider that is able to handle the media types in the call is created using the appropriate media provider factory. This provider is cached in the call. The conversation helps to bind the call to the media provider using the media provider factory.

A class derived from the Call class must provide definitions for the two abstract properties on the Call class. These nonabstract properties on the subclass override their abstract counterparts on the Call class.

The DefaultMediaType can be used to get or set the default media type that will be used to establish an outbound call.

public abstract string DefaultMediaType { get; set; }

The SupportedMediaTypes property holds a list of the types of media intended to be supported in new Call subclass. The media types appear in the media description line (m=<media> <port> <proto> <fmt> ...",) in the SDP session description.

public abstract ReadOnlyCollection<string> SupportedMediaTypes { get; }

A class derived from the Call class must also provide definitions for four abstract methods on the Call class.

HandleFlowConfigurationRequested

protected abstract bool HandleFlowConfigurationRequested(MediaFlow mediaFlow);}

HandleForwardReceived

protected abstract void HandleForwardReceived(CallForwardReceivedEventArgs e);

HandleTransferNotificationReceived

protected abstract void HandleTransferNotificationReceived(TransferStateChangedEventArgs e);

HandleTransferReceived

protected abstract void HandleTransferReceived(CallTransferReceivedEventArgs e);

If the custom call control is intended to provide call forwarding or call transfer functionality, the derived class can raise a strongly-typed event to the application. Alternatively, if the custom call control does not support these capabilities, the event can be ignored (forwarding) or declined (transfer).

If the custom Call subclass implementation is intended to support call transfer, it should implement the HandleTransferReceived and HandleTransferNotificationReceived protected methods. The expected behavior in these methods is that they expose a first-class event handler so that an application can register for the events that notify it of incoming REFER requests and REFER status.

Show: