Subject: RE: Comedia Issues.

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 4 Jul 2001 00:39:44 -0400

> -----Original Message-----
> From: David Yon [mailto:[email-masked]]
> Sent: Sunday, July 01, 2001 10:01 AM
> To: Fairlie-Cuninghame, Robert; [email-masked]'
> Subject: Re: Comedia Issues.
> 
> 
> Comments below.
> 
> At 10:59 AM 6/29/2001, Fairlie-Cuninghame, Robert wrote:
> 
> >David Yon & myself where having offline discussions about 
> the wording of 
> >how the source information in the comedia draft may be used 
> by applications.
> >
> >The source information in the a=direction attribute is only 
> used when two 
> >applications are establishing logical bidirectional channels 
> between them 
> >(using two SDP complementary descriptions). The information 
> encodes where 
> >a connection will be originating from.
> >
> >Now existing SDP requires you to accept media from anywhere. 
> I do not 
> >think that comedia should be changing this.
> >
> >So I believe that the draft should be very clear that an 
> application must 
> >not enforce the source information supplied in the direction 
> attribute 
> >when accpeting connections and that this should only be used by 
> >residential firewalls/NAT to open holes in the firewall 
> (which was the 
> >reason the information was originally added). This allows 
> the RTP media to 
> >cross a single (eg residential) NAT/firewall without modification or 
> >remapping of the SDP fields - very useful!
> >
> >[Now David if I get your position wrong please correct me.] 
> David believes 
> >that the draft should not be so emphatic that the source 
> information may 
> >not be enforced by the application because in many cases there is no 
> >NAT/firewall and thus gives a small amount of security to 
> media. I realize 
> >that many people want to solve the lack of security on RTP problems. 
> >Whilst certain implementations may end up enforcing the information 
> >anyway,  the draft should say that applications MAY NOT do this.
> 
> My problem with this is that folks are reading too much into 
> what the draft 
> says.  It never, EVER says "enforce".  That is entirely 
> outside the scope 
> of what the source address is all about.  The point of the source 
> address/port (SAP) is all about ENDPOINT IDENTIFICATION.
> 
> SAP is intended to address the topology there a TCP-based 
> media endpoint is 
> using the canonical TCP server style of accepting connections 
> at a single 
> port number.  The problem is that once you constrain the 
> server to a single 
> port, mapping connections to sessions becomes impossible 
> without additional 
> information.  There are two ways to solve this problem:
> 
>          a) Embed session identification information into the 
> media stream, or
>          b) Identify the session by the address/port of the 
> remote endpoint.
> 
> Since (a) is incompatible with most media signalled by SDP, 
> (b) is your 
> only option.  That is the essence of why SAP is included in 
> comedia.  

I think the nat fiasco has taught us that relying on IP addresses as
identification is a bad thing. So, whilst I agree with (b), I wonder why we
don't put the SSRC/cname in there instead? That has the advantage that it is
globally unique (well, the cname is; the ssrc' may collide. But, you can
detect this by notticing that the same ssrc came from two different IP
addresses. Several ways to fix it...., but the problem goes away when the
cname arrives. Just need to mandate that for unicast, you send a few RTCP
right away to set the cname.). It provides endpoint identification that
works through nats. It also allows us to <gasp> turn "RTP servers" (PSTN
gateways, media servers, etc.) into traditional servers by defining a <gasp
again> well-known port for RTP, and then demuxing on the SSRC/CNAME. Couple
that with the symmetric RTP proposal, which has media sent back to the
source IP where it came from. That means I could get RTP through firewalls
by static configuration of a simple rule: allow outbound UDP to RTP-port
(and allow media back to source addresses of outbound media). 

-Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 06 Jul 2001 15:57:23 -0400

Jonathan,

I will second David Yon in objecting to an RTP-centric solution.
A generalization of what you are suggesting might be:

Include something unique in the SDP media description that is guaranteed
to be conveyed by the active party to the passive party within the
resulting media stream. (Exactly what, and how it is conveyed, could be
transport and media specific.)

Even in this general form there are a couple of problems with this:

- existing protocols may not provide a way to send something suitable.
  At best this may require overloading the meaning of something in
  the media protocol, and this may not work in all cases.
  Consider the problems if there are two media sessions of the
  same type in the same call. 

- the intended direction of communication may not give me any
  opportunity to send anything. (The active party is recvonly.)
  This works out for RTP because the RTCP channel is assumed to
  be bidirectional even when the actual media is only going one
  way. But this is not likely to be true for connection oriented
  media unless they are designed with the requirement in mind.

Paul Kyzivat
Cisco Systems