Symbian^3 Application Developer Library > Symbian Guide > Multimedia Protocols Guide > SIP > SIP Client Resolver API >

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:

  • dll_uid and implementation_uid : These UIDs are obtained from Symbian Signed .

    Note: Both these UIDs can be the same.

  • The interface_uid must be 0x10282EE5 .

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.

Figure 1. 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. 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

  3. 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.

See also

Example of a SIP Client Resolver Plug-in

Parent topic: SIP Client Resolver API

Copyright ©2010 Nokia Corporation and/or its subsidiary(-ies).
All rights reserved. Unless otherwise stated, these materials are provided under the terms of the Eclipse Public License v1.0.