Ofono CF states not always correct

Ofono CF states not always correct

[Jarko Poutiainen]

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

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-

Re: Ofono CF states not always correct

[Denis Kenzior]

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

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

Re: Ofono CF states not always correct

[Jarko Poutiainen]

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

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-

Re: Ofono CF states not always correct

[Denis Kenzior]

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

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

Re: Ofono CF states not always correct

[Jarko Poutiainen]

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

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

-Jarko-

Re: Ofono CF states not always correct

[Denis Kenzior]

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

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

Re: Ofono CF states not always correct

[Pekka Pessi]

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

HI Denis,

2011/1/18 Denis Kenzior <denkenz@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

Re: Ofono CF states not always correct

[Denis Kenzior]

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

Hi Pekka,

On 01/18/2011 03:08 PM, Pekka Pessi wrote:
> HI Denis,
> 
> 2011/1/18 Denis Kenzior <denkenz@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

Re: Ofono CF states not always correct

[Pekka Pessi]

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

Hi Denis,

2011/1/18 Denis Kenzior <denkenz@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

Re: Ofono CF states not always correct

[Denis Kenzior]

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

Hi Pekka,

On 01/18/2011 03:32 PM, Pekka Pessi wrote:
> Hi Denis,
> 
> 2011/1/18 Denis Kenzior <denkenz@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

Re: Ofono CF states not always correct

[Pekka Pessi]

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

Hi Denis,

2011/1/18 Denis Kenzior <denkenz@gmail.com>:
>> 2011/1/18 Denis Kenzior <denkenz@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

Re: Ofono CF states not always correct

[Jarko Poutiainen]

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

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-

Re: Ofono CF states not always correct

[Denis Kenzior]

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

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