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 resource file. This resource file is an XML file. All client applications using Client Resolver must be implemented as ECOM plug-ins and must have capabilities.

An application must declare capabilities, that are the supported content types and media formats that use the SIP headers and SDP m-lines. The capabilities must be declared in the code of the plug-in, in the XML file, or in the opaque_data field of the resource 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>
     

The resource ( .rss ) file contains the XML file and the following information:

• dll_uid and implementation_uid : These UIDs are supplied on request to Symbian Signed .

  Note : 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 field is empty if application capabilities are defined in the implementation.

Resolving the target client using CSIPResolvedClient

The following illustration 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 plan, the default resolution logic is applied.

Figure 1. Call flow of resolving a target client implementation using CSIPResolvedClient

The following list describes how the target client is resolved using CSIPResolvedClient .

1. The user receives a SIP request and the target client is defined using CSIPResolvedClient .

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

3. The user requests the target client to connect to SIP with the resolved UID if there is no connection with the resolved channel UID.

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