Subject: RE: [midcom] Does midcom work with RTSP?

From: Johan Gerhardsson <[email-masked]>
Date: Fri, 24 Aug 2001 09:39:47 +0200

> -----Original Message-----
> From: Scott Brim [mailto:[email-masked]]
> Sent: Thursday, August 23, 2001 4:59 PM
> To: Johan Gerhardsson
> Cc: [email-masked]'
> Subject: Re: [midcom] Does midcom work with RTSP?
> 
> 
> Johan Gerhardsson schrieb am Thu, Aug 23, 2001 04:31:06PM +0200:
> > Hello all,
> > 
> > my name is Johan Gerhardsson, I'm thinking of a use case 
> where a RTSP proxy
> > "implements" midcom agent procuderes (i.e. a RTSP proxy 
> uses midcom to do
> > nat bindings and opens a pin-hole in a middlebox in order 
> to let media
> > through to an end-user application that is located in a 
> private network).
> > Question: Does RTSP really work with midcom?
> > 
> > RFC2326 (RTSP), page.59, general parameters: destination: 
> "A server SHOULD
> > not allow a client to direct media streams to an address 
> that differs from
> > the address commands are coming from." 
> > I.e. the RTSP protocol recomend RTSP servers to NOT allow 
> clients to specify
> > an alternate IP address to receive media (e.g. RTP) other 
> than what was used
> > in the RTSP signalling (the TCP stream where RTSP is in use). 
> > 
> > How is it then possible to use midcom in order to open a 
> pinhole through a
> > middlebox that routes the RTP packets from the server 
> directly to the client
> > (not through the proxy) when the proxy opens a second TCP 
> stream connection
> > towards the server which implicitely tells the server to 
> send the RTP
> > packets to the proxy?
> > 
> > I think fig.2 in <draft-ietf-midcom-framework-03.txt> isn't 
> in harmony with
> > the statement above from the RTSP RFC.
> > 
> > Have I missed something?
> 
> The issue raised in rfc2326 would be between a client and and an RTSP
> proxy.  The midcom machinery is separate and wouldn't even 
> know there's
> an issue.
> 
> The midcom protocol has not been specified yet.  However, the general
> feeling is that it will be very simple.  An authorized agent will be
> able to request a middlebox to install packet matching and modifying
> rules, for example "let packets between X and Y to pass through".  The
> requirements on the midcom protocol, to the extent that they have been
> worked out, do not say anything about restricting which addresses or
> group of addresses can be in such a rule.
> 
> Similarly, there is nothing in the midcom protocol that would 
> require a
> middlebox to know about any relationship between agent and endpoint
> client.  Unless new requirements come up, the middlebox has 
> no reason or
> means to know which particular endpoint activity caused an agent to
> generate a particular ruleset request.  In fact the whole point of the
> Midcom WG is to remove such intelligence from the middlebox.
> 
> So, if there is an issue, it is with the RTSP proxy -- it needs to
> follow rfc2326 in deciding how it grants client requests.  Once those
> decisions are made, the requests it makes to the middlebox via the
> midcom protocol will fall out automatically.
> 
> ..Scott
> 

I agree that there is no issue regarding midcom in this scenario (the mb is
just doing what it is told via midcom), except I think the picture (fig.2)
in the framework draft is wrong. The RTP and RSTP data streams, opened by
the RTSP proxy via midcom, must be routed through the RTSP proxy because of
the statement in FRC2326 which I quoted below.
http://search.ietf.org/internet-drafts/draft-ietf-midcom-framework-03.txt
ftp://ftp.isi.edu/in-notes/rfc2326.txt

// Johan

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "'Scott Brim'" <[email-masked]>
Date: Fri, 24 Aug 2001 08:59:01 -0400

Suresh?