RE: Clarification on USSD support in ofono
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 10:39 AM, jeevaka.badrap...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 10:48 AM, jeevaka.badrap...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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@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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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@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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka, On 08/31/2010 03:58 AM, jeevaka.badrap...@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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi, On 31 August 2010 15:59, 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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
Hi Jeevaka,
2010/8/31 :
> 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
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
RE: Clarification on USSD support in ofono
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@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.
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: Clarification on USSD support in ofono
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 ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Clarification on USSD support in ofono
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. ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
