Since the standard JSR82 API does not support SCO links, JSR82ext extends the existing API to provide Java applications with the ability to create and use SCO links.

The architecture of SCO support code in JSR82ext closely resembles the one designed to support ACL links. Just like BluezTransport, SCOTrasport consists in a Java class providing to higher-lever classes an interface for data transmission and receival over Bluetooth SCO links and a Linux-native C module that makes use of Bluez SCO sockets as low-level wrapper to Bluez interfaces.

The architecture of SCO stack in JSR82ext

The API we have developed for the creation of SCO connections in JSR82ext closely resembles the one defined by JSR82 for the creation of L2CAP connections, with the Generic Connection Framework (GCF) from the Connected Limited Device Configuration (CLDC) providing the base connection for communication protocol implementation. The only significant differences are that SCO URLs start with the btsco schema and don't have a PSM (Protocol Service Multiplexor) parameter.

In fact, we have adopted the following grammar, presented in an Augmented Backus-Naur Form (ABNF), according to the guidelines of RFC 2234, and using the rules specified by the the JSR82 1.0a specification, for SCO server and client connection URLs:

      
srvString = protocol colon slashes srvHost 0*6(srvParams)
cliString = protocol colon slashes cliHost 0*4(cliParams)
protocol = btsco
btsco = %d98.116.115.99.111 ; defines the literal btsco
cliHost = address
srvHost =  localhost colon uuid
cliParams = encrypt / authenticate / receiveMTU / transmitMTU
srvParams = name / encrypt / authorize / authenticate / receiveMTU / transmitMTU
      
    

where the uuid, colon, slashes, bool, address, text, name, encrypt, authorize, authenticate, receiveMTU and transmitMTU productions are those defined in the JSR82 specification 1.0a, page 73. Notice that, unlike the L2CAP case, for SCO connections the master parameter is not needed, since all client connections require the device to be a slave and all server connections require the device to be a master.

As a result, Java code that uses SCO connections will closely resemble normal code that uses L2CAP connections. When called with a valid SCO client URL, the open() method of the javax.microedition.io.Connector class returns a SCOConnection object (which must implement the generic StreamConnection interface), which can be used to perform data transfers over the SCO link.

      
/* example client pseudo-code */
byte[] datain  = new byte[512];
byte[] dataout = new byte[512];
SCOConnection client = null;
try {
  SCOConnection client = (SCOConnection)Connector.open("btsco://0DEADBEEF0");
} 
catch (...) { ... }
client.send(dataout);
client.receive(datain);
      
    

Instead, when called with a valid SCO server URL, the open method of the javax.microedition.io.Connector class returns a SCOConnectionNotifier object (derived from StreamConnectionNotifier), which can be used to listen for an incoming SCO connection from a slave in the piconet. The acceptAndOpen() method blocks until a connection from a client arrives, and then returns a SCOConnection object that can be used to perform data transfers over the established connection.

      
/* example server pseudo-code */
byte[] datain  = new byte[512];
byte[] dataout = new byte[512];
SCOConnectionNotifier server = null;
SCOConnection con = null;
try {
  server = (SCOConnectionNotifier)Connector.open("btsco://localhost");
  con = (SCOConnection)server.acceptAndOpen();
} 
catch (...) { ... }
client.send(dataout);
client.receive(datain);