A call that moves from the dialing to active state before the +CLCC response
will not properly be added as a voicecall. This is because the dialing callback
was using simplified handling and only looked for calls in the dialing or
alerting state.
AT sequence that exhibited the failure (AG device was an iPhone accessing
visual voicemail):
> +CIND: ("service",(0-1)),("call",(0-1)),("callsetup",(0-3)),
("battchg",(0-5)),("signal",(0-5)),("roam",(0-1)),("callheld",(0-2))
...
> +CIEV: 3,2
< AT+CLCC
> +CIEV: 2,1
> +CIEV: 3,0
> +CLCC: 1,0,0,0,0,"**21153**",129,"Voicemail"
Even though service watches accepted a "destroy" callback, they were
being ignored. This fix properly pass them along so they are called when
the watch is removed.
Voice output serial port is enabled on some Huawei models (e.g. E169)
without problems, but for example on E173u-2 it is never enabled
during an incoming call. There might also be other Huawei models
having the same issue.
I traced the issue down to "^DDSETEX" AT command, which is used
to notify the device to start streaming audio. It seems that Ofono
sends this command too early on incoming calls. The command should
always be sent *after* the dial "D" or answer "A" command. The patch
fixes this behavior and afterwards voice will also work on E173u-2.
Indicators should not be updated if:
- multiple separate calls are active at same time
- a conf call and a call are active at same time
- multiple separate calls are held at same time
- a conf call and a call are held at same time
- a conf call has call in active and held state
Some phones report CLCC calls with out-of-range info. E.g. call index
being 0 (it is 1 based according to 27.007) and call states being
reported as '6' (valid call states are 0-5.)
Due to how the quiescent behavior of conditional call forwarding rules
when CFU is active, do not allow the user to try and set conditional
rules. This will fail at the network level anyway.