Hi Slava,
On 09/10/2018 02:56 PM, Slava Monich wrote:
Hi Denis,
Hi Slava,
On 09/10/2018 01:26 PM, Slava Monich wrote:
Hi Anirudh, Denis at al.
@@ -669,6 +669,10 @@ const char *registration_status_to_string(int
status)
return "unknown";
case NETWORK_REGISTRATION_STATUS_ROAMING:
return "roaming";
+ case NETWORK_REGISTRATION_STATUS_REGISTERED_EUTRAN:
+ return "registered lte";
+ case NETWORK_REGISTRATION_STATUS_ROAMING_EUTRAN:
+ return "roaming lte";
What would be the difference between "roaming lte" and "roaming" (or
"registered lte" vs "registered") from the viewpoint of D-Bus API
clients? In other words, what would e.g. dialer do differently
depending on whether registration status is "registered lte" or just
"registered"? Is it worth the API break? The existing clients won't
know how to handle the new values until they (clients) get updated.
I agree. That is why I suggested a separate Property for this (and
the CSFB case from 27.007) instead of modifying the Status property
directly.
E.g. REGISTERED_SMS_EUTRAN would map to Status="registered" and
SmsOnly=False. ROAMING_SMS_EUTRAN would map to Status="roaming" and
SmsOnly=True.
I assume that the Dialer can ignore this as the modem will fall back
to 3G in case of a call? Someone feel free to educate me.
The modems I dealt with do drop to 3G for voice calls. Once voice call
terminates, they switch back to LTE (well, most of the time). Dialler
(at least our dialler) doesn't care about access technology.
That is what I've seen as well. But these are pre-VoLTE devices most
likely. VoLTE might act differently.
Just a thought - could the presence of org.ofono.VoiceCallManager and
org.ofono.MessageManager interfaces be used to indicate whether voice
calls and/or messaging is available? That wouldn't require any D-Bus API
changes at all.
VoiceCallManager should always be available since you still need to make
Emergency Calls. There might be some really weird legacy devices which
were Data-Only, but those aren't really the focus of oFono anyway.
What I assume is happening in 27.007 is that registration states 6/9 &
7/10 allows one to discern whether Circuit Switched Fallback would be
triggered. I assume if the device (& network) is VoLTE capable, then
you'd see state 9/10, 6/7 otherwise. Perhaps all 4 states should be
combined into a single CircuitSwitchedFallback property instead...
Regards,
-Denis
_______________________________________________
ofono mailing list
ofono@ofono.org
https://lists.ofono.org/mailman/listinfo/ofono