12:16 a.m.
Hi,
The following patch "Added missing DCS handling in stkutil and stk"
handles the missing dcs case as:
As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs
and text string to be sent. Current stkutil function and data structure
is missing the dcs information.
In this patch, we handle the case where dcs will be a value other than
-1, yesno and packed values are false. This text string structure is
used in Terminal response of Get Inkey, Get Input and Send USSD.
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.
10:57 a.m.
Hi Jeevaka,
On 2 September 2010 16:16, <Jeevaka.Badrappan(a)elektrobit.com> wrote:
The following patch "Added missing DCS handling in stkutil and
stk"
handles the missing dcs case as:
As per 3GPP TS 31.111 section 8.15 Text string structure requires dcs
and text string to be sent. Current stkutil function and data structure
is missing the dcs information.
In this patch, we handle the case where dcs will be a value other than
-1, yesno and packed values are false. This text string structure is
used in Terminal response of Get Inkey, Get Input and Send USSD.
There are two cases:
* Get Inkey/Get Input, where the answer is actual text, in this case
the dcs can be determined automatically,
* Send USSD where we're sending the "8.15 Text string" but the
contents don't actually have to contain a string, it may be any data
that the network sends us. So to me it makes more sense to handle
this using a separate structure like you did in your original patch,
which contains len, dcs and contents.
Best regards
11:59 a.m.
Hi Andrzej,
There are two cases:
* Get Inkey/Get Input, where the answer is actual text, in this case
the dcs can be determined automatically,
* Send USSD where we're sending the "8.15 Text string" but the
contents don't actually have to contain a string, it may be any data
that the network sends us. So to me it makes more sense to handle
this using a separate structure like you did in your original patch,
which contains len, dcs and contents.
Yes, I undestand for the Get Inkey/Get Input, dcs is determined
automatically. Currently, we are providing one function for building
each data object specificed in 3GPP specification. If we provide a new
structure, then we need to provide a new function for building the
text string data object. This will result in having 2
build_dataobj_text( existing one for handling Get Inkey and Get Input)
and build_dataobj_ussdtext(new one for handling the section 8.15),
which is deviating from the existing ones. If we extend the existing
structure and add generalised handling which is done now in this
patch, we won't be deviating from the existing things.
Regards,
jeevaka
7:10 a.m.
Hi Jeevaka,
On 09/02/2010 08:59 PM, Jeevaka Prabu Badrappan wrote:
Hi Andrzej,
> There are two cases:
> * Get Inkey/Get Input, where the answer is actual text, in this case
> the dcs can be determined automatically,
>
> * Send USSD where we're sending the "8.15 Text string" but the
> contents don't actually have to contain a string, it may be any data
> that the network sends us. So to me it makes more sense to handle
> this using a separate structure like you did in your original patch,
> which contains len, dcs and contents.
Yes, I undestand for the Get Inkey/Get Input, dcs is determined
automatically. Currently, we are providing one function for building
each data object specificed in 3GPP specification. If we provide a new
structure, then we need to provide a new function for building the
text string data object. This will result in having 2
build_dataobj_text( existing one for handling Get Inkey and Get Input)
and build_dataobj_ussdtext(new one for handling the section 8.15),
I agree with Andrew completely here.
In effect your modifications to build_dataobj_text are doing this
anyway. You're also forcing the Display Text, Get Input, Get Inkey, etc
objects to care about details of USSD, which they really shouldn't. The
code will be much simpler to follow if we use a different structure for
this particular case.
which is deviating from the existing ones. If we extend the existing
structure and add generalised handling which is done now in this
patch, we won't be deviating from the existing things.
Actually the spec is deviating from the intended purpose of the Text
data object (which should contain Text), so handling it specifically is
actually better.
Regards,
-Denis
7:34 p.m.
Hi Denis, Andrzej,
Actually the spec is deviating from the intended purpose of the Text
data object (which
should contain Text), so handling it specifically is actually better.
I have incorported the comments as part of the Patch "stk and stkutil
changes for Send USSD proactive command". As per your comments, I have
also grouped the "Send USSD" proactive command into 2
compilable patches "[PATCH 1/2] Internal and Driver API changes for Send
USSD proactive command" and "[PATCH 2/2] stk and stkutil changes for
Send USSD proactive command."
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.
4395
days inactive
4399
days old
4 comments
4 participants
participants (4)
-
andrzej zaborowski -
Denis Kenzior -
Jeevaka Prabu Badrappan -
Jeevaka.Badrappan＠elektrobit.com