Subject: Re: Topology

From: "Alessandro Mordacci (ERA)" <[email-masked]>
Date: Wed, 25 Aug 1999 17:41:30 +0200

This is what you find in CALEA and ETSI:

1) There are three basic schemas:
   a) ("mono" mode) you intercept both A and B and mix them. One connection is used for the delivery of the media to the LEA.
   b) ("stereo" mode) you intercept A and B independently. Two independent connections are used.
   c) ("half stereo" ?) you intercept only the target.

What mode to use is decided by the agency that order the monitoring, on a case by case basis. They can also specify a different schema depending on teleservice etc.

2) All the data are sent by the call control function in the form of messages at specific events (ACM, redirection, B-answer, SMS, etc. etc.). One communication channel between the MGC and the LEA may be used for every call. The correlation may be established sending a common identifier in the signalling data and in the media connection. There are several ways: A-number, tone sending, user to user messages...  Note that I call it a media connection  because it has its own signalling and it is totally independent from the subscriber signalling. I think that some of this can be applied to ATM, but I don't know.

3) Considering that you may have 1 to n agencies and 1 to x monitored subscribers in a conference call with x subscribers, you understand that almost every topology is possible. Tapping needs to be turned on and off when a subscriber is put on hold (but not always), or if he switch between different conference calls, so there is a dynamics in this.

Hope this will help...

Alessandro

> -----Original Message-----
> From: Hong Liu [SMTP:[email-masked]]
> Sent: Wednesday, August 25, 1999 4:40 PM
> To:   [email-masked]
> Subject:      Re: Topology
>
> Brian,
>
> I have been monitoring the discussion on this thread for a few days. It seems
> that we need to identify exactly what we mean by wiretap, in the context of
> megaco, before we rush into devising mechanisms to solve it. Otherwise, with
> different problem definitions in mind, we end up with arguing oranges vs. apples
> without much progress. Of course, Tom will need to decide whether we should beat
> this topic to death now, or can be left for further discussion.
>
> I think Brian's email is a good start. Let's take a step back. I am very naive,
> so I will ask a number of naive questions below. I am requesting experts in this
> area to clarify the issues for me, and some other people on this list. Hopefully,
> in the process we can refine the requirements on wiretap for MEGACO:
>
> (1) What is wiretap in a simple two-way conversation, say between A and B?
> Suppose A is to be tapped, shall the monitoring be one way from A to B, or two
> way? If it is two way, will B's civil rights be violated? I seem to remember one
> email talked about one way media flow monitoring. But I don't know how to make
> sense out of a one way conversation, -:)
> (2) In addition to media tapping, Brian also mentioned call signaling monitoring
> and the correlation between signaling and media. I would like to know how this is
> done in today's PSTN. In particular, I would like to know how it is done in the
> context of ATM, where call signaling and bearer connection setup are separated.
> (3) Conference. I would like to understand (1) and (2) more before getting into
> this more complicated case.
>
> Cheers,
>
> --Hong
>
> "Brian F. G. Bidulock" wrote:
>
> > Chip,
> >
> > Chip Sharp wrote:
> > >
> > > A wiretap capability can be builtinto the MG without megaco.  All megaco
> > > allows you to do is control it from an MGC (via megaco).  I could just as
> > > easily set this up via a management interface.
> > >
> >
> > It's not just a wiretap, and that was my point.  According to GR-2973,
> > which pretty much turned into J-STD-025, there is specific coordination
> > required between the delivery of Call Identifying Information (acquired>
> > from signaling) and Call Content (acquired from the bearer channel).
> > The format of the Call Identifying Information must at all times provide
> > complete and evidentiary details as to the connection (in all directions)
> > of all of the participants in a communications session or context.
> >
> > Conferencing is a particular example, where Call Information must identify
> > when participants join and leave the conference.  Further, laws complicate
> > the participants whose communications can be monitored in a conference.
> > Only participants whose communications are supported by a service subscribed
> > to by the target are fair game.  Participants on hold are not fair game.
> >
> > Simple call forwarding (where the forwarding is provided by the target's
> > call forwarding service) are fair game.
> >
> > In some instances, the specifications call for monitoring of a communications
> > channel before the call is even cut through on the target's side.
> >
> > Call Identifying Information (and even Call Content) on abandoned calls
> > is required by the specifications.
> >
> > Traditional wiretap capabilities were deemed insufficient for the Act and
> > compliance to CALEA cannot be met with traditional wiretaps, inviting fines.
> >
> > Approximately 80% of the calls missed by a duly authorized warrant are due
> > to call forwarding (or a variant such as voice mail).
> >
> > I fail to see how one could be compliant at the MG when it lacks the
> > signaling (and call state: read MGC) information necessary to provide the
> > Call Identifying Information required by the Act and the specifications.
> > Further, I fail to see how it would be able to deliver information pertaining
> > to abandonned calls for which the MGC has disposed of and not delivered
> > so much as a message to the MG.
> >
> > No, clearly the MGC and MG must work in tandem to provide both the Call
> > Information and the Call Content in a tightly coupled fashion to be
> > compliant, requiring support from the communicating protocol, in this
> > case megaco.
> >
> > >
> > > VoIP-based networks were not remotely considered when CALEA was
> > > written.  If  megaco seems to be a problem, end-to-end VoIP calls (and
> > > SIP-based networks) will be even more fun.  In that case, where do you
> > > apply the wiretap.
> > >
> >
> > Au contraire, VoIP was considered: so were a whole raft of new services
> > and communications capabilities, including Internet redirect and xDSL
> > technologies and the surveillance of packet data.  Each of these were
> > designed without consideration for assistance to law enforcement, while
> > further reducing the effectiveness of a traditional line wiretap: thus
> > the call for legislation: not just here in the US but abroad as well.
> >
> > Megaco is no more a problem than any other communications protocol or
> > service.  What has and will continue to cause a problem is if the
> > communications industry persists in providing advanced services to
> > criminals without regard to assistance to law enforcement.  It sure looks
> > to me like the FCC pushed the compliance date to watch the industry sit
> > on its heels for another 18 months.
> >
> > (MOAMO-NNTOME)
> >
> > --
> > Brian F. G. Bidulock