[RFC] voicecallmanager-api: call related SS signals (proposal)

[RFC] voicecallmanager-api: call related SS signals (proposal)

[Andras Domokos]

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

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.
+
+		ClosedUserGroupCall(object path, int32 index)
+
+			Signal sent during call setup when the incoming call is
+			a Closed User Group call. Since the user may belong to
+			multiple groups, the index indicates the group that is
+			applied to the incoming call.
+
+		CallOnHold(object path)
+
+			Signal sent during voice call when a call has been put
+			on hold by the remote party.
+
+		HoldRetrieved(object path)
+
+			Signal sent during voice call when the call has been
+			retrived from held state by the remote party.
+
+		MulipartyCall(object path)
+
+			Signal sent during voice call when a call has been
+			added to a multiparty/conference call.
+
+		HoldReleased(object path)
+
+			Signal sent during voice call when a call put earlier on
+			hold has been released.
+
+		CallForwardCheck()
+
+			Signal sent when a forward check message has been received.
+
+		CallInTransfer(object path)
+
+			Signal sent during voice call with the remote party in
+			alerting state in explicit call transfer operation.
+
+		CallTransferred(object path)
+
+			Signal sent when the call has been connected with the
+			remote party in explicit call transfer operation.
+
+		CallDeflected(object path)
+
+			Signal sent during call setup when the incoming call is
+			a deflected call.
+
+		CallAdded(object path, dict properties)
 
 			Signal that is sent when a new call is added.  It
 			contains the object path of the new voice call and
-- 
1.7.0.4

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[=?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont]

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

On Thursday 27 January 2011 12:20:50 ext Andras Domokos, you wrote:
> 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).

Is there any reason why forwarded, transferred, CUG and deflected incoming 
calls would not use the existing CallAdded signal? Shouldn't those be factoids 
be visible as properties of the call?

Similarly, I'd rather have the other signals be property changes in of call 
object itself, no?

-- 
Rémi Denis-Courmont
Nokia Devices R&D, Maemo Software, Helsinki

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[Marcel Holtmann]

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

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.

Regards

Marcel

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[Andras Domokos]

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

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
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
Regards,
Andras

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[Denis Kenzior]

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

Hi Andras,

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

Have you seen the thread from Pekka's previous attempt to define such
APIs?  Its been a while now but should be in the archives.

Regards,
-Denis

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[Andras Domokos]

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

Hi Denis,

On 01/27/2011 06:01 PM, ext Denis Kenzior wrote:
> Hi Andras,
>
>> 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?
> Have you seen the thread from Pekka's previous attempt to define such
> APIs?  Its been a while now but should be in the archives.

It seems, we might have a bit work to do here.

The first thing is to settle on  the APIs for handling the voice call SS
notifications, I am thinking about the DBus level API and the oFono
internal API.

Currently the SSI notifications are handled in the call barring code, a
better place for handling those notifications would be under the voice
call atom.

Some of the SSI/SSU notifications should be presented as DBus signals
on the VoiceCallManager interface, others converted to voice call
properties, visible on the VoiceCall interface. I compiled a list of
properties/signals based on the possible SSI/SSU notification. The list
is not complete, but can be expanded any time later, based on practical
needs.

Here is the mapping between the properties/signals and SS notification
codes I considered essential to start with:

VoiceCall properties:
Forwarded (bool):: +CSSI: 2, +CSSU: 0
RemoteHold (bool):: +CSSU: 2, +CSSU: 3
Multiparty (bool): +CSSU: 4

VoiceCallManager signals:
UnconditionalForwardingInEffect: +CSSI: 0
ConditionalForwardingInEffect: +CSSI: 1
OutgoingBarringInEffect: +CSSI: 5
IncomingBarringInEffect: +CSSI: 6

In the case of the VoiceCall properties, it is assumed that call instance
number (call id) is available either implicitly, or explicitly provided 
by the
modem driver. Some of the SSN functions needs to be changed to
add call id to the function parameters list, so that modems supporting
the "call id" feature can deliver this information.
For cases when it's impossible to unambiguously determine the call id
for the SS notifications, the notification will be either discarded, or a
VoiceCallManager DBus could be emitted in connection with the
notification (+CSSU: 2, +CSSU: 3, +CSSU: 4 cases).

I see no any need for the SSN atom, and my proposal is to remove it
completely.

> Regards,
> -Denis

Regrads,
Andras

Re: [RFC] voicecallmanager-api: call related SS signals (proposal)

[Denis Kenzior]

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

Hi Andras,

On 01/28/2011 11:13 AM, Andras Domokos wrote:
> Hi Denis,
> 
> On 01/27/2011 06:01 PM, ext Denis Kenzior wrote:
>> Hi Andras,
>>
>>> 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?
>> Have you seen the thread from Pekka's previous attempt to define such
>> APIs?  Its been a while now but should be in the archives.
> 
> It seems, we might have a bit work to do here.
> 
> The first thing is to settle on  the APIs for handling the voice call SS
> notifications, I am thinking about the DBus level API and the oFono
> internal API.
> 
> Currently the SSI notifications are handled in the call barring code, a
> better place for handling those notifications would be under the voice
> call atom.
> 
> Some of the SSI/SSU notifications should be presented as DBus signals
> on the VoiceCallManager interface, others converted to voice call
> properties, visible on the VoiceCall interface. I compiled a list of
> properties/signals based on the possible SSI/SSU notification. The list
> is not complete, but can be expanded any time later, based on practical
> needs.
> 
> Here is the mapping between the properties/signals and SS notification
> codes I considered essential to start with:
> 
> VoiceCall properties:
> Forwarded (bool):: +CSSI: 2, +CSSU: 0
> RemoteHold (bool):: +CSSU: 2, +CSSU: 3
> Multiparty (bool): +CSSU: 4
> 
> VoiceCallManager signals:
> UnconditionalForwardingInEffect: +CSSI: 0
> ConditionalForwardingInEffect: +CSSI: 1
> OutgoingBarringInEffect: +CSSI: 5
> IncomingBarringInEffect: +CSSI: 6
> 
> In the case of the VoiceCall properties, it is assumed that call instance
> number (call id) is available either implicitly, or explicitly provided
> by the
> modem driver. Some of the SSN functions needs to be changed to
> add call id to the function parameters list, so that modems supporting
> the "call id" feature can deliver this information.
> For cases when it's impossible to unambiguously determine the call id
> for the SS notifications, the notification will be either discarded, or a
> VoiceCallManager DBus could be emitted in connection with the
> notification (+CSSU: 2, +CSSU: 3, +CSSU: 4 cases).

Emitting a signal or setting a property depending on the circumstances
is not a good idea.  You either do one or the other.

> 
> I see no any need for the SSN atom, and my proposal is to remove it
> completely.
> 

If you read the earlier discussion you'll note that Pekka already
proposed this.  I'm fine with this approach, removing ssn atom is just fine.

Regards,
-Denis