Clarification on USSD support in ofono

Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1535 bytes --]


Hi,

  Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver -
AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and
sends it to the network. In this way, we will always send the data
coding scheme as GSM 7-bit default alphabet or whatever the character
set modem is configured. Why are we not sending the USSD string with
DCS(Data coding scheme) as is to the network? There are USIM conformance
test cases which expects the DCS(Data coding scheme) and USSD string
sent as it is to the network. Also, as per the 3GPP TS 24.090, DCS and
USSD string are sent as part of UnstructuredSS-Request to the network
and MT is not expected to interpret the string. But ,here oFono doesn't
have the interface to accept DCS(Data coding scheme) and also it expects
the USSD string to be in UTF-8. 
 
Thanks and Regards,
jeevaka



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.


[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 2222 bytes --]

Re: Clarification on USSD support in ofono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 1753 bytes --]

Hi Jeevaka,

>   Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
> - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet
> and sends it to the network. In this way, we will always send the data
> coding scheme as GSM 7-bit default alphabet or whatever the character
> set modem is configured. Why are we not sending the USSD string with
> DCS(Data coding scheme) as is to the network? There are USIM
> conformance test cases which expects the DCS(Data coding scheme) and
> USSD string sent as it is to the network. Also, as per the 3GPP TS
> 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request
> to the network and MT is not expected to interpret the string.
> But ,here oFono doesn't have the interface to accept DCS(Data coding
> scheme) and also it expects the USSD string to be in UTF-8. 

the one main design goal behind oFono's D-Bus APIs is to make them
useful for users. This means that the main input data type are strings
and they are UTF-8.

If you need magic binary APIs that are only used by specific application
or even purely for conformance testing, then you need to propose an
interface for these. By default we will not make application to any kind
of conversation.

Every single nasty conversion that has to be done by every single
application using such an interface is wrong. Complexity belongs into
oFono and not the application. The idea of just pushing complex tasks up
into the application so that oFono doesn't have to deal with it is a
really bad idea. Remember that one main goal of oFono is to make the
usage of standard telephony functionality as easy as possible when you
are developing telephony applications.

Regards

Marcel

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 3955 bytes --]

 
Hi Marcel,

>   Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
> - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet 
> and sends it to the network. In this way, we will always send the data

> coding scheme as GSM 7-bit default alphabet or whatever the character 
> set modem is configured. Why are we not sending the USSD string with 
> DCS(Data coding scheme) as is to the network? There are USIM 
> conformance test cases which expects the DCS(Data coding scheme) and 
> USSD string sent as it is to the network. Also, as per the 3GPP TS 
> 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request

> to the network and MT is not expected to interpret the string.
> But ,here oFono doesn't have the interface to accept DCS(Data coding
> scheme) and also it expects the USSD string to be in UTF-8. 

> the one main design goal behind oFono's D-Bus APIs is to make them
useful for users. This means that the main input data type are strings
and they are UTF-8.

> If you need magic binary APIs that are only used by specific
application or even purely for conformance testing, then you need to
propose an interface for these. By default we will not make application
> to any kind of conversation.

> Every single nasty conversion that has to be done by every single
application using such an interface is wrong. Complexity belongs into
oFono and not the application. The idea of just pushing complex 
> tasks up into the application so that oFono doesn't have to deal with
it is a really bad idea. Remember that one main goal of oFono is to make
the usage of standard telephony functionality as easy as
> possible when you are developing telephony applications.


I'm not proposing any changes to the dbus interface and I completely
understand that its a very bad idea to push the conversions to the
application side. USAT conformance specification expects that the
information sent by the application toolkit to be sent as it is to the
network. Conformance test setup is such that if the data received at the
network doesn't match with the data sent by the application toolkit then
the conformance test case is considered to be a failure case.

When a Send USSD proactive command is received, STK atom sends an
internal request to the USSD atom to send the string along with the DCS
supplied. So, for sending the USSD string and dcs received from the
proactive command, support needs to be added to the USSD driver
interface. 
 
What I meant was to provide a driver API which will take both the dcs
and string as parameter. something like the following:

enum ofono_dcs{
	OFONO_DCS_UNKNOWN, 
	OFONO_DCS_GSM_7BIT,
	OFONO_DCS_8BIT,
	OFONO_DCS_UCS2,
};

void (*request)(struct ofono_ussd *ussd, int dcs, const char *str,
			ofono_ussd_cb_t, void *data);

If the dcs is set to OFONO_DCS_UNKNOWN, then the conversion from UTF-8
to GSM 7 bit default alphabet needs to be done. Anything other than
OFONO_DCS_UNKNOWN, modem driver doesn't need to do any conversion and
sends the dcs and string as it is to the network. 

Regards,
jeevaka

_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: Clarification on USSD support in ofono

[Pekka Pessi]

[-- Attachment #1: Type: text/plain, Size: 1100 bytes --]

Hi Jeevaka,

2010/8/31  <Jeevaka.Badrappan@elektrobit.com>:
> What I meant was to provide a driver API which will take both the dcs
> and string as parameter. something like the following:
>
> enum ofono_dcs{
>        OFONO_DCS_UNKNOWN,
>        OFONO_DCS_GSM_7BIT,
>        OFONO_DCS_8BIT,
>        OFONO_DCS_UCS2,
> };
>
> void (*request)(struct ofono_ussd *ussd, int dcs, const char *str,
>                        ofono_ussd_cb_t, void *data);
>
> If the dcs is set to OFONO_DCS_UNKNOWN, then the conversion from UTF-8
> to GSM 7 bit default alphabet needs to be done. Anything other than
> OFONO_DCS_UNKNOWN, modem driver doesn't need to do any conversion and
> sends the dcs and string as it is to the network.

Would it always make sense to do the conversion of the USSD string in
the core, not in the modem driver? So the API would be something like

 void (*request)(struct ofono_ussd *ussd, int dcs, void const *data,
size_t len,
                        ofono_ussd_cb_t, void *data);


-- 
Pekka.Pessi mail at nokia.com

Re: Clarification on USSD support in ofono

[Andrzej Zaborowski]

[-- Attachment #1: Type: text/plain, Size: 2452 bytes --]

Hi,

On 31 August 2010 15:59,  <Jeevaka.Badrappan@elektrobit.com> wrote:
>> If you need magic binary APIs that are only used by specific
> application or even purely for conformance testing, then you need to
> propose an interface for these. By default we will not make application
>> to any kind of conversation.
>
>> Every single nasty conversion that has to be done by every single
> application using such an interface is wrong. Complexity belongs into
> oFono and not the application. The idea of just pushing complex
>> tasks up into the application so that oFono doesn't have to deal with
> it is a really bad idea. Remember that one main goal of oFono is to make
> the usage of standard telephony functionality as easy as
>> possible when you are developing telephony applications.
>
>
> I'm not proposing any changes to the dbus interface and I completely
> understand that its a very bad idea to push the conversions to the
> application side. USAT conformance specification expects that the
> information sent by the application toolkit to be sent as it is to the
> network. Conformance test setup is such that if the data received at the
> network doesn't match with the data sent by the application toolkit then
> the conformance test case is considered to be a failure case.
>
> When a Send USSD proactive command is received, STK atom sends an
> internal request to the USSD atom to send the string along with the DCS
> supplied. So, for sending the USSD string and dcs received from the
> proactive command, support needs to be added to the USSD driver
> interface.
>
> What I meant was to provide a driver API which will take both the dcs
> and string as parameter. something like the following:

Yes, the driver api may need a change like this.  The current API was
created based on the fact that many modems don't understand anything
other than DCS = 15.  However with STK's "Send USSD" command, sending
the requested DCS as-is is probably our best bet.

There is a hope that most modems implement Send USSD in their firmware
so that ofono doesn't have to do anything (this is the case on the
Texas Instruments Calypso modem), do you have a modem that you know
does not handle Send USSD internally?  Of course it makes sense to
implement the fallback in ofono anyway.

Have you been working on implementation of this command? I'm asking to
avoid duplicating the effort.

Best regards

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1757 bytes --]

Hi,
 
> Yes, the driver api may need a change like this.  The current API was
created based on the fact that many modems don't understand anything
other than DCS = 15.  However 
> with STK's "Send USSD" command, sending the requested DCS as-is is
probably our best bet.

> There is a hope that most modems implement Send USSD in their firmware
so that ofono doesn't have to do anything (this is the case on the Texas
Instruments Calypso modem), > do you have a modem that you know does not
handle Send USSD internally?  Of course it makes sense to implement the
fallback in ofono anyway.

> Have you been working on implementation of this command? I'm asking to
avoid duplicating the effort.

No, I dont have any modem which doesn't handle the Send USSD command
internally. 

Yes, I have done some implementation. Planning to test it with the
phonesim. If needed, I can do the implementation of the Send USSD
command.

Regards,
jeevaka
_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: Clarification on USSD support in ofono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1283 bytes --]

Hi Jeevaka,

On 08/31/2010 10:39 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> Hi,
>  
>> Yes, the driver api may need a change like this.  The current API was
> created based on the fact that many modems don't understand anything
> other than DCS = 15.  However 
>> with STK's "Send USSD" command, sending the requested DCS as-is is
> probably our best bet.
> 
>> There is a hope that most modems implement Send USSD in their firmware
> so that ofono doesn't have to do anything (this is the case on the Texas
> Instruments Calypso modem), > do you have a modem that you know does not
> handle Send USSD internally?  Of course it makes sense to implement the
> fallback in ofono anyway.
> 
>> Have you been working on implementation of this command? I'm asking to
> avoid duplicating the effort.
> 
> No, I dont have any modem which doesn't handle the Send USSD command
> internally. 
> 
> Yes, I have done some implementation. Planning to test it with the
> phonesim. If needed, I can do the implementation of the Send USSD
> command.

Can you send what you have so far to the list?  Andrew and Yang are
actually already looking into this, so it might be nice for the three of
you to be on the same page and not duplicate effort.

Thanks,
-Denis

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 955 bytes --]

 
Hi,

> Can you send what you have so far to the list?  Andrew and Yang are
actually already looking into this, so it might be nice for the three of
you to be on the same page and > not duplicate effort.

Ok, I'll try to send the patch by today.

Thanks and Regards,
Jeevaka


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1097 bytes --]

 
Hi Denis,

> Can you send what you have so far to the list?  Andrew and Yang are
actually already looking into this, so it might be nice for the three of
you to be on the same page and not duplicate effort.

I'm sending the patches for the Send USSD proactive command handling. I
have tested the changes with the modified phonesim. Let me know if you
need the modified phonesim files.

Thanks and Regards,
Jeevaka


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

RE: Clarification on USSD support in ofono

[Marcel Holtmann]

[-- Attachment #1: Type: text/plain, Size: 2949 bytes --]

Hi Jeevaka,

> >   Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver
> > - AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet 
> > and sends it to the network. In this way, we will always send the data
> 
> > coding scheme as GSM 7-bit default alphabet or whatever the character 
> > set modem is configured. Why are we not sending the USSD string with 
> > DCS(Data coding scheme) as is to the network? There are USIM 
> > conformance test cases which expects the DCS(Data coding scheme) and 
> > USSD string sent as it is to the network. Also, as per the 3GPP TS 
> > 24.090, DCS and USSD string are sent as part of UnstructuredSS-Request
> 
> > to the network and MT is not expected to interpret the string.
> > But ,here oFono doesn't have the interface to accept DCS(Data coding
> > scheme) and also it expects the USSD string to be in UTF-8. 
> 
> > the one main design goal behind oFono's D-Bus APIs is to make them
> useful for users. This means that the main input data type are strings
> and they are UTF-8.
> 
> > If you need magic binary APIs that are only used by specific
> application or even purely for conformance testing, then you need to
> propose an interface for these. By default we will not make application
> > to any kind of conversation.
> 
> > Every single nasty conversion that has to be done by every single
> application using such an interface is wrong. Complexity belongs into
> oFono and not the application. The idea of just pushing complex 
> > tasks up into the application so that oFono doesn't have to deal with
> it is a really bad idea. Remember that one main goal of oFono is to make
> the usage of standard telephony functionality as easy as
> > possible when you are developing telephony applications.
> 
> 
> I'm not proposing any changes to the dbus interface and I completely
> understand that its a very bad idea to push the conversions to the
> application side. USAT conformance specification expects that the
> information sent by the application toolkit to be sent as it is to the
> network. Conformance test setup is such that if the data received at the
> network doesn't match with the data sent by the application toolkit then
> the conformance test case is considered to be a failure case.
> 
> When a Send USSD proactive command is received, STK atom sends an
> internal request to the USSD atom to send the string along with the DCS
> supplied. So, for sending the USSD string and dcs received from the
> proactive command, support needs to be added to the USSD driver
> interface. 

you have me confused now. Are you talking about the D-Bus based API
towards applications or the SIM Toolkit support?

SIM Toolkit is something totally different. Even for SMS we just deal
with raw PDUs there. While the user side applications over D-Bus will
never get access to the raw PDUs.

Regards

Marcel

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1342 bytes --]

 
Hi Marcel

> you have me confused now. Are you talking about the D-Bus based API
towards applications or the SIM Toolkit support?

> SIM Toolkit is something totally different. Even for SMS we just deal
with raw PDUs there. While the user side applications over D-Bus will
never get access to the raw
> PDUs.

I think I was not clear in my first mail:-). I'm talking about the
driver API( Modifications to the ofono_ussd_driver:request). No changes
to the D-Bus interface based API towards applications.

Regards,
jeevaka



_______________________________________________
ofono mailing list
ofono(a)ofono.org
http://lists.ofono.org/listinfo/ofono


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: Clarification on USSD support in ofono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1527 bytes --]

Hi Jeevaka,

On 08/31/2010 03:58 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> 
> Hi,
> 
>   Currently, oFono expects the USSD string in UTF-8. ofono(Atom driver -
> AT or ISI) converts the UTF-8 string to GSM 7-bit default alphabet and
> sends it to the network. In this way, we will always send the data
> coding scheme as GSM 7-bit default alphabet or whatever the character
> set modem is configured. Why are we not sending the USSD string with
> DCS(Data coding scheme) as is to the network? There are USIM conformance
> test cases which expects the DCS(Data coding scheme) and USSD string
> sent as it is to the network. Also, as per the 3GPP TS 24.090, DCS and
> USSD string are sent as part of UnstructuredSS-Request to the network
> and MT is not expected to interpret the string. But ,here oFono doesn't
> have the interface to accept DCS(Data coding scheme) and also it expects
> the USSD string to be in UTF-8.
> 

The original USSD API actually did look like this.  It used binary data
+ dcs field.  However, we quickly found that all modems are screwed up
in this area.  The specification added binary PDU mode to SMS and CBS,
but never bothered with USSD.  So all modems get this part wrong.

Currently about the best we can do is pass UTF8 around.  If you have a
modem that gets this part right, we'd like to hear about it.  If the
Send USSD proactive command is not handled by the modem, then oFono will
try to do its best.  However, we make no guarantees ;)

Regards,
-Denis

RE: Clarification on USSD support in ofono

[Jeevaka.Badrappan]

[-- Attachment #1: Type: text/plain, Size: 1545 bytes --]


Hi Denis,
 
> The original USSD API actually did look like this.  It used binary
data
> + dcs field.  However, we quickly found that all modems are screwed up
> in this area.  The specification added binary PDU mode to SMS and CBS,
but never bothered with USSD.  So all modems get this part wrong.

> Currently about the best we can do is pass UTF8 around.  If you have a
modem that gets this part right, we'd like to hear about it.  If the
Send USSD proactive command is 
> not handled by the modem, then oFono will try to do its best.
However, we make no guarantees ;)

I think its better to send the dcs and the binary data to the atom
driver. If the modem doesn't support other than GSM 7-bit alphabet, then
the conversion can be done in the atom driver. This way it will be
general to any modem.

Let me know your views on this.

Regards,
jeevaka


----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.



----------------------------------------------------------------
Please note: This e-mail may contain confidential information
intended solely for the addressee. If you have received this
e-mail in error, please do not disclose it to anyone, notify
the sender promptly, and delete the message from your system.
Thank you.

Re: Clarification on USSD support in ofono

[Denis Kenzior]

[-- Attachment #1: Type: text/plain, Size: 1511 bytes --]

Hi Jeevaka,

On 08/31/2010 10:48 AM, Jeevaka.Badrappan(a)elektrobit.com wrote:
> 
> Hi Denis,
>  
>> The original USSD API actually did look like this.  It used binary
> data
>> + dcs field.  However, we quickly found that all modems are screwed up
>> in this area.  The specification added binary PDU mode to SMS and CBS,
> but never bothered with USSD.  So all modems get this part wrong.
> 
>> Currently about the best we can do is pass UTF8 around.  If you have a
> modem that gets this part right, we'd like to hear about it.  If the
> Send USSD proactive command is 
>> not handled by the modem, then oFono will try to do its best.
> However, we make no guarantees ;)
> 
> I think its better to send the dcs and the binary data to the atom
> driver. If the modem doesn't support other than GSM 7-bit alphabet, then
> the conversion can be done in the atom driver. This way it will be
> general to any modem.

The send part is not really the problem, and can be easily done as pdu +
dcs.  However, it is the reception that is screwed up.  By convention,
all APIs in oFono must be symmetric.  E.g. what the driver sends it must
also accept.

According to 27.007, +CUSD is converted into the current character set
used by CSCS.  It is not a binary PDU at all.  So the driver now has to
fake this information...

Go ahead and send your suggested approach as a patch to this mailing
list and we can continue from there.  Just remember the symmetry part ;)

Regards,
-Denis