How the target client is resolved using CSIPResolvedClient

SIP Client Resolver determines the target clients by comparing the Request-URI of the incoming SIP request to the information provided in the ECom plug-in’s resource file (an XML file). All client applications using Client Resolver must be implemented as ECom plug-ins and they must announce their capabilities using this XML file.

The following is the DTD for the ECom plug-in’s resource file:

<!-- 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 media 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>

In addition to the XML file, 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.

The following diagram 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.

As per the diagram above, this is how the target client is resolved:

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

2. The user requests the SIP Client Resolver API implementation for a channel UI to connect to the user.

3. The user also requests the target 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.

Example of a SIP client resolver plugin