/* HINT: Search archives @ http://www.indyramp.com/masq/ before posting! 
/* ALSO: Don't quote this header. It makes you look lame :-) */


Was this module ever fixed?  I tried Tom's module, and while it makes the RealProducer 
work, all the Real Players behind the firewall die in the "Buffering..." phase.

Bob


Tom Marshall wrote:
> 
> It is a complete rewrite of the module.  The major functional difference is
> that my module does not support PNA (an old pre-G2 binary protocol) but
> attempts to do RTSP as correctly as possible.  By correct, I mean that the
> module replaces the client_port in both directions.  All previous modules
> "leak" the masq box's allocated port back to the client like this:
> 
> C->S: Transport: RTP/AVP/UDP;client_port=6970-6971
> (masq module replaces client_port with something like 60246-60247)
> S->C: Transport: RTP/AVP/UDP;client_port=60246-60247;server_port=10026-10027
> 
> My module will replace the client_port with the original values before
> sending the reply back to the client.  Others don't.
> 
> Some comments from the top of the module source:
> 
>  *   - This is a complete rewrite of the code.  Emphasis has been placed
>  *     on correctness.  It has been written and tested on the 2.2.18 kernel
>  *     but should work with any recent 2.2.x kernel.  I have heard rumor that
>  *     the masq code changed slightly somewhere around 2.2.5 so you will
>  *     probably want 2.2.6 or later.  If you know exactly what changed and
>  *     when, I would be interested in knowing.
>  *
>  *   - This module doesn't keep any state between packets, so there is a
>  *     (extremely remote) possibility that we will misinterpret the data.
>  *
>  *   - In order to be "seen", an RTSP message must be contained within a
>  *     single packet, or at least begin on a packet boundary and include the
>  *     transport and cseq headers.  It is conceivable that messages could
>  *     span packets (suppose the headers are written one line at a time).
>  *     I am not aware of any apps that do such a silly thing.
>  *
>  *   - Multiple RTSP messages in a single packet are handled, including
>  *     entities (note: this is mostly untested).  TCP interleaved data is
>  *     not handled, but support could/should be added.
>  *
>  *   - Multicast transports are ignored (we should probably strip them).
>  *
>  *   - Encoding/recording (eg. RealProducer, SLTA) is fully supported,
>  *     provided that the server's encoder port is in the list.  SLTA worked
>  *     fine in my tests, but RealProducer seemed to be a bit shaky (lots of
>  *     rebuffering on the clients).  I don't think that was related to this
>  *     module, but I can't say for sure.
>  *
>  *   - client_port mapping uses the cseq to track request/response pairs
>  *     because we cannot rely on the client_port values in the server's
>  *     response (ie, if another firewall running a broken masq module is
>  *     between us and the server).  In an ideal world, we would just lookup
>  *     the returned client_port value in a mapping table and replace it.
>  *
>  *   - We don't track teardowns to release the mports.  There are two reasons
>  *     for this: (1) the masq code relies on timeouts, there is no mport
>  *     delete function, and (2) the RTSP protocol makes it prohibitive.  We
>  *     would have to track sessions, which are tokens of arbitrary size.  It
>  *     would be nice if the client_port was sent in the teardown request.
>  *
>  *   - RTP port allocation sucks.  It's an irritant on the client side, it's
>  *     a pain on the server side, and it's downright hostile in between.
>  *     There is no reason that RTP couldn't have been designed to use two
>  *     unrelated UDP ports, or even a single UDP port.  Whoever designs
>  *     standard internet protocols should be required to either have done
>  *     proxy/firewall coding or consult with someone who was.
> 
> On Sun, Sep 09, 2001 at 10:08:38AM -0700, David Ranch wrote:
> >
> > >My RTSP masquerading module should work for this.  Make sure that you are
> > >using the standard encoding port or use the ports option when loading the
> > >module.
> >
> > Hey Tom,
> >
> > Hows does your RTSP module compare to the one that Eddie modified
> > a while ago to support both RealAudio and RTSP-based QuickTime?
> >
> > http://www.e-infomax.com/ipmasq/files22/ip_masq_raudio.c.tgz
> >
> > --David
> >
> > .----------------------------------------------------------------------------.
> > |  David A. Ranch - Linux/Networking/PC hardware         [EMAIL PROTECTED]
> > |
> > !----
> > ----!
> > `----- For more detailed info, see http://www.ecst.csuchico.edu/~dranch
> > -----'

_______________________________________________
Masq maillist  -  [EMAIL PROTECTED]
Admin requests can be handled at http://www.indyramp.com/masq-list/ -- 
THIS INCLUDES UNSUBSCRIBING!
or email to [EMAIL PROTECTED]

PLEASE read the HOWTO and search the archives before posting.
You can start your search at http://www.indyramp.com/masq/
Please keep general linux/unix/pc/internet questions off the list.

Reply via email to