Subject: Event Detection

From: Mario Monteiro <[email-masked]>
Date: Fri, 23 Jun 2000 09:28:42 -0500

If there are two termination ids within a context, an SCN and an RTP
termination, will an event which occurs on the SCN termination also be
"seen" at the RTP termination?

The specific case I am refering to is a terminating circuit where an
off-hook (answer) detected on the SCN is also seen at the RTP. The RTP
termination is connected via a IP network path to the originating side.
Would like this event detection to trigger removal of the signal applied
at the RTP (KeepActive off and off-hook event detection at RTP armed)
when the off-hook occurs. Also is my understanding correct that the
StreamMode at the RTP termination does not affect this event detection?

Another question. Can the MediaDescriptor (StreamMode) be set as an
embedded event such that the stream mode gets changed when a specified
event occurs? Only noticed Signal Descriptor and Event Descriptor in the
spec.

An eary response will be much appreciated.

---

From: Al Varney <[email-masked]>
Date: Tue, 27 Jun 2000 16:26:48 -0500

At 13:50 06/27/2000 -0500, Tom-PT Taylor wrote:
>I think you've got the ends of the conversation confused.  Off-hook happens
>in the terminating MG, while ringback happens in the originating MG.  The
>originating MG has no in-band way of detecting that the called party has
>answered.  Instead, the terminating MG tells the terminating MGC, which
>signals the originating MGC, which in turn modifies the terminations
>associated with the call in the originating MG.  Agreed that speech clipping
>could occur, but this is a normal hazard of VoIP operation.

    In the original models of H.323, SIP and other "VoIP" applications, the Audible Ringing tone (also called "ringback") is provided by the originating MG under control of an originating MGC.  That MGC has to trust that the terminating MGC/MG can reliably indicate when Alerting (power ringing) has begun, and can quickly signal when Answer (off-hook) occurs.  Even so, with MGC-to-MGC (or MGC-to-MG) delays, speech clipping is not unlikely.

    These models also suffer from another problem -- if the terminating MG connects to a PSTN exchange interface (MF or SS7 trunk), the PSTN assumes the MG (after signaling) is providing an audio path back to the originating user.  This allows the PSTN to begin Audible Ringing at about the same time as Alerting to the far-end user.  More importantly, it allows the PSTN to provide ANNOUNCEMENTS to the originating user without Answer being signalled ("the number you have reached is not in service").  The elimination of speech clipping after answer is an intentional added benefit of this arrangement.  Even SS7, which signals Answer quickly back to the originating exchange, assumes the terminating exchange provides Audible Ringing tone.

    While it might be reasonable to declare a single MGC (controlling both originating MG and terminating MG) equivalent to a single exchange (and thus the originating MG could provide the Audible Ring), this cannot reasonably be extended to a multiple MGC environment.  That's why potential MGC-to-MGC protocols (H.323, SIP, BICC) have all been enhanced to allow Audible Ring and Announcements to be provided by the terminating MGC/MG.  That's in Version 2 of H.323, SIPs "183 Session Progress" message and the CS-1 version of BICC.

    I would assume you are not indicating Megaco/H.248 is only suitable for supporting the "old" VoIP protocols?  Or that Audible Ringing and Alerting cannot be provided by the same MG?  Also, there are other instances where signals/events on one MG termination must be quickly coordinated with another.  If H.248 cannot be made to do so (perhaps via new packages), then we do have a problem....

Al Varney   [email-masked]

> > -----Original Message-----
> > From: Chuong Nguyen [SMTP:[email-masked]]
> > Sent: Tuesday, June 27, 2000 2:30 PM
> > To:   [email-masked]
> > Subject:      Re: Event Detection
> >
> > Well Tom can something be done now?
> >
> > It is a very important feature which can prevent speech clipping.
> > If the off-hook detected by the endpoint (TDM termination) has to result
> > in MG sending a notify to MGC.
> > Upon which MGC has to send a Modify to connection (RTP termination) to
> > stop ringback.
> > If there is any network delay, speech clipping could be pronounced.
> >
> > I thought one of the goal of Megaco is to at a minimun maintain the same
> > capability as MGCP.
> >
> > I guess the MG can always buffer the speech until the RTP ringing is
> > stopped.
> > Or just send the speech w/the ringing until ringing is stopped by MGC.
> > Or somehow has the MG detected speech ("signal"?) and stop ringing - a new
> > package?
> >
> >
> > Thanks
> > Chuong
> >
> > Flemming Andreasen wrote:
> >
> >       "Rosen, Brian" wrote:
> >
> >       > Hmm, did you just see the message from Chuong Nguyen or
> >       > is there a warp in the space/time fabric of the universe?
> >       >
> >       > The reply is the same - events are scoped to a termination,
> >       > not a context.  Off hook is not detectable on the RTP.
> >       > It occurs to me to wonder if this is the same as MGCP.
> >
> >       It is. In MGCP, if you want to detect an event on the endpoint you
> > use the
> >       normal event detection syntax, i.e. simply include the event in the
> > list of
> >       RequestedEvents for the endpoint. If you want to detect the event on
> > the
> >       connection, you use the "event@connection" syntax instead however
> > not all
> >       events can be detected on a connection (and vice versa actually).
> > The
> >       off-hook event (as defined right now) cannot be detected on a
> > connection.
> >
> >       One note related to Chuong's message. MGCP's single endpoint model
> >       inherently contains the synchronization you are looking for to turn
> > off
> >       ringback on a connection when detecting off-hook on the endpoint. To
> > achieve
> >       something similar in Megaco's dual endpoint model, you either need
> > some form
> >       of script as Brian suggested, or an event/signal construct similar
> > to MGCP's
> >       "@connection", e.g. "@termination". You could for example achieve
> > the latter
> >       by simply defining such a signal and define the semantics
> > accordingly - the
> >       worst that can happen is that the protocol police will come looking
> > for you.
> >
> >       -- Flemming
> >
> >       >
> >       > We intended it to be.  You can set an event using a
> >       > wildcard, as with MGCP, but I think that detection is
> >       > on an endpoint, not a connection, and you can't stop
> >       > the ringback signal on the RTP with the off hook event
> >       > on the analog line.
> >       >
> >       > Stream mode does not affect events.
> >       >
> >       > You can't have a Media Descriptor in an embedded event.
> >       >
> >       > Brian
> >       >
> >       > > -----Original Message-----
> >       > > From: Mario Monteiro [ <mailto:[email-masked]>]
> >       > > Sent: Friday, June 23, 2000 10:29 AM
> >       > > To: [email-masked]
> >       > > Subject: Event Detection
> >       > >
> >       > >
> >       --
> >       Flemming Andreasen                Phone: +1 732 452 1667
> >       Cisco Systems                     Fax:   +1 240 359 5839
> >
> > --
> >   Alcatel USA, Inc             Internet: [email-masked]
> >   1000 Coit Road Plano, Texas 75075           Phone:    (972) 519-4613
> >   **** The opinions expressed are not those of Alcatel USA, Inc ****
> >

Al Varney - Lucent Technologies  +1 630 224-7493    [email-masked]