Subject: [SIP] mwi in SIP: supplying waiting message lists

From: Ilya Slain <[email-masked]>
Date: Sun, 23 Apr 2000 10:07:50 -0700 (PDT)

There has recently been some discussion on the way to
do message waiting indication (mwi) using SUBSCRIBE/
NOTIFY SIP extensions.  However, I am not aware of
any proposals to for specifying waiting message list
summary, supplied in mwi NOTIFY message.  In other
words, there is no proposed way to supply the summary
of messages being available in the voice mail system.

So I would like to submit a brief sample proposal to
do
message waiting indication with message summary using
SIP
SUBSCRIBE/NOTIFY.  This is based on the recent
SUBSCSRIBE/
NOTIFY IETF draft:
http://search.ietf.org/internet-drafts/draft-roach-sip-subscribe-notify-00.txt

The main purpose of this proposal is to start the
discussion
on the topic with the aim of eventually submitting an
Inf. Draft.

1. Subscription
----------------
Event field specifies "mwi" field (message waiting
indication).
There is no message body.

SUBSCRIBE ...
To:             ...
From:           ...
Call-ID:        ...
CSeq:           ...
Contact:        ...
Expires:        ...
Event:          mwi
Content-Length: 0

2. Notification
-----------------
Event field specifies "mwi".
Message body specifies the message summary.

NOTIFY
To:             ...
From:           ...
Call-ID:        ...
CSeq:           ...
Contact:        ...
Expires:        ...
Event:          mwi
Content-Type:   application/um
Content-Length: 148

VOICEMAIL: <TOTAL_MESSAGES>; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
EMAIL:     <TOTAL_MESSAGES>; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
FAX:       <TOTAL_MESSAGES>; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2
VIDEO:     <TOTAL_MESSAGES>; U:n1/n2; S:n1/n2;
F:n1/n2; R:n1/n2; A:n1/n2; D:n1/n2

where TOTAL_MESSAGES, n1, n2 are integers
U = UNTOUCHED
S = SKIPPED
F = FLAGGED
R = READ
A = ANSWERED
D = DELETED

For example:
voicemail: 10; U:3/1; S:1/0; F:0/0; R:5/2; A:1/0;
D:0/0
where U: 3/1  indicates that there are 3 untouched
messages, 1 of which is urgent.

More formal grammar for the application/um message
body:

application_um_message_body = message_summary_list
message_summary_list = message_summary "\n"
message_summary_list | NULL
message_summary = message_type ": " total_messages ";
" typed_summary_list
message_type = "VOICEMAIL" | "EMAIL" | "FAX" | "VIDEO"
total_messages = INTEGER
typed_summary_list = typed_summary ";"
typed_summary_list | NULL
typed_summary = type ":" number_of_messages "/"
number_of_urgent_messages
type = "U" | "S" | "F" | "R" | "A" | "D"
number_of_messages = INTEGER
number_of_urgent_messages = INTEGER

______________________________________________________________________________

Ilya Slain                       ||        ||         
  Cisco Systems, Inc.
Technology Center               .||.      .||.        
           Building 9
                               .||||.    .||||.       
170 West Tasman Drive
Tel:    408.527.9446       ...||||||||..||||||||...   
  San Jose, CA  95134
Fax:    408.527.1221       C i s c o  S y s t e m s
E-Mail: [email-masked]
____________________________________________________________________________

__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 28 Apr 2000 02:53:31 -0400

Message waiting has come up numerous times. I agree we should have a
solution based on a subscribe/notify method. Just to note, I do believe
there are other ways to do this that can make use of other existing
protocols. For systems that use email-based voicemail storage (like
VPIM), IMAP may actually be the appropriate protocol for message
waiting. I accept that IMAP is gross overkill for systems that just want
voicemail only message waiting lamps, so something a little more focused
would be useful.

As pointed out in another thread, the described mechanism of enumerating
events in SUBSCRIBE is too restrictive and not compatible with pint.
Rather than attacking these bit at a time, I think it would be
tremendously valuable to list the general set of events and state
associated with SIP communications systems that one might wish to
subscribe to. This will help us figure out the set of things we might
like to build in to some set of "sip presence subscription documents",
which are carried in SUBSCRIBE messages to indicate what is being
subscribed to.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (732) 741-4778
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 28 Apr 2000 11:14:23 -0400

> voicemail only message waiting lamps, so something a little more focused

It should also be noted that IMAP and POP are client-initiated, i.e.,
the client has to poll periodically.

> which are carried in SUBSCRIBE messages to indicate what is being

We should also avoid a new syntax for each type of event, if at all
possible.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs