Subject: RE: [Simple] Sessions of MESSAGEs

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 18:36:12 -0400

> -----Original Message-----
> From: Zane Thomas [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 6:13 PM
> To: Robert Osborne; [email-masked]
> Subject: Re: [Simple] Sessions of MESSAGEs
> 
> 
> > Therefore there has to be a server
> > (that may be acting as a proxy) to cross firewalls. If this server
> > has to be there, it might as well be a SIP proxy that allows for
> > the IM traffic to flow using any authenticated connections it has
> > to the destination domain.
> 
> I understand that as an issue, however I just don't see that 
> opening SIP up
> as a solution is the right answer.  A more generalized proxy 
> scheme which
> could be used on a box by SIP and by other protocols might 
> make more sense,
> or so it seems to me.

Indeed.

What you really want is something thats a cross between SOCKS and the "nat
detection and allocation protocol" described in
draft-rosenberg-sip-entfw-02. Ideally, the client would open a tcp
connection to a "refector" server like those described in entfw. After the
connection is opened, the client is passed, over that connection, and IP
address and TCP port that can be used to receive packets over that
connection. The client places that IP address/port in the SDP in their
INVITE. If the server receives a TCP connection on the IP/port it passed to
the client, it "connects" the two connections, forwarding data on one to the
other. 

Such a server is very simple to build; all it does is pass data from sets of
TCP connections that it holds onto. Such a server is reusable for all tcp
applications that a provider will want to offer to its customers, including
IM but other things as well. Its performance will likely way exceed a SIP
proxy, since its doing NOTHING but pure data shuffling. You'd need some
capabilities for authentication, so that only users who are really you're
customers can connect. But, thats not too hard. 

Perhaps I should extend the protocol in draft-rosenberg-sip-entfw-02 to
cover TCP as well, to provide this service.... Integration with that would
be nice. THis way, the intermediary "TCP shuffler" is used only when both
are behind a nat. Otherwise, direct communication without any servers can
take place. The "detection" bit of the protocol will take care of that case.

Another alternative is just a standard VPN, which does the same kind of
thing, but at the IP layer. Managing these things at the IP layer is a bit
of a pain, though, since the app has no easy way to know to determine which
interface is the virtual interface of the vpn, as thats the one whose
IP/port it needs to put into the SDP.

-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: "Zane Thomas" <[email-masked]>
Date: Mon, 20 Aug 2001 15:58:36 -0700

Jonathan,

> draft-rosenberg-sip-entfw-02.

Right, that's in my favorites->programming->protocols->sip and ...->p2p
folders.  I've been a devoted follower of your work for a while, without of
course always agreeing with everything you say. :-)

> TCP connections that it holds onto.

Piece of cake, I wrote one using c# in less than a day a while back.  At
that time I was just sorta fooling around and decided to conserve resources
on the server by including routing headers in my messages so that I could
multiplex many-to-one connections internally.  Each peer connects to the
proxy once, and can then pass messages to all other connected peers.

> be nice. ...

tap, tap, tap ... I'm waiting.

Thanks,

Zane