9 p.m.
Hello,
I have been trying out and going through the code concerning Call Forwarding and I found
out that if you enable for example CF VoiceBusy and then CF VoiceUnconditional, the
VoiceBusy is still according to ofono enabled. This of course as such isn't so bad but
by using org.ofono.SupplementaryServices to query the CF states ofono gives different
response i.e. now only the VoiceUnconditional is enabled and then I can disable only the
VoiceUnconditional by using the org.ofono.SupplementaryServices and when doing so I found
out that now ofono thinks that no CF is enabled even though VoiceBusy is actually active.
Now to fix this there exists multiple solutions I believe, here's some that I came
up.
1:Ofono could send query to modem/network for all the CF values when ever voice
unconditional value is changed. The good side in this is that ofono would definetly be up
to date.
2:Have separate status value internally and change that accordingly. E.g<property>
<number to> <status> and return<number to> to client
when<status> == 1. Change any conditional<status> to 0 if
unconditional<status> == 1 without touching the<number to> field and when
unconditional<status> is changed to 0 change all conditional<status> to 1 if
respecting<number to> exists. This would of course be much faster however I'm
not sure how tedious this would be to implement.
3:Whenever unconditional value is changed, empty the internal "CF cache" i.e.
remove all the conditional values all together or set "cache flag" to 0 and thus
forcing the query to be made to modem/network.This should be as good as option 1 except
the queries are made only when client needs it. Although the assumption is that client
queries the properties after changing them(otherwise the client remains in wrong state).
So depending on how the client's been implemented might result on system level to same
behavior as option 1.
As I said these are what quickly came to my mind so there might be other solutions as
well. So the reason for this posting is to raise discussion on what would be the correct
way to fix this?
-Jarko-
2:16 a.m.
Hi Jarko,
On 01/11/2011 04:00 AM, Jarko Poutiainen wrote:
Hello,
I have been trying out and going through the code concerning Call
Forwarding and I found out that if you enable for example CF VoiceBusy
and then CF VoiceUnconditional, the VoiceBusy is still according to
ofono enabled. This of course as such isn't so bad but by using
org.ofono.SupplementaryServices to query the CF states ofono gives
different response i.e. now only the VoiceUnconditional is enabled and
then I can disable only the VoiceUnconditional by using the
org.ofono.SupplementaryServices and when doing so I found out that now
ofono thinks that no CF is enabled even though VoiceBusy is actually
active.
So quickly looking at 22.082, for example 1.6.82.2:
"If Call forwarding on mobile subscriber busy is active, activation of
Call forwarding unconditional will be accepted. Call forwarding on
mobile subscriber busy will be quiescent during the active period of
Call forwarding unconditional. If Call forwarding unconditional is
subsequently deactivated, Call forwarding on mobile subscriber busy
becomes operative again (unless the interaction with another
supplementary service requests that it remains quiescent)."
To me it sounds like oFono is doing exactly the right thing. Are you
sure your modem is behaving properly?
Regards,
-Denis
12:20 a.m.
Hi Denis,
On 01/11/2011 05:16 PM, Denis Kenzior wrote:
Hi Jarko,
So quickly looking at 22.082, for example 1.6.82.2:
"If Call forwarding on mobile subscriber busy is active, activation of
Call forwarding unconditional will be accepted. Call forwarding on
mobile subscriber busy will be quiescent during the active period of
Call forwarding unconditional. If Call forwarding unconditional is
subsequently deactivated, Call forwarding on mobile subscriber busy
becomes operative again (unless the interaction with another
supplementary service requests that it remains quiescent)."
To me it sounds like oFono is doing exactly the right thing. Are you
sure your modem is behaving properly?
Regards,
-Denis
It seems that I explained this poorly. So modem is behaving as you
quoted but ofono is not. I can for example get ofono in a state where
ofono replies that no CF is active even though one of them is.
e.g. when I do following:
./list-modems
./test-ussd '**61*+358401234567*11#'
./list-modems
./test-ussd '**21*+358401234567*11#'
./list-modems
Now ofono claims that both are active
./test-ussd '*#002#'
./list-modems
Now ofono correctly states that only VoiceUnconditional is active
./test-ussd '##21#'
./list-modems
Now ofono claims that no call forwarding is set active when VoiceNoReply
in fact is.
./test-ussd '*#002#'
./list-modems
Now ofono correctly states that VoiceNoReply is active
Does this make this any clearer?
-Jarko-
2:59 a.m.
Hi Jarko,
On 01/14/2011 07:20 AM, Jarko Poutiainen wrote:
Hi Denis,
On 01/11/2011 05:16 PM, Denis Kenzior wrote:
> Hi Jarko,
>
> So quickly looking at 22.082, for example 1.6.82.2:
>
> "If Call forwarding on mobile subscriber busy is active, activation of
> Call forwarding unconditional will be accepted. Call forwarding on
> mobile subscriber busy will be quiescent during the active period of
> Call forwarding unconditional. If Call forwarding unconditional is
> subsequently deactivated, Call forwarding on mobile subscriber busy
> becomes operative again (unless the interaction with another
> supplementary service requests that it remains quiescent)."
>
> To me it sounds like oFono is doing exactly the right thing. Are you
> sure your modem is behaving properly?
>
> Regards,
> -Denis
It seems that I explained this poorly. So modem is behaving as you
quoted but ofono is not. I can for example get ofono in a state where
ofono replies that no CF is active even though one of them is.
e.g. when I do following:
./list-modems
./test-ussd '**61*+358401234567*11#'
./list-modems
./test-ussd '**21*+358401234567*11#'
./list-modems
Now ofono claims that both are active
./test-ussd '*#002#'
./list-modems
Now ofono correctly states that only VoiceUnconditional is active
Both are active and the modem should be reporting both. At least that
is how I understood the specifications.
./test-ussd '##21#'
./list-modems
Now ofono claims that no call forwarding is set active when VoiceNoReply
in fact is.
./test-ussd '*#002#'
./list-modems
Now ofono correctly states that VoiceNoReply is active
Does this make this any clearer?
A bit, but having the AT command logs would help greatly.
Regards,
-Denis
11:21 p.m.
Hi Denis,
On Fri, 2011-01-14 at 17:59 +0200, Denis Kenzior wrote:
Hi Jarko,
Both are active and the modem should be reporting both. At least that
is how I understood the specifications.
Well that is a bit debatable. As 27.007 states:
command:
+CCFC=<reason>,<mode>[,<number>[,<type>[,<class>[,<subaddr>[,<satype>[,<time>]]]]]]
<reason>: integer type
0 unconditional
1 mobile busy
2 no reply
3 not reachable
4 all call forwarding (refer 3GPP TS 22.030 [19])
5 all conditional call forwarding (refer 3GPP TS 22.030 [19])
<mode>: integer type
0 disable
1 enable
2 query status
3 registration
4 erasure
response when<mode>=2 and command successfull:
+CCFC:<status>,<class1>[,<number>,<type>[,<subaddr>,<satype>[,<time>]]][<CR><LF>+CCFC:
<status>,<class2>[,<number>,<type>[,<subaddr>,<satype>[,<time>]]][...]]
<status>: integer type
0 not active
1 active
So actually they aren't both "active" at same time as the logs show but
personally I don't really care as long as the results are consistent
regardless which API you use which is not the case at the moment as
querying through org.ofono.CallForwarding can give you different result
than using org.ofono.SupplementaryServices.
A bit, but having the AT command logs would help greatly.
Well hopefully these will help. I have numbered each step and copied
corresponding logs after it. list-modems doesn't cause AT queries to
modem(except on a very first time which I have already done) so I have
copied what it prints regarding CF. It's a bit long though so sorry
about that.
#1: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 0
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply =
VoiceUnconditional =
#2: ./test-ussd '**61*+358401234567*11#'
ofonod[30925]: Default: > AT+CCFC=2,3,"358401234567",145,1,,,20\r
ofonod[30925]: Default: < \r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=2,2\r
ofonod[30925]: Default: < \r\n+CCFC:
1,1,"0401234567",129,"",,20\r\n\r
\nOK\r\n
#3: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 0
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply = 0401234567
VoiceUnconditional =
#4: ./test-ussd '**21*+358401234567*11#'
ofonod[30925]: Default: > AT+CCFC=0,3,"358401234567",145,1\r
ofonod[30925]: Default: < \r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=0,2\r
ofonod[30925]: Default: < \r\n+CCFC: 1,1,"0401234567",129\r\n\r\nOK\r\n
#5: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 1
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply = 0401234567
VoiceUnconditional = 0401234567
#6: ./test-ussd '*#002#'
ofonod[30925]: Default: > AT+CCFC=0,2\r
ofonod[30925]: Default: < \r\n+CCFC: 1,1,"0401234567",129\r\n\r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=1,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n+CCFC: 0,4\r\n+CCFC: 0,16\r
\n
ofonod[30925]: Default: < +CCFC: 0,32\r\n+CCFC: 0,64\r\n
ofonod[30925]: Default: < +CCFC: 0,128\r\n\r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=2,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n+CCFC: 0,4\r\n
ofonod[30925]: Default: < +CCFC: 0,16\r\n+CCFC: 0,32\r\n
ofonod[30925]: Default: < +CCFC: 0,64\r\n+CCFC: 0,128\r\n
ofonod[30925]: Default: < \r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=3,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n+CCFC: 0,4\r\n
ofonod[30925]: Default: < +CCFC: 0,16\r\n+CCFC: 0,32\r\n+CCFC: 0,64\r\n
ofonod[30925]: Default: < +CCFC: 0,128\r\n\r\nOK\r\n
#7: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 1
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply =
VoiceUnconditional = 0401234567
#8: ./test-ussd '##21#'
ofonod[30925]: Default: > AT+CCFC=0,4\r
ofonod[30925]: Default: < \r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=0,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n
ofonod[30925]: Default: < +CCFC: 0,4\r\n+CCFC: 0,16\r\n+CCFC: 0,32\r\n
ofonod[30925]: Default: < +CCFC: 0,64\r\n+CCFC: 0,128\r\n
ofonod[30925]: Default: < \r\nOK\r\n
#9: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 0
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply =
VoiceUnconditional =
#10: ./test-ussd '*#002#'
ofonod[30925]: Default: > AT+CCFC=0,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n+CCFC: 0,4\r\n+CCFC: 0,16\r
\n
ofonod[30925]: Default: < +CCFC: 0,32\r\n+CCFC: 0,64\r\n
ofonod[30925]: Default: < +CCFC: 0,128\r\n\r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=1,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n+CCFC: 0,4\r\n
ofonod[30925]: Default: < +CCFC: 0,16\r\n+CCFC: 0,32\r\n+CCFC: 0,64\r\n
ofonod[30925]: Default: < +CCFC: 0,128\r\n\r\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=2,2\r
ofonod[30925]: Default: < \r\n+CCFC:
1,1,"0401234567",129,"",,20\r\n\r
\nOK\r\n
ofonod[30925]: Default: > AT+CCFC=3,2\r
ofonod[30925]: Default: < \r\n+CCFC: 0,1\r\n
ofonod[30925]: Default: < +CCFC: 0,4\r\n+CCFC: 0,16\r\n
ofonod[30925]: Default: < +CCFC: 0,32\r\n+CCFC: 0,64\r\n
ofonod[30925]: Default: < +CCFC: 0,128\r\n\r\nOK\r\n
#11: ./list-modems
[ org.ofono.CallForwarding ]
ForwardingFlagOnSim = 0
VoiceNoReplyTimeout = 20
VoiceNotReachable =
VoiceBusy =
VoiceNoReply = 0401234567
VoiceUnconditional =
So as can be seen the result changes between #5 and #7 although nothing
has been changed. What's more concerning is that at #9 ofono claims that
no CF is active but as can be seen in #11 actually VoiceNoReply no
longer is "quiescent" but "active".
-Jarko-
2:56 a.m.
Hi Jarko,
So actually they aren't both "active" at same time as
the logs show but
personally I don't really care as long as the results are consistent
regardless which API you use which is not the case at the moment as
querying through org.ofono.CallForwarding can give you different result
than using org.ofono.SupplementaryServices.
Ok, so I'm convinced we're not handling this properly. Based on your
testing and my own independent testing setting the Unconditional CF rule
does indeed 'hide' all other rules so they appear inactive.
So do you care to come up with a patch fixing this? Briefly thinking
about this I believe we can implement option 2 from your earlier email.
I'd rather play some tricks and not clear the cache unless really
necessary.
Regards,
-Denis
8:08 a.m.
HI Denis,
2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
Ok, so I'm convinced we're not handling this properly. Based
on your
testing and my own independent testing setting the Unconditional CF rule
does indeed 'hide' all other rules so they appear inactive.
So do you care to come up with a patch fixing this? Briefly thinking
about this I believe we can implement option 2 from your earlier email.
I've yet to see a network which sends forwardingFeatureList for
conditional CFs if unconditional CF is active, they just tell that the
unconditional CFs are, uh, quiescent.
Try your self, do you get anything sensible from *#67# if you have CFU
active? (Like after step #4 above?)
I'd rather play some tricks and not clear the cache unless
really
necessary.
I just don't see any option but clearing the cache. Of course, we can
optimize by the fact that CFU makes conditional CFs
inactive/quiescent.
--
Pekka.Pessi mail at nokia.com
8:24 a.m.
Hi Pekka,
On 01/18/2011 03:08 PM, Pekka Pessi wrote:
HI Denis,
2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
> Ok, so I'm convinced we're not handling this properly. Based on your
> testing and my own independent testing setting the Unconditional CF rule
> does indeed 'hide' all other rules so they appear inactive.
>
> So do you care to come up with a patch fixing this? Briefly thinking
> about this I believe we can implement option 2 from your earlier email.
I've yet to see a network which sends forwardingFeatureList for
conditional CFs if unconditional CF is active, they just tell that the
unconditional CFs are, uh, quiescent.
Try your self, do you get anything sensible from *#67# if you have CFU
active? (Like after step #4 above?)
That was indeed the behavior on T-mobile during my personal testing. So
I'm already convinced ;)
> I'd rather play some tricks and not clear the cache unless
really
> necessary.
I just don't see any option but clearing the cache. Of course, we can
optimize by the fact that CFU makes conditional CFs
inactive/quiescent.
I think we can track the cached flag for conditional CFs independently
from CFU. The question is really whether the networks allow us to
modify conditional CFs when CFU is active. In my testing the answer is No.
Regards,
-Denis
8:32 a.m.
Hi Denis,
2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
I think we can track the cached flag for conditional CFs
independently
from CFU. The question is really whether the networks allow us to
modify conditional CFs when CFU is active. In my testing the answer is No.
You can erase (##67#) or deactivate (#67#) them.
--
Pekka.Pessi mail at nokia.com
8:50 a.m.
Hi Pekka,
On 01/18/2011 03:32 PM, Pekka Pessi wrote:
Hi Denis,
2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
> I think we can track the cached flag for conditional CFs independently
> from CFU. The question is really whether the networks allow us to
> modify conditional CFs when CFU is active. In my testing the answer is No.
You can erase (##67#) or deactivate (#67#) them.
So CFB active.
Activate CFU
Query CFB -> Inactive
Deregister CFB -> OK
Query CFB -> Inactive
Register CFB -> Error
Deactivate CFU
Query CFB -> Inactive
Correct?
Jeez, who thought this stuff up.
So my thinking is that we should:
- Not update conditional cfs when cfu is active (whether via
GetProperties or mmi)
- only clear the conditional cache flag if a conditional operation is
attempted and succeeds while cfu is active
- Report conditional cfs as empty when CFU is active (and emit signals
appropriately when cfu is activated / deactivated)
- Don't bother running conditional cf queries via GetProperties if cfu
is active
Do you see any issues with this? I'm really trying to minimize the
number of queries we have to do in the most common case (which is
activating / deactivating cfu via settings)
Regards,
-Denis
9:08 a.m.
Hi Denis,
2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
> 2011/1/18 Denis Kenzior <denkenz(a)gmail.com>:
>> I think we can track the cached flag for conditional CFs independently
>> from CFU. The question is really whether the networks allow us to
>> modify conditional CFs when CFU is active. In my testing the answer is No.
>
> You can erase (##67#) or deactivate (#67#) them.
So CFB active.
Activate CFU
Query CFB -> Inactive
Deregister CFB -> OK
Query CFB -> Inactive
Register CFB -> Error
Deactivate CFU
Query CFB -> Inactive
Correct?
That is how I think it works.
Jeez, who thought this stuff up.
So my thinking is that we should:
- Not update conditional cfs when cfu is active (whether via
GetProperties or mmi)
- only clear the conditional cache flag if a conditional operation is
attempted and succeeds while cfu is active
- Report conditional cfs as empty when CFU is active (and emit signals
appropriately when cfu is activated / deactivated)
- Don't bother running conditional cf queries via GetProperties if cfu
is active
Do you see any issues with this?
Nope, it sounds reasonable.
--
Pekka.Pessi mail at nokia.com
8:14 p.m.
Hi Denis,
First sorry for slow reply.
On Tue, 2011-01-18 at 23:50 +0200, Denis Kenzior wrote:
So my thinking is that we should:
- Not update conditional cfs when cfu is active (whether via
GetProperties or mmi)
- only clear the conditional cache flag if a conditional operation is
attempted and succeeds while cfu is active
- Report conditional cfs as empty when CFU is active (and emit signals
appropriately when cfu is activated / deactivated)
- Don't bother running conditional cf queries via GetProperties if cfu
is active
Do you see any issues with this? I'm really trying to minimize the
number of queries we have to do in the most common case (which is
activating / deactivating cfu via settings)
So:
- Check if CFU is active and if so return empty string to any
conditional query regardless of the the actual state and regardless of
the used API.
- If CFU not active return the state of queried conditional
- If CFU active and there's an attempt to activate/deactivate
conditional make the operation to modem/network and return possible
error code but do not update conditional state in ofono OR if the
attempt is successful then clear the conditional cache flag.
did I get this right?
and to your earlier question regarding if I could make the patch
unfortunately I don't think I have got the time at the moment so should
I maybe make a TODO out of this so that it won't be forgotten?
-Jarko-
6:10 a.m.
Hi Jarko,
On 01/26/2011 03:14 AM, Jarko Poutiainen wrote:
Hi Denis,
First sorry for slow reply.
On Tue, 2011-01-18 at 23:50 +0200, Denis Kenzior wrote:
>
> So my thinking is that we should:
> - Not update conditional cfs when cfu is active (whether via
> GetProperties or mmi)
> - only clear the conditional cache flag if a conditional operation is
> attempted and succeeds while cfu is active
> - Report conditional cfs as empty when CFU is active (and emit signals
> appropriately when cfu is activated / deactivated)
> - Don't bother running conditional cf queries via GetProperties if cfu
> is active
>
> Do you see any issues with this? I'm really trying to minimize the
> number of queries we have to do in the most common case (which is
> activating / deactivating cfu via settings)
So:
- Check if CFU is active and if so return empty string to any
conditional query regardless of the the actual state and regardless of
the used API.
- If CFU not active return the state of queried conditional
- If CFU active and there's an attempt to activate/deactivate
conditional make the operation to modem/network and return possible
error code but do not update conditional state in ofono OR if the
attempt is successful then clear the conditional cache flag.
did I get this right?
Yep, sounds right.
and to your earlier question regarding if I could make the patch
unfortunately I don't think I have got the time at the moment so should
I maybe make a TODO out of this so that it won't be forgotten?
That works. Or alternatively file a bug in Meego bugzilla, but since
this is a major change it probably belongs in the TODO.
Regards,
-Denis
4253
days inactive
4268
days old
12 comments
3 participants
participants (3)
-
Denis Kenzior -
Jarko Poutiainen -
Pekka Pessi