[SIPForum-discussion] Lighting the MWI

Rosen, Brian Brian.Rosen at neustar.biz
Wed Jun 2 00:25:45 UTC 2010

It's not clear to me if you are trying to implement the entire voicemail service, or just the MWI.

I'm going to assume the latter.

If all your app needs to do is light the MWI, you don't register.

Your app shouldn't be subscribing, assuming the MITEL is compliant with the MWI RFC.  Instead, the phones should be subscribing to your app.  This isn't a UAC/UAS thing, the roles are Notifier and Subscriber.  You have to be the Notifier, not the Subscriber.

You should be sending the NOTIFY to the phone, not receiving a NOTIFY from the controller.

Now, it's possible that the MITEL doesn't follow the RFCs and has some proprietary mechanism.  If that is the case, I can't help you.

Phones usually only have one MWI source: whatever VM server they use.  They usually can't subscribe to more than one MWI source.

The sequence for MWI according to the standards is
1) phone subscribes to VM server or other MWI source once when they boot.  The subscription is refreshed so it is always active
2) VM server or MWI source sends NOTIFY to change state of MWI lamp.


On Jun 1, 2010, at 6:34 PM, Michael Reynolds wrote:

Interesting, Brian and I am beginning to understand further.  Here is what I am attempting to do.  Perhaps you can point out the spot(s) where I am misunderstanding?

1.      My IVR is a VXML system that handles all of the TBT and other functionality either via a SIP REFER or via a bridged transfer depending upon the circumstances.
2.      If the caller ends up in the “Mailbox” which is of course merely another set of VXML/CCXML forms, he or she can leave a message.
3.      My VXML/CCXML application sends a web service call to the main Web-App server (IIS in this case) telling it to send an email containing the wav message to the mailbox holder.
4.      It also sends another web service command to the IIS server telling it to begin a series of SIP tasks (the TRANSACTION)
a.       This application becomes the UAC (Client) and REGISTES itself with the UAS (SIP SERVER) on the Mitel controller (3300)
b.      The application awaits the 200-OK which it receives in one or two tries
c.       The Application then SUBSCRIBES to the REGISTRAR passing the address of the handset whose light needs to be activated as one of the arguments
d.      This client then awaits the NOTIFY from the UAS and will send its ACK (here is where I believe that I am not understanding).

My device is not a UAS.  Should it be?  If so, (briefly) how would the phone “SUBSCRIBE” to it?  Can the phone SUBSCRIBE to multiple servers (remember that it still needs to register with and subscribe to the 3300’s SIP servers)?

This is a bit confusing but follow the numbers.

<image002.png> 1. TDM or VOIP call
2. Grabbed by Mitel 3300
3. Sent to Speech enabled IVR
4. Company grammar is built on the fly and caller asks for an employee.
5. IVR queries the speech server
6.ASR queries DB
7.DB returns callee data
8 ASR Returns Callee data
9 Caller is transferred
10. RNA or BUSY, IVR Takes back call and caller leaves message.
11. IVR sends SIP MWI Transaction to light  MWI

Michael Reynolds
CrystalVoice, LLC
Tel: 772-539-9034
Cell: 772-834-5460

From: Rosen, Brian [mailto:Brian.Rosen at neustar.biz]
Sent: Tuesday, June 01, 2010 3:39 PM
To: mreynol5 at mkrpro.com<mailto:mreynol5 at mkrpro.com>
Cc: discussion at sipforum.org<mailto:discussion at sipforum.org>
Subject: Re: [SIPForum-discussion] Lighting the MWI

What are you registering to and why are you doing that?  if your UAC is a voicemail system, then it would probably register, but a device that lights the lamp, if that is all it does, wouldn't register.

You then say it can SUBSCRIBE. Who is "it"?  The phone (not the server) should be subscribing to your device.

Then you say the NOTIFY times out.  Who is timing out?  Your device (which should be sending the NOTIFY) or the phone (which should be receiving it)?

I'll repeat in different words what I said the last time.

The phone, the device with a lamp, subscribes to a system that manages the light (a voicemail system for example).  The system sends a NOTIFY to the device to light the lamp.  That is all there is for the lamp: Subscribe by the phone to the VM, notify by the VM to the phone to change lamp status.  To get a call to divert to the VM system takes more work (and usually registration), but lighting the light takes a SUB/NOT.

The phone has to be configured to know who to subscribe to.  Perhaps that is part of your problem.


On Jun 1, 2010, at 1:10 PM, Michael Reynolds wrote:

Mitel 3300 UAS

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sipforum.org/pipermail/discussion/attachments/20100601/037bd60c/attachment-0002.html>

More information about the discussion mailing list