Subject: How do you deal with incoming RTP sessions you don't anticipate

From: Brian Rosen <[email-masked]>
Date: Thu, 19 Aug 1999 15:06:49 -0400

In general, the side of a call that is expecting it's
counterpart to establish an RTP flow is prepped for that flow
by performing an Add of an RTP Termination with appropriate
parameter settings.  There could be an event when the flow
arrives.  Matching is done on the basis of port assignments.

What happens when a flow arrives without the prep?

At the very least, you want an event.  How would you establish
such an event, and against what termination would it be
reported?

I used to know the answer to this; there was a termination
"base" and you could have events on it.  For example, there
was RTP/.  When you did the Add, you did it to RTP/?, meaning,
I want an RTP connection, choose a the last part of a
terminationID.  In theory, RTP could have properties that were
different from RTP/???.  All of that is gone now.

At the moment, the best I can come up with is that it is an
event on the root termination.  We might even go so far as to
define an RTP package for root that had the event, and any
parameters we needed.

Brian

---

From: "Michael A. Ramalho, Ph.D." <[email-masked]>
Date: Thu, 19 Aug 1999 17:47:46 -0700

Re: "What happens when a flow arrives without the prep?
.... At the very least, you want an event. "

For the case of native IP ... why?

Shouldn't you naturally just ignore it?

I think quite a bit about the impact of malicious users
of a network. It appears to me that the whole issue
of directing streams to points in a IP network where they
were not requested is an open invitation to network abuse
by malicious users.

Think of a process that would send RTP packets to all known
ports/addresses of a given gateway (or set of gateways). These
malicious streams would kick off events to be processed in
an attempt to determine the source (and presumably request it
to shut up). This could potentially kick off a signaling (or processing)
overload in the network (causing it to fail or fail to meet
other network obligations).

I think this issue may require a bit more thought.

I might agree to sending an event in the case of a
persistent stream to a given port (one that exists
for much longer than any reasonable call set-up
delay). But ... what exactly to do after that? For
an IP over ATM network .. the ATM VC might
give a clue to the (potentially errant) source.

Any other comments?

Michael

>define an RTP package for root that had the event, and any

Michael A. Ramalho, Ph.D.
Cisco Systems
Wall Township, NJ
Office email: [email-masked]
Personal email: [email-masked]
Office: +1.732.449.5762
Cell: +1.732.245.3957