Bug 24901

Braindump:

My cunning plan for voicemail notifications is to replace the magic voicemail text channel with specially-crafted messages with the MailNotification interface. It's actually pretty similar: the special messages only have headers, so the type of Mail (a{sv}) is perfect.

I guess for retrieving messages, there could be a header in the "mail" with the TargetID of the voicemail channel, and for Skype-style one-call-per-voicemail import the Voicemail.Skype interface with two requestable properties for sender and timestamp. I don't really have any better ideas. :)

Something to consider: we want to be able to log the receipt of Voicemail messages in the logger (with the details so that we can retrieve them from the History dialog, as well as from the Empathy main screen).

Rob, Sjoerd and I got discussing this in the office today. Rob had the better idea of having a channel-request field in the mail notification; clients can just dump it into CreateChannel() in its entirety! I wrote up a draft while it was fresh in my mind: http://people.freedesktop.org/~wjt/telepathy-spec-voicemail_retrieval/spec/Channel_Interface_Voicemail_Retrieval.html

I didn't think about how logging would work.

One possible roadblock for re-using MailNotification: GSM voicemail notifications need to be acked to the network. Maybe we could get away with Ring just acking them immediately, and caching them on disk, or something.

Also: Rob wondered whether mail notification should be a singleton channel, to ensure that it's dispatched. Either that, or we need connection-observing API as Guillaume requests in bug 28974.

Line 68 of Channel_Interface_Voicemail_Retrieval.xml, missing a v to voicemail

With GSM, you can read/write the Voice Mail number, is this handled somewhere ? (see AT+CSVM)

(In reply to comment #5)
> Line 68 of Channel_Interface_Voicemail_Retrieval.xml, missing a v to voicemail

Thanks, fixed. (I rebased the branch onto current master, and amended the single patch.)

(In reply to comment #6)
> With GSM, you can read/write the Voice Mail number, is this handled somewhere ?
> (see AT+CSVM)

Not currently. If we wanted to support this it could go on http://telepathy.freedesktop.org/spec/Connection_Interface_Cellular.html maybe? (That's where the SMSC number is configured.)

I don't think this is really mergeable until we have the voicemail notifications, so removing the patch keyword for now.

I wonder whether VoicemailTimestamp should be some sort of opaque token/ID instead of a timestamp, with the implementation detail that on some protocols it might indeed be a timestamp; it looks as though on visual voicemail, it ought to be an IMAP4 UID, for instance.

The voicemail itself (elsewhere, possibly in MailNotification or Messages depending on the need for acknowledgements / spooling / other guarantees) should certainly have an optional timestamp for when the message was left, but that's orthogonal.

> (In reply to comment #6)
> > With GSM, you can read/write the Voice Mail number
>
> If we wanted to support this it could go on
> http://telepathy.freedesktop.org/spec/Connection_Interface_Cellular.html maybe?

I'd be in favour of that.

(In reply to comment #8)
> I wonder whether VoicemailTimestamp should be some sort of opaque token/ID
> instead of a timestamp, with the implementation detail that on some protocols
> it might indeed be a timestamp;

I support this.

There are a few things missing from this proposal:

 - we need management API, some voicemail APIs let us do things like delete voicemails
 - we need a way to open a voicemail for recording, this is possible on some protocols

So I propose:

Conn.I.Voicemail: looks similar to Conn.I.MailNotification, has API to list, delete, notify. Doesn't include cellular-specific voicemail features, they should go on Conn.I.Cellular.

Chan.I.Voicemail: this is wjt's current Chan.I.VoicemailRetrieval, but with tokens instead of timestamps. Depends on Chan.T.Call. Plus has an extra property that lets you open a channel to record a voicemail for someone without having to call them first.

I'm wondering how a call that gets redirected to voicemail should be notified (I think that on some protocols we can tell this has happened, actually, I think on some protocols you have to redirect to voicemail yourself.. I'm not sure). All Call channels could implement Chan.I.Voicemail, then emit a signal if it gets directed + set the recording property = True.

If people like this approach, I'll cook up some specxml.

http://git.collabora.co.uk/?p=user/danni/telepathy-spec.git;a=shortlog;h=refs/heads/voicemail

Here is a branch that builds of wjt's (rebased of course) and adds the things I talked about. A few small FIXMEs, but in general I think it could support everything we need.

http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Connection_Interface_Voicemail.html
http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Channel_Interface_Voicemail.html

(In reply to comment #12)
> http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Connection_Interface_Voicemail.html
> http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Channel_Interface_Voicemail.html

Some small points:

Connection.I.Voicemail might want to rever to ClientInterests, at least on some protocol the CM might need to do some extra work to poll for voicemail.

Channel.Interface.Voicemail seems useful to have different interfaces for retrieving voicemail and sending voicemail. The properties seem mostly orthogonal and they are two quite different use-cases as well.

I agree with Sjoerd's points - Chan.I.Voicemail is pretty confusing right now. With it split in half, I think this'll be a reasonable shape to have as an implementable draft.

It's also not completely clear which properties are "genuinely part of the request", which properties are there so that the "you have new messages" UI can interpret them, and which properties go both ways.

These interfaces would benefit greatly from some examples: I'd like to see what would typically appear in Voicemails and requestable channel classes for a protocol where you can retrieve voicemails individually by sender/token tuples (Skype), and for a protocol where you can only retrieve voicemails by calling a service and letting the user interact with it (GSM, presumably).

Do we want/need to support protocols where you *can* retrieve voicemails individually, but there's also an interactive service you can call? If we do, we'd want either a separate property for "this is what you request to reach the interactive service", or a convention for "this request dict SHOULD be supported, and should reach the interactive service".

Conn.I.Voicemail.NewVoicemails:
> If the server supports requesting individual voicemails, this signal
> will herald each unique voicemail, and these voicemails will appear
> individually in Voicemails.
>
> If the server does not support individual voicemails, this signal
> will be emitted each time there are new voicemails to be retrieved,
> but will contain a generic channel request. Only this generic channel
> request will appear in Voicemails.

This is quite nice, but the number of voicemails can't be state-recovered in the "not individually addressable" case. A separate VoicemailCount property, perhaps?

Is it actually useful for this signal to be plural, or could it be NewVoicemail(a{sv})?

More cross-references between this, Voicemails and the "individually addressable" flag would be useful.

Voicemails only has change notification in one direction: as currently spec'd, the property seems to never shrink in size. It'd be good to have some way to ack the notification/make the CM shut up, analogous to acknowledging a Text/Messages message... hmm, have we just reinvented the N900's voicemail-via-Messages? :-)

> If present, the protocol allows the user to request individual voicemails
> from the server

I think appending "non-interactively" would make this clearer...

> Otherwise, the voicemail channel is driven via some other method,
> e.g. DTMF  tones.

and "driven via some method requiring user interaction, e.g." here.

> ...retrieving individual voicemails, identified by their sender and a token.
> On those protocols, VoicemailToken and one of VoicemailSenderID or
> VoicemailSenderHandle must be included in channel requests

Why not set VoicemailToken to a composite thing which is informative enough on its own? (VSI, VSH are still useful for UIs to display "you have two voicemails from sjoerd and one from danni", though.)

> But now we have the MailNotification interface, these fit much better there.

No longer relevant :-)

> This property should only be requestable on Skype-style protocols.

What's a Skype-style protocol? I'd prefer "protocols with the Supports_Retrieving_Individual_Voicemail flag, such as Skype" (or whatever you actually meant, if my guess is wrong).

> [RecordVoicemail] should appear in the immutable properties, if the
> channel was requested with it.

That's tp:immutable="sometimes".

(In reply to comment #13)
> Channel.Interface.Voicemail seems useful to have different interfaces for
> retrieving voicemail and sending voicemail. The properties seem mostly
> orthogonal and they are two quite different use-cases as well.

I concur. At least two different channel classes should be distinguished, to discover when the protocol allows recording voicemails without trying to call, and when on-demand voicemail playback is supported.

(In reply to comment #14)
> It's also not completely clear which properties are "genuinely part of the
> request", which properties are there so that the "you have new messages" UI can
> interpret them, and which properties go both ways.

In moving from VoicemailTimestamp to a generic VoicemailToken for the former use, we did lose information for the latter use, so perhaps we should re-introduce the timestamp in addition.

From the department of namespacing, Duration and AllowedDuration are a little ambiguous. My usual rule of thumb for good enough namespacing is: if I only tell you the member name and "it's in Telepathy", can you guess what it means? Out of context, I think Duration sounds more like a perpetually incrementing in-call counter, and AllowedDuration sounds more like a limit on the length of all calls (a rubbish PAYG tariff that disconnects you after 10 minutes as an incentive to upgrade to something more expensive, perhaps).

After splitting the Channel interface into VoicemailRetrieval and VoicemailRecording (Voicemailable?), we'd presumably have VoicemailRetrieval only appear in Interfaces if one of its properties was in the request, whereas VoicemailRecording would appear in the Interfaces of every call in case it became relevant? If that's the case, then VoicemailRetrieval doesn't need to be held to such a high standard regarding out-of-context member names.

On GSM, the voicemail notifications SMS usually contain one bit of usual information, is there voicemails available or not. As smcv mentioned, an explicit shrink notification in case this bit goes to 0 would be nice.

Also, the voicemail number is stored on the SIM card. Some operators have neglected to save voicemailbox number the SIM card, so there must be a way for CM to indicate the voicemails are available even when it is not possible to create a meaningful channel request.

(In reply to comment #13)

> Connection.I.Voicemail might want to rever to ClientInterests, at least on some
> protocol the CM might need to do some extra work to poll for voicemail.

Agreed.

(In reply to comment #14)
> I agree with Sjoerd's points - Chan.I.Voicemail is pretty confusing right now.
> With it split in half, I think this'll be a reasonable shape to have as an
> implementable draft.

I agree. I'm thinking that I'll split this into Chan.I.Voicemail and Chan.I.Voicemail.Retrieval

> It's also not completely clear which properties are "genuinely part of the
> request", which properties are there so that the "you have new messages" UI can
> interpret them, and which properties go both ways.

I'm going to change this such that only the token is required for the request. The CM can store whatever information in the token it requires. This means only the token will be required for the request and all other retrieval properties will be informational.

> Do we want/need to support protocols where you *can* retrieve voicemails
> individually, but there's also an interactive service you can call? If we do,
> we'd want either a separate property for "this is what you request to reach the
> interactive service", or a convention for "this request dict SHOULD be
> supported, and should reach the interactive service".

I think not (why would anyone want this?). But there could be an Conn.I.Voicemail.InteractiveService property, which includes a request token.

> Conn.I.Voicemail.NewVoicemails:
> > If the server supports requesting individual voicemails, this signal
> > will herald each unique voicemail, and these voicemails will appear
> > individually in Voicemails.
> >
> > If the server does not support individual voicemails, this signal
> > will be emitted each time there are new voicemails to be retrieved,
> > but will contain a generic channel request. Only this generic channel
> > request will appear in Voicemails.
> 
> This is quite nice, but the number of voicemails can't be state-recovered in
> the "not individually addressable" case. A separate VoicemailCount property,
> perhaps?

How do we indicate there are >=1 voicemails but the number is unknown?

> Is it actually useful for this signal to be plural, or could it be
> NewVoicemail(a{sv})?

I thought so, when you reconnect to the network, you might receive a bunch of new messages.

> Voicemails only has change notification in one direction: as currently spec'd,
> the property seems to never shrink in size. It'd be good to have some way to
> ack the notification/make the CM shut up, analogous to acknowledging a
> Text/Messages message... hmm, have we just reinvented the N900's
> voicemail-via-Messages? :-)

I'm going to add a Removed:av argument. I don't think the client needs to acknowledge a voicemail message, but there's an open question about whether we need MarkRead/MarkUnread on Conn.I.Voicemail.

> Why not set VoicemailToken to a composite thing which is informative enough on
> its own? (VSI, VSH are still useful for UIs to display "you have two voicemails
> from sjoerd and one from danni", though.)

I agree. See above.

(In reply to comment #16)

> From the department of namespacing, Duration and AllowedDuration are a little
> ambiguous. My usual rule of thumb for good enough namespacing is: if I only
> tell you the member name and "it's in Telepathy", can you guess what it means?
> Out of context, I think Duration sounds more like a perpetually incrementing
> in-call counter, and AllowedDuration sounds more like a limit on the length of
> all calls (a rubbish PAYG tariff that disconnects you after 10 minutes as an
> incentive to upgrade to something more expensive, perhaps).

Would you prefer VoicemailDuration and AllowedVoicemailDuration?

(In reply to comment #17)

> Also, the voicemail number is stored on the SIM card. Some operators have
> neglected to save voicemailbox number the SIM card, so there must be a way for
> CM to indicate the voicemails are available even when it is not possible to
> create a meaningful channel request.

I'm thinking in these instances, we should simply omit the VoicemailToken, meaning a request cannot be made.

Further point. Some protocols (including Skype and GSM) can attach a message to the voicemail. We should have a property on Chan.I.V.R to store this message.

(In reply to comment #14)

> That's tp:immutable="sometimes".

Does this work?

Draft updated:

http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Connection_Interface_Voicemail.html
http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Channel_Interface_Voicemail.html
http://people.freedesktop.org/~danni/telepathy-spec-voicemail/spec/Channel_Interface_Voicemail_Retrieval.html

(In reply to comment #20)
> (In reply to comment #14)
> 
> > That's tp:immutable="sometimes".
> 
> Does this work?

Turns out it only works for tp:requestable. Bug #32015

(In reply to comment #18)
> I'm going to change this such that only the token is required for the request.
> The CM can store whatever information in the token it requires.

If you're going to do that...

(In reply to comment #14)
> which properties are there so that the "you have new messages" UI can
> interpret them

... then these properties don't necessarily need to be properties (since they're no longer part of the request), they can be an a{sv} of extra information.

I assume that informational stuff like the sender is pretty irrelevant for the observer/handler of the voicemail channel: if that's the case, then the sender/timestamp/bees don't need to be properties on the channel at all.

The rationale for this:

(In reply to comment #3)
> Rob had the better
> idea of having a channel-request field in the mail notification; clients can
> just dump it into CreateChannel() in its entirety!

was that if the mechanism for retrieving voicemail is "dial 123", it would be nice if the channel request that started the whole process contained { TargetID: 123 }, for instance. If we're breaking that anyway (by using a dedicated voicemail-token thing), there's no point in mapping things to properties.

If you agree with that reasoning, then all of Voicemail.Retrieval except the token can go away, and be replaced by a (token, a{sv}) pair in Conn.I.Voicemail where the a{sv} is something like this:

{ 'sender': 42, 'sender-id': 'smcv@example.com', 'timestamp': now(),
  'duration': 65, 'message': 'dial 0800-your-ad-here to hear your voicemail' }

(In reply to comment #18)
> Would you prefer VoicemailDuration and AllowedVoicemailDuration?

I'd certainly prefer AllowedVoicemailDuration. If the above is persuasive, then we don't need VoicemailDuration at all.

(In reply to comment #18)
> I agree. I'm thinking that I'll split this into Chan.I.Voicemail and
> Chan.I.Voicemail.Retrieval

VoicemailRetrieval would be conventional, FWIW - we don't generally do nested namespaces within Chan.T.*, Chan.I.*.

> How do we indicate there are >=1 voicemails but the number is unknown?

I see you fixed this by having -1 indicate an unspecified nonzero number. That seems entirely reasonable.

> I'm thinking in these instances, we should simply omit the VoicemailToken,
> meaning a request cannot be made.

If voicemails are a (token, info) tuple, you can't omit the token. Omitting the token would break your API for DeleteVoicemail and VoicemailsRemoved, though, so I don't think that's a good idea anyway.

Having non-unique tokens would also break DeleteVoicemail and VoicemailsRemoved - if you've told me { token: "generic-voicemail-box", sender-id: "smcv" } and { token: "generic-voicemail-box", sender-id: "sjoerd" }, how do you indicate that the voicemail from me has been removed but the one from Sjoerd is still there?

Perhaps what you want here is to say that the tokens are mandatory, and in addition, there'll be a RequestableChannelClass that allows VoicemailToken (and you should specify its fixed properties) if and only if individual voicemails can be received? (RCCs have to have a target handle type, so you may need to use Handle_Type_None.)

For the GSM-style "generic inbox" case, you'd need some other mechanism - perhaps a second property on VoicemailRetrieval, which can be requestable-or-not? GenericVoicemailBox:b perhaps?

------------------------------------------------------------------

Comments on your spec HTML, assuming we discard VoicemailRetrieval and keep the two Voicemail interfaces:

I think the intro blurb on Chan.I.Voicemail should specifically say that the presence of this interface doesn't imply that this *is* voicemail, only that you *might be* diverted to voicemail. Perhaps it should be called VoicemailDiversion or VoicemailRecording, but perhaps that's too long.

RecordVoicemail should be tp:requestable="sometimes", and explain in the text that it appears in the allowed properties of 1-1 StreamedMedia and Call calls if and only if you can "go directly to voicemail" in this protocol.

VoicemailToken is tp:requestable="sometimes".

(In reply to comment #23)

> If you're going to do that...
> ... then these properties don't necessarily need to be properties (since
> they're no longer part of the request), they can be an a{sv} of extra
> information.
> 
> I assume that informational stuff like the sender is pretty irrelevant for the
> observer/handler of the voicemail channel: if that's the case, then the
> sender/timestamp/bees don't need to be properties on the channel at all.

I think it is still useful. We may want to log that you downloaded voicemail, but more importantly, the handler may want to show metadata about the voicemail (Sender, Duration, Time) and it doesn't seem reasonable to have to go back to the connection in order to look that information up. We could collapse it down into a single VoicemailMetadata property. I'm not entirely sure what that gains us though.

> > I'm thinking in these instances, we should simply omit the VoicemailToken,
> > meaning a request cannot be made.
> 
> If voicemails are a (token, info) tuple, you can't omit the token. Omitting the
> token would break your API for DeleteVoicemail and VoicemailsRemoved, though,
> so I don't think that's a good idea anyway.
> 
> Having non-unique tokens would also break DeleteVoicemail and VoicemailsRemoved
> - if you've told me { token: "generic-voicemail-box", sender-id: "smcv" } and {
> token: "generic-voicemail-box", sender-id: "sjoerd" }, how do you indicate that
> the voicemail from me has been removed but the one from Sjoerd is still there?

Very good point. Rather than a requestable channel class (plus badgers), we could return to using 'aa{sv}'s for Delete and Removed.

We should include API indicating whether or not to redirect calls to Voicemail. Potentially after how long?

We may also desire an EnableVoicemail() method, read-only VoicemailEnabled property, and VoicemailEnabledChanged signal.

(In reply to comment #25)
> We should include API indicating whether or not to redirect calls to Voicemail.
> Potentially after how long?

The o.f.T.C.I.Forwarding is up to the task, provided you have a handle for voicemail:

http://telepathy.freedesktop.org/spec/Connection_Interface_Forwarding.html

Are there some systems where you don't have such a handle?

I've realised that we're also lacking a mechanism to record your voicemail greeting.

Could add another requestable property to Chan.I.Voicemail: RecordGreeting, which opened a call channel allowing you to record your greeting.

I generally like the shape of C*.I.V*. Here are a few comments though:

Maybe AllowedDuration should be included in DivertedToVoicemail () to avoid the UI having to poll for it.

“; provides properties that can be requested on a new channel to leave a voicemail (for protocols that support this feature).
On protocols that allow it, the RecordVoicemail property can be used to leave a voicemail for a remote user without first placing an outgoing call.”

It looks like you meant to remove one or other of those fragments.

  Channel.TargetHandle: 0,
  Channel.TargetHandleType: Target_Handle_None,

I don't think TargetHandle should be included if THT is None.

We should note that calling a 

Supports_Placing_Voicemail_Without_Call (8)
If present, you can request a voicemail channel to a remote contact to leave a voicemail without having to make a call that might potentially be answered.

This flag isn't necessary. You can use a requestable channel class with RecordVoicemail: True. Removing this flag would make Conn.I.Voicemail exclusively about retrieval.

The use of the verb ‘to herald’ is excellent.

The preamble for VoicemailRetrieval (which should have no dot between those two words; I agree with Simon) should include a sample entry in RequestableChannelClasses (specifically, with the Token property in Allowed).

----

I think having a RecordGreeting requestable property would not be bad at all.

----

This is crying out for a ConnectionObserver as discussed on bug 28974, so that your voicemail UI can ensure that it's running when a connection that supports voicemail is online.

----

I think Forwarding is really over-complicated, and if we could get away with a simpler version of it that would be good. The UI I imagine would be:

  If I don't answer for [ 30 ± ] seconds, am engaged, or am offline:
    ( ) End the call
    (o) Redirect the call to voicemail
    ( ) Redirect the call to [ type recipient here_     ]

I guess you might hypothetically want to do something different in those three scenarios… We could combine the second and third options at the Telepathy API level by allowing you to use (say) an empty string to mean “the default voicemail service”. Just thinking aloud here, really.

(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.

So at the moment I'm ignoring this part of the spec, because it requires changes to new-call-demo to support 0/None. Instead I've created a '-voicemail-'/Contact handle.

Doing this sort of makes sense compared with protocols where voicemail is a specific handle you dial. Alternatively I've also considered making the TargetHandle the same as SenderHandle. We need to think about this.

> We should note that calling a 

Some text missing?

~

Need to be aware that currently type 'av' isn't supported by our tools/dbus-glib:

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

NewVoicemails should probably include the updated value of VoicemailCount, since it's not always the same as the length of the @Voicemails array.

Should NewVoicemails return a zero-length (or NULL) array when the server doesn't support individual listing? That would avoid confusing the generic entry with the case that there is one new voicemail. You can avoid this by looking at the Capabilities, but I don't see the reason to return a generic Voicemail, although I may be missing something...

Couple of syntax issues:
"voicemail is provied by the"
"this signal will be emitted each time there are voicemails have been removed" (this doesn't make sense to me... perhaps "each time voicemails have been removed" ?)

I'm implementing a UI in Empathy, but when implementing voicemail deletion, I'm confused on whether VoicemailToken inside a Voicemail map as returned by NewVoicemails is a variant inside a variant (as everything else is something inside a variant) or is just the variant itself. It may be good to clarify this.

I checked danni's voicemail spec branch and it looks like it's vaguely backwards-compatible with SIP thanks to the limitations put in place for cellular interop. I would need to see the final spec to see how it is affected by the changes people have suggested though. (I've not checked out the Forwarding spec properly, so I'll leave it to the nokia guys to say whether that's appropriate for sip).


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)

In the case of generic DTMF-based mailbox systems, it would be nice to have this reflected a property on the *channel* (possibly bool, as Comment 23 by Simon McVittie suggested). This could double as a hint to UIs that they will be talking to an IVR system, and to ensure that the "speakerphone" button and DTMF dialpad are visible on mobile handset UIs (tp:rationale anyone?).

Other SIP considerations that shouldn't require spec changes
------------------------------------------------------------

(This is mostly a note to myself, or whoever ends up implementing voicemail in sofiasip)

In rfc4458 suggests that calling yourself (To==From) should be the default way to retrieve your voicemail (this may not be the case on all SIP servers, but we can have an optional account parameter for that, so that's not a spec problem)

http://wiki.freeswitch.org/wiki/Mod_voicemail#Can_I_share_voicemail_boxes_between_multiple_phones.2Fusers.3F suggests a way to have shared mailboxes. I think that this should be configurable using the same account parameter as above, but it's certainly a test case that's worth considering.

(In reply to comment #33)
> In rfc4458 suggests that calling yourself (To==From) should be the default way
> to retrieve your voicemail (this may not be the case on all SIP servers, but we
> can have an optional account parameter for that, so that's not a spec problem)

Right, all SIP parameters should be assumed to be provisionable outside of Telepathy. If the call-to voicemail address is provided, we can simply use it in a property on Conn.I.Voicemail, namely?.. I'm not sure the spec for property Voicemails currently allows the single voicemailbox RCC for a normal call.

(In reply to comment #34)
> (In reply to comment #33)
> > In rfc4458 suggests that calling yourself (To==From) should be the default way
> > to retrieve your voicemail (this may not be the case on all SIP servers, but we
> > can have an optional account parameter for that, so that's not a spec problem)
> 
> Right, all SIP parameters should be assumed to be provisionable outside of
> Telepathy. If the call-to voicemail address is provided, we can simply use it
> in a property on Conn.I.Voicemail, namely?.. I'm not sure the spec for property
> Voicemails currently allows the single voicemailbox RCC for a normal call.

as I understand it:

Voicemails = [{"VoicemailToken"=SomeOpaqueVariant}]
VoicemailCapabilities = 0 (or specifically not Supports_Retrieving_Individual_Voicemail)
VoicemailCount = 5

implies "I know that you have 5 voicemails, and if you call
RequestChannel ({"ChannelType"="Call", "VoicemailToken"=SomeOpaqueVariant} then you will be magically put through to your interactive mailbox, where you can retrieve them."

Is this correct, or am I missing something here?

(In reply to comment #35)
> as I understand it:
> 
> Voicemails = [{"VoicemailToken"=SomeOpaqueVariant}]
> VoicemailCapabilities = 0 (or specifically not
> Supports_Retrieving_Individual_Voicemail)
> VoicemailCount = 5
> 
> implies "I know that you have 5 voicemails, and if you call
> RequestChannel ({"ChannelType"="Call", "VoicemailToken"=SomeOpaqueVariant} then
> you will be magically put through to your interactive mailbox, where you can
> retrieve them."
> 
> Is this correct, or am I missing something here?

It's correct, thanks. I misunderstood the draft.

(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.

(In reply to comment #32)
> I'm implementing a UI in Empathy, but when implementing voicemail deletion, I'm
> confused on whether VoicemailToken inside a Voicemail map as returned by
> NewVoicemails is a variant inside a variant (as everything else is something
> inside a variant) or is just the variant itself. It may be good to clarify
> this.

GValue *token = tp_asv_get_boxed (props, EMP_PROP_..._VOICEMAIL_TOKEN, G_TYPE_VALUE); will return the opaque voicemail token.

However I've just remembered that there's no g_value_cmp() or g_value_equal() etc. function we can use to actually compare the opaque GValues for equality. This isn't a problem with GVariant, where we have g_variant_equal(), so I suppose we could work around it by converting the GValues to GVariants via dbus_g_value_build_g_variant().

It's worth noting that simply using the token is not enough, multiple connections could use the same tokens (e.g. if the tokens are just say uint32s enumerating from 1), so when finding which voicemail to remove it will be important to compare the tuple (Connection, token).

We need a way to listen to the greeting we've just recorded. I wonder if it should also be possible to replay a message (where you can) without having to create a new channel.

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.

Problem that's been encountered:

In one protocol, the AllowedDuration does not become available until after the greeting has finished playing.

We want to emit DivertedToVoicemail as soon as possible, but perhaps we need an additional VoicemailState property (NOT_VOICEMAIL, UNKNOWN, MESSAGE_PLAYING, RECORDING) that can allow us to update properties as we can discover them.

I think it's time to get this finalised and merged.

http://cgit.collabora.com/git/user/danni/telepathy-spec.git/log/?id=refs/heads/voicemail

(In reply to comment #41)
> In one protocol, the AllowedDuration does not become available until after the
> greeting has finished playing.

Fixed this by adding changed notification to AllowedDuration.

> I think there should be a corresponding property, for state-recoverability.

Done.

(In reply to comment #39)
> We need a way to listen to the greeting we've just recorded. I wonder if it
> should also be possible to replay a message (where you can) without having to
> create a new channel.

Added a PlaybackGreeting that has the same semantics as RecordGreeting. We probably also need a map of recorded greetings on Conn.I.VM.

I've only looked at the commits since Will's latest patches.

The RecordVoicemail property MUST be set True before emitting this signal, as well as DiversionReason, any other properties whose values can now be determined by the Connection Manager.

^ This is really unclear. Can you just reword a bit to make a little easier to understand please?

+ <tp:rationale>
+ Provided for state recoverability by Observers.
+ </tp:rationale>

You could link Observers.

I didn't really look at the rest of this branch or even this bug so haven't followed rationales, but your latest five patches look fine except the two comments above.

(In reply to comment #43)

> I didn't really look at the rest of this branch or even this bug so haven't
> followed rationales, but your latest five patches look fine except the two
> comments above.

Resolved these. Added one more commit for handling recorded greetings.

I'm sort of not sure if recorded greetings are overspecced or not. It's not clear if any system supports this level of detail. Given the Handle Types have been deprecated, I'm sort of considering scrapping it.

It would be useful for someone to review the spec again in fullness.

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/telepathy/telepathy-spec/issues/46.