diff -r 43e37759235e -r 51a74ef9ed63 Symbian3/SDK/Source/GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/Symbian3/SDK/Source/GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita Wed Mar 31 11:11:55 2010 +0100 @@ -0,0 +1,81 @@ + + + + + +How +the target Client is Resolved using CSIPResolvedClient2 +

The SIP Client Resolver determines the target clients by comparing the +Request-URI of the incoming SIP request to the information stored in SIP Client +Resolver mapping table in the Central Repository. The information required +to access the map table in the Central Repository is defined in the sipclientresolverconfigcrkey.h file. +The incoming SIP request compares with the Request-URI’s user part in the +Central Repository mapping table.

+

If a match is found, the related ECOM plug-in is loaded by its UID. The +loaded plug-in matches the incoming SIP requests based on their fields. If +the request matches, the plug-in returns the UID of the matching client. SIP +Client Resolver requests the resolved ECom plug-in to connect to the Symbian +platform server that uses SIP.

+

The resource (.rss) file contains the information +in the Central Repository and also the following information:

+ +
Resolving the target client using CSIPResolvedClient2

The +following illustration shows how the SIP Client Resolver subsystem resolves +the target client implementing CSIPResolvedClient2 and +requests the resolved client to connect to the SIP implementation.

+ Call flow of resolving a target client implementation +using CSIPResolvedClient2 + +

The target clients must implement the CSIPResolvedClient2 interface +to receive SIP requests including SIP dialogs and enable the client resolution +mechanism. Note: The channel UIDs must be unique across all +SIP clients. For example clients may use UIDs assigned for binaries.

The +SIP stack uses the plug-ins that implement the CSIPResolvedClient2 interface +as follows:

    +
  1. If the SIP request does +not contain an Accept-Contact-header, go to step 2. If it does, the SIP stack +calls CSIPResolvedClient2::MatchAcceptContactsL for all the +plug-ins and applies the following logic:

      +
    • If none of the clients +match, go to step 2

    • +
    • If one of the client +match, the SIP request is sent to the matching client

    • +
    • If more than one of +the clients match, go to step 2

    • +
  2. +
  3. If the SIP request does +not contain an Event-header go to step 3. If it does, the SIP stack calls CSIPResolvedClient2::MatchEventL for +all the plug-ins and applies the following logic:

      +
    • If none of the clients +match, go to step 3

    • +
    • If one of the client +match, the SIP request is sent to the matching client

    • +
    • If more than one of +the clients match, go to step 3

    • +
  4. +
  5. The SIP stack calls CSIPResolvedClient2::MatchRequestL for +all the plug-ins and applies the following logic:

      +
    • If none of the clients +match, the SIP generates an error response

    • +
    • If one of the client +match, the SIP request is sent to the matching client

    • +
    • If more than one of +the clients match, SIP selects one of these clients randomly and sends the +request to it. The ROM-based clients are preferred.

    • +
  6. +
+
See also

Example +of a SIP Client Resolver Plug-in

+
\ No newline at end of file