Subject: Re: Can we identify calls from messages ?

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 8 Jun 2000 19:16:57 -0400

The idea of having a value kept by the MG on behalf of the MGC on a per
context (or even per-termination)
is a worthy thought, and my own development people are asking me to promote
that idea for another
reason - recovery from failure.  Creating a package that allows the MGC to
specify that a termination hold
an opaque data object, which the MGC can set and get is straightforward.

We have a draft, which we could publish.

Trying to get the MG to do something with this object (like delete all
contexts with this value) is a
behavior change that would need a protocol extension.

Brian

-----Original Message-----
From: Al Varney [mailto:[email-masked]]
Sent: Wednesday, June 07, 2000 3:02 PM
To: [email-masked]
Subject: Re: Can we identify calls from messages ?

At 13:52 06/06/2000 -0500, Tom-PT Taylor wrote:

There is no necessary connection between Megaco messages and calls.  One
Megaco message could contain multiple transactions.  The one thing you can
be fairly sure of is that actions related to the same context are related to
the same conference, but Megaco/H.248 has no call identifier as such.

   In the spirit of keeping protocols "open" (to new applications), I think
is useful to decouple the concept of "a call" (something only an MGC can
determine/distinguish) and connections (something H.248 MGs do).  If I use
Megaco messages to intermix music, barge-in requests and announcements of
blue-light specials over an H.248-based public address system at K-Mart,
where are the "calls"?

   More seriously, many actions requested of an MG could be done outside the
bounds of any "call".  Maintenance requests, loop-back, connections for
testing, release of resources due to audit, etc. might not involve a "call".
Even where calls exist, I could easily find examples (in today's network)
where a single Context serves several calls, and a single call involves
multiple Contexts (to permit the needed control of who hears what and when).

   On the other hand, it might be useful for MGCs to hand MGs a "reference
value" to be associated with a termination.  This would allow an MGC to
request removal of all terminations associated with a particular "reference
value".  If the reference value happened to be a call-identifier, then some
"call association" would result.  Worth doing -- probably not.

   If, on the other hand, you want to monitor an H.248 interface and collect
messages associated with a particular TDM interface or a particular call,
that's going to be tough.

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

---

From: "Brian F. G. Bidulock" <[email-masked]>
Date: Thu, 8 Jun 2000 18:44:28 -0500

Brian,

>    We have a draft, which we could publish.

I would be quite interested in seeing your draft.

> >       If, on the other hand, you want to monitor an H.248 interface
> >    and collect messages associated with a particular TDM interface or
> >    a particular call, that's going to be tough.
> >
Monitoring an H.248 interface and correlating messages is exactly what
I would like to do (and make possible).  It increases the ability to
perform remote monitoring and diagnostics of systems communicating
with the protocol using external protocol diagnostic equipment.
It also permits network management systems to monitor the network
and collect useful usage and performance information.

And then there's those CALEA requirements...

--
Brian F. G. Bidulock
Director GeoGate SW Development
Network Products, Inet Technologies Inc.

---

From: Abdallah Rayhan <[email-masked]>
Date: Fri, 9 Jun 2000 08:34:36 -0400

Brian,

I dont see much difference between this approach and scripts!
We dont have scripts in v1. Is this a way around that?

Abdallah

"Rosen, Brian" wrote:

>  The idea of having a value kept by the MG on behalf of the MGC on a
> per context (or even per-termination)is a worthy thought, and my own
> development people are asking me to promote that idea for
> anotherreason - recovery from failure.  Creating a package that allows
> the MGC to specify that a termination holdan opaque data object, which
> the MGC can set and get is straightforward. We have a draft, which we
> could publish. Trying to get the MG to do something with this object
> (like delete all contexts with this value) is abehavior change that
> would need a protocol extension. Brian
>
>     > There is no necessary connection between Megaco messages
>     > and calls.  One Megaco message could contain multiple
>     > transactions.  The one thing you can be fairly sure of is
>     > that actions related to the same context are related to
>         In the spirit of keeping protocols "open" (to new
>      applications), I think is useful to decouple the concept of
>      "a call" (something only an MGC can determine/distinguish)
>      and connections (something H.248 MGs do).  If I use Megaco
>      messages to intermix music, barge-in requests and
>      announcements of blue-light specials over an H.248-based
>      public address system at K-Mart, where are the "calls"?
>
>         More seriously, many actions requested of an MG could be
>      done outside the bounds of any "call".  Maintenance
>      requests, loop-back, connections for testing, release of
>      resources due to audit, etc. might not involve a "call".
>      Even where calls exist, I could easily find examples (in
>      today's network) where a single Context serves several
>      calls, and a single call involves multiple Contexts (to
>      permit the needed control of who hears what and when).
>
>         On the other hand, it might be useful for MGCs to hand
>      MGs a "reference value" to be associated with a
>      termination.  This would allow an MGC to request removal of
>      all terminations associated with a particular "reference
>      value".  If the reference value happened to be a
>      call-identifier, then some "call association" would result.
>      Worth doing -- probably not.
>
>         If, on the other hand, you want to monitor an H.248
>      interface and collect messages associated with a particular
>      TDM interface or a particular call, that's going to be
>      tough.
>

---

From: Michael Thomas <[email-masked]>
Date: Fri, 9 Jun 2000 08:57:32 -0700

> We dont have scripts in v1. Is this a way around that?

   I disagree. The MGC can deposit and retrieve
   state on the MG right now: that's what signals
   and audits get you. Normally the deposited state
   causes an action. What Brian is describing is
   depositing state for which the action is to
   store it in memory for a later audit.

   Scripts, on the other hand, imply programatic
   flow. The base variable mechanism was always
   there in the form of signals and events. What
   is lacking for scripts is the execution flow
   definitions, which is a substantial can of
   worms.

   Hey Brian! What you want here is a TECO
   registers package! :-)

                Mike

 > <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
 > <html>
 > Brian,
 > <p>I dont see much difference between this approach and scripts!
 > <br>We dont have scripts in v1. Is this a way around that?
 > <p>Abdallah
 > <p>"Rosen, Brian" wrote:
 > <blockquote TYPE=CITE>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>The
 > idea of having a value kept by the MG on behalf of the MGC on a per context
 > (or even per-termination)</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>is
 > a worthy thought, and my own development people are asking me to promote
 > that idea for another</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>reason
 > - recovery from failure.&nbsp; Creating a package that allows the MGC to
 > specify that a termination hold</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>an
 > opaque data object, which the MGC can set and get is straightforward.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>We
 > have a draft, which we could publish.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Trying
 > to get the MG to do something with this object (like delete all contexts
 > with this value) is a</font></font></font><font face="Arial"><font color="#0000FF"><font size=-1>behavior
 > change that would need a protocol extension.</font></font></font>&nbsp;<font face="Arial"><font color="#0000FF"><font size=-1>Brian</font></font></font>
 > <blockquote
 > style="BORDER-LEFT: #0000ff 2px solid; MARGIN-LEFT: 5px; PADDING-LEFT: 5px">
 > <div class="OutlookMessageHeader" dir="ltr"><font face="Tahoma"><font size=-1>-----Original
 > Message-----</font></font>
 > <br><font face="Tahoma"><font size=-1><b>From:</b> Al Varney [<A HREF="mailto:[email-masked]">mailto:[email-masked]</A>]</font></font>
 > <br><font face="Tahoma"><font size=-1><b>Sent:</b> Wednesday, June 07,
 > 2000 3:02 PM</font></font>
 > <br><font face="Tahoma"><font size=-1><b>To:</b> [email-masked]</font></font>
 > <br><font face="Tahoma"><font size=-1><b>Subject:</b> Re: Can we identify
 > calls from messages ?</font></font>
 > <br>&nbsp;</div>
 > <br>&nbsp;
 > <blockquote cite type="cite"><font face="Arial, Helvetica"><font color="#0000FF"><font size=-1>There
 > is no necessary connection between Megaco messages and calls.&nbsp; One
 > Megaco message could contain multiple transactions.&nbsp; The one thing
 > you can be fairly sure of is that actions related to the same context are
 > related to the same conference, but Megaco/H.248 has no call identifier
 > as such.</font></font></font></blockquote>
 >
 > <p><br>&nbsp;&nbsp; In the spirit of keeping protocols "open" (to new applications),
 > I think is useful to decouple the concept of "a call" (something only an
 > MGC can determine/distinguish) and connections (something H.248 MGs do).&nbsp;
 > If I use Megaco messages to intermix music, barge-in requests and announcements
 > of blue-light specials over an H.248-based public address system at K-Mart,
 > where are the "calls"?
 > <p>&nbsp;&nbsp; More seriously, many actions requested of an MG could be
 > done outside the bounds of any "call".&nbsp; Maintenance requests, loop-back,
 > connections for testing, release of resources due to audit, etc. might
 > not involve a "call".&nbsp; Even where calls exist, I could easily find
 > examples (in today's network) where a single Context serves several calls,
 > and a single call involves multiple Contexts (to permit the needed control
 > of who hears what and when).
 > <p>&nbsp;&nbsp; On the other hand, it might be useful for MGCs to hand
 > MGs a "reference value" to be associated with a termination.&nbsp; This
 > would allow an MGC to request removal of all terminations associated with
 > a particular "reference value".&nbsp; If the reference value happened to
 > be a call-identifier, then some "call association" would result.&nbsp;
 > <p>&nbsp;&nbsp; If, on the other hand, you want to monitor an H.248 interface
 > and collect messages associated with a particular TDM interface or a particular
 > call, that's going to be tough.
 > <p>Al Varney - Lucent Technologies&nbsp; +1 630 224-7493&nbsp;&nbsp;&nbsp;
 > [email-masked]</blockquote>
 > </blockquote>
 > </html>

---

From: Chakravarthi PSK <[email-masked]>
Date: Mon, 12 Jun 2000 10:12:49 +0530

Hello,

    How MGC can instruct MG to establish connection between two terminations
existing on same MG?

    In MGCP we can send second end point to inform MG that a hairpin
connection is required between the two end points.

    How does MEGACO support this?

    Is it by sending two TDM trunks in the same transaction without any
media descriptor?

Thanks
Chak