|
1 <?xml version="1.0" encoding="utf-8"?> |
|
2 <!-- Copyright (c) 2007-2010 Nokia Corporation and/or its subsidiary(-ies) All rights reserved. --> |
|
3 <!-- This component and the accompanying materials are made available under the terms of the License |
|
4 "Eclipse Public License v1.0" which accompanies this distribution, |
|
5 and is available at the URL "http://www.eclipse.org/legal/epl-v10.html". --> |
|
6 <!-- Initial Contributors: |
|
7 Nokia Corporation - initial contribution. |
|
8 Contributors: |
|
9 --> |
|
10 <!DOCTYPE concept |
|
11 PUBLIC "-//OASIS//DTD DITA Concept//EN" "concept.dtd"> |
|
12 <concept xml:lang="en" id="GUID-5C215C64-5D3D-5B65-A11F-BE6F8C306CF4"><title>How the Target Client is Resolved using CSIPResolvedClient</title><prolog><metadata><keywords/></metadata></prolog><conbody><p>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. </p> <p>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. </p> <p>The following is the DTD for the ECOM plug-in’s resource file: </p> <codeblock id="GUID-68B0C530-A5DA-5230-870E-49649C242F08" xml:space="preserve"><!-- SIP_CLIENT --> |
|
13 <!ELEMENT SIP_CLIENT (SIP_HEADERS, SDP_LINES?)> |
|
14 |
|
15 <!-- ALLOW_STARTING determines if a client can be started by the SIP stack. --> |
|
16 <!ATTLIST SIP_CLIENT ALLOW_STARTING (YES|NO) #REQUIRED> |
|
17 |
|
18 <!-- SIP_HEADERS --> |
|
19 <!ELEMENT SIP_HEADERS (ACCEPT+, ALLOW_EVENTS*, ACCEPT_CONTACT*)> |
|
20 |
|
21 <!-- ACCEPT: Accept-header as specified in RFC 3261. |
|
22 Indicates Content-Types supported by the client. |
|
23 Note that support for application/sdp must be announced as well, |
|
24 especially when the application aims to indicate capabilities based |
|
25 on SDP. Otherwise the SDP-based rules will not be taken into account. |
|
26 An empty value means that the application is willing |
|
27 to receive SIP requests without content. |
|
28 --> |
|
29 <!ELEMENT ACCEPT EMPTY> |
|
30 <!ATTLIST ACCEPT value CDATA #REQUIRED> |
|
31 |
|
32 <!-- ALLOW_EVENTS: Allow-Events-header as specified in RFC 3265 |
|
33 Indicates events supported by the client. |
|
34 Compared to the event-package part of a Event-header |
|
35 in an incoming SIP request if present. |
|
36 --> |
|
37 <!ELEMENT ALLOW_EVENTS EMPTY> |
|
38 <!ATTLIST ALLOW_EVENTS value CDATA #REQUIRED> |
|
39 |
|
40 <!-- ACCEPT_CONTACT: Accept-Contact-header as specified in RFC 3841 |
|
41 Indicates caller preferences supported by the client. |
|
42 All the parameters must match to a Accept-Contact header |
|
43 in an incoming SIP request if present. |
|
44 --> |
|
45 <!ELEMENT ACCEPT_CONTACT EMPTY> |
|
46 <!ATTLIST ACCEPT_CONTACT value CDATA #REQUIRED> |
|
47 |
|
48 <!-- SDP_LINES --> |
|
49 <!ELEMENT SDP_LINES (LINE+)> |
|
50 |
|
51 <!-- SDP Lines |
|
52 Can be used to indicate supported media by the client. |
|
53 If defined the application must announce the capability of |
|
54 receiving content of type application/sdp. |
|
55 Only M-line is supported currently as follows: |
|
56 - supported values of media field |
|
57 - port is rendered useless, |
|
58 but is mandatory in M-Line's BNF (should be set to zero) |
|
59 - supported values of proto field |
|
60 - name of the application in fmt field if the |
|
61 value of media field is 'application' |
|
62 BNF for the value of the M-Line: |
|
63 media space port ["/" integer] space proto 1*(space fmt) |
|
64 media = 1*(alpha-numeric) |
|
65 port = 1*(DIGIT) |
|
66 proto = 1*(alpha-numeric) |
|
67 fmt = 1*(alpha-numeric) |
|
68 alpha-numeric = ALPHA | DIGIT |
|
69 ALPHA = "a"|"b"|"c"|"d"|"e"|"f"|"g"|"h"|"I"|"j"|"k"| |
|
70 "l"|"m"|"n"|"o "|"p"|"q"|"r"|"s"|"t"|"u"|"v"| |
|
71 "w"|"x"|"y"|"z"|"A"|"B"|"C "|"D"|"E"|"F"|"G"| |
|
72 "H"|"I"|"J"|"K"|"L"|"M"|"N"|"O"|"P"|" Q"|"R"| |
|
73 "S"|"T"|"U"|"V"|"W"|"X"|"Y"|"Z" |
|
74 DIGIT = "0"|"1"|"2"|"3"|"4"|"5"|"6"|"7"|"8"|"9" |
|
75 --> |
|
76 <!ELEMENT LINE EMPTY> |
|
77 <!ATTLIST LINE name CDATA #REQUIRED> |
|
78 <!ATTLIST LINE value CDATA #REQUIRED> |
|
79 </codeblock> <p>The resource (<filepath>.rss</filepath>) file contains the XML file and the following information: </p> <ul><li id="GUID-ECADCF4D-C7B1-5F8F-861C-247682A61B41"><p> <codeph> dll_uid</codeph> and <codeph>implementation_uid</codeph>: These UIDs are supplied on request to <xref scope="external" href="http://www.symbiansigned.com">Symbian Signed</xref>. </p> <p> <b>Note</b>: These UIDs can be the same. </p> </li> <li id="GUID-CF722A1F-0FCE-5E12-9DD2-876C1DB776FD"><p> <codeph> interface_uid</codeph>: This must have the value <codeph>0x102010DD</codeph>. </p> </li> <li id="GUID-A9CF8349-9202-508A-83EA-48B0BDBDB147"><p> <codeph>default_data</codeph>: The application UID (without 0x). </p> </li> <li id="GUID-EB1AFAED-F5B6-591D-9412-9E240587ABB5"><p> <codeph> opaque_data</codeph>: The application capabilities in XML format. This field is empty if application capabilities are defined in the implementation. </p> </li> </ul> <section><title>Resolving the target client using CSIPResolvedClient</title> <p>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. </p> <fig id="GUID-AF6C1C45-A5A0-56FF-BBFC-3635BF4F9AD1"><title> |
|
80 Call flow of resolving a target client implementation using |
|
81 CSIPResolvedClient |
|
82 </title> <image href="GUID-8E8F1999-4DE0-5CA0-9656-C54127FDB3D4_d0e343948_href.png" placement="inline"/></fig> <p>The following list describes how the target client is resolved using <xref href="GUID-F0E4FA44-A41C-3C6F-993E-39CED042A879.dita"><apiname>CSIPResolvedClient</apiname></xref>. </p> <ol id="GUID-3D917824-7288-5893-8FFB-C4C81D30BF79"><li id="GUID-D801505D-4B4F-503B-95F7-F0C412413F70"><p>The user receives a SIP request and the target client is defined using <xref href="GUID-F0E4FA44-A41C-3C6F-993E-39CED042A879.dita"><apiname>CSIPResolvedClient</apiname></xref>. </p> </li> <li id="GUID-6AE1B8B5-83AF-5346-9F6C-68DE86B08800"><p>The user requests the SIP Client Resolver API implementation for a channel UI to connect to the user. </p> </li> <li id="GUID-CBF6BEDC-6062-5E21-80C4-920303B6C3FC"><p>The user requests the target client to connect to SIP with the resolved UID if there is no connection with the resolved channel UID. </p> </li> <li id="GUID-6EEEBE30-C31B-5E7C-9F91-FEAC3D14A340"><p>The SIP Client Resolver API implementation starts the target client. </p> </li> </ol> </section> <section><title>See also</title> <p> <xref href="GUID-0D579DDC-0A8A-5CFA-8194-CAA955B65A57.dita">Example of a SIP client resolver plug-in</xref> </p> </section> </conbody></concept> |