Hi Marcel,
On 01/27/2011 03:07 PM, ext Marcel Holtmann wrote:
Hi Andras,
Here is a proposal for expanding VoiceCallManager's DBus interface with
call related Supplementary Services signals.
The implementation would be based on the functionality provided by the SSN
atom (handling the CSSU codes).
---
doc/voicecallmanager-api.txt | 54 +++++++++++++++++++++++++++++++++++++++++-
1 files changed, 53 insertions(+), 1 deletions(-)
diff --git a/doc/voicecallmanager-api.txt b/doc/voicecallmanager-api.txt
index 2bf9ded..5212eac 100644
--- a/doc/voicecallmanager-api.txt
+++ b/doc/voicecallmanager-api.txt
@@ -123,7 +123,59 @@ Methods dict GetProperties()
'*', '#', 'A', 'B', 'C', 'D'. The last four are
typically not used in normal circumstances.
-Signals CallAdded(object path, dict properties)
+Signals CallForwarded(object path)
+
+ Signal sent during call setup when the incoming call is
+ a forwarded call. The signal contains the object path of
+ the call in cause.
I don't like this even a single bit. We changed the voice call API
exactly this way to avoid any potential race conditions between calls
and their properties. So please leave this as CallAdded() with the
object path and its properties.
Also having to watch more than three signals for call handling is a bit
overboard. This will cause a lot of extra traffic during setup towards
the D-Bus daemon. Pretty much a bad idea.
I agree, it seems better to have the various call related Supplementary
Services indications coming from the network be treated as voice call
properties.
The informations carried in SS indications coming from the network
during an MT call setup can be easily bound to the right call instance
(is the call being instantiated) and have them show up in the CallAdded
signal as properties. But then there are the indications sent during a
voice call, like when a call is put on hold or retrieved from held state by
the remote party, cases in which there is no information about what is
the targeted call instance, the SSN notifications are not providing this
info.
This becomes a problem when there are multiple calls since it is not
possible to determine to which call instance the indication is referring to.
This raises the question where/how to show this type of properties?
Regards
Marcel
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
Regards,
Andras
_______________________________________________
ofono mailing list
[email protected]
http://lists.ofono.org/listinfo/ofono
