diff -r 51a74ef9ed63 -r ae94777fff8f Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita --- a/Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita Wed Mar 31 11:11:55 2010 +0100 +++ b/Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita Fri Jun 11 12:39:03 2010 +0100 @@ -1,99 +1,99 @@ - - - - - -Overview -

The SIP Client Resolver defines the architecture used to resolve or identify -the target client when SIP requests are received from the default port. The -Symbian SIP stack is implemented as a Symbian server and uses the default -UDP and TCP port 5060 to send and receive SIP messages. Many applications -or target clients receive SIP messages that use the default port, and the -correct target client must be determined.

-

The SIP Client Resolver determines the target client based on the SIP request -and the XML-description provided by every SIP Client Resolver API implementation. -It requests the resolved ECOM plug-in to connect to the SIP or another server -which uses SIP.

-
Architectural relationships

The Client Resolver -API requires the SIP Codec API and the SIP Codec API.

The target clients -that receive SIP requests must implement the API Client Resolver API. The -following are the two methods in which a target client can receive SIP requests:

    -
  • Implement the CSIPResolvedClient -interface and provide an XML description with their capabilities

    The -XML description describes the supported content-types and media formats that -use SIP headers and SDP m-lines in the ECOM resource file. Client Resolver -framework determines the target client by comparing the incoming SIP request -to the XML descriptions provided by the CSIPResolvedClient implementation.

  • -
  • Implement the CSIPResolvedClient2 interface -and add Request-URIs user-part, plug-ins UID, and the client UID to the SIP -Client Resolver mapping table in the Central Repository

    The table -maps the user-part of the incoming SIP request’s Request-URI to the related CSIPResolvedClient2 implementation’s -UID. SIP Client Resolver framework gives the SIP request to only the plug-ins -for which a mapping entry is found in the Central Repository.

  • -

This implies that every target client must provide an ECOM plug-in -that is used by the Client Resolver Framework. The Client Resolver Framework -uses the information in the SIP request and matches it with the XML description -or the mapping table entry provided by the target clients. It then decides -which target client plug-in to load.

-
Class structure

SIP Client Resolver must create -a class derived from CSIPResolvedClient or CSIPResolvedClient2 to -receive requests outside the SIP dialogs. If the target client is not running, -it must be started to enable it to receive SIP requests.

- -

CSIPResolvedClient

The target clients must implement -the CSIPResolvedClient interface to receive SIP requests -outside SIP dialogs and enable the client resolution mechanism.

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

CSIPResolvedClient2

The -target clients must implement the CSIPResolvedClient2 interface -to receive SIP requests outside SIP dialogs and enable the client resolution -mechanism.

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

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

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

    • -
    • If one of the clients -match, send the SIP request 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 the Event-header, go to step 3. If it does, SIP stack calls the CSIPResolvedClient2::MatchEventL() method -on all the plug-ins and applies the following logic:

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

    • -
    • If one of the clients -match, send the SIP request to the matching client.

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

    • -
  4. -
  5. The SIP stack calls -the CSIPResolvedClient2::MatchRequestL() method on all -the plug-ins and applies the following logic:

      -
    • If none of the clients -match, an error response is generated.

    • -
    • If one of the clients -matches, send the SIP request to the matching client.

    • -
    • If more than one of -the clients match, one of the client is randomly selected and the SIP request -is sent to it. Normally, the ROM-based clients are preferred.

    • -
  6. -

The channel UIDs must be unique across all SIP clients. The clients -may use UIDs assigned for the binaries.

-
-How - the target client is resolved using CSIPResolvedClient - -How - the target client is resolved using CSIPResolvedClient2 - + + + + + +Overview +

The SIP Client Resolver defines the architecture used to resolve or identify +the target client when SIP requests are received from the default port. The +Symbian SIP stack is implemented as a Symbian server and uses the default +UDP and TCP port 5060 to send and receive SIP messages. Many applications +or target clients receive SIP messages that use the default port, and the +correct target client must be determined.

+

The SIP Client Resolver determines the target client based on the SIP request +and the XML-description provided by every SIP Client Resolver API implementation. +It requests the resolved ECOM plug-in to connect to the SIP or another server +which uses SIP.

+
Architectural relationships

The Client Resolver +API requires the SIP Codec API and the SIP Codec API.

The target clients +that receive SIP requests must implement the API Client Resolver API. The +following are the two methods in which a target client can receive SIP requests:

    +
  • Implement the CSIPResolvedClient +interface and provide an XML description with their capabilities

    The +XML description describes the supported content-types and media formats that +use SIP headers and SDP m-lines in the ECOM resource file. Client Resolver +framework determines the target client by comparing the incoming SIP request +to the XML descriptions provided by the CSIPResolvedClient implementation.

  • +
  • Implement the CSIPResolvedClient2 interface +and add Request-URIs user-part, plug-ins UID, and the client UID to the SIP +Client Resolver mapping table in the Central Repository

    The table +maps the user-part of the incoming SIP request’s Request-URI to the related CSIPResolvedClient2 implementation’s +UID. SIP Client Resolver framework gives the SIP request to only the plug-ins +for which a mapping entry is found in the Central Repository.

  • +

This implies that every target client must provide an ECOM plug-in +that is used by the Client Resolver Framework. The Client Resolver Framework +uses the information in the SIP request and matches it with the XML description +or the mapping table entry provided by the target clients. It then decides +which target client plug-in to load.

+
Class structure

SIP Client Resolver must create +a class derived from CSIPResolvedClient or CSIPResolvedClient2 to +receive requests outside the SIP dialogs. If the target client is not running, +it must be started to enable it to receive SIP requests.

+ +

CSIPResolvedClient

The target clients must implement +the CSIPResolvedClient interface to receive SIP requests +outside SIP dialogs and enable the client resolution mechanism.

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

CSIPResolvedClient2

The +target clients must implement the CSIPResolvedClient2 interface +to receive SIP requests outside SIP dialogs and enable the client resolution +mechanism.

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

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

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

    • +
    • If one of the clients +match, send the SIP request 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 the Event-header, go to step 3. If it does, SIP stack calls the CSIPResolvedClient2::MatchEventL() method +on all the plug-ins and applies the following logic:

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

    • +
    • If one of the clients +match, send the SIP request to the matching client.

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

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

      +
    • If none of the clients +match, an error response is generated.

    • +
    • If one of the clients +matches, send the SIP request to the matching client.

    • +
    • If more than one of +the clients match, one of the client is randomly selected and the SIP request +is sent to it. Normally, the ROM-based clients are preferred.

    • +
  6. +

The channel UIDs must be unique across all SIP clients. The clients +may use UIDs assigned for the binaries.

+
+How + the target client is resolved using CSIPResolvedClient + +How + the target client is resolved using CSIPResolvedClient2 +
\ No newline at end of file