[Bug 24901] voicemail interface usable with at least GSM and Skype

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=24901

--- Comment #40 from Will Thompson <will.thompson at collabora.co.uk> 2011-03-29 10:08:15 PDT ---
I pushed a few editorial patches to
http://cgit.collabora.co.uk/git/user/wjt/telepathy-spec-wjt.git/log/?h=voicemail
and a few other fixes.

Here are some comments on some comments:

(In reply to comment #37)
> (In reply to comment #33)
> > Suggested changes to danni's spec branch
> > ----------------------------------------
> > 
> > One thing that would be nice is if the DivertedToVoicemail() signal could have
> > a "reason" argument (an enum including at least the values in
> > http://tools.ietf.org/html/rfc4458#section-2.2 would be ideal)
> 
> I think there should be a corresponding property, for state-recoverability.

Hmm, were it not for observers, this would not actually be necessary with Call,
because this state can't change before the handler calls Accept().

Similarly, a bunch of the channel properties are marked as immutable, but
they're not actually immutable: DivertedToVoicemail indicates that
RecordVoicemail and AllowedDuration have changed. But it is completely safe to
include these properties in the NewChannels dictionary when using Call. I'm not
sure whether we should introduce a new annotation for such properties, or just
un-label them as immutable and specify that as a special case they can be
included in the immutable dict. I guess this probably applies to other Call
properties too.

(In reply to comment #36)
> It's correct, thanks. I misunderstood the draft.

If the Mighty Mikhail Zabaluev misunderstood the draft, it needs tweaking. I've
added specific examples.

(In reply to comment #28)
>   Channel.TargetHandle: 0,
>   Channel.TargetHandleType: Target_Handle_None,
> 
> I don't think TargetHandle should be included if THT is None.

I fixed this.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.