HXC 1.7

Router

Developer's Guide

HXC 1.7: Router: Developer's Guide

Copyright © reserved by Ericsson and its licensors: 2006, 2007

DisclaimerNo part of this document many be reproduced in any form without the written permission of the copyright holder.

The contents of this document are subject to revision without notice due to continued progress in methodology, design andmanufacturing. Ericsson and partners shall have no liability for any error or damage of any kind resulting from the use of thisdocument.

This document is supplied to Ericsson under license from Concurrent Systems (Pty) Ltd.

Trademark ListEricsson is the trademark or registered trademark of Telefonaktiebolaget LM Ericsson. All other products or service namesmentioned in this document are trademarks of their respective companies.

v

Table of ContentsPreface ...................................................................................................................................... vii

1. Purpose ......................................................................................................................... vii2. Scope ............................................................................................................................ vii3. Audience ........................................................................................................................ vii4. Assumptions .................................................................................................................. vii

1. General ................................................................................................................................... 12. Using HXC XML-RPC ............................................................................................................ 3

1. Introduction ..................................................................................................................... 32. Type Definitions .............................................................................................................. 33. Procedure Descriptions .................................................................................................. 4

3. State Behaviour and Flow Diagrams ...................................................................................... 51. Introduction ..................................................................................................................... 52. Single Request-Response Dialogue ............................................................................... 53. Multiple Request-Response Dialogue ............................................................................. 6

4. XML-RPC Syntax ................................................................................................................... 71. Introduction ..................................................................................................................... 72. XML-RPC Request ......................................................................................................... 73. XML-RPC Response ...................................................................................................... 84. XML-RPC Fault .............................................................................................................. 9

5. HTTP Transfer Mechanism .................................................................................................. 111. Introduction ................................................................................................................... 112. Supported HTTP mechanisms ...................................................................................... 113. HTTP error handling ..................................................................................................... 114. HTTP implementation limitations .................................................................................. 115. Example HTTP Request Header .................................................................................. 126. Example HTTP Response Header ............................................................................... 12

6. Operations ............................................................................................................................ 131. handleUSSD ................................................................................................................. 13

1.1. Expected Behaviour ........................................................................................... 131.2. handleUSSDRequest ......................................................................................... 131.3. handleUSSDResponse ...................................................................................... 14

7. Fault Responses and Behaviour .......................................................................................... 151. Introduction ................................................................................................................... 152. HXC Behaviour for Faults ............................................................................................ 153. Fault Response ............................................................................................................ 154. Fault Definitions ............................................................................................................ 165. HTTP Fault Translations ............................................................................................... 17

8. Element Descriptions ............................................................................................................ 191. action ............................................................................................................................ 192. faultCode ....................................................................................................................... 193. faultString ...................................................................................................................... 194. MSISDN ........................................................................................................................ 19

vi

5. ResponseCode ............................................................................................................. 196. response ....................................................................................................................... 207. TransactionId ................................................................................................................ 208. TransactionTime ........................................................................................................... 209. USSDRequestString ..................................................................................................... 2010. USSDResponseString ................................................................................................. 2111. USSDServiceCode ...................................................................................................... 21

9. Building an Application ......................................................................................................... 231. Requirements ................................................................................................................ 232. The XML-RPC Server ................................................................................................... 23

A. HelloWorld in PHP ............................................................................................................... 29B. WhoAmI in Java ................................................................................................................... 31

vii

Preface

1. Purpose

This document provides specific explanation of the protocol used between the HXC and USSDService Modules - HXC or third-party applications. The purpose of this document is to provide adeveloper's guide for the implementation of new services integrated with the HXC platform.

2. Scope

The document covers the HTTP implementation of the HXC platform, the XML-RPC protocoland the operations defined by HXC. All operations and parameters are explained in detail andexamples are provided to demonstrate implementation to developers. Behaviour of HXC and theexpected behaviour of external applications are documented for all operational scenarios.

3. Audience

This document is designed for use by developers wishing to develop third-party USSDapplications integrated with the HXC platform. It is also of use to general System Administratorsand Application Administrators wishing to understand the workings of the HXC and HXCplatform.

4. Assumptions

It is assumed that the consumers of this document have a good understanding of XML, remoteprocedural calls (RPC), HTTP and an understanding of general development concepts andprogramming principles. Experience with the chosen software development tools and serverswill also be required to successfully implement a third-party USSD application. For the purposesof this document, knowledge of Apache and the PHP programming language is expected inorder to make use of the examples found later on in the document.

1

Chapter 1. GeneralThe HXC receives USSD requests from the SS7 network and translates them into XML-RPCrequests to HXC or third-party applications for servicing.

Signaling System #7 (SS7) is a set of telephony signalling protocols which are used to set up thevast majority of the world's public switched telephone network telephone calls.

Unstructured Supplementary Service Data (USSD) is a capability of all GSM phones. It isgenerally associated with real-time or instant messaging type phone services.

XML-RPC is an XML based method of RPC which generally uses the HTTP protocol as atransport medium. The official site may be found at http://www.xmlrpc.com/.

3

Chapter 2. Using HXC XML-RPC

1. Introduction

The HXC translates the USSD requests received from the SS7 network and encodes them intoXML-RPC requests which are then sent to the configured HXC or third-party applications.

It's the responsibility of the HXC or the third-party developers to ensure that their third-partyapplications have implemented all of the required RPC operations according to this specificationwithin their system. This ensures that HXC is interacting with a well-defined interface and willoperate according to intention.

This document provides a detailed description of the RPC operations required, their expectedbehaviour and their expected responses.

2. Type Definitions

In communication between the HXC and external application, each parameter which is passedneeds to belong to a certain type definition. Each of these types need to be clearly defined inorder to facilitate correct communication between the server and client. These are the typedefinitions to use when they are referred to within this document:

Table 2.1. Type Definitions

Type Range Description

Integer -2147483648 to 2147483647 32 bit signed integer

UnsignedShort

0 to 65535 16 bit unsigned integer

Unsigned Byte 0 to 255 8 bit unsigned integer

String Character array A character array representinga string. The encoding of thisstring is based on the specifiedencoding of the XML data.

DateTime YYYYMMDD[T]hh:mm:ss Specific representation of anISO 8601 compatible date.

4

3. Procedure Descriptions

The RPC operations are described in brief within the following table. For a more detailedexplanation of the individual operations, the consumer should consult the Operations chapter ofthis document.

A developer wishing to develop an USSD application integrated with HXC will need to implementall of the RPCs within their system and expose it in a location accessible to the HXC platform.

Table 2.2. HXC RPC Operations

Operation Description

handleUSSD When the HXC receives an USSD message, it'stranslated into this RPC call which is sent to the HXC orthird-party applications for servicing.

5

Chapter 3. State Behaviour and FlowDiagrams

1. Introduction

USSD-based services built using the HXC communicate using an asynchronous messagesequence between the cellular device, HLR, HXC and the recipient Service Application. Reviewof this transaction sequence is useful in order to understand the complete flow which takes placewhen servicing subscriber requests.

2. Single Request-Response Dialogue

Figure 3.1. Single Transaction Sequence

6

3. Multiple Request-Response Dialogue

Figure 3.2. Menu Transaction Sequence

7

Chapter 4. XML-RPC Syntax

1. Introduction

The RPC between the HXC and third-party application is encoded using XML. The XMLcomplies with the XML-RPC generalized specification as found on www.xmlrpc.com [http://www.xmlrpc.com/].

As with most procedures - whether remote or local - there is a set of input parameters and a setof output parameters. Because the members of the request may be different to the members ofthe response, both of the sets need to be properly defined in order to be described in the XMLformat. In addition, these sets of parameters will be different in most occasions.

All request and response structures take the name of the operation to which they areassociated. In the case of HXC, the terms "Request" and "Response" are merely appendedto the operation name in order to name the parameter structures. This is how the request andresponse structures will be referred to within this document.

In the case of the handleUSSD operation, the request structure will have the namehandleUSSDRequest and the response structure will be named handleUSSDResponse. TheHXC receives an incoming USSD request and populates a handleUSSDRequest structure whichit sends to the HXC or third-party application. The HXC or third-party application is then requiredto respond using a correctly populated handleUSSDResponse structure.

In the case of HXC or the third-party application experiencing a severe internal error and notbeing able to handle the incoming request, it may also respond with a standard XML-RPC faultmessage. This fault message will then be handled according to standard fault handling rules asdefined elsewhere in this document.

2. XML-RPC Request

Example of a request:

<?xml version="1.0"?><methodCall> <methodName>handleUSSDRequest</methodName> <params> <param> <value> <struct> <member>

8

<name>TransactionId</name> <value> <string>00001</string> </value> </member> <member> <name>TransactionTime</name> <value> <dateTime.iso8601>20060723T14:08:55</dateTime.iso8601> </value> </member> <member> <name>MSISDN</name> <value> <string>275551234</string> </value> </member> <member> <name>USSDServiceCode</name> <value> <string>543</string> </value> </member> <member> <name>USSDRequestString</name> <value> <string>14321*1000#</string> </value> </member> <member> <name>response</name> <value> <string>false</string> </value> </member> </struct> </value> </param> </params></methodCall>

3. XML-RPC Response

Example of a response:

<?xml version="1.0"?><methodResponse> <params>

9

<param> <value> <struct> <member> <name>TransactionId</name> <value> <string>00001</string> </value> </member> <member> <name>TransactionTime</name> <value> <dateTime.iso8601>20060723T14:08:56</dateTime.iso8601> </value> </member> <member> <name>USSDResponseString</name> <value> <string>Your Return Message Here</string> </value> </member> <member> <name>action</name> <value <string>end</string> </value> </member> </struct> </value> </param> </params></methodResponse>

4. XML-RPC Fault

Example of a fault response:

<?xml version="1.0"?><methodResponse> <fault> <value> <struct> <member> <name>TransactionId</name> <value> <string>00001</string> </value> </member>

10

<member> <name>TransactionTime</name> <value> <dateTime.iso8601>20060723T14:08:56</dateTime.iso8601> </value> </member> <member> <name>faultCode</name> <value> <int>4001</int> </value> </member> <member> <name>faultString</name> <value> <string>Application busy</string> </value> </member> </struct> </value> </fault></methodResponse>

11

Chapter 5. HTTP Transfer Mechanism

1. Introduction

The HXC application supports a base, strict partial implementation of the HTTP 1.1 standard asdefined in the RFC-2616 [http://www.w3.org/Protocols/rfc2616/rfc2616.html]). The majority ofthe base support is listed below along with the caveats and notices regarding standard featureswhich are not supported.

The implementation is compatible with most scenarios.

2. Supported HTTP mechanisms

1. HTTP Methods: GET and POST

2. Transfer-Encodings: chunked (NB: The chunked-extension field of the chunk is not supportedand will be regarding as an invalid HTTP field.

3. HTTP error handling

HTTP errors are supported and recognized by the transport protocol.

4. HTTP implementation limitations

The HTTP limitations present within the transport protocol mechanism include:

1. Fragmented HTTP packets over multiple TCP packets is not supported currently. Thissituation should never occur within the realm of standard development and integration.However, in the case of third-party developers using niche HTTP products which are obscureand network-inefficient, this situation may occur.

12

5. Example HTTP Request Header

Example 5.1. Example HTTP Request Header

POST /app.jsp HTTP/1.1User-Agent: HXC/1.0Host: ussd.thirdparty.comContent-Type: text/xmlContent-length: 180

6. Example HTTP Response Header

Example 5.2. Example HTTP Response Header

HTTP/1.1 200 OKConnection: closeContent-Length: 158Content-Type: text/xmlDate: Fri, 17 Jul 2006 19:55:08 GMTServer: Apache

13

Chapter 6. Operations

1. handleUSSD

1.1. Expected Behaviour

This is the main operation which is required to be supported by the third-party application. Thisoperation is called whenever the HXC receives an USSD request and it needs to pass it along tothe configuration application for servicing.

This operation is required to respond within the configured timeout defined on the HXC. If theapplication does not respond, the HXC closes the connection, and then sends the subscribera rejection message. This may lead to duplicate transactions if the service module has alreadyprocessed the transaction, but failed to return a response. The subscriber may retry theoperation. It is left up to the SM to properly handle the possible duplicates.

This operation is required to respond with the same TransactionId as provided in the request.

1.2. handleUSSDRequest

Table 6.1. handleUSSDRequest

Element Type

TransactionId M

TransactionTime M

MSISDN M

USSDServiceCode M

USSDRequestString M

response O

14

1.3. handleUSSDResponse

Table 6.2. handleUSSDResponse

Element Type

TransactionId M

TransactionTime M

USSDResponseString M

action O

ResponseCode O

15

Chapter 7. Fault Responses andBehaviour

1. Introduction

In some scenarios, the HXC or third-party application may encounter a serious error or conditionin which it can not correctly respond to an incoming request from HXC. In cases like these,the XML-RPC standard defines a Fault response which must be returned by the externalapplication. HXC will handle the fault according to the defined fault behaviour.

If the third party service module does not respond with a successful transaction or faultCode(e.g. closes the socket to HXC without responding), then HXC will raise an alarm and beginthrottling traffic to the service module reducing the rate until the the application starts returning acorrect response. It's in everyone's best interests to return correct responses.

2. HXC Behaviour for Faults

The HXC can be configured to return specific messages for each faultCode returned. Theseconfigurations are done on HXC itself.

So in the case of HXC or third-party application returning a fault, the HXC will attempt to returnthe configured message specific for the faultCode. If there is none, the default fault message willbe returned.

3. Fault Response

Table 7.1. Fault Response

Element Type

TransactionId M

TransactionTime M

faultCode M

faultString M

16

4. Fault Definitions

Table 7.2. Fault Definitions

faultCode faultString Description

4000 Malformed XML-RPC The HXC or third-party applicationcould not parse the XML-RPC sent bythe HXC platform.

4001 Missing parameters The HXC or third-party applicationcould not find expected parametersin the XML-RPC sent by the HXCplatform.

4002 Application busy The HXC or third-party applicationis too busy to process the incomingrequest.

4003 Invalid service code The service code received HXC orthird-party application is not expected.The third-party application hasrejected the request. This usuallymeans HXC is configured to routeaspecific USSD short code to theexternal application but the applicationisn't configured to received it.

4004 Internal server error The server encountered anunrecoverable error whilst trying toprocess the RPC.

4005 Application not found In the case of the destinationapplication multiplexing requests toadditional applications, it may bethat an incoming service code isnot correctly mapped in the externalapplication and it is unable to processthe request correctly.

17

5. HTTP Fault Translations

In some cases, the HTTP server used to serve the HXC or third-party applications canencounter an error itself. It will return an HTTP response according to the HTTP protocol with adefined HTTP response code in the header. These responses are defined in the HTTP standardand HXC have defined translations to the previously mentioned faultCodes for most of them.

The following table defines the HTTP response code to faultCodes mappings as set up in theHXC application:

Table 7.3. HTTP Fault Translations

HTTP code faultCode Description

404 4005 Application not found.

* 4004 Every other error encountered.

19

Chapter 8. Element Descriptions

1. action

Type: String.

This indicates the action to be performed on the MAP dialogue. Allowed values include:request, end and notify.

2. faultCode

Type: Integer.

The logical code number representing a fault message.

3. faultString

Type: String.

The message text displayed on a subscriber cellular device.

4. MSISDN

Type: String.

This is the unique identifier of the subscriber SIM card and is sent to the HXC from the HLR.

5. ResponseCode

Type: Integer.

This is an optional value returned by the third-party application which will be inserted intothe CDRs generated by the system. It's provided for convenience and is not used by the

20

gateway itself but provides developers the ability to generate detailed statistics regarding theirapplications. The default value if not present is 0.

6. response

Type: String.

This indicates whether an incoming request is a response to a previously open request sentback by the HXC or third-party application. Allowed values include: true or false.

7. TransactionId

Type: Unsigned Short.

The TransactionId parameter is received from the HLR via SS7 and is a number in the range0 - 65535 that uniquely identifies the transaction to all components. In practice the HLR autoincrements and decrements through this number range.

A Service Application must return this parameter.

8. TransactionTime

Type: DateTime.

This is the system date and time in a ISO 8601 compatible format. The TransactionTimeparameter is generated by the HXC for methodCall document types and Service Application formethodResponse document types just before transmitting.

9. USSDRequestString

Type: String.

USSD messages are formatted using the following syntax:

*<Service Code>*<Request String>#

This is the Request String (second part) of the USSD string received from the HLR (including thesecond asterisk (*).

21

The USSDRequestString parameter transparently accepts the specified string. The syntax of thestring may contain zero (empty) or more parameters, delimetered by asterisk (*), followed by ahash (#). The USSD syntax for the Request String with multiple parameters would therefore looksomething like this:

*<Request String 1>*<Request String 2>*<Request String 3>#

The USSDRequestString parameter may be blank or "#" for simple requests e.g. *123#

10. USSDResponseString

Type: String.

The message, returned from the Service Application, that is to be displayed on the screen of thesubscriber device.

11. USSDServiceCode

Type: String.

USSD messages are formatted using the following syntax:

*<Service Code>*<Request String>#

This is the Service Code (first part) of the USSD string received from the HLR (excluding thesecond asterisk (*).

The HXC USSDServiceCode parameter is mapped to a Service Application in the HXCconfiguration and routing table. Based on this information the HXC is able to send theREQUEST message to the correct recipient.

23

Chapter 9. Building an ApplicationIn this chapter we provide a sample application to demonstrate how an application can bedeveloped using the HXC.

The demonstrated application enables a subscriber to originate a request via USSD in order toretrieve the number (MSISDN) of the SIM card currently in use. The application, which we willcall "whoami" will be developed using PHP. A full listing of the application code can be found in??? .

1. Requirements

The following explanation assumes that an Apache Web Server is installed and configured withPHP and the XML parser from mod_php.

In addition, for the whoami application to work, it is assumed that the HXC routing table isconfigured to route all USSD strings originating from the HLR with the service code 100 tothe host computer running the whoami application in an XML-RPC server. For example, asubscriber originating an USSD message with the string *100#. HXC Gateway will convertthe USSD string into an XML-RPC method call and route the message to the host running thewhoami application.

2. The XML-RPC Server

The XML-RPC server receives an XML-RPC method call via HTTP-REQUEST containing thehandleUSSDRequest method over HTTP port 80.

To create the XML-RPC server in PHP we first need to start a PHP document. Create a new textfile, e.g. hxc_webapp.php, containing the following HTML tags.

<?php

>

Since we want the server to run the whoami application, we can create a function for whoami.

<?php

24

function whoami_func( $params ){ $response = ""; if ( strlen( $params[0]["MSISDN"] ) < 7 ) { $response = array('TransactionId'=> $params[0] \ ['TransactionId'], 'TransactionTime'=> $params[0] \ ['TransactionTime'], 'USSDResponseString'=>'Incorrect \ MSISDN length. Expecting at least 7 digits.'); } else { $response = array('TransactionId'=>$params[0] \ ['TransactionId'], 'TransactionTime'=>$params[0] \ ['TransactionTime'], 'USSDResponseString'=> \ 'Your mobile number is: ' . $params[0]['MSISDN']); } return $response;}

To avoid problems we validate and marshall the parameters received against some expectedcriteria.

function ussd_handler( $method_name, $params, $app_data){ $response = ""; if ((! $params[0]['MSISDN']) || (! $params[0] \ ['TransactionId']) || (! $params[0]['TransactionTime']) || \ (! $params[0]['USSDServiceCode'])) { $response = array('faultCode'=>4001, 'faultString'=> \ 'Missing mandatory parameter'); } else { /* * Marshall the request based on the service code */ switch ( $params[0]['USSDServiceCode'] ) { case "100": $response = whoami_func( $params ); break; default: $response = array('faultCode'=>4002, 'faultString'=> \ 'Unknown service request: '. $params[0] \ ['USSDServiceCode']);

25

} }

return $response;}

With our functions defined and marshaled we can continue to create the XML-RPC server usingthe xmlrpc_server_create() function and set a handle for the server. In the sample below wedo this in a variable named $xmlrpc_server.

$xmlrpc_server = xmlrpc_server_create();

Next we use the xmlrpc_server_register_method() to register a PHP function. Thexmlrpc_server_register_method() takes three parameters:

1. The handle of a server created

2. The name to register the server under. This should be the methodname. In our casehandleUSSDRequest

3. The name of the PHP function to register.

26

xmlrpc_server_register_method( \ $xmlrpc_server, "handleUSSDRequest", "ussd_handler");

We need a way to obtain the XML-RPC string from Apache. In this case the string will be foundin the default Apache environment variable HTTP_RAW_POST_DATA. The variable $request_xml isour handle to extract the string.

Validation of the XML-RPC string would take place in production environments, but for thisexample we will assume the integrity of the string is valid and well-formed.

$request_xml = $HTTP_RAW_POST_DATA;

Now we can use the xmlrpc_server_call_method() function to send the request to theserver and receive an XML-RPC response. In this case it will send the string contained inthe $request_xml variable which was obtained from the Apache server HTTP_RAW_POST_DATAvariable. The xmlrpc_server_call_method() requires three arguments:

1. The handle of a server

2. The string containing an XML-RPC request

3. The application data. Any additional arguments required by the target application. In this casewhoami requires no additional parameters, so we pass a null string.

$response = xmlrpc_server_call_method( \ $xmlrpc_server, $request_xml, '' );

To return the response to the HXC we print and Apache will return the string as an XML-RPCmethodResponse document using HTTP-RESPONSE.

print $response;

To end the session we tear down the server.

xmlrpc_server_destroy( $xmlrpc_server );

27

29

Appendix A. HelloWorld in PHP<?phpfunction helloworld_func( $method_name, $params, $app_data){ $response = "";

if ( (! $params[0]["MSISDN"]) || (! $params[0]["TransactionId"]) || (! $params[0]["TransactionTime"]) ) { $response = array( 'faultCode'=>4001, 'faultString'=>"A mandatory parameter was missing"); } else

$response = array("TransactionId"=>$params[0]["TransactionId"], "TransactionTime"=>$params[0]["TransactionTime"], "USSDResponseString"=> "Hello World" );

return $response;}

$xmlrpc_server = xmlrpc_server_create();xmlrpc_server_register_method($xmlrpc_server, "handleUSSDRequest", "helloworld_func");$request_xml = $HTTP_RAW_POST_DATA;$response = xmlrpc_server_call_method($xmlrpc_server, $request_xml, '');print $response;xmlrpc_server_destroy($xmlrpc_server);?>

31

Appendix B. WhoAmI in Java

/* This is an example WhoAmI application which relies on the * Marquee XML-RPC library for Java. (Now known as the Redstone * XML-RPC library). * * References: * * IBM developerWorks - http://www.ibm.com/developerworks/xml/library/j-xmlrpc.html * Redstone - http://xmlrpc.sourceforge.net/ * * Requirements: * * Marquee 1.3 * Java * * */

import java.util.HashMap;import java.io.*;

import marquee.xmlrpc.XmlRpcServer;import marquee.xmlrpc.handlers.ReflectiveInvocationHandler;

public class WhoAmI{ private boolean isShuttingDown = false;

private String host; private int port;

private XmlRpcServer rpcServer; private Thread rpcThread;

public WhoAmI( String lhost, int lport, String rpcName ) { host = lhost; port = lport; createRpcServer( rpcName ); startRpcServer(); }

/* Public methods exposed to RPC */

32

public Object handleUSSDRequest( HashMap request ) { try { String TransactionId = (String)request.get("TransactionId"); String USSDServiceCode = (String)request.get( "USSDServiceCode" ); String USSDRequestString = (String)request.get( "USSDRequestString" ); String msisdn = (String)request.get( "MSISDN" ); String responseFlag = (String)request.get( "response" ); java.util.Date TransactionTime = (java.util.Date)request.get( "TransactionTime" );

String msg = "Your phone number is " + msisdn;

java.util.HashMap<String,Object> response = new java.util.HashMap<String,Object>();

response.put( "TransactionId", TransactionId ); response.put( "TransactionTime", new java.util.Date() ); response.put( "USSDResponseString", msg ); response.put( "ResponseCode", 0 ); response.put( "action", "end" );

return response; } catch (Exception e) { System.out.println( "Exception was: " + e ); return new String( e.toString() ); } }

protected void startRpcServer() { rpcThread = new Thread( new Runnable() { public void run() { try { rpcServer.runAsService(port); } catch (IOException ioe) { if (!isShuttingDown) ioe.printStackTrace(); } } }); rpcThread.setName("WhoAmI["+this.host+"] on "+this.port ); rpcThread.start(); }

protected void createRpcServer( String object_name ) {

33

rpcServer = new XmlRpcServer(); rpcServer.registerInvocationHandler( object_name, new ReflectiveInvocationHandler(this)); }

protected void join() { try { rpcThread.join(); } catch (InterruptedException ie) { } }

static public void main( String[] args ) { WhoAmI ds = new WhoAmI( "0.0.0.0", 4050, "WhoAmI" ); ds.join(); }}