SIP client Resolver API Overview

The SIP Client Resolver defines the architecture for resolving, or identifying, the target client on receipt of SIP requests from the default port.

The Client Resolver API requires the SIP Codec API and the SAP Codec API

Target clients interested in receiving SIP requests must:

• provide a description of their capabilities in an ECOM resource file. The description is in XML format and defines the content types and media formats supported by the client using SIP headers and SDP m-lines.

• implement an ECOM interface using the Client Resolver API.

This means that every target client must provide an ECOM plugin that can be used by the Client Resolver Framework.

The Client Resolver Framework uses the information in the SIP request and the XML description supplied by all target clients to decide which target client plugin to load.

Clients must create a class derived from CSIPResolvedClient to receive requests outside SIP dialogs. The receipt of a SIP request might require the launch of the resolved target client if the client is not running.

CSIPResolvedClient

Clients need to define and implement a class derived from CSIPResolvedClient.

SIP uses the data provided in the ECOM resource file or, optionally, as requested by the implementation to decide which target client is to be used.

Note that the channel UIDs must be unique across all SIP clients, e.g. clients may use UIDs assigned for binaries.

Capability information

You need the ProtServ capability to use the Client Resolver API.

Installation

Client Resolver uses the Symbian ECom framework to read application capabilities and launch SIP applications. All applications using Client Resolver must announce their capabilities by implementing an ECom plugin. These plugins are monitored and used by the Client Resolver. The application capabilities are described in the ECom plugin’s resource file using XML. The DTD governing the XML is as follows:

<!-- SIP_CLIENT -->
<!ELEMENT SIP_CLIENT (SIP_HEADERS, SDP_LINES?)>

<!-- ALLOW_STARTING determines if a client can be started by the SIP stack. -->
<!ATTLIST SIP_CLIENT ALLOW_STARTING (YES|NO) #REQUIRED>

<!-- SIP_HEADERS -->
<!ELEMENT SIP_HEADERS (ACCEPT+, ALLOW_EVENTS*, ACCEPT_CONTACT*)>

<!-- ACCEPT: Accept-header as specified in RFC 3261.
  Indicates Content-Types supported by the client.
  Note that support for application/sdp must be announced as well,
  especially when the application aims to indicate capabilities based 
  on SDP. Otherwise the SDP-based rules will not be taken into account.
  An empty value means that the application is willing
  to receive SIP requests without content. 
-->
<!ELEMENT ACCEPT EMPTY>
<!ATTLIST ACCEPT value CDATA #REQUIRED>

<!-- ALLOW_EVENTS: Allow-Events-header as specified in RFC 3265
  Indicates events supported by the client.
  Compared to the event-package part of a Event-header
  in an incoming SIP request if present. 
-->
<!ELEMENT ALLOW_EVENTS EMPTY>
<!ATTLIST ALLOW_EVENTS value CDATA #REQUIRED>

<!-- ACCEPT_CONTACT: Accept-Contact-header as specified in RFC 3841
  Indicates caller preferences supported by the client.
  All the parameters must match to a Accept-Contact header 
  in an incoming SIP request if present.
-->
<!ELEMENT ACCEPT_CONTACT EMPTY>
<!ATTLIST ACCEPT_CONTACT value CDATA #REQUIRED>

<!-- SDP_LINES -->
<!ELEMENT SDP_LINES (LINE+)>

<!-- SDP Lines 
  Can be used to indicate supported medias by the client.
  If defined the application must announce the capability of 
  receiving content of type application/sdp.
  Only M-line is supported currently as follows:
    - supported values of media field
    - port is rendered useless, 
          but is mandatory in M-Line's BNF (should be set to zero)
    - supported values of proto field
    - name of the application in fmt field if the
      value of media field is 'application'
  BNF for the value of the M-Line:
        media space port ["/" integer] space proto 1*(space fmt)
        media = 1*(alpha-numeric)
        port = 1*(DIGIT)
        proto = 1*(alpha-numeric)
        fmt = 1*(alpha-numeric)
    alpha-numeric = ALPHA | DIGIT
        ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"i"|"j"|"k"|
                "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"|
                "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"|
                "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"|
                "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z"
    DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9"
-->
<!ELEMENT LINE EMPTY>
<!ATTLIST LINE name CDATA #REQUIRED>
<!ATTLIST LINE value CDATA #REQUIRED>

Resource file requirements

The resource (.rss) file must contain the following information:

• dll_uid and implementation_uid: These UIDs can be supplied on request to Symbian Signed. Note that these UIDs can be the same.

• interface_uid: This must have the value 0x102010DD.

• default_data: The application UID (without 0x).

• opaque_data: The application capabilities in XML format. This can be empty if application capabilities are defined in the implementation.

Protocol

The following figure shows how the SIP Client Resolver subsystem resolves the target client implementation and requests the resolved client to connect to the SIP implementation. In this scenario, the default resolution logic is applied.

The main points are:

1. The user has received a SIP request and the target client is defined using the SIP Client Resolver API

2. Requests to provide a channel UI for the connection with the user.

3. Requests the client to connect to SIP with the resolved UID in case there is no connection with the resolved channel UID.

4. The SIP Client Resolver API implementation starts the target client.

Errors are passed to the application as leaves.

The SIP Client Resolver API implementation imposes an overhead on memory.

There are no possible extensions to this API.