Symbian3/SDK/Source/GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE.dita
author Dominic Pinkman <Dominic.Pinkman@Nokia.com>
Thu, 21 Jan 2010 18:18:20 +0000
changeset 0 89d6a7a84779
permissions -rw-r--r--
Initial contribution of Documentation_content according to Feature bug 1266 bug 1268 bug 1269 bug 1270 bug 1372 bug 1374 bug 1375 bug 1379 bug 1380 bug 1381 bug 1382 bug 1383 bug 1385

<?xml version="1.0" encoding="utf-8"?>
<!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. -->
<!-- This component and the accompanying materials are made available under the terms of the License 
"Eclipse Public License v1.0" which accompanies this distribution, 
and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". -->
<!-- Initial Contributors:
    Nokia Corporation - initial contribution.
Contributors: 
-->
<!DOCTYPE concept
  PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd">
<concept id="GUID-768CCC6E-16D2-50E8-8EED-EB2C2AF0E9BE" xml:lang="en"><title>Overview</title><prolog><metadata><keywords/></metadata></prolog><conbody>
<p>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. </p>
<p>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. </p>
<section><title>Architectural relationships</title> <p>The Client Resolver
API requires the SIP Codec API and the SIP Codec API. </p> <p>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: </p> <ul>
<li id="GUID-F3BEAD9E-744E-5154-91EC-E0B66034A8F4"><p> <b>Implement the CSIPResolvedClient
interface and provide an XML description with their capabilities</b>  </p> <p>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 <xref href="GUID-F0E4FA44-A41C-3C6F-993E-39CED042A879.dita"><apiname>CSIPResolvedClient</apiname></xref> implementation. </p> </li>
<li id="GUID-07B5DFE5-D376-57F7-8ACB-50BB1EF8351B"><p>Implement the <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita"><apiname>CSIPResolvedClient2</apiname></xref> 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 </p> <p>The table
maps the user-part of the incoming SIP request’s Request-URI to the related <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita"><apiname>CSIPResolvedClient2</apiname></xref> 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. </p> </li>
</ul> <p>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. </p> </section>
<section><title>Class structure</title> <p>SIP Client Resolver must create
a class derived from <xref href="GUID-F0E4FA44-A41C-3C6F-993E-39CED042A879.dita"><apiname>CSIPResolvedClient</apiname></xref> or <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita"><apiname>CSIPResolvedClient2</apiname></xref> 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. </p> <fig id="GUID-B8A796EA-6850-5695-A516-E92629BE7971">
<image href="GUID-E77E2E2A-2F2D-549E-ABD6-175E68A406CB_d0e317911_href.png" placement="inline"/>
</fig> <p><b>CSIPResolvedClient</b> </p> <p>The target clients must implement
the <xref href="GUID-F0E4FA44-A41C-3C6F-993E-39CED042A879.dita"><apiname>CSIPResolvedClient</apiname></xref> interface to receive SIP requests
outside SIP dialogs and enable the client resolution mechanism. </p> <p>SIP
uses the data provided in the ECOM resource file or, as requested by the implementation
to decide which target client is used. </p> <p><b>CSIPResolvedClient2</b> </p> <p>The
target clients must implement the <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita"><apiname>CSIPResolvedClient2</apiname></xref> interface
to receive SIP requests outside SIP dialogs and enable the client resolution
mechanism. </p> <p>The SIP stack uses the plug-ins that implement this interface
as follows: </p> <ol id="GUID-E3325143-0AA4-5A60-885C-875F388EF0E3">
<li id="GUID-816770B7-3A85-5894-9868-64BEE12FD50C"><p>If the SIP request does
not contain the Accept-Contact-header, go to step 2. If it does, the SIP stack
calls the <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita#GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E/GUID-2C145D8C-DB4C-33C9-9CCE-193433909937"><apiname>CSIPResolvedClient2::MatchAcceptContactsL()</apiname></xref> method
on all the plug-ins and applies the following logic: </p> <ul>
<li id="GUID-5457D39D-DE84-5A3F-8E8B-7E79C863E118"><p>If none of the clients
match, go to step 2. </p> </li>
<li id="GUID-BE1A9D22-BD88-519E-AC4A-242FC6D3B098"><p>If one of the clients
match, send the SIP request to the matching client. </p> </li>
<li id="GUID-3A027E2A-C805-595D-B43C-28B19BC07609"><p>If more than one of
the clients match, go to step 2. </p> </li>
</ul> </li>
<li id="GUID-7F822965-0220-52A8-8CAF-EACA4D87E75D"><p>If the SIP request does
not contain the Event-header, go to step 3. If it does, SIP stack calls the <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita#GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E/GUID-9DB2CFFE-09ED-367D-9C14-6917F8E3DCF4"><apiname>CSIPResolvedClient2::MatchEventL()</apiname></xref> method
on all the plug-ins and applies the following logic: </p> <ul>
<li id="GUID-8E85F9F9-D645-53D7-A4D8-6717951B0D1C"><p>If none of the clients
match, go to step 3. </p> </li>
<li id="GUID-B713BE42-D8AF-51D6-8832-D0B221CFF4D8"><p>If one of the clients
match, send the SIP request to the matching client. </p> </li>
<li id="GUID-93037264-2B67-5DD4-990B-9D3EEEDE6C4D"><p>If more than one of
the clients match, go to step 3. </p> </li>
</ul> </li>
<li id="GUID-BFCEF7B8-4068-58E6-B960-27035A5A52D6"><p>The SIP stack calls
the <xref href="GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E.dita#GUID-30BC7BC4-0FBE-3C60-A2E4-2E5AE206C61E/GUID-9C9E49C8-602B-3C1C-B036-A176FF323A54"><apiname>CSIPResolvedClient2::MatchRequestL()</apiname></xref> method on all
the plug-ins and applies the following logic: </p> <ul>
<li id="GUID-86228E63-7E10-571E-B465-EB4D14E8855D"><p>If none of the clients
match, an error response is generated. </p> </li>
<li id="GUID-6F578483-34E7-5CFB-A565-2209FFF82D28"><p>If one of the clients
matches, send the SIP request to the matching client. </p> </li>
<li id="GUID-C1BD2E18-CFEB-558F-9F10-60EF6B9539E7"><p>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. </p> </li>
</ul> </li>
</ol><p>The channel UIDs must be unique across all SIP clients. The clients
may use UIDs assigned for the binaries. </p> </section>
</conbody><related-links>
<link href="GUID-5C215C64-5D3D-5B65-A11F-BE6F8C306CF4.dita"><linktext>How     
           the target client is resolved using CSIPResolvedClient</linktext>
</link>
<link href="GUID-AFE7F3DA-6D61-5A4C-A08F-C998C8805A06.dita"><linktext>How     
           the target client is resolved using CSIPResolvedClient2</linktext>
</link>
</related-links></concept>