Hi,
Below is the Sim Access Profile server role API discription.
Please let me know your comments.
Regards
Suraj
---
Makefile.am | 2 +-
doc/sap-api.txt | 216 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 217 insertions(+), 1 deletions(-)
create mode 100644 doc/sap-api.txt
diff --git a/Makefile.am b/Makefile.am
index a8829d9..52537bc 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -350,7 +350,7 @@ EXTRA_DIST += doc/manager-api.txt \
doc/service-api.txt doc/agent-api.txt doc/attribute-api.txt \
doc/serial-api.txt doc/network-api.txt \
doc/input-api.txt doc/audio-api.txt doc/control-api.txt \
- doc/hfp-api.txt doc/assigned-numbers.txt
+ doc/hfp-api.txt doc/assigned-numbers.txt doc/sap-api.txt
AM_YFLAGS = -d
diff --git a/doc/sap-api.txt b/doc/sap-api.txt
new file mode 100644
index 0000000..9a684fa
--- /dev/null
+++ b/doc/sap-api.txt
@@ -0,0 +1,216 @@
+BlueZ D-Bus Sim Access Profile API description
+**********************************************
+
+Copyright (C) 2009-2010 Atheros Communication Ltd
+
+
+Sim Access Server hierarchy
+===========================
+
+Service org.bluez
+Interface org.bluez.SAPServer
+Object path [variable prefix]/{hci0,hci1,...}
+
+This interface is available for devices which can function as the
+Server role of the Sim Access profiles.
+It is intended to be used with external stacks / handlers of the Sim Access
+protocol.
+
+
+Methods void RegisterAgent(object agent)
+
+ This registers the Sim Access server agent.
+ This also registers the profile with the service
+ databse and start waiting for an RFCOMM connection
+ on the SAP server channel.
+
+ The object path defines the path the of the agent.
+
+ If an application disconnects from the bus all
+ of its registered agents will be removed.
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.AlreadyExists
+ org.bluez.Error.Failed
+
+ void UnregisterAgent(object agent)
+
+ This unregisters the agent that has been previously
+ registered. The object path parameter must match the
+ same value that has been used on registration.
+
+ Possible errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Response(string command, string result, object response)
+
+ This sends a SAP response packet to a SAP sequest.
+
+ The command parameter specifies the SAP command for
+ which response is being sent.
+
+ The result parameter specifies the ResultCode for the
+ operation.
+
+ The object response specifies the response packet to
+ be sent if any.
+
+ Below mentioned are the parameters and possible value.
+
+ command result response
+ ----------------------------------------------------
+
+ Connect OkSuccess NA
+ ConnectFailed
+ OkOngoingCall
+
+ APDU OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ APDU7816 OkSuccess array{uint8}
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ ATR OkSuccess array{uint8}
+ NoReason
+ CardPoweredOff
+ CardRemoved
+ DataNotAvailable
+
+ SimPowerOn OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardRemoved
+ CardPoweredOn
+
+ SimPowerOff OkSuccess NA
+ NoReason
+ CardPoweredOff
+ CardRemoved
+
+ Reset OkSuccess NA
+ NoReason
+ CardNotAccessible
+ CardPoweredOff
+ CardRemoved
+
+ CardReaderStatus OkSuccess uint8
+ NoReason
+ DataNotAvailable
+
+ TransportProtocol OkSuccess NA
+ NotSupported
+
+ Disconnect NA NA
+
+ Possible errors: org.bluez.Error.InvalidArguments
+ org.bluez.Error.Failed
+
+ void Disconnect(string type)
+
+ This initiates a SAP disconnection from SAP server.
+
+ The type parameter specifies the type of disconnection.
+
+ "Graceful" -> lets the SAP client initiate a
+ garceful disconnection.
+
+ "Immediate" -> disconnects the connection
+ immediately from the server.
+
+ void SetProperty(string name, variant value)
+
+ Changes the value of the specified property. Only
+ properties that are listed a read-write are changeable.
+ On success this will emit a PropertyChanged signal.
+
+ Possible Errors: org.bluez.Error.DoesNotExist
+ org.bluez.Error.InvalidArguments
+
+ dict GetProperties()
+
+ Returns all properties for the interface. See the
+ properties section for available properties.
+
+ Possible Errors: org.bluez.Error.InvalidArguments
+
+Signals PropertyChanged(string name, variant value)
+
+ This signal indicates a changed value of the given
+ property.
+
+Properties string SimStatus [readwrite]
+
+ Specifies the availability of the SIM.
+
+ The possible value are
+
+ "UnknownError"
+ "CardReset"
+ "CardNotAccesible"
+ "CardRemoved"
+ "CardInsterted"
+ "CardRecovered"
+
+ uint16 MaxMessageSize [readwrite]
+
+ The maximum possible message size supported by
+ SAP server.
+
+ uint16 MinMessageSize [readwrite]
+
+ The minimum possible message size supported by
+ SAP server.
+
+ uint16 MessageSize [readonly]
+
+ The negotiated message size for the current connection.
+ This is valid only when there is an active
+ SAP connection.
+
+Sim Access Server Agent hierarchy
+=================================
+
+Service unique name
+Interface org.bluez.SAPServerAgent
+Object path freely definable
+
+Methods Request(string command, object param)
+
+ This method gets called whenever a SAP request is received
+ from SAP client. This will help deliver the
+ SAP request to the Agent.
+
+ The command parameter specifies the SAP request type
+ received.
+
+ The param parameter specifies the command parameter
+ packet received from SAP client.
+
+ Below mentioned is the parameters and possible value.
+
+ command parameter
+ ----------------------------------------------------
+
+ Connect NA
+ APDU array{uint8}
+ APDU7816 array{uint8}
+ ATR NA
+ SimPowerOn NA
+ SimPowerOff NA
+ Reset NA
+ CardReaderStatus NA
+ TransportProtocol uint8
+ Disconnect NA
+
+ void Release()
+
+ This method gets called whenever the service daemon
+ unregisters the agent or whenever the Adapter where
+ the SimAccessServerAgent registers itself is removed.
--
1.7.0.4
Hi Nicolas,
> >>that is just because we haven't gotten there yet. Of course if SAP takes
> over we have to shutdown oFono's handling of the modem. This could be
> done similar to the support for Lockdown we have in the oFono TODO list.
>
> Do you have information about the release date of this feature? And about the interface to lockdown, is it a D-BUS message?
good one ;)
We know that we need such or similar feature for firmware updates where
we have to essentially shutdown oFono from driving the modem for a
period of time. The details are not 100% clear. For firmware updates
this has to be a D-Bus method, actually D-Bus property on the modem
interface.
In theory we can even extend this to do this internally as well. So that
an oFono plugin could lock down the modem. Things we clearly have to
figure out at some point.
> >There is a framework for card services in general, but I think that is
> just pure overhead for this.
>
> >And to be honest, my current thinking is that even for pure SIM card
> readers with APDU mode, we might wanna support them via oFono anyway.
> Having to add SAP support in multiple levels is a bad idea.
>
> Yes but an APDU interface is needed in the SIM driver of oFono, I don't see any interface of this kind in the source code.
Because we haven't had any hardware that does this so far. You will only
see code in oFono once we had hardware in our hands that is able of
doing this and we know how to drive it.
> Maybe it's not the good place to speak about that.
Essentially the oFono mailing list is a better place for such a
discussion.
> >However in the end this all depends on the hardware and right now I have
> not had access to SAP capable hardware. Or maybe I did and I didn't know
> it yet. Do we have any target hardware in mind?
>
> Yes we have, it's Renesas Modem solution.
Any chance you guys could add Renesas Modem support to oFono and then us
some samples?
Regards
Marcel
Hi Marcel,
-----Message d'origine-----
De=A0: [email protected] =
[mailto:[email protected]] De la part de Marcel =
Holtmann
Envoy=E9=A0: vendredi 17 septembre 2010 01:00
=C0=A0: Nicolas GUILBAUD
Cc=A0: Suraj Sumangala; Suraj Sumangala; =
[email protected]; Jothikumar Mothilal
Objet=A0: RE: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>>that is just because we haven't gotten there yet. Of course if SAP =
takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.
Do you have information about the release date of this feature? And =
about the interface to lockdown, is it a D-BUS message?=20
>There is a framework for card services in general, but I think that is
just pure overhead for this.
>And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.
Yes but an APDU interface is needed in the SIM driver of oFono, I don't =
see any interface of this kind in the source code.
Maybe it's not the good place to speak about that.
>However in the end this all depends on the hardware and right now I =
have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?
Yes we have, it's Renesas Modem solution.
Regards
Nicolas
Hi Waldemar,
> >if we talk about the SAP server role found in a mobile phone,
> >then that support clearly needs to interact with the telephony
> >stack. Since when SAP is active the telephony stack needs to
> >be suspended and all SIM transaction being forwarded.
>
> I agree, but a telephony stack needs to care about its state when SAP is active. Not all linux based mobile platforms use ofono.
I think they should use oFono of course since that is the only way to be
modem hardware agnostic in the long run.
> >Currently I would be thinking that the SAP implementation
> >should be done inside oFono actually. Since then you have
> >direct access to the hardware. The D-Bus approach just doesn't
> >sound correct to me. I could be of course wrong, but I can't
> >wrap my mind around on how you can make this work.
>
> I assume that ofono should handle sap transactions (as it's kind of hardware abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did for sap transactions in spec (http://www.wirelessmodemapi.com/), and not implement sap profile itself. Again, not all use ofono as telephony stack.
>
> Sorry, I don't know ofono well. What's the interface between ofono and bluez?
In this case there will be no direct interface besides oFono registering
the SDP records for SAP.
> >Even with file descriptor passing this doesn't look like the
> >right approach. If we need a hardware abstraction than we
> >either use oFono or we have to create some SAP hardware access
> >abstraction.
>
> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.
I still don't see this as a really good idea. We want modem abstraction
inside oFono and not all over the place.
Regards
Marcel
Hi Nicolas,
> >>> I would really appreciate if you can give me any idea about working
> >>> around the above mentioned issues.
> >>
> >> if we talk about the SAP server role found in a mobile phone, then that
> >> support clearly needs to interact with the telephony stack. Since when
> >> SAP is active the telephony stack needs to be suspended and all SIM
> >> transaction being forwarded.
> >>
> >> Currently I would be thinking that the SAP implementation should be done
> >> inside oFono actually. Since then you have direct access to the
> >> hardware. The D-Bus approach just doesn't sound correct to me. I could
> >> be of course wrong, but I can't wrap my mind around on how you can make
> >> this work.
> >>
> >> Even with file descriptor passing this doesn't look like the right
> >> approach. If we need a hardware abstraction than we either use oFono or
> >> we have to create some SAP hardware access abstraction.
> >
> >The advantage I thought d-bus has would be the generic interface it
> >could provide. But, if we have a system with direct access to the Sim
> >access hardware, D-bus could possibly become a bottleneck.
> >
> >I would really appreciate if others who have worked with Sim Access and
> >OFono can give their comments.
> >
> >Also, please share some information on regarding the SIM reader
> >implementation in linux based systems.
> >
> >>
> >> The SAP client role found a carkit is obviously a different story.
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.
that is just because we haven't gotten there yet. Of course if SAP takes
over we have to shutdown oFono's handling of the modem. This could be
done similar to the support for Lockdown we have in the oFono TODO list.
> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it.
There is a framework for card services in general, but I think that is
just pure overhead for this.
And to be honest, my current thinking is that even for pure SIM card
readers with APDU mode, we might wanna support them via oFono anyway.
Having to add SAP support in multiple levels is a bad idea.
However in the end this all depends on the hardware and right now I have
not had access to SAP capable hardware. Or maybe I did and I didn't know
it yet. Do we have any target hardware in mind?
Regards
Marcel
Hi,
> I agree with this too. I prefere to have a sap implementation as bluez plugin, but we need to define api for sim operations which could be implemented in ofono or other proprietary stacks. I guess dbus was intended to be kind of hw abstraction api.
> Some time ago Claudio sent proposal implementation of sap server where he defined api for a driver to sim.
The main question will be
"where should be SAP profile packet handling be implemented?"
1. If it has to be implemented as part of bluetoothd, there is no other
option other than using dbus so that we have a consistent interface for
all modules who would be interested in using it.
2. If it has to be done in the "modem/SIM reader", then it will be part
of that module, not an independent module.
will all SIM card reader implementation be ready to implement a
Bluetooth SAP parser as part of it just to support Bluetooth as transport?
>
> Regards,
> /Waldek
Regards
Suraj
Hi Marcel,=20
>if we talk about the SAP server role found in a mobile phone,=20
>then that support clearly needs to interact with the telephony=20
>stack. Since when SAP is active the telephony stack needs to=20
>be suspended and all SIM transaction being forwarded.
I agree, but a telephony stack needs to care about its state when SAP is ac=
tive. Not all linux based mobile platforms use ofono.
>Currently I would be thinking that the SAP implementation=20
>should be done inside oFono actually. Since then you have=20
>direct access to the hardware. The D-Bus approach just doesn't=20
>sound correct to me. I could be of course wrong, but I can't=20
>wrap my mind around on how you can make this work.
I assume that ofono should handle sap transactions (as it's kind of hardwar=
e abstraction for bluez) and expose SAP APDU interfaces as i.e Nokia did fo=
r sap transactions in spec (http://www.wirelessmodemapi.com/), and not impl=
ement sap profile itself. Again, not all use ofono as telephony stack.
Sorry, I don't know ofono well. What's the interface between ofono and blue=
z?=20
>Even with file descriptor passing this doesn't look like the=20
>right approach. If we need a hardware abstraction than we=20
>either use oFono or we have to create some SAP hardware access=20
>abstraction.
I agree with this too. I prefere to have a sap implementation as bluez plug=
in, but we need to define api for sim operations which could be implemented=
in ofono or other proprietary stacks. I guess dbus was intended to be kind=
of hw abstraction api.
Some time ago Claudio sent proposal implementation of sap server where he d=
efined api for a driver to sim.
Regards,
/Waldek=
>-----Message d'origine-----
>De=A0: [email protected] =
[mailto:linux-bluetooth->[email protected]] De la part de Suraj =
Sumangala
>Envoy=E9=A0: mercredi 15 septembre 2010 10:25
>=C0=A0: Nicolas GUILBAUD
>Cc=A0: Suraj Sumangala; Marcel Holtmann; =
[email protected]; >Jothikumar Mothilal
>Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>
>Hi Nicolas,
>
>On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
>> Hello Marcel and Suraj,
>>
>> I agree with Marcel, because in standard Mobile phone implementation, =
the >SIM card is directly connected to the Modem. To access the SIM =
card, AT >command (or proprietary commands) are needed, oFono implements =
both of them >to access SIM card in Modem side, but in my understanding =
there is no >possibilities to disconnect modem (in oFono) due to SIM =
SAP.
>>
>> In the case where SIM card is connected to the Application processor =
>(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any >SIM implementation in Linux, may be we have to specify it.
>>
>Other than transferring APDUs, SAP profile also specifies operations on =
>the SIM cards like SIM Reset, SIM power on/off, Getting Card reader=20
>status etc.
>
>How do we do these operations case of mobile phones?
There are specific interfaces, you can find example of interface in =
Nokia Wireless Open API (uicc_fp.pdf) in =
http://www.wirelessmodemapi.com/, register is free.
SIM reset is an OFF command following by ON command (ATR comes with ON), =
card status is a local information...=20
Best Regards,
Nicolas.
Hi Nicolas,
On 9/15/2010 1:02 PM, Nicolas GUILBAUD wrote:
> Hello Marcel and Suraj,
>
> I agree with Marcel, because in standard Mobile phone implementation, the SIM card is directly connected to the Modem. To access the SIM card, AT command (or proprietary commands) are needed, oFono implements both of them to access SIM card in Modem side, but in my understanding there is no possibilities to disconnect modem (in oFono) due to SIM SAP.
>
> In the case where SIM card is connected to the Application processor (Linux side), it's missing the SIM stack (APDU server...). I don't find any SIM implementation in Linux, may be we have to specify it.
>
Other than transferring APDUs, SAP profile also specifies operations on
the SIM cards like SIM Reset, SIM power on/off, Getting Card reader
status etc.
How do we do these operations case of mobile phones?
>
> Best Regards,
>
> Nicolas.
Regards
Suraj
Hello Marcel and Suraj,
-----Message d'origine-----
De=A0: [email protected] =
[mailto:[email protected]] De la part de Suraj =
Sumangala
Envoy=E9=A0: mercredi 15 septembre 2010 08:14
=C0=A0: Marcel Holtmann
Cc=A0: Suraj Sumangala; [email protected]; Jothikumar =
Mothilal
Objet=A0: Re: [RFC] BlueZ D-Bus Sim Access Profile Server API =
description
>Hi Marcel,
>
>On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
>> Hi Suraj,
>>
>>>
>>> I would really appreciate if you can give me any idea about working
>>> around the above mentioned issues.
>>
>> if we talk about the SAP server role found in a mobile phone, then =
that
>> support clearly needs to interact with the telephony stack. Since =
when
>> SAP is active the telephony stack needs to be suspended and all SIM
>> transaction being forwarded.
>>
>> Currently I would be thinking that the SAP implementation should be =
done
>> inside oFono actually. Since then you have direct access to the
>> hardware. The D-Bus approach just doesn't sound correct to me. I =
could
>> be of course wrong, but I can't wrap my mind around on how you can =
make
>> this work.
>>
>> Even with file descriptor passing this doesn't look like the right
>> approach. If we need a hardware abstraction than we either use oFono =
or
>> we have to create some SAP hardware access abstraction.
>
>The advantage I thought d-bus has would be the generic interface it=20
>could provide. But, if we have a system with direct access to the Sim=20
>access hardware, D-bus could possibly become a bottleneck.
>
>I would really appreciate if others who have worked with Sim Access and =
>OFono can give their comments.
>
>Also, please share some information on regarding the SIM reader=20
>implementation in linux based systems.
>
>>
>> The SAP client role found a carkit is obviously a different story.
>>
>> Regards
>>
>> Marcel
>>
>>
>Regards
>Suraj
I agree with Marcel, because in standard Mobile phone implementation, =
the SIM card is directly connected to the Modem. To access the SIM card, =
AT command (or proprietary commands) are needed, oFono implements both =
of them to access SIM card in Modem side, but in my understanding there =
is no possibilities to disconnect modem (in oFono) due to SIM SAP.
In the case where SIM card is connected to the Application processor =
(Linux side), it's missing the SIM stack (APDU server...). I don't find =
any SIM implementation in Linux, may be we have to specify it.=20
Best Regards,
Nicolas.
Hi Marcel,
On 9/15/2010 9:14 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>>
>> I would really appreciate if you can give me any idea about working
>> around the above mentioned issues.
>
> if we talk about the SAP server role found in a mobile phone, then that
> support clearly needs to interact with the telephony stack. Since when
> SAP is active the telephony stack needs to be suspended and all SIM
> transaction being forwarded.
>
> Currently I would be thinking that the SAP implementation should be done
> inside oFono actually. Since then you have direct access to the
> hardware. The D-Bus approach just doesn't sound correct to me. I could
> be of course wrong, but I can't wrap my mind around on how you can make
> this work.
>
> Even with file descriptor passing this doesn't look like the right
> approach. If we need a hardware abstraction than we either use oFono or
> we have to create some SAP hardware access abstraction.
The advantage I thought d-bus has would be the generic interface it
could provide. But, if we have a system with direct access to the Sim
access hardware, D-bus could possibly become a bottleneck.
I would really appreciate if others who have worked with Sim Access and
OFono can give their comments.
Also, please share some information on regarding the SIM reader
implementation in linux based systems.
>
> The SAP client role found a carkit is obviously a different story.
>
> Regards
>
> Marcel
>
>
Regards
Suraj
Hi Suraj,
> >> Below is the Sim Access Profile server role API discription.
> >> Please let me know your comments.
> >
> > my obvious question is why do we wanna do this over D-Bus and not
> > connect it directly to the hardware via a plugin?
>
> You meant creating something like a tty device and let the hardware
> connect directly to this?
>
> The initial plan was to use a D-Bus file descriptor and transfer the SAP
> packets to the agent over it.
>
> The problem was the SAP packet format is specified by the Bluetooth SAP
> spec. I could not relate it to any generic packet format ( Like HF, HS,
> DUN can be mapped to an AT parser).
>
> I am not sure if any existing card reader implementation could parse it
> to extract SIM card related data (APDU) without additional support for it.
>
> Another reason I thought about D-Bus was because, most of the SAP
> operations are Request/Response type like Reset, SimOn etc.
>
> It mapped better with a Method/Signal communication than packet transfer.
>
> Some of the card reader implementation I checked had proprietary packet
> format. So not sure how we could interface with them.
> >
> > Remember that SIM transaction are timing critical and just relaying them
> > over D-Bus doesn't sound the right approach right now. While of course
> > even bluetoothd can't guarantee and response time, it is clearly better
> > than over D-Bus.
> >
>
> I would really appreciate if you can give me any idea about working
> around the above mentioned issues.
if we talk about the SAP server role found in a mobile phone, then that
support clearly needs to interact with the telephony stack. Since when
SAP is active the telephony stack needs to be suspended and all SIM
transaction being forwarded.
Currently I would be thinking that the SAP implementation should be done
inside oFono actually. Since then you have direct access to the
hardware. The D-Bus approach just doesn't sound correct to me. I could
be of course wrong, but I can't wrap my mind around on how you can make
this work.
Even with file descriptor passing this doesn't look like the right
approach. If we need a hardware abstraction than we either use oFono or
we have to create some SAP hardware access abstraction.
The SAP client role found a carkit is obviously a different story.
Regards
Marcel
Hi Marcel,
On 9/14/2010 11:12 AM, Marcel Holtmann wrote:
> Hi Suraj,
>
>> Below is the Sim Access Profile server role API discription.
>> Please let me know your comments.
>
> my obvious question is why do we wanna do this over D-Bus and not
> connect it directly to the hardware via a plugin?
You meant creating something like a tty device and let the hardware
connect directly to this?
The initial plan was to use a D-Bus file descriptor and transfer the SAP
packets to the agent over it.
The problem was the SAP packet format is specified by the Bluetooth SAP
spec. I could not relate it to any generic packet format ( Like HF, HS,
DUN can be mapped to an AT parser).
I am not sure if any existing card reader implementation could parse it
to extract SIM card related data (APDU) without additional support for it.
Another reason I thought about D-Bus was because, most of the SAP
operations are Request/Response type like Reset, SimOn etc.
It mapped better with a Method/Signal communication than packet transfer.
Some of the card reader implementation I checked had proprietary packet
format. So not sure how we could interface with them.
>
> Remember that SIM transaction are timing critical and just relaying them
> over D-Bus doesn't sound the right approach right now. While of course
> even bluetoothd can't guarantee and response time, it is clearly better
> than over D-Bus.
>
I would really appreciate if you can give me any idea about working
around the above mentioned issues.
> Regards
>
> Marcel
>
>
Regards
Suraj
Hi Suraj,
> Below is the Sim Access Profile server role API discription.
> Please let me know your comments.
my obvious question is why do we wanna do this over D-Bus and not
connect it directly to the hardware via a plugin?
Remember that SIM transaction are timing critical and just relaying them
over D-Bus doesn't sound the right approach right now. While of course
even bluetoothd can't guarantee and response time, it is clearly better
than over D-Bus.
Regards
Marcel
Hi,
On 9/13/2010 10:17 PM, Johan Hedberg wrote:
> Why would you want to expose these extra SAP profile details to the
> Agent? The bluetoothd side should take care of all details like this
> whenever possible. The only relevant data that needs to be transmitted
> from the Agent to bluetoothd in this case is the ATR and bluetoothd can
> then proceed with creating a proper SAP response packet based on that.
>
>> How do we map the D-Bus error return to the ResultCode?
>
> You'd need to define some sort of mapping table yourself. The list of
> possible result codes is quite short (8 in SAP 1.1) so this shouldn't be
> too hard. E.g. "Error, card not accessible" (0x02) could map to the
> D-Bus error org.bluez.SapError.CardNotAccessible.
The idea was to return the ResultCode as a string from the agent and map
it to the corresponding code in the server.
If we can define error codes for each result, that would be fine.
>
> Johan
Regards
Suraj
Hi,
On Mon, Sep 13, 2010, Suraj Sumangala wrote:
> The "array{uint8}" is just the ATR response from the card reader. it
> is not a complete Bluetoth SAP response packet. We need to
> encapsulate ATR packet to form a Bluetooth SAP response packet. The
> packet will be roughly.
>
> |Response code|Param1|Param data ( ResultCode )|param2|param data (ATR)|
>
> The ResultCode will have to be mapped as 1 byte result code in the
> SAP response packet sent to the client.
Why would you want to expose these extra SAP profile details to the
Agent? The bluetoothd side should take care of all details like this
whenever possible. The only relevant data that needs to be transmitted
from the Agent to bluetoothd in this case is the ATR and bluetoothd can
then proceed with creating a proper SAP response packet based on that.
> How do we map the D-Bus error return to the ResultCode?
You'd need to define some sort of mapping table yourself. The list of
possible result codes is quite short (8 in SAP 1.1) so this shouldn't be
too hard. E.g. "Error, card not accessible" (0x02) could map to the
D-Bus error org.bluez.SapError.CardNotAccessible.
Johan
Hi Waldek,
On 9/13/2010 6:17 PM, [email protected] wrote:
> Hi Suraj,
>
>> The agent will be in a better position to take this decision
>> as it will be interfacing between actual card reader and SAP server.
>>
>> For example, if the agent is connected to an external card
>> reader and it has lost connection with the reader. It can ask
>> for an Immediate disconnection.
>
> What will happen when dbus connection will be lost? SAP server will start immediate disconnection. Right?
Yes,
>
>> If disconnection was triggered by a user action, it can decide
>> to call this API with Graceful as the parameter.
>
> What exactly do you mean "triggerd by a user" ? Does agent interact with the user somehow? In which way, any API for that?
Here we only specifies the interface required by the Agent using SAP
server. The agent implementation will depend on the actual system which
uses SAP server.
For example, if we have use ofono. The agent will be implemented as part
of ofono's implementation. This will be similar to the way Handsfree
Gateway is implemented.
>
>> One candidate would be when the MessageSize is changed.
>> Another one will be with the "SimStatus" property. It makes
>> sense to raise his signal after the server sends the STATUS
>> IND response successfully.
>>
>> But, it is a fact that most of the Properties are set by the
>> Agent itself. So agent will know that they have changed.
>
> Exactly.
>
> Thanks,
> /Waldek
Regards
Suraj
Hi,
On 9/13/2010 6:50 PM, Johan Hedberg wrote:
> Hi,
>
>> Should we have the method like,
>> struct RequestATR(string command, variant param)
>
> ATR doesn't take any parameters so it'd be just RequestATR()
>
>> where, struct = { string, array{uint8} )
Yep,
>
> What do you need the string for? Wouldn't an array{uint8} suffice? A
> D-Bus error return could be used when the ResultCode in the response
> indicates failure.
The "array{uint8}" is just the ATR response from the card reader. it is
not a complete Bluetoth SAP response packet. We need to encapsulate ATR
packet to form a Bluetooth SAP response packet. The packet will be roughly.
|Response code|Param1|Param data ( ResultCode )|param2|param data (ATR)|
The ResultCode will have to be mapped as 1 byte result code in the SAP
response packet sent to the client.
How do we map the D-Bus error return to the ResultCode?
>
> Johan
> --
> To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Regards
Suraj
Hi,
> Should we have the method like,
> struct RequestATR(string command, variant param)
ATR doesn't take any parameters so it'd be just RequestATR()
> where, struct = { string, array{uint8} )
What do you need the string for? Wouldn't an array{uint8} suffice? A
D-Bus error return could be used when the ResultCode in the response
indicates failure.
Johan
Hi Suraj,
>The agent will be in a better position to take this decision
>as it will be interfacing between actual card reader and SAP server.
>
>For example, if the agent is connected to an external card
>reader and it has lost connection with the reader. It can ask
>for an Immediate disconnection.
What will happen when dbus connection will be lost? SAP server will start immediate disconnection. Right?
>If disconnection was triggered by a user action, it can decide
>to call this API with Graceful as the parameter.
What exactly do you mean "triggerd by a user" ? Does agent interact with the user somehow? In which way, any API for that?
>One candidate would be when the MessageSize is changed.
>Another one will be with the "SimStatus" property. It makes
>sense to raise his signal after the server sends the STATUS
>IND response successfully.
>
>But, it is a fact that most of the Properties are set by the
>Agent itself. So agent will know that they have changed.
Exactly.
Thanks,
/Waldek
Hi Waldek,
On 9/13/2010 5:41 PM, [email protected] wrote:
> Hi Suraj,
>
>> + void Disconnect(string type)
>> +
>> + This initiates a SAP disconnection from
>> SAP server.
>> +
>> + The type parameter specifies the type
>> of disconnection.
>> +
>> + "Graceful" -> lets the SAP client initiate a
>> + garceful disconnection.
>> +
>> + "Immediate" -> disconnects the connection
>> + immediately from the server.
>
> How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?
The agent will be in a better position to take this decision as it will
be interfacing between actual card reader and SAP server.
For example, if the agent is connected to an external card reader and
it has lost connection with the reader. It can ask for an Immediate
disconnection.
If disconnection was triggered by a user action, it can decide to call
this API with Graceful as the parameter.
>
>> +Signals PropertyChanged(string name, variant value)
>> +
>> + This signal indicates a changed value
>> of the given
>> + property.
>
> Is the signal really needed? Who is interested in keeping track on properties?
One candidate would be when the MessageSize is changed.
Another one will be with the "SimStatus" property. It makes sense to
raise his signal after the server sends the STATUS IND response
successfully.
But, it is a fact that most of the Properties are set by the Agent
itself. So agent will know that they have changed.
>
> Thanks,
> /Waldek
Regards
Suraj
Hi Suraj,
>+ void Disconnect(string type)
>+
>+ This initiates a SAP disconnection from
>SAP server.
>+
>+ The type parameter specifies the type
>of disconnection.
>+
>+ "Graceful" -> lets the SAP client initiate a
>+ garceful disconnection.
>+
>+ "Immediate" -> disconnects the connection
>+ immediately from the server.
How agent will use this method? I mean when it is supposed to use gracefull and when immediate disconnection?
>+Signals PropertyChanged(string name, variant value)
>+
>+ This signal indicates a changed value
>of the given
>+ property.
Is the signal really needed? Who is interested in keeping track on properties?
Thanks,
/Waldek
Hi Johan,
On 9/13/2010 4:29 PM, Johan Hedberg wrote:
> Hi Suraj,
>
> On Mon, Sep 13, 2010, Suraj Sumangala wrote:
>> + void Response(string command, string result, object response)
>
> This method should be removed. Instead, you should use the methor return
> messages for the commands to relay the response information.
Ok,
Should we have the method like,
struct RequestATR(string command, variant param)
where, struct = { string, array{uint8} )
>
>> +Sim Access Server Agent hierarchy
>> +=================================
>> +
>> +Service unique name
>> +Interface org.bluez.SAPServerAgent
>> +Object path freely definable
>> +
>> +Methods Request(string command, object param)
>
> Since the set of SAP commands is fixed and rather short it'd be much
> simpler if you have a separate D-Bus method for each command
> (particularly from the method and method return signature perspective).
> You also seem to have some confusion about what an "object" type
> parameter is. It seems you're using it for some sort of variant type
> when it will only ever represent a simple object path.
Thanks, My mistake. I was referring to a variant type there.
>
> Johan
Regards
Suraj
Hi Suraj,
On Mon, Sep 13, 2010, Suraj Sumangala wrote:
> + void Response(string command, string result, object response)
This method should be removed. Instead, you should use the methor return
messages for the commands to relay the response information.
> +Sim Access Server Agent hierarchy
> +=================================
> +
> +Service unique name
> +Interface org.bluez.SAPServerAgent
> +Object path freely definable
> +
> +Methods Request(string command, object param)
Since the set of SAP commands is fixed and rather short it'd be much
simpler if you have a separate D-Bus method for each command
(particularly from the method and method return signature perspective).
You also seem to have some confusion about what an "object" type
parameter is. It seems you're using it for some sort of variant type
when it will only ever represent a simple object path.
Johan