* [RFC] voicecallmanager-api: call related SS signals (proposal) [not found] <cover.1296122953.git.Andras.Domokos@nokia.com> @ 2011-01-27 10:20 ` Andras Domokos 2011-01-27 10:39 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont 2011-01-27 13:07 ` Marcel Holtmann 0 siblings, 2 replies; 7+ messages in thread From: Andras Domokos @ 2011-01-27 10:20 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-27 10:20 ` [RFC] voicecallmanager-api: call related SS signals (proposal) Andras Domokos @ 2011-01-27 10:39 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont 2011-01-27 13:07 ` Marcel Holtmann 1 sibling, 0 replies; 7+ messages in thread From: =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont @ 2011-01-27 10:39 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-27 10:20 ` [RFC] voicecallmanager-api: call related SS signals (proposal) Andras Domokos 2011-01-27 10:39 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont @ 2011-01-27 13:07 ` Marcel Holtmann 2011-01-27 15:54 ` Andras Domokos 1 sibling, 1 reply; 7+ messages in thread From: Marcel Holtmann @ 2011-01-27 13:07 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-27 13:07 ` Marcel Holtmann @ 2011-01-27 15:54 ` Andras Domokos 2011-01-27 16:01 ` Denis Kenzior 0 siblings, 1 reply; 7+ messages in thread From: Andras Domokos @ 2011-01-27 15:54 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-27 15:54 ` Andras Domokos @ 2011-01-27 16:01 ` Denis Kenzior 2011-01-28 17:13 ` Andras Domokos 0 siblings, 1 reply; 7+ messages in thread From: Denis Kenzior @ 2011-01-27 16:01 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-27 16:01 ` Denis Kenzior @ 2011-01-28 17:13 ` Andras Domokos 2011-01-28 18:19 ` Denis Kenzior 0 siblings, 1 reply; 7+ messages in thread From: Andras Domokos @ 2011-01-28 17:13 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [RFC] voicecallmanager-api: call related SS signals (proposal) 2011-01-28 17:13 ` Andras Domokos @ 2011-01-28 18:19 ` Denis Kenzior 0 siblings, 0 replies; 7+ messages in thread From: Denis Kenzior @ 2011-01-28 18:19 UTC (permalink / raw) To: ofono [-- 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 ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2011-01-28 18:19 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <cover.1296122953.git.Andras.Domokos@nokia.com> 2011-01-27 10:20 ` [RFC] voicecallmanager-api: call related SS signals (proposal) Andras Domokos 2011-01-27 10:39 ` =?unknown-8bit?q?R=C3=A9mi?= Denis-Courmont 2011-01-27 13:07 ` Marcel Holtmann 2011-01-27 15:54 ` Andras Domokos 2011-01-27 16:01 ` Denis Kenzior 2011-01-28 17:13 ` Andras Domokos 2011-01-28 18:19 ` Denis Kenzior
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.