Subject: Re: [Megaco] New Draft on Legal Intercept in MEGACO without use of Topology descriptor

From: [email-masked]
Date: Tue, 17 Dec 2002 19:13:55 +0530

Hi Kevin/Terry/Christian

Thanks for your comments. Before writing this draft we were fully aware that
whatever can be achieved
with this package can be very well done by the topology descriptor also. However
we still decided
to write this package for the following reasons

  1. Intercept function seems to be a better fit at termination properties
rather than at context level.
      The media streams and events received and sent by the termination are of
interest to the intercept authority. The
      rest of the context or rest of the terminations in that context should
remain oblivious to it.
      Another advantage is that the termination properties move with the
termination and this is what we precisely want in
      intercept. Context level details remain in the original context even when
the termination is moved between contexts.

  2. This scheme will work in conjunction with topology descriptor also. Imagine
a scenario where you could have a three
       party call with all of the parties under intercept (very imaginary
scenario though). You could have the conference setup
      using the topology while the intercept takes place at terminations. Using
topology alone for this can get very complex
      and would require 6 terminations to be added to the context.

3. Implementors have always found Topology as the complex feature of the
protocol to implement.
    There are forums (like MSF) which have not mandated the use of Topology
descriptors and yet looking for
    mechanism to provide support for Legal Intercept. Combining Legal Intercept
with Topology
    would mean forcing the gateway implementations to support topology. This
package provides a
    very simple (as the rules for media replication according to the package are
very simple) mechanism
    to intercept media and transport it towards intercept authority. We have
deliberately not specified
    the format of intercepted streams or how these are setup since these could
be specific to the
   network scenario/country etc and are best left open.

4  There are gateways in the network architecture which do not require complete
topology support
      and still needs to support LI. Therefore this package will provide them an
alternative way.

Best Regards,
  Rohit Gupta
  Vivek Bansal

Christian Groves <[email-masked]> on 12/16/2002 06:21:39 AM

To:   Terry L Anderson <[email-masked]>
cc:   Kevin Boyle <[email-masked]>, Rohit Gupta/HSS@HSS,
      [email-masked] (bcc: Vivek Bansal/HSS)

Subject:  Re: [Megaco] New Draft on Legal Intercept in MEGACO without use of
      Topology descriptor

G'Day,

I think Kevin and Terry comments highlight the problems with this draft very
well. Apart from the duplication of functionality arguments I think this is also
going against the Megaco connection model. With the addition of this package we
would have another stream of data that does fit use the context, termination and
stream model. Thus if people want to do LI then they should use topology.

Regards, Christian

Terry L Anderson wrote:
>
> I agree with Kevin.  There is no more likelihood that this package will
> be implemented on a given element than the topology descriptor and
> probably less.  The only reason for a second way to do this would be if
> its implementation were much easier than the full topology package.  But
> this does not appear to be the case.  It is far preferable to implement
> the more general package and bad to have two ways to do the same thing.
>
> Kevin Boyle wrote:
>
> >I do not see the utility of this package, other than making an optional
> >descriptor into an optional set of properties.  The streams will still have
> >to be forked, so the real underlying packet forking work will still have to
> >be done.  If the function of the topology descriptor is needed, then why not
> >implement it?
> >
> >This seems to be attempting to solve a problem that doesn't exist.  The main
> >(stated) motivation here is that the topology descriptor is optional.
> >Packages are ALSO optional, so this does not solve the stated problem.
> >Also, the lack of information on how to set up the replicated streams to the
> >LI receiver is a big weakness of this draft.  While much of that will be up
> >to the individual implementation, the lack of even a mention on how it
> >would/could be done indicates that this is a problem that hasn't received
> >much thought.  I believe that it will involve at least the same work as
> >implementing the topology descriptor, meaning that this really isn't as
> >simple as just defining a package.
> >
> >The topology descriptor was invented for exactly this kind of application.
> >Just because it is optional doesn't mean you CAN'T use it.  If the H.248
> >elements require the use of that function (because, for instance, LI is
> >required by law) then the descriptor should be implemented.  This draft
> >attempts to reinvent the topology descriptor, without going through the
> >exercise of defining termination and stream interactions within the context.
> >The interactions between the forked streams and the rest of the context
> >should be explained and well defined.  The topology descriptor and its
> >effects upon the terms and context are rigorously defined and well
> >documented.
> >
> >I suggest that we not reinvent the wheel.  The topology descriptor is
> >capable of producing the required results, is well defined in its
> >interactions with the definitions and elements of the rest of the H.248.1
> >specification, and is an already existing portion of the base H.248.1
> >specification, whether it is optional or not.  This draft defines a package
> >that is not capable of producing the required results without additional
> >specification, is not well defined in its interactions with the rest of the
> >specification, and has the additional weakness of being an add-on, rather
> >than an integral part of the specification.
> >
> >Kevin
> >
> >-----Original Message-----
> >From: [email-masked] [mailto:[email-masked]]
> >Sent: Thursday, December 12, 2002 9:46 AM
> >To: [email-masked]
> >Subject: [Megaco] New Draft on Legal Intercept in MEGACO without use of
> >Topology descriptor
> >
> >
> >
> >
> >
> >A New Internet-Draft is available from the on-line Internet-Drafts
> >directories.
> >
> >
> >        Title           : Legal Intercept Package for Megaco/H.248
> >        Author(s)       : R. Gupta, V. Bansal
> >        Filename        : draft-rogupta-hss-megaco-legal-intercept-00.txt
> >        Pages           : 13
> >        Date            : 2002-12-11
> >
> >This document proposes a mechanism for MEGACO controlled legal intercept
> >without the use of topology descriptor. Only call content duplication is
> >addressed in this draft. The generation of call data information is outside
> >the scope of this draft.
> >
> >A URL for this Internet-Draft is:
> >http://www.ietf.org/internet-drafts/draft-rogupta-hss-megaco-legal-intercept
> >-00.txt
> >
> >
> >
> >DISCLAIMER: This message is proprietary to Hughes Software Systems Limited
> >(HSS) and is intended solely for the use of the individual to whom it is
> >addressed. It may contain  privileged or confidential information  and
> >should not be circulated or used for any purpose other than for what it is
> >intended. If you have received this message in error, please notify the
> >originator immediately. If you are not the intended recipient, you are
> >notified that you are strictly prohibited from using, copying, altering, or
> >disclosing the contents of this message. HSS accepts no responsibility for
> >loss or damage arising from the use of the information transmitted by this
> >email including damage from virus.
> >
> >
> >_______________________________________________
> >Megaco mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/megaco
> >_______________________________________________
> >Megaco mailing list
> >[email-masked]
> >https://www1.ietf.org/mailman/listinfo/megaco
> >
> >
> >
>
> --
> -------------------------------------------------------
> Terry L Anderson                     [email-masked]
> Voice: +1 908.766.4463          Mobile: +1 908.342.9595
> http://www.gti.net/tla
> -------------------------------------------------------
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

_______________________________________________
Megaco mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/megaco

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Dec 2002 16:22:27 +1100

Hello Vivek and Rohit,

Please see my comments below.

>From past discussions also on this topic I was under the impression that the
IETF did not support mechanisms solely designed for the purposes of Legal
Interception.

Regards, Christian

> the termination is moved between contexts.

[CHG] The intercept authority should be completely unaware of the model used by
H.248 and the MG. So I don't see that the perception that LI fits termination
properties better is a valid reason for a new package. You can also set the
topologies properties when you do a move so I don't see the justification for a
new package for this either.

>       and would require 6 terminations to be added to the context.

[CHG] I don't understand. The premise for this package is that you don't have
the topology descriptor?? If you have the topology descriptor then you don't
need the package.

>    network scenario/country etc and are best left open.

[CHG] As discussed by Kevin earlier the hardware and connection setup on the MG
would be identical for each case so I don't see that you save much.

>       and still needs to support LI. Therefore this package will provide them an

[CHG] If the MGC tries to set a topology that the MG doesn't support then the MG
can always provide an appropriate error code.

---

From: Christian Groves <[email-masked]>
Date: Wed, 18 Dec 2002 16:22:27 +1100

Hello Vivek and Rohit,

Regards, Christian