Ofono CF states not always correct

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-

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

Hi 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-

Hi Jarko,

Both are active and the modem should be reporting both. At least that is how I understood the specifications.

A bit, but having the AT command logs would help greatly.

Regards,
-Denis

Hi Denis,

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.

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@#9 ofono claims that no CF is active but as can be seen in #11 actually VoiceNoReply no longer is "quiescent" but "active".

-Jarko-

Hi Jarko,

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

HI Denis,

2011/1/18 Denis Kenzior <[email protected]>:

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 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

Hi Pekka,

That was indeed the behavior on T-mobile during my personal testing. So I'm already convinced ;)

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

Hi Denis,

2011/1/18 Denis Kenzior <[email protected]>:

You can erase (##67#) or deactivate (#67#) them.

Pekka.Pessi mail at nokia.com

Hi Pekka,

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

Hi Denis,

2011/1/18 Denis Kenzior <[email protected]>:

That is how I think it works.

Nope, it sounds reasonable.

Pekka.Pessi mail at nokia.com

Hi Denis,

First sorry for slow reply.

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-

Hi Jarko,

Yep, sounds right.

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