Subject: Re: Event Detection

From: "Rosen, Brian" <[email-masked]>
Date: Fri, 23 Jun 2000 13:20:22 -0400

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.
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
>
>
> 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: Flemming Andreasen <[email-masked]>
Date: Tue, 27 Jun 2000 14:09:41 -0400

> 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

--
Flemming Andreasen                Phone: +1 732 452 1667
Cisco Systems                     Fax:   +1 240 359 5839

---

From: Chuong Nguyen <[email-masked]>
Date: Tue, 27 Jun 2000 13:29:36 -0500

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

--
  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 ****