Subject: RE: [Simple] Sessions of MESSAGEs

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 30 Aug 2001 12:01:16 -0400

I accept as a requirement that the solution needs to support communications
between enterprises in the case where:

  1. there is no public provider on the public Internet,
  2. one/both or neither of the enterprises has deployed a nat and/or
firewall, but is willing to affect static configuration changes to that
firewall/nat to enable real time communications,
  3. it is feasible and acceptable to deploy elements within the enterprise
that are application specific, to facilitate this application

I think that, so long as a solution meets these requirements, Robert and the
others will be satisfied, right? My big beef is that I do not want the
solution to this to be IM specific, as the same issue arises with voice,
video, etc. Therefore, I would prefer a more generic solution.

The generic solution is what we lovingly call a "B2BUAWM", which is a B2BUA
with Media (B2BUA is a SIP term, Back-to-back user agent). This is a
proxy-like kind of element which is call-stateful and capable of complete
manipulation of sip messages, initiation of sip messages, and so on. In this
case, it also handles the media.

So, let us assume that IM is carried over some TCP oriented transport. The
configuration of interest is:

    Please view in a fixed-width font such as Courier.

                         NAT/FW
                            |   \
                            |    \
                             |    \
        .....................\/    \/......................
        .                    ++    ++                     .
        .                    ||    ||                     .
        .                    ||    ||                     .
        .    +-------+       ||    ||      +-------+      .
        .    |       |       ||    ||      |       |      .
        .    |  S1   |       ||    ||      |  S2   |      .
        .    |       |       ||    ||      |       |      .
        .    +-------+       ++    ++      +-------+      .
        .                     .     .                     .
        .                     .     .                     .
        .                     .     .                     .
        .                     .     .                     .
        .     //---\\         .     .       //---\\       .
        .   || UA A  ||       .     .     || UA B  ||     .
        .     \\---//         .     .       \\---//       .
        .                     .     .                     .
        . Enterprise X        .     .  Enterprise Y       .
        .......................     .......................

A wishes to talk to B. Both are in two enterprises, X and Y, which both
deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an IM
session. It includes, within the SDP, the IP/port for incoming TCP
connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1. S1
rewrites the SDP, to rather include an IP/port of its own, which is a
publically routable one (as such, there must be cooperation of the fw/nat
admin to allow a single IP address of S1 to be visible to the outside). So,
the INVITE from S1 to S2 contains 64.22.1.2:8876 in the SDP. S1 remembers
the mapping {10.0.1.1:9988 <-> 64.22.1.2:8876}. This goes to S2. S2 does a
similar thing, placing a private internal address into the SDP in the
INVITE, 192.168.10.1:1234. This goes to UA B. In the 2xx in the reverse
direction, a similar set of rewrites can occur. 

For simplicities sake to facilitate discussion, lets assume that we are
using comedia, and arbitrarily have elected for A to act as the passive
side. B will attempt to open a TCP connection to the address it receive in
the INVITE (192.168.10.1:1234). This succeeeds. S2 is the server side of
this connection. It accepts it, and proceeds to open a connection to the
address bound to that (64.22.1.2:8876). This is S1. This connection
succeeds. S1 now opens a connection to the address mapped to that,
10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can send
data. S2 and S1 do nothing more than bit shuffling across these TCP
connections. There is no message processing or anything, just pure bit
shuffling, which is very efficient.

Now, the key thing is that whether the rewrite of the SDP is done in either
direction is a local matter. So, if enterprise X has no nat or firewall, S1
is just a proxy. In that case, the TCP connection extends from S2 to UA A.
If neither sides have nats/firewalls, the TCP connection is direct from  UA
A to UA B, as it should ideally be. Even if both sides deploy nat/fw, they
can elect to rewrite in one direction only (the incoming side) so that the
TCP connection only involves one of S1 or S2 (whether its S1 or S2 depends
on which TCP connection is ultimately chosen; draft-ietf-mmusic-comedia
discusses how this is done). 

Now, this little trick of rewiring SDP will also work for RTP, with the same
kind of bit shuffling going on. 

For security purposes, one can also specify the use of TLS instead of TCP on
some of the hops.

Now, things are a bit more complex if one wishes to separate the SIP
component from the IM forwarding component. In that case, there needs to be
some kind of control relationship between the two. Certainly SIP can fill
that role, using third party call control (I will send a separate note with
the call flows). This would require a TCP enabled "IM conference server".
Another option is MGCP/megaco, but I am not sure if MGCP/megaco support TCP
or just UDP/RTP. Perhaps someone who knows can tell me. Midcom would be
another possibility, and would result in the fastest performance and lowest
cose. In that case, the "IM conference server thing" is actually another
nat. 

All of these things will work for IM and RTP, and the benefit of the session
model is that you reuse the solutions we are developing for RTP to support
IM as well.

Now, there is one additional requirement that merits discussion. Oded, I
believe, asked that there be a single TCP connection between each
enterprise, and a single one between any UA and its proxy. In the proposal
above, there will be multiple connections. Thats because I am using the TCP
ports as a demux, so that forwarding decision for data is based on port
number alone. If you want shared TCP connections, thats a harder problem,
and will require demux at the higher layers. It is not clear whether the
additional message processing needed for each IM is more or less expensive
than multiple TCP connections.

Thanks,
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: "Robert Brown" <[email-masked]>
Date: Tue, 4 Sep 2001 18:51:41 -0700

Thanks for this detailed description.  You're going to hate me, I'm sure
:-), but I still think this is the wrong solution for IM.

You're assuming "one/both or neither of the enterprises has deployed a nat
and/or firewall, but is willing to affect static configuration changes to
that firewall/nat to enable real time communications" and "it is feasible
and acceptable to deploy elements within the enterprise that are application
specific, to facilitate this application".  But I don't think these are
completely valid assumptions.

I think it is flawed to assume all "real time communication" modes are
equally complicated and should be solved in the same way.  It is far easier
to get cross-firewall IM (there are already many existing widespread
implementations of this) than it is to get cross-firewall audio/video
streams.  IM is not "real time" in the same sense as audio and video:  it
tolerates considerable delays; it does not tolerate loss of information; it
has extremely low bandwidth requirements.  I just don't see the evidence
that IM has much in common with RTP, and hence that an RTP solution is
automatically the best solution for IM.

The second flaw is to assume that IT departments will be willing to open
port ranges.  At most, an IT department will open a well-defined port for a
specific purpose.  E.g. 443 for HTTPS, 5061 for SIP/TLS.  Hence mapping
sessions to ports will not be deployable.  You will need to map sessions to
sockets.  As you point out below, this is more difficult because it requires
encoding at a higher layer.

Thirdly, I don't think we should base something as fundamental as instant
messaging on assumptions about what an acceptable generalized firewall
traversal architecture may be.  I don't want SIMPLE to make a design call
based on whether something like your entfw-02 draft, or a MEGACO draft, or
whatever, will be the firewall traversal solution.

Fourthly, multiplexing multiple conversations on a single TCP session is a
very valid requirement.  Imagine you're a large IM service provider (such as
MSN, AOL, Yahoo, and the various larger ISPs).  You can expect quite a mesh
between users of these services (assuming they want to open themselves to
interop via SIMPLE).  Hence probably millions of parallel TCP connections
between a few data centers.  I doubt that anybody who runs a data center
wants to take this hit.  And forget about making the TCP connections using
TLS - how many cycles do you want to burn on session establishment?

I can send a SIP MESSAGE request pretty easily.  I've read nothing in any of
these threads that convinces me that extending this innate SIP capability is
a bad idea.  If people are worried about swamping their proxies with IM,
it's too late - you'll find SIP proxies will be far busier with SUBSCRIBE
and NOTIFY than they ever will be with MESSAGE.  Don't believe me?  I have
62 buddies in my buddy list.  That's 62 NOTIFYs each time my status changes.
When I log on, I'm sending 62 SUBSCRIBEs, and receiving 62 NOTIFYs, and
triggering 62 watcherinfo NOTIFYs to my buddies.  Why not INVITE my buddies
to a presence session, and define a separate protocol for transferring this
presence information?

----- Original Message -----
From: "Jonathan Rosenberg" <[email-masked]>
To: "'David R. Oran'" <[email-masked]>; "'Robert Brown'"
<[email-masked]>; "'Patil Basavaraj (NET/Dallas)'"
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Thursday, August 30, 2001 9:01 AM
Subject: RE: [Simple] Sessions of MESSAGEs