AW: MWI - Message Waiting Indication

Karl Klaghofer Karl.Klaghofer at ICN.SIEMENS.DE
Thu Mar 23 03:26:08 EST 2000


I want to point out that there are at least two models to handle H.450.7 mwi
at the user side:

The MWI notification sent by the H.450.7 message center (Messaging System)
needs a peer at the user side that terminates the functional H.450.7 message
waiting indication signalling.
This "H.450.7 user side functional entity" may be located either
a)       in a feature server/gatekeeper (as you have already pointed out, in
this model you need a protocol that signals the mwi further to the user
endpoint (may be a stimulus protocol according to H.323AnnexL)
b)       in the endpoint itself (the H.450.7 message waiting indication
signalling immediately would set the lamp,  display, etc. to indicate to the
user that messages are available at the message center).

Regards,
Karl Klaghofer



> -----Ursprüngliche Nachricht-----
> Von:  Bob Gilman [SMTP:rrg at LUCENT.COM]
> Gesendet am:  Mittwoch, 22. März 2000 21:04
> An:   ITU-SG16 at mailbag.cps.intel.com
> Betreff:      Re: MWI - Message Waiting Indication
>
> Boaz-
> I think Markku described the mechanism for MWI signalling to
> an Annex L terminal correctly: the Voice Mail server could
> communicate via H.450.7 with the endpoint's feature server,
> which would then signal the endpoint via Annex L.  This is
> essentially what we do today with different (proprietary)
> protocols.  Basically, the GK/feature server "translates".
> Note that there can be a significant time gap between the
> events (depending on implementation): the VM server notifies
> the feature server that a message is waiting for user X;
> later, user X registers, establishes a signalling channel,
> and gets the news from the FS.
> -Bob
> ----------------------------------------------------
> Bob Gilman       rrg at lucent.com     (303)538-3868
>
>
> "Michaely, Boaz" wrote:
> >
> > Markku, Bob ,
> > Sorry for the multiple responses .. Let me see if I get this correctly:
> > What you're saying, Markku, is in fact that Annex L is not applicable
> for a
> > Voice Mail server if it external to the home GK, as in my example.
> > The applicable interfaces, would then be primarily H.450.7, and possibly
> > Annex K (Service Control Indication), which in both cases need to be
> > intercepted by the home GK in case the terminal is not available.
> > Again, thank you very much for these clarifications
> > -- Boaz
> >
> > > -----Original Message-----
> > > From: Markku Korpi [mailto:korpim at SCN.DE]
> > > Sent: Monday, March 20, 2000 10:30 PM
> > > To: ITU-SG16 at mailbag.cps.intel.com
> > > Subject: Re: MWI - Message Waiting Indication
> > >
> > >
> > > Boaz,
> > > H.450.7 MWI was made made for the purpose you indicate.
> > > The MWI uses non-call associated signalling connection, i.e.
> > > a connectioon
> > > that looks like a normal H.323 call, does not have any
> > > logical channel and
> > > is (usually) immediately released.
> > >
> > > The messaging server actually sends the MWI to an H.323
> > > address and does
> > > not need to know how MWI is processed at the terminating
> > > side. A gatekeeper
> > > (or a separate feature server) may, of course, act on behalf of the
> > > terminal and intercept the MWI for specific terminals. And as
> > > indicated by
> > > Bob Gilman in his answer, the GK/Feature server can then use,
> > > for example,
> > > Annex L stimulus signalling to control the terminals display
> > > and MWI lamp
> > > or other indicator.
> > >
> > > On the other hand, if I have an intelligent H.323/H.450 terminal, that
> > > processes the MWI, I probably want my gatekeeper to pass the MWI
> > > transparently to my terminal.
> > >
> > > Additionally you can open an Annex K HTTP session within the
> > > MWI procedure
> > > - provided the terminal (or its feature server) supports Annek K.
> > >
> > > One more point: H.450.7 follows (not by accident...) QSIG MWI
> > > procedures,
> > > so that seemless interworking with PBX networks is relatively easy to
> > > implement in the gateways.
> > >
> ...
> > > Markku Korpi



More information about the sg16-avd mailing list