Re: [RFC] voicecall API changes (proposal 2)

[Denis Kenzior <denkenz@gmail.com>]

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

Hi Andras,

>> The explanations you have should be applied to the type.  Another point
>> is whether we want this signal on the call object itself.  Question is
>> how reliably we can figure out the call index.  At what point does CSSI
>> / CSSU fire, before or after the call goes to active / disconnected
>> state?
> Usually, the user is informed about the call barred situation in a
> very generic wording, like "call barring active" with no interest
> in the call index information.
> I prefer to keep it simple and make this signal call index "free". I
> suggest keeping it on the VoiceCallManager interface.
> The CSSI indication comes right after when call reached the MO
> dialing state and an operator announcement is played over
> and over again telling the caller the reason why calls are not
> possible.
> 

Ok, sounds fine to me.

>>> +        OutgoingCallCondForwarded()
>>> +
>>> +            Signal is emitted when an outgoing voice call is made
>>> +            and the call has been redirected to another number due
>>> +            to the remote party's conditional "Call Forwarding"
>>> +            Supplementary Service settings.
>>> +
>>> +        OutgoingCallUncondForwarded()
>>> +
>>> +            Signal is emitted when an outgoing voice call is made
>>> +            and the call has been redirected to another number due
>>> +            to the remote party's unconditional "Call Forwarding"
>>> +            Supplementary Service settings.
>>> +
>> Same with these two, lets call it CallForwarded(string type)
>>
>> where type is:
>> "conditional" or "unconditional"
> I'll combine them into one, that's fine.
>> And the same question applies here as well, do we want this on the call
>> object itself?  If so, then calling this signal Forwarded(string type)
>> would be better.  Perhaps adding another type for incoming calls that
>> are forwarded and removing the 'Forwarded' property would be a good idea
>> as well.  e.g. something like "incoming" type.
> I am thinking along the same line. Let's replace the "Forwarded"
> property with the "Forwarded" signal and add the "incoming" type
> you were suggesting to this signal.
> And we shall not care about the call index, since most probably
> is not going to be used anywhere, in this respect this cases is
> pretty similar to the call barring signaling case; signal will be
> emitted on the VoiceCallManager interface.

Sounds good to me.

Please resend V3 for final review.

Regards,
-Denis