Subject: RE: [Megaco] New Draft on Legal Intercept in MEGACO without use o f Topology descriptor

From: "Kevin Boyle" <[email-masked]>
Date: Thu, 12 Dec 2002 16:44:18 -0500

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

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 12 Dec 2002 17:01:10 -0500

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.

-- 
-------------------------------------------------------
Terry L Anderson                     [email-masked]
Voice: +1 908.766.4463	        Mobile: +1 908.342.9595
http://www.gti.net/tla
-------------------------------------------------------

---

From: Terry L Anderson <[email-masked]>
Date: Thu, 12 Dec 2002 17:01:10 -0500

---

From: Christian Groves <[email-masked]>
Date: Mon, 16 Dec 2002 11:51:39 +1100

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

---

From: Christian Groves <[email-masked]>
Date: Mon, 16 Dec 2002 11:51:39 +1100

G'Day,

Regards, Christian

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Mon, 16 Dec 2002 10:40:54 +0100

Hi all,

Maybe this have been discussed before ..
Let's say there is a conversation established between two MGs and one
resource in one of them fails (e.g. a DSP). The conversation stops working ,
may I use g/cause {Generalcause = "FT or FP..."} to notify the MGC?
If this is so, this event should always be requested by the MGC to detect
any error, shouldn't it?
Is there any other way?

Regards
Fernando

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL

---

From: Fernando Vallejo Lazaro <[email-masked]>
Date: Mon, 16 Dec 2002 10:40:54 +0100

Hi all,

Regards
Fernando

--
Fernando Vallejo Lazaro
Phone:  +34 91 330 8279
SW  Wireline ASD-Madrid
       ALCATEL