VISUAL VOICE MAIL INTERFACE SPECIFICATION

Full text

(1)

PUBLISHED

O M T P

VISUAL VOICE MAIL IN TERFACE

SPECIFICATION

VERSION: v1.3 STATUS: Published DATE OF LAST EDIT: June 11th, 2010

(2)

CONTENTS

1

I

NTRODUCTION

... 5

1.1

D

OCUMENT

P

URPOSE

... 5

1.2

B

USINESS

R

ATIONALE

... 5

1.3

I

NTENDED

A

UDIENCE

... 6

1.4

C

OMPLIANCE

R

EQUIREMENTS

... 6

2

VVM

I

NTERFACES

O

VERVIEW

... 7

2.1

M

ESSAGE

R

ETRIEVAL

I

NTERFACE

D

ESCRIPTION

... 8

2.1.1 Message Retrieval: IMAP4 Command Reference ... 9

2.1.2 Message Retrieval: Supported Message Types ... 18

2.1.3 Message Retrieval: Supported Attachment Formats ... 18

2.1.4 VVM TUI Features Limitations ... 19

2.1.5 Message Retrieval Header Reference ... 19

2.2

M

ESSAGE

D

EPOSIT

I

NTERFACE

D

ESCRIPTION

... 26

2.2.1 Standard Message Deposit Header Reference ... 26

2.2.2 VVM Specific Message Deposit Header Reference ... 30

2.2.3 Message Deposit Attachment Header Reference ... 30

2.3

TUI

P

ASSWORD

C

HANGES

I

NTERFACE

D

ESCRIPTION

... 32

2.3.1 Change Password Request Syntax ... 32

2.3.2 Change Password Response Syntax ... 34

2.4

C

HANGE

TUI

L

ANGUAGE

I

NTERFACE

D

ESCRIPTION

... 35

2.4.1 Change Language Request Syntax ... 35

2.4.2 Change Language Response Syntax ... 37

2.5

C

LOSE

NUT

I

NTERFACE

D

ESCRIPTION

... 38

2.5.1 Close NUT Request Syntax ... 38

2.5.2 Close NUT Response Syntax ... 38

2.6

O

N

D

EMAND

A

UDIO

M

ESSAGE

T

RANSCRIPTION

C

OMMAND

S

ERVICES FROM

V

ISUAL

V

OICE

M

AIL

C

LIENT

... 39

2.6.1 On-demand Transcription Request Syntax ... 39

2.6.2 On-demand transcription Response Syntax ... 39

2.6.3 Automatic Transcription Service START/STOP Request Syntax ... 40

2.6.4 Automatic Transcription Service START/STOP Response Syntax ... 40

2.7

G

UIDELINES FOR

G

REETINGS AND

V

OICE

S

IGNATURE

M

ANAGEMENT

... 42

2.7.1 Uploading a Greeting or VS ... 43

2.7.2 Deleting a Greeting or VS ... 44

(3)

2.8

P

ROVISIONING

S

TATUS

... 48

2.9

VVM

SMS

I

NTERFACE

D

ESCRIPTION

... 50

2.9.1 System Originated SMS Messages ... 50

2.9.2 Mobile (Client) Originated SMS Messages ... 66

2.10

VVM

M

ESSAGE

C

OMMAND

E

XAMPLES

... 73

2.10.1 IMAP4 MD5 Authentication Example ... 74

2.10.2 SMTP MD5 Authentication Example ... 75

2.10.3 Voice Message Example ... 76

2.10.4 Video Message Example... 77

2.10.5 Fax Message Example ... 78

2.10.6 ECC Message Example ... 79

2.10.7 Number Message Example ... 80

2.10.8 Voice DSN Message Example ... 81

2.10.9 Voice Message Disposition Notification Message Example ... 83

2.10.10 Deposit Voice Message Example ... 85

2.10.11 Greeting Message Example ... 86

2.10.12 VS Message Example ... 86

2.11

R

EFERENCE

... 87

2.11.1 RFC Compliance Related to Internet Mail ... 87

2.11.2 RFC Compliance Related to IMAP4 ... 87

2.11.3 RFC Compliance Related to SMTP ... 88

(4)

The information contained in this document represents the current view held by OMTP Limited on the issues discussed as of the date of publication.

This document is provided “as is” with no warranties whatsoever including any warranty of merchantability, non-infringement, or fitness for any particular purpose. All liability (including liability for infringement of any property rights) relating to the use of information in this document is disclaimed. No license, express or implied, to any intellectual property rights are granted herein. This document is distributed for informational purposes only and is subject to change without notice. Readers should not design products based solely on this document.

Each Open Mobile Terminal Platform member and participant has agreed to use reasonable endeavours to inform the Open Mobile Terminal Platform in a timely manner of Essential IPR as it becomes aware that the Essential IPR is related to the prepared or published specification. The declared Essential IPR is publicly available to members and participants of the Open Mobile Terminal Platform and may be found on the “OMTP IPR Declarations” list at the OMTP Members Access Area.

The Open Mobile Terminal Platform has not conducted an independent IPR review of this document and the information contained herein, and makes no representations or warranties regarding third party IPR, including without limitation patents, copyrights or trade secret rights. This document may contain inventions for which you must obtain licenses from third parties before making, using or selling the inventions.

(5)

1 I

NTRODUCTION

1.1 D

OCUMENT

P

URPOSE

The aim of this document is to provide a Technical Recommendation for an open and standardised Visual Voice Mail (VVM) interface protocol which VVM clients may use to interact with a voice mail server. The key functions of this interface will be support of:

• Message Retrieval

• Message Upload

• VVM Management

• Greeting Management

• Provisioning

The document will not define how a VVM client looks nor will it define the general behaviour of a client/user interface or the manner in which a user shall interact with the user interface. The definition of the protocol may however imply certain client and/or user behaviours. The intention of the document is to ensure that the standard functionality of voice mail servers may be accessed through a range of VVM clients via a defined interface. This approach leaves scope for operators and vendors to differentiate their products.

1.2 B

USINESS

R

ATIONALE

The growth of VVM services and possible new business models is restrained by the lack of a standardised client side interface to the voice mail server. Native support on terminals for a voice mail interface will significantly improve the overall user experience, which in turn will encourage wider use of voice mail services.

If vendors are able to support a single VVM interface their time to market and associated costs shall be reduced.

A standardised interface definition shall allow client developers to focus on producing better clients rather than modifying clients to work with multiple interfaces.

Having only one interface to support will improve the ability of an operator to provide the VVM service on a variety of terminals, roll out the service more quickly and contain operational expenditure.

A number of VVM implementations currently exist in the market, however, service deployment is at a nascent stage and therefore market fragmentation

(6)

1.3 I

NTENDED

A

UDIENCE

The audience for this document includes:

 Network operators who define specific requirements for VVM

clients to be delivered on mobile Terminals which are delivered in accordance with the operators mobile requirements documents.

 OMTP Terminal vendors, i.e. equipment and technology vendors

who will deliver VVM clients on their Terminals.

 Third party providers of VVM clients and servers.

 Other projects inside OMTP that will take these requirements as

input.

1.4 C

OMPLIANCE

R

EQUIREMENTS

Conformance to this document does not offer a partial compliance option at the individual requirements level as is the case with most OMTP requirements documents. Conformance may only be stated if the vendor is 100% compliant to all aspects of the recommendation.

This document is a Technical Recommendation for an open and standardised VVM interface protocol. VVM clients may use the interface protocol to interact with a voice mail server. The compliance statement encompasses only the interface protocol and does not state compliance to VVM functionalities implemented.

(7)

2 VVM

I

NTERFACES

O

VERVIEW

The VVM service enables third parties to develop terminal client applications for subscribers to manage their mailbox messages. Subscribers can use the VVM client on their terminals to listen to messages, delete messages, and compose messages.

The following actions can be performed from the VVM client:  Message Retrieval: As described in section 2.1.  Message Deposit: As described in section 2.2.

TUI (Telephony User Interface) Password Changes: As described in section 2.3

TUI Language Settings Changes: As described in section 2.4.

NUT (New User Tutorial) Session Disabling: As described in section 2.5.

Greeting and VS (Voice Signature) Management: As described in section 2.6.

Examples of VVM message commands and responses are provided in section 2.10.

SMS (Short Message Service) messages sent between the VVM service and client, used to notify the client about events in the subscriber mailbox, query the subscriber’s provisioning status and activate and deactivate the service are described in section 2.9. Subscriber provisioning statuses are described in section 2.8.

The VVM service complies with Request for Change (RFC) standards

(8)

2.1 M

ESSAGE

R

ETRIEVAL

I

NTERFACE

D

ESCRIPTION

The VVM client communicates with the VVM server via a standard IMAP4 protocol for message retrieval. In addition to the IMAP4 RFC, some extensions have been added to enable the client to perform certain mailbox configuration actions, such as changing the Telephony User Interface (TUI) password and language.

The number of concurrent IMAP4 sessions for a single client has a configurable limit. The client must log out at the end of a session.

Commands used during the IMAP4 message retrieval sessions are described in section 2.1.1.

The headers included in the messages retrieved via the VVM service are described in section 2.1.5.

Message types and attachment formats supported by the VVM message retrieval sessions are described in sections 2.1.2 and 2.1.3.

Some TUI features are limited by the VVM service, as described in section 2.1.4.

(9)

2.1.1 MESSAGE RETRIEVAL:IMAP4COMMAND REFERENCE

The VVM service supports the IMAP4 commands listed in Table 1, with some restrictions described in this chapter. Other IMAP4 extensions are not supported, unless specifically stated.

Command Name RFC Reference

APPEND RFC3501

AUTHENTICATE RFC3501 for the

DIGEST-MD5 algorithm (RFC 2831) only CAPABILITY RFC3501 CHECK RFC3501 CLOSE RFC3501 EXAMINE RFC3501 EXPUNGE RFC3501 FETCH RFC3501 GETMETADATA RFC5464 GETQUOTAROOT RFC2087 GETQUOTA RFC2087 LIST RFC3501 LOGIN RFC3501 LOGOUT RFC3501 NOOP RFC3501 SEARCH RFC3501 SELECT RFC3501 SETMETADATA RFC5464 STARTTLS RFC3501 STATUS RFC3501 STORE RFC3501 UID RFC3501

Table 1 Supported IMAP4 Commands

When a server receives a command that is not listed in Table 1 and which thee server does not support, it will respond with the following error message:

(10)

2.1.1.1 APPEND

The VVM service supports the APPEND command, as described in RFC3501. The APPEND command is not supported on the Inbox folder. The APPEND command can be used only to append a new greeting to the Greetings folder. If the APPEND command is performed on the Inbox folder, the system returns the following error message:

NO command not allowed

The APPENDUID response code described in RFC4315 is supported. However, commands described in RFC4315 are not supported.

(11)

2.1.1.2 AUTHENTICATE

The VVM service supports the AUTHENTICATE command described in RFC3501 for the DIGEST-MD5 algorithm (RFC2831) only.

The AUTHENTICATE command includes the following credentials:

Username: Defines the subscriber’s IMAP4 user name as received in the STATUS SMS

Password: Defines the VVM service password, and is either the subscriber’s IMAP4 password or the TUI password, depending on the system setup.

The IMAP4 password is sent in the STATUS SMS message. If a TUI password is used, it must be set by the user.

The table below describes error messages that can be returned for the AUTHENTICATE command.

Error Description

NO unknown user The subscriber can not be located in the system. NO unknown

client

The Client Type or Protocol Version is unknown. NO invalid

password

The password received from the client does not match the password defined in the subscriber's profile.

NO mailbox not initialized

The subscriber's mailbox has not yet been initialised via the TUI (the VVM server can, by configuration, reject login attempts if the subscriber has not changed the default password/greeting via the TUI).

NO service is not provisioned

The subscriber has not been provisioned for the VVM service.

NO service is not activated

The subscriber is provisioned for the VVM service but the VVM service is currently not active (the VVM server can, by configuration, reject login attempts in such cases also)

NO user is blocked

The Voice Mail Blocked flag in the subscriber's profile is set to YES.

No application error

There is a system error preventing authentication Table 2 AUTHENTICATE Command Error Messages

(12)

2.1.1.3 CAPABILITY

The VVM service supports the CAPABILITY command, as described in RFC3501.

Note: The untagged response returned by the server indicates which authentication mechanisms are supported. Currently AUTH=DIGEST-MD5 and STARTTLS LOGINDISABLED are returned.

The QUOTA IMAP4 extension (RFC2087) and the IMAP METADATA extension (RFC5464) are also supported, as indicated in the CAPABILITY response.

2.1.1.4 FETCH

The VVM service supports the FETCH command, as described in RFC3501. Note: The Fetch item RFC822.SIZE, in addition to ALL, FAST, and FULL Fetch macros, return an inaccurate size value.

Upon receiving the Fetch Body content, the attachment is transcoded to the format supported by the client. The size returned with the Fetch item RFC822.SIZE command is the size of the original attachment format, as stored in the server and not necessarily the size of the content sent to the client after the server performed any transcoding.

A Partial Body Fetch, such as BODY[<section>]<<partial>> is not currently

supported. If a partial fetch command is performed, the system returns the following error message:

NO command not allowed

If the user has no credit, the system may return the following error message: NO reservation failed

2.1.1.5 GETMETADATA

The GETMETADATA command, as defined in RFC5464, is used for the client to query the VVM server about some information. The "depth" and "maxsize" command options are not supported.

All parameter names are defined in a namespace, with the following prefix: “/private/VVM/”

(13)

Table 3 Parameters supported by GETMETADATA, lists the parameters to be managed by the GETMETADATA command. It is envisaged that any new parameters included in this protocol will be managed via the METADATA extension rather than via SMS.

Variable Values Comment

GreetingTypesAllowed Comma Separated List of zero or more of:  personal  voiceSignature  busyGreeting  noAnswerGreeting  extendedAbsenceGreeting This parameter defines the list of the greeting announcements supported by the VVM server.

Table 3 Parameters supported by GETMETADATA Example of usage for the allowed greeting:

C: a GETMETADATA "" /private/VVM/GreetingTypesAllowed S: * METADATA "" (/private/VVM/GreetingTypesAllowed personal,voiceSignature,busyGreeting)

S: a OK GETMETADATA complete The possible error responses are:

S: a BAD GETMETADATA invalid parameter S: a NO GETMETADATA application error

If the GETMETADATA command is used with parameters not defined in RFC5464 or not supported by the server, the error response will be:

S: a BAD GETMETADATA invalid command S: a BAD GETMETADATA command not allowed

(14)

2.1.1.6 GETQUOTAROOT and GETQUOTA Commands

The VVM service supports the GETQUOTAROOT and GETQUOTA commands,

as described in RFC2087. All other commands in the quota extension are not supported.

Both the GETQUOTAROOT and GETQUOTA responses include the total quota and the quota per media types for all mailbox folders. The following is the GETQUOTA response syntax:

QUOTA "" (STORAGE [occupied] [total] MESSAGE [occupied]

[total] MESSAGE-soft [occupied] [total] empty-call-capture

[occupied] [total] empty-call-capture-soft [occupied] [total] number [occupied] [total] number-soft [occupied] [total] fax [occupied] [total] fax-soft [occupied] [total] voice [occupied] [total] voice-soft [occupied] [total] video [occupied] [total] video-soft [occupied] [total] x-voice-greeting [occupied] [total] x-voice-greeting-soft [occupied] [total])

Where:

 The media type returned in the GETQUOTAROOT or

GETQUOTA responses depends on the media types supported in the system, including the following:

o Voice

o Fax

o Video

o Greeting

o Empty Call Capture

o NUMBER message

Additional media types might be returned in the response. Such media types shall be ignored by the client.

 The soft quota represents the quota on which the

subscriber is being notified.

 The returned units depend on system initial setup. The

default setup is as follows:

o Voice messages = Length in seconds

o Video messages = Length in seconds

(15)

o Greetings messages = Length in seconds

o STORAGE = Size in KB

o Empty Call Capture and NUMBER messages = number of

messages

The VVM service can be configured to return total storage only or a specific media type, such as voice only, fax only, video only, or greeting only. In this case the response syntax is as follows:

* QUOTA "" (STORAGE [occupied][total])

2.1.1.7 LOGIN

The VVM service supports the LOGIN command, as described in RFC3501. For the error messages that can be returned for the LOGIN command, refer to Table 2 AUTHENTICATE Command Error Messages.

2.1.1.8 SEARCH

The VVM service supports the SEARCH command, as described in RFC3501. Note: The BODY, LARGER, SMALLER, and TEXT search criteria must not be used. SEARCH commands performed with one of these attributes can respond with incorrect results, due to the differences between the media format stored in the server and the format returned to the client upon the Body Fetch command.

2.1.1.9 SETMETADATA

The SETMETADATA command, as defined in the RFC5464, is used for the client to set annotations, and it is only available in authenticated or selected states.

All parameter names for this command are defined in a namespace, with the following prefix: “/private/VVM/”. It is envisaged that any new parameters included in the protocol will be managed via the METADATA extension rather than via SMS.

Table 4 Parameters supported by SETMETADATA, lists the parameters

(16)

Variable Values Comment

Accept A list of the media

formats supported by the VVM client. Legal values: List of one or more voice media types listed in Table 5 separated by a comma (,).

This parameter defines the media formats supported by the client.

A SETMETADATA command shall be issued by the client at the beginning of an IMAP session, right after a successful authentication with the VVM server.

Table 4 Parameters supported by SETMETADATA

Example of usage for the allowed greeting:

C: a SETMETADATA "" (/private/VVM/Accept "audio/amr,audio/wav; codec=g711a")

S: a OK SETMETADATA complete Possible error responses are:

2.1.1.10 STARTTLS

The VVM service supports the STARTTLS command, as described in RFC3501.

S: a BAD invalid parameter (wrong parameters) S: a NO application error (server error)

S: a BAD SETMETADATA unrecognized IMAP4 command (for backward compatibility in case of new client working against old server)

(17)

2.1.1.11 STATUS

The VVM service supports the STATUS command, as described in RFC3501. The client application must not perform the STATUS command on the Greetings folder. The VVM server synchronises the greetings in the Greetings folder with the greeting in the TUI storage upon a SELECT Greetings command. If the STATUS command is performed on the greeting folder, the system returns the following error message:

NO command not allowed

2.1.1.12 Supported IMAP4 Flags

The following standard IMAP4 flags are supported by the VVM service:  \Seen: Indicates that the message was played

\Deleted: Indicates that the message was deleted

\Recent: Indicates that the message is "recently" arrived in this mailbox

Note: Other standard or non-standard IMAP4 flags, must not be set by the client, except for the $CNS-Greeting-On flag (see section 2.7).

If non-supported flags are set by the client, the system returns the following error message:

(18)

2.1.2 MESSAGE RETRIEVAL:SUPPORTED MESSAGE TYPES

The following message types can be retrieved via the VVM service:  Voice

Video

Fax

ECC (Empty Call Capture): An empty voice message.

NM (Number Message): An empty voice message including the number to which the reply is sent.

MDN (Message Disposition Notification): A system message advising the subscriber whether the message has been displayed, deleted, dispatched, or denied

DSN (Delivery Status Notification): A system message notifying the subscriber of the message delivery status (Delivered, Failed, or Delayed).

Infotainment: A voice message deposited directly to the subscriber mailbox by an external application.

2.1.3 MESSAGE RETRIEVAL:SUPPORTED ATTACHMENT FORMATS

Upon a Fetch Body command, the VVM server transcodes the message attachment to a format supported by the client. A message may have multiple attachments or components. Depending on how the TUI formats forwarded messages, a component may also encapsulate multiple components.

All attachments are encoded in base64.

The table below lists the file formats supported by the protocol. Attachment Type File Formats MIME Types

Voice and Greeting attachments AMR 12200 audio/amr WAV g711a WAV g711u audio/wav; codec=“g711a” audio/wav; codec=“g711u” QCELP 13300 EVRC, 13000 audio/qcelp audio/evrc Video attachments

3gpp h263_amr video/3gpp; codec=“h263_amr”

Fax attachments PDF application/pdf

Scripted Text Text plain/text

(19)

2.1.4 VVMTUIFEATURES LIMITATIONS

The VVM service has the following limitations relating to specific TUI features:  Re-save: When a message is re-saved via the TUI, the

original message is deleted and the internal date of the new message reflects the last date in which the message was re-saved. The original message deposit date can be

obtained from the message Date header.

ECC from the same Calling Line Identification (CLI) Aggregation: When ECC messages from the same CLI are aggregated, the internal date of the resulted message reflects the last missed call date. The date in which the

ECC was first issued can be obtained from message Date

header.

Note: When these TUI features are used, the UID of the message on which the action was executed changes.

2.1.5 MESSAGE RETRIEVAL HEADER REFERENCE

The following types of headers are returned to the VVM client during message retrieval sessions:

Standard Root Level Message Retrieval Header Reference: Describes the standard message headers returned in the root level of the message

VVM Specific Root Level Message Retrieval Header Reference: Describes the VVM specific message headers returned in the root level of the message

Attachment Message Retrieval Header Reference: Describes the message header returned at the attachment level of the message

(20)

2.1.5.1 Root Level Message Retrieval Header Reference

The following headers are returned to the VVM client during message retrieval sessions at the root level:

From

Description: Defines the message originator. This header is mandatory.

Note: In case of a restricted CLI, the VVM client should not rely on the From field, because the default value can change depending on the voice mail deployment.

Legal Values: The phone number of the message originator, including the domain, in the following format: <phone-number>@<domain name>

Default Value: In case of a restricted CLI, Unknown@<domain name>

The client recognizes that the CLI is restricted if the left side of the email address is not a numeric phone number.

To

Description: Defines the phone line numbers associated with the message. Multiple addresses are separated by commas. This header is mandatory.

Legal Values: <main-phone>@<domain name> Default Value: N/A

(21)

Date

Description: Defines the date that the message was sent. This header is mandatory.

Note: It is the responsibility of the client to display dates in the time-zone of the client. The message received date is accessed from the internal date message attribute. The Internal date may not reflect the actual received time of the message when the Re-save or ECC aggregation features are used via the TUI (see VVM TUI Features Limitations).

Legal Values: As defined in RFC2822. Default Value: N/A

Example:

Sun, 2 Sep 2007 07:36:05 +0000 (UTC)

Subject

Description: Determines the message subject. This header is optional.

Note: The VVM client should not rely on the Subject header to detect the message type. The message type should be detected according to the Message-Context header. Legal Values: Alphanumeric string (maximum length 90

characters). Default Value: N/A

(22)

Message-Context

Description: Determines the message context. This header is mandatory.

For MDN and DSN message types, this header specifies the original message type.

Legal Values: Voice-message Video-message Fax-message

X-empty-call-capture-message X-number-message

X-voice-infotainment-message Default Value: N/A

Content-Duration

Description: Defines the length of the message, and is returned only for voice and video messages. This header is mandatory for voice and video messages.

Legal Values: Length of voice or video content, in seconds. Default Value: N/A

(23)

Content-Type

Description: The message content type. This header is used to recognize MDN and DSN messages. This header is mandatory.

Note: The VVM client can use this header value to distinguish between MDN or DSN messages and other messages.

Legal Values: For voice messages: Multipart/voice-message or Multipart/mixed

For fax messages: Multipart/fax-message or Multipart/mixed

For video messages: Multipart/video-message or Multipart/mixed

For ECC and number messages: Text/Plain For DSN messages: Multipart/report: report-type=delivery-status

For MDN messages: Multipart/report; type=receipt-disposition-notification (or report-type=disposition-notification)

For Infotainment messages: multipart/mixed Default Value: N/A

MIME-Version

Description: Determines the MIME version. This header is mandatory. Legal Values: 1.0 (Voice Version 2.0) Default Value: 1.0 (Voice Version 2.0)

Importance

Description: Determines the message priority. This header is optional.

Legal Values: Normal High Default Value: Normal

(24)

Sensitivity

Description: Determines the message sensitivity. This header is optional.

Legal Values: Private Confidential Personal Default Value: N/A

X-Content-Pages

Description: Defines the number of fax pages in a fax message, and is relevant only for fax messages.

This header is mandatory for fax messages. Legal Values: Integer

Default Value: N/A X-Original-Msg-UID

Description: Used in case the message is the result of on-demand (asynchronous) transcription that replaced an original voice message. It contains the UID of that original voice message which no longer exists in the voice mail system (and may exist in the client cache).

This header is optional.

Note: The current message contains both voice message and the text transcription.

Legal Values: UID as defined in RFC 3501 Default Value:N/A

2.1.5.2 Attachment Message Retrieval Header Reference

The following header is returned to the VVM client during message retrieval sessions per attachment:

Content-Type

(25)

The name and application parameters can optionally be added to this header.

This header is mandatory. Legal Values: For Voice Messages:

audio/wav; codec=g711a audio/wav; codec=g711u audio/amr

audio/qcelp

For Fax Messages: application/pdf

For Video Messages:

video/3gpp; codec="h263_amr" For Scripted Voice Messages: text/plain

For nested messages: Message/rfc822 Default Value: N/A

X-Transcription

Description: This header is added to text attachments (transcription result). It contains the content ID of the transcripted attachment.

This header is optional.

Legal Values: Source-ID= <id>, id value MUST equal to the value of Content-ID header of the transcripted body part (Content-ID header legal value is according to RFC 2111)

(26)

2.2 M

ESSAGE

D

EPOSIT

I

NTERFACE

D

ESCRIPTION

The VVM service supports voice message deposit via the Simple Mail Transfer

Protocol (SMTP) protocol as described in RFC2821. SMTP authentication uses the AUTH mechanism command as described inRFC 2554.

The client may optionally use STARTTLS from RFC2595, RFC3207, RFC4642 for session encryption.

In the SMTP AUTH (Digest MD5) command, the client is authenticated with a predefined username and password, supplied as part of the STATUS SMS. For an example of an SMTP authentication command, see SMTP MD5 Authentication Example.

Note: Only voice messages can be deposited via the VVM service.

Only the Digest-MD5 algorithm is supported in the AUTH mechanism command.

Delivery Status Notification (DSN) messages are deposited in the sender’s mailbox if one of the message recipients was not located. See Voice DSN Message Example for an example of DSN.

For details about the headers included in deposited messages, see:

 Standard Message Deposit Header Reference (section

2.2.1): Describes message deposit headers that require specific values

 VVM Specific Message Deposit Header Reference

(section 2.2.2): Describes additional headers that can be added to the deposited message

 Message Deposit Attachment Header Reference (section 2.2.3):

Describes attachment headers that require specific values

When forwarding or replying, the original should be attached as a message [RFC822] mime component. Putting the original as a message [RFC822] component in the reply/forward preserves all the header information of the original message. The TUI might need this information. The VVM server might have to reformat the message to the format that the TUI expects.

2.2.1 STANDARD MESSAGE DEPOSIT HEADER REFERENCE

(27)

From

Description: The Phone number and domain of the message sender.

This header is mandatory.

Legal Values: <phone-number>@<domain name> Default Value: N/A

Example: 1234@Example.com

To

Description: Defines the message addressee. Multiple addresses are separated by commas.

This header is mandatory.

Note: RCPT TO envelope headers are used to resolve the destination. The VVM client must set the RCPT TO envelope header in addition to the message TO field.

Legal Values: <main-phone>@<domain name> Default Value: N/A

Date

Description: Defines the date that the message was sent. This header is mandatory.

Legal Values: Date and time as defined by RFC2822 Default Value: N/A

Example:

Sun, 2 Sep 2007 07:36:05 +0000 (UTC) Subject

Description: Defines the message subject. This header is optional.

Note: The subject header is not available via TUI sessions, and can be displayed through web UI access.

(28)

The subject set by the client may be overridden by the VVM system with default values.

Legal Values: Alphanumeric string (maximum length 90 characters)

Default Value: N/A

Message-Context

Description: Defines the standard header for message presentation, based on RFC 3458.

This header is mandatory. Legal Values: Voice-message

Default Value: N/A

Content-Duration

Description: Defines the length of the message in seconds.

This header is mandatory. Legal Values: Integer

Default Value: N/A Content-Type

Description: Determines the message content-type. This header is mandatory.

Legal Values: Multipart/mixed; Default Value: N/A

MIME-Version

Description: Defines the MIME version. This header is mandatory. Legal Values: 1.0

(29)

Importance

Description: Defines the message importance. This header is optional.

Legal Values: High

Normal (including Low importance) Default Value: Normal

Sensitivity

Description: Determines the message sensitivity. This is an optional header.

Legal Values: Private Confidential Personal Default Value: N/A Expires

Description: Determines the message expiration date, after which the message is automatically purged by the server periodic process.

This is an optional header. Legal Values: Date in the following format:

DAY, D MMM YYYY HH:MM:SS (+-)TTTT Default Value: N/A

Example:

(30)

2.2.2 VVMSPECIFIC MESSAGE DEPOSIT HEADER REFERENCE

The following additional header fields can be added to the deposited message:

X-CNS-Messaging-Action

Description: Determines the messaging action of the message.

This header is relevant only for messages created using a messaging service and is applicable only to some VVM systems.

This header is optional.

Legal Values: reply = Indicates that the message is a reply to a subscriber’s message

forward = Indicates that the message was forwarded to the subscriber by another subscriber

Default Value: N/A

2.2.3 MESSAGE DEPOSIT ATTACHMENT HEADER REFERENCE

The following headers must be set by the VVM client in the attachment level: Content-Type

Description: Determines the attachment content-type. This header is mandatory.

Legal Values: message/rfc822 Multipart/mixed

See Table 5 Supported Attachment Formats

for list of content-types.

Default Value: N/A

Content-Transfer-Encoding

Description: Determines the content transfer encoding. This header is mandatory.

(31)

Default Value: N/A Content-Disposition

Description: Determines the attachment, along with the filename.

The voice mail system ignores the path for the file.

This header is mandatory.

Legal Values: attachment; filename="<file name>" Default Value: N/A

Example:

attachment; filename="test.wav" Content-Duration

Description: Defines the length of the voice attachment in seconds.

This header is mandatory. Legal Values: Integer

(32)

2.3 TUIPASSWORD CHANGES INTERFACE DESCRIPTION

The VVM service enables the client to change the subscriber’s TUI password via a custom IMAP4 command. The change password command can be invoked only in the authenticated state, meaning that the user must be in the authenticated IMAP4 session.

The password must be made up of numeric digits only.

The password minimum and maximum length will be sent to the client in the STATUS SMS message (see STATUS SMS Description (System Originated)).

For details about the command syntax used to change TUI passwords, see:

 Change Password Request Syntax (section 2.3.1)

 Change Password Response Syntax (section 2.3.2)

2.3.1 CHANGE PASSWORD REQUEST SYNTAX

The change password request syntax is as follows:

CNS1 XCHANGE_TUI_PWD PWD=<Value> OLD_PWD=<Value> The change password request syntax uses the following parameters:

PWD

Description: Defines the new TUI password. This parameter is mandatory. Legal Values: Integer

Default Value: N/A

OLD_PWD

Description: The current TUI password that is being replaced.

This parameter is mandatory. Legal Values: Integer

Default Value: N/A

In case of invalid command syntax, the following error is returned:

(33)
(34)

2.3.2 CHANGE PASSWORD RESPONSE SYNTAX

Upon successfully changing the password, the following response is returned: CNS1 OK password changed successfully

The following errors can also be returned in the change password response: CNS1 NO password too short

CNS1 NO password too long CNS1 NO password too weak

CNS1 NO old password mismatch

CNS1 NO password contains invalid characters

(35)

2.4 CHANGE TUILANGUAGE INTERFACE DESCRIPTION

The VVM service enables the client to change the subscriber’s voice mail

language via a custom IMAP4 command. The change language command can be invoked only in the authenticated state, meaning that the user must be in the authenticated IMAP4 session.

The system supported languages is sent to the client in the STATUS SMS message (see STATUS SMS Description (System Originated))

For details about the command syntax used to change TUI languages, see:

 Change Language Request Syntax (section 2.4.1)

 Change Language Response Syntax (section 2.4.2)

2.4.1 CHANGE LANGUAGE REQUEST SYNTAX

The change language request syntax is as follows:

CNS2 XCHANGE_VM_LANG LANG=<Language number>

The change language request syntax includes the following parameter: Lang

Description: Determines the new language, and is one of the system supported languages as returned in the STATUS SMS (see STATUS SMS Description (System Originated)).

This parameter is mandatory.

Legal Values: String maximum 5 digits in the following format:

<lang code>.<variant>

The "lang code" is an ISO 639-2 value, 3 characters max

The "variant" is optional and is one (values 0 to 9) digit indicating a speech characteristic or accent extension (for example a male or female voice). The definition of the variant value will be configured in the VVM client and server sides according to the operator policies and requirements.

(36)

Examples of valid values: Lang=eng

Lang=eng.1

Default Value: N/A

In case of invalid command syntax, the following error message is returned: No unknown command

(37)

2.4.2 CHANGE LANGUAGE RESPONSE SYNTAX

Upon a successful language change, the following response is returned: CNS2 OK language changed successfully

The following possible errors can also be returned in the change language response:

CNS2 NO invalid language CNS2 NO system problem

(38)

2.5 CLOSE NUTINTERFACE DESCRIPTION

If available, the New User Tutorial (NUT) is implemented in the client. It is usually played the first time the user uses the VVM application if the subscriber status is “new subscriber” (see STATUS SMS Description (System Originated)). The VVM service enables the client to disable the New User Tutorial (NUT) flag in the server via a custom IMAP4 command to change the provisioning status of the customer in order for the server to avoid re-playing the TUI NUT. The CLOSE NUT command can be invoked only in the authenticated state, meaning that the user must be in the authenticated IMAP4 session.

For details about the command syntax used to change TUI languages, see:

 CLOSE NUT Request Syntax (section 2.5.1)

 CLOSE NUT Response Syntax (section 2.5.2)

2.5.1 CLOSE NUTREQUEST SYNTAX

The CLOSE NUT request syntax is as follows: CNS3 XCLOSE_NUT

In case of invalid command syntax, the following error is returned: No unknown command

2.5.2 CLOSE NUTRESPONSE SYNTAX

Upon successful NUT CLOSE, the following response is returned: CNS3 OK NUT closed

Note: A successful CLOSE NUT command changes the VVM subscriber provisioning status and triggers a STATUS SMS message (see STATUS SMS Description (System Originated)).

The following error can also be returned as part of the CLOSE NUT response: CNS3 NO system error

(39)

2.6 O

N

D

EMAND

A

UDIO

M

ESSAGE

T

RANSCRIPTION

C

OMMAND

S

ERVICES FROM

V

ISUAL

V

OICE

M

AIL

C

LIENT

The VVM service enables the client to order an audio message transcription via a custom IMAP4 command. It allows also START/STOP the transcription service.

For details about the command syntax used to trigger the transcription, see:

 On-demand transcription Request Syntax (section 2.6.1)

 On-demand transcription response Syntax (section 2.6.2)

For details about the command syntax used to START/STOP the service, see:

 START/STOP service request Syntax (section 2.6.3)

 START/STOP service response Syntax (section 2.6.4)

2.6.1 ON-DEMAND TRANSCRIPTION REQUEST SYNTAX

The on-demand transcription request syntax is as follows: CNS4 XTRANSCRIBE_ UID=< UID>

The on-demand transcription request syntax includes the following parameter: UID

Description: Determines UID of the audio message to be transcribed on-demand

This parameter is mandatory.

Legal Values: UID as defined in RFC 3501 Default Value: N/A

In case of invalid command syntax, the following error message is returned:

No unknown command

2.6.2 ON-DEMAND TRANSCRIPTION RESPONSE SYNTAX

Upon a successful on-demand transcription request, the following response is returned:

(40)

CNS4 OK Transcription order sent successfully

The following possible errors can also be returned in the on-demand transcription response:

CNS4 NO invalid UID

CNS4 NO transcription service not available CNS4 NO system error

2.6.3 AUTOMATIC TRANSCRIPTION SERVICE START/STOPREQUEST SYNTAX

The VVM service allows the VVM client to control the automatic transcription service status. While the automatic transcription service is enabled, every new voice message deposited to the mailbox will be transcribed.

The automatic transcription START/STOP request syntax is as follows: CNS5 XTRANSCRIPTION_SERVICE_ STATE=<START|STOP> The command includes the following parameter:

STATE

Description: Determines the requested state of the automatic transcription service.

Legal Values: "START" or "STOP" strings Default Value: N/A

In case of invalid command syntax, the following error message is returned: No unknown command

2.6.4 AUTOMATIC TRANSCRIPTION SERVICE START/STOPRESPONSE SYNTAX

Upon a successful automatic transcription state change request, the following response is returned:

(41)

Where <state> is either "stopped" or "started".

The following possible errors can also be returned in the response: CNS5 NO Transcription service remains unchanged CNS5 NO Transcription service unreachable

(42)

2.7 G

UIDELINES FOR

G

REETINGS AND

V

OICE

S

IGNATURE

M

ANAGEMENT

The VVM service enables the client to manage personalised greetings and voice signatures. Not all voice mail users want to leave a fully personalised greeting. The Voice Signature (VS) option allows users to leave a very short recording typically a couple of seconds long. The Voice Mail System would use this message, the voice signature, to replace the phone number in the default system voice mail greeting that a user hears when the call is diverted to the voice mail system. Thus, for example, instead of hearing the response "You have reached the mailbox of 12345678910, please leave a message after the beep", one would hear "You have reached the mailbox of Michel Arnaud, please leave a message after the beep".

Greetings (personalised and VS) are stored in the server in the subscriber’s

Greetings Folder, in the format of a multipart-mixed message with an audio attachment. Personalised greetings and VS are distinguished by a specific header, as described in section 2.7.3.

Several personalised greetings or VS can be flagged as “ON”. This flag

indicates to the server that these messages are to be used by the voice mail

system in the TUI session, according to the voice mail logic.

If several greetings of the same type are simultaneously flagged as ($CNS-Greeting-On) the voice mail system will play the one with the smallest message-sequence. If no personalised greeting or VS are flagged as ($CNS-Greeting-On) then the default system voice mail greeting will be played by the voice mail system.

Greeting headers that require specific values and are set by the VVM client are described in section 2.7.3.

See the following for details about how to upload or delete greetings or VSs from the Greetings Folder on the VVM server:

 Uploading a Greeting or VS section 2.7.1

 Deleting a Greeting or VS section 2.7.2

Note:

Greeting management error responses are formatted according to the IMAP4 standard.

In order to perform actions on the Greetings folder, the client application must issue the SELECT GREETINGS command.

(43)

The client application must not perform STATUS command on the Greetings Folder.

2.7.1 UPLOADING A GREETING OR VS

This procedure describes how to upload a personalised greeting or VS to the Greetings Folder.

How:

1. Use the IMAP4 APPEND command to append the message to the Greetings Folder.

2. In order to activate a greeting, set the $CNS-Greeting-On

flag.

Note:

The VVM client can append several personalised greetings and several VS to the Greetings folder, up to the quota limit.

The flag can be set as part of the APPEND command or with a dedicated store command.

The client must limit the recorded greeting or VS length according to the maximum greeting or VS length received in the STATUS SMS message (see STATUS SMS Description (System Originated)).

(44)

2.7.2 DELETING A GREETING OR VS

This procedure describes how to delete a greeting or VS from the Greetings Folder.

How:

1. Flag the greeting or VS as deleted. 2. Send the Expunge command.

Note:

Deleted greetings or VS flagged as ($CNS-Greeting-On) are not played by

the VVM system, and the default greeting is played instead.

2.7.3 GREETING HEADER REFERENCE

The following greeting and VS headers require specific values, and must be set by the client.

X-CNS-Greeting-Type

Description: Determines the greeting type. This header is mandatory.

Legal Values:normal-greeting For Personalised greeting voice-signature For VS (Name greeting) busy-greeting For a personalised greeting

when busy. If not recorded,

normal greeting is used. If

recorded, the normal greeting is used for the “no-answer” case, and the busy-greeting used for the “busy” case.

extended-absence-greeting If this greeting

is flagged “on”, it takes

precedence over “normal” and “no-answer” greetings.

(45)

From

Description: The phone number@Domain of the message sender.

This header value is ignored by the server. Legal Values: N/A

(46)

Subject

Description: Defines the message subject.

This header value is ignored by the server. Legal Values: N/A

Default Value: N/A Content-Type

Description: Determines the message content type.

This header is mandatory and appears in the message header and in the MIME part header.

The greeting must include a single voice attachment at the root level only.

Legal Values: Message header content-type: multipart/mixed; [boundary=<boundary -string>]

MIME part content-type (must be encoded in base64):

The valid values are the audio MIME types in Table 5 Supported Attachment Formats Default Value: N/A

To

Description: Defines the message addressee.

This header value is ignored by the server. Legal Values: N/A

Default Value: N/A

MIME-Version

Description: Defines the MIME version. This header is mandatory. Legal Values: 1.0

Default Value: N/A

Content-Transfer-Encoding

Description: Defines the content transfer encoding. This header is mandatory.

(47)

Legal Values: base64 Default Value: N/A

(48)

2.8 P

ROVISIONING

S

TATUS

The provisioning status of a subscriber determines their access level to VVM services.

(49)

The table below describes the possible status of VVM provisioning. VVM

Provisioning Status

Description VVM Service Impact

Subscriber Unknown

The subscriber is not provisioned to the VVM service or does not have a mailbox in the voice mail system

VVM service is not active:

 SYNC SMS will not be sent from the server.  The server may send legacy notifications for voice

mail deposit.

 STATUS SMS may be sent from the server.  The client must not initiate IMAP4 sessions.  The server will block IMAP4 session initiation

attempts. Subscriber

Provisioned

The subscriber is provisioned to the VVM service, while the VVM service is not activated yet.

VVM service is temporarily not active:  SYNC SMS will not be sent from the server.  The server may send legacy notifications for voice

mail deposit.

 STATUS SMS may be sent from the server.  The VVM server will block IMAP4 session

initiation attempts.

 The VVM client may send activate SMS to change provisioning status to New or Ready.

Subscriber New

The subscriber is provisioned to the VVM service, and the VVM service is active, while the subscriber has not gone through NUT (New User Tutorial) session.

VVM service is active:

 SYNC SMS may be sent from the server.

 The server may send legacy notifications for voice mail deposit.

 STATUS SMS may be sent from the server.  The VVM server allows IMAP4 session initiation

attempts.

 The VVM client may issue CLOSE_NUT command (to change provisioning status to READY).

 The VVM client may send de-activate SMS to change the provisioning status to Provisioned. Subscriber

Ready

The subscriber is provisioned to the VVM service, and the VVM service is active, while the subscriber has already gone through NUT session.

VVM service is active:

 SYNC SMS may be sent from the server.

 The server may send legacy notifications for voice mail deposit.

 STATUS SMS may be sent from the server.  The VVM server allows IMAP4 session initiation

attempts.

 The VVM client may send de-activate SMS to change the provisioning status to Provisioned Subscriber

Blocked

The subscriber mailbox is Blocked

VVM service is temporarily not active:  SYNC SMS may be sent from the server.

 The server may send legacy notifications for voice mail deposit.

 STATUS SMS may be sent from the server.  The VVM server will block IMAP4 session

initiation attempts.

(50)

2.9 VVM

SMS

I

NTERFACE

D

ESCRIPTION

The VVM service includes the following types of SMS messages:

 System Originated SMS Messages: SMS messages sent to

the VVM client to notify the client about a specific event in the subscriber’s mailbox or profile.

 Mobile (Client) Originated SMS Messages: SMS messages

that enable the client to query the system about the subscriber’s status, as well as to turn the service notifications on or off.

The SMS format is based on the Terminal type, which is stored in the subscriber’s profile either during the service activation process (see Activate SMS (Client Originated)) or by the operator’s customer support.

The VVM service sends the VVM notifications to the client’s VVM application port. The notifications have specific characteristics, as described in System Originated SMS Message Characteristics.

Note: Depending on the Terminal type, it is possible to configure the VVM service to send legacy notifications in addition to the VVM notifications, in order to support a scenario in which the VVM subscriber SIM is switched to a non-VVM enabled Terminal that cannot process VVM notifications.

If regular notifications are sent in addition to VVM notifications, it is the responsibility of the client to filter out the regular notifications according to the SMS source address or SMS Protocol Identifier.

2.9.1 SYSTEM ORIGINATED SMSMESSAGES

The VVM service sends the following SMS messages to the client:  SYNC SMS: Notifies the client that the status of a message

or greeting in the mailbox may have been changed.

For details see SYNC SMS Description (System Originated).

STATUS SMS: Notifies the client that the VVM subscriber’s provisioning status was changed.

(51)

The maximum length for system originated SMS messages is 160 characters for 7bit encoding and 140 characters for 8bit encoding. It is recommended not to exceed the maximum SMS message length.

If the SMS message exceeds the maximum message length, the Short Message

Service Centre (SMSC) for both the operator and the client must support SMS concatenation.

For more details about system originated SMS messages, see System Originated SMS Message Characteristics.

2.9.1.1 SYNC SMS Description (System Originated)

SYNC SMS messages are sent from the system to the client in order to notify the client that the status of a message or greeting in the mailbox may have changed. A SYNC SMS message will be sent when:

 A new message has been deposited in the subscriber’s

mailbox,

Additionally a SYNC SMS may be sent when one or more of the following events occur:

 Message purge due to retention time exceeded,

 TUI session logout,

 Greeting changed via the TUI, including a personalised

greeting or VS recorded or deleted.

In the SYNC SMS message, both the Client prefix and Prefix fields are

followed by a colon (:), and all other fields are followed by semicolons (;).

Each field is represented by the field name, an equal sign (=), and a legal

value. Spaces are not allowed between parameters, although parameter values may include spaces.

For details about SYNC SMS notification messages see SYNC SMS Field Reference and SYNC SMS Notification Examples.

2.9.1.2 SYNC SMS Field Reference

(52)

Client prefix

Description: The definition is dependant on the client. Also see Client prefix in Activate SMS section 2.9.2.2.

This field is mandatory.

Legal Values: Configurable string, unlimited length, always followed by a colon (:)

Default Value: //VVM Prefix

Description: Determines the SMS type.

This field is always followed by a colon (:). This field is mandatory.

Legal Values: String, maximum four characters SYNC

Default Value: SYNC

ev

Description: Determines the event that triggered the SYNC SMS.

This field is mandatory.

Legal Values: String, maximum three characters;

NM = New message deposit,or update of a message with a text transcription,

MBU = Mailbox update, including TUI session end or message purge,

GU = Greetings/VS update. Default Value: N/A

id

Description: Defines the message UID.

This field is returned for new message events only, and the value can be used by the client for the IMAP4 FETCH command, used to retrieve the message.

(53)

This field is mandatory.

Legal Values: New message UID, maximum 21 digits. Default Value: N/A

c

Description: Defines the number of new messages in the inbox.

The client may use this field to show the number of new messages.

This field is mandatory. Legal Values: Integer, maximum five digits. Default Value: N/A

t

Description: Determines the message type. This field is returned for new message events only.

The client may use this field to show the type of message.

This field is mandatory.

Legal Values: Maximum length one character; v = Voice,

o = Video, f = Fax,

i = Infotainment, e = ECC.

Default Value: N/A

s

Description: Defines the message sender (message

originator Mobile Subscriber Integrated

Services Digital Network Number (MSISDN)). This field is returned for new message events only.

(54)

The client may use this field to show the message sender before initiating IMAP communication.

This field is mandatory.

Legal Values: Numeric string (phone number in E164 format), maximum length 29 digits (30 including the null terminator).

Default Value: N/A dt

Description: Defines the deposit date and time, in the time zone of the VM server. This field is returned for new message events only.

The client may use this field to show the

deposit time before initiating IMAP

communication.

This field is mandatory.

Legal Values: Date and time in DD/MM/YYYY HH:MM TZ format.

Maximum length 22 characters. Default Value: N/A

Example:

02/08/2008 12:53 +0200 l

Description: Determines the message length.

This field is returned for new message events only.

This field is dependent on system

configuration, and is used in the default setup. The client may use this field to show the length of message before initiating IMAP communication.

This field is mandatory.

Legal Values: Numeric string, maximum five digits, as follows:

Voice, Video, and Infotainment messages: Length in seconds,

Fax messages: Number of pages, Number and ECC messages: 0.

(55)

Default Value: 0

2.9.1.3 SYNC SMS Notification Examples

The following is an example of system originated SYNC SMS notifications:

//VVM:SYNC:ev=NM;id=3446456;c=1;t=v;s=01234567898;dt=02/08/2008 12:53 +0200;l=30

Fields used in the SYNC SMS messages are described in SYNC SMS Field Reference.

2.9.1.4 STATUS SMS Description (System Originated)

STATUS SMS messages are sent from the system to the client to notify the client about provisioning status changes. The VVM client is also able to query the VVM service for the current status.

For details about provisioning status, see section 2.8.

In the STATUS SMS message, the mandatory Client prefix field is following by

a colon (:), as well as the mandatory Prefix field. All other fields are followed

by semicolons (;). Each field is represented by the field name, an equal sign

(=), and a legal value. Spaces are not allowed.

For details about STATUS SMS notification messages see STATUS SMS Field Reference and STATUS SMS Field Examples.

(56)

2.9.1.5 STATUS SMS Field Reference

The following fields are used in the STATUS SMS text that is sent to the VVM client:

Client prefix

Description: The definition is dependant on the client. Also see Client prefix in Activate SMS section 2.9.2.2.

This field is mandatory.

Legal Values: Configurable string, unlimited length, always followed by a colon (:).

Default Value: //VVM

Prefix

Description: Determines the SMS type.

This field is always followed by a colon (:)

This field is mandatory.

Legal Values: String, maximum six characters STATUS

Default Value: STATUS

st

Description: Determines the subscriber’s provisioning status.

For details about provisioning status transitions, see section 2.8.

This field is mandatory.

Note: Depending on system configuration, the st value may appear between quotation marks.

For example: st="N"

Legal Values: Maximum length one character N = Subscriber New

(57)

P = Subscriber Provisioned U = Subscriber Unknown B = Subscriber Blocked Default Value: N/A

rc

Description: Determines the return code. When the VVM provisioning status is unknown one of the following codes is returned:

Mailbox unknown: The user is unknown by the voice mail system, he does not have any voice mail box provisioned, even with a non-VVM service.

VVM not provisioned: The user has a voice mail box provisioned on the voice mail system, but he does not belong to a class of service allowing him to use the VVM service. VVM not activated: The user has been

provisioned with a VVM service on the system but the VVM service activation has failed. VVM client unknown: The Client Type or Protocol Version is unknown.

VVM mailbox not initialised: The subscriber's mailbox has not yet been initialized via the TUI, so the VVM service cannot be activated. This field is mandatory.

Legal Values: Maximum length one character; 0 = Success, 1 = System error, 2 = Subscriber error, 3 = Mailbox unknown, 4 = VVM not activated, 5 = VVM not provisioned, 6 = VVM client unknown,

Figure

Table 1 Supported IMAP4 Commands

Table 1

Supported IMAP4 Commands p.9
Table 3 Parameters supported by GETMETADATA, lists the parameters to be  managed  by  the  GETMETADATA  command

Table 3

Parameters supported by GETMETADATA, lists the parameters to be managed by the GETMETADATA command p.13
Table 4 Parameters supported by SETMETADATA

Table 4

Parameters supported by SETMETADATA p.16
Table 5 Supported Attachment Formats

Table 5

Supported Attachment Formats p.18
Figure 1: VVM Provisioning Status Transitions

Figure 1:

VVM Provisioning Status Transitions p.48
Table 4: VVM Provisioning States

Table 4:

VVM Provisioning States p.49