Subject: RE: [Simple] Sessions of MESSAGEs

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Aug 2001 09:23:34 -0400

Vasilis,

I made a concrete proposal on a mechanism for TCP transport of IM, using a
TCP version of the reflector protocol documented in
draft-rosenberg-sip-entfw-02.txt. I discussed it in the email yesterday:

http://mailman.dynamicsoft.com/pipermail/simple/2001-August/000606.html

you seem to be proposing an alternate mechanism (not entirely sure, though).
Is there any reason you do not support the above approach? As I mentioned in
the email, by using the discovery/negotiation mechanisms in entfw, we get
the benefit of using direct tcp whenever possible (at least one of the users
has a direct connection to the Internet (i.e., not natted)), but we work
through nats even in the hard case where both users are natted.

-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
  
-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 5:38 AM
To: Robert Osborne
Cc: Zane Thomas; [email-masked]
Subject: Re: [Simple] Sessions of MESSAGEs

Hi Robert, 
The following is just a rough proposal but I hope will 
answer your questions. 
Obviously we need a couple of IDs in order to completely specify the 
functionality of the IM session proposal. 
Please see my comments below: 
Kind Regards, 
-Vasilis Polychronidis 
Robert Osborne wrote: 
Well I do :-) 
What is simple or is not as objective as we would like to think. 
After all most of the commercial systems today include (as you clearly
explained above) 
an IM Server (trusted server) and this is how the overcome the NAT issues. 

[Robert Osborne]  Ok, so lets agree to disagree on the simplicity, but agree
that a server is required at the domain's edge.
Well first let me provide some background information that will make this
discussion more precise: 
1. For simplicity lets assume the IM Service providers under discussion
deployed only IM systems that initiate IM sessions via 
    "normal" SIP operations (Similar way as it is done for VoIP). For other
cases please refer to IMPP and CPIM gatewaying. 
2. Let us assume that we have two such IM service providers: 
    IM provider X 
    IM provider Y 
3. For simplicity lets assume that each provider has each one domain that
servers all of its users 
    IM provider X --> simple.OperatorX.net 
    IM provider Y --> simple.OperatorY.net 
4. Each user can be addressed by a SIP URL. It is assumed that the operators
have deployed a SIP 
    proxy infrastructure for establishing VoIP sessions. 
Now under these assumptions each operator will have its own IM Server in
order to solve the following issues: 
1. NAT issues 
2. Universal access (mobile, PDA, PC, etc.) 
3. Consistency and synchronization 
4. Authorization/Authentication 
5. "Mobility" of buddy lists 
6. Security 
Operators are very reluctant to deploy a peer to peer model for various
reasons that I will not analyze here. 
Treating IM as a session does not preclude the use of the peer to peer
model. 
So under the above logic and assuming that the operators do not wish to
deploy a peer to peer IM system 
I would agree that each operator will have its own IM Server. 
Now let me analyze the case where IM User A<x> that is being served by
OperatorX wants to set up an IM 
session with IM User B<y> and start the chat. 
The following diagram is a rough example that depicts the message flow for
establishment of the IM session. 
The SDP documents carried by the appropriate SIP messages can indicate to
B<y> 
(or A<x>) client to connect to the IM Server X (or IM Server Y) 
A<x> Client can reside behind Openwave's firewall. 
B<y> client can reside behind Microsoft's firewall. 
There is the issue of the OperatorX to allow incoming TCP connections 
from subscribers other than its own (for example like MSN subs). 
For additional security OperatorX can deploy a gateway IM Server X' in order
to allow 
interoperability with other Operators. 
  
Please view in a fixed-width font such as Courier. 
 +-----+        +-------+    +-------+        +-------+        +-----+ 
 |A<x> |        |IM     |    |SIP    |        |SIP    |        |B<y> | 
 |     |        |Srv X  |    |proxy X|        |proxy Y|        |     | 
 +-----+        +-------+    +-------+        +-------+        +-----+ 
    | TCP connection |           |                |               | 
  1 |<-------------->|           |                |               | 
    |       INVITE               |                |               | 
    |--------------------------->|     INVITE     |               | 
    |        100                 |--------------->|   INVITE      | 
    |<---------------------------|                |-------------->| 
    |                            |<-----100-------|               | 
    |                            |                |               | 
    |                            |                |               | 
    |                            |      180       |<-----180------| 
    |          180               |<---------------|               | 
    |<---------------------------|                |               | 
    |                            |                |      200      | 
    |                            |      200       |<--------------| 
    |          200               |<---------------|               | 
    |<---------------------------|                |               | 
    |                            |                |               | 
    |----------ACK-------------->|                |               | 
    |                            |------ACK------>|      ACK      | 
    |                            |                |-------------->| 
    | TCP to home IM |  Initiate TCP connection with IM Srv X     | 
    |<-------------->|<----------+----------------+---------------| 
    |                |           |                |               | 
    | TCP to home IM |    TCP connection is established           | 
    |<-------------->|<----------+----------------+-------------->| 
    |                |           |                |               | 
    |                |           |                |               | 
    |                |           |                |               | 
    |        BYE                 |                |               | 
    |--------------------------->|       BYE      |               | 
    |                            |--------------->|     BYE       | 
    |                            |                |-------------->| 
    |                            |                |               | 
    |                            |                |<----200-------| 
    |         200                |<------200------|               | 
    |<---------------------------|                |               | 
    |                            |                |               | 
  
This is is the most complicated case so for any other case you should be
able to analyze it using the above mentioned analysis. 
Now let me answer your questions: 
1) How would client A<x> within domain X ensure that the local server (IM
Server X) is aware that a session with client B<y> in domain Y 
    has been created? 
After the SIP exchange the client A<x> will convey the session information
(Call-ID:, IP address, Port # in SDP, etc.) to its local IM Server 
via its TCP connection. 
I know this answer is vague but the details should be specified in the
upcoming ID for the IM session. 
2) How would the server know that a particular TCP connection from domain Y
actually maps into a session with client A<x> within the domain? 
Well since the IM Server X is aware of the session information (see above
answer) it can map the TCP connections. 
3) How would the server authenticate that the TCP connection is actually
from client B<y> within domain Y? 
When the client B<y> connects to the IM Server X uses the information
received via the INVITE message in order to authenticate. 
4) How does the server become aware that client A<x> no longer wishes to
receive traffic for this session (i.e. user has closed IM window)? 
The client A<x> sends a BYE to the client B<y> and tears down the TCP
connection. 
For another implementation (taken from draft-ietf-sip-call-flows-05.txt)
please see the diagram below: 
I wish I knew about it before I wrote the above "rough" scenario :-) 
3.1.5 Successful SIP to SIP through SIP Firewall Proxy 
Please view in a fixed-width font such as Courier. 
   User A          IM Server         Proxy 1          User B 
     |                |                |                | 
     |   INVITE F1    |                |                | 
     |--------------->|   INVITE F2    |                | 
     |    (100) F3    |--------------->|   INVITE F4    | 
     |<---------------|    (100) F5    |--------------->| 
     |                |<---------------|      180 F6    | 
     |                |     180 F7     |<---------------| 
     |     180 F8     |<---------------|                | 
     |<---------------|                |      200 F9    | 
     |                |    200 F10     |<---------------| 
     |     200 F11    |<---------------|                | 
     |<---------------|                |                | 
     |     ACK F12    |                |                | 
     |--------------->|     ACK F13    |                | 
     |                |--------------->|     ACK F14    | 
     |                |                |--------------->| 
     |     IM Media   |         Both Way IM Media       | 
     |<==============>|<===============================>| 
     |     BYE F15    |                |                | 
     |--------------->|     BYE F16    |                | 
     |                |--------------->|     BYE F17    | 
     |                |                |--------------->| 
     |                |                |     200 F18    | 
     |                |     200 F19    |<---------------| 
     |     200 F20    |<---------------|                | 
     |<---------------|                |                | 
     |                |                |                | 
Where in the above picture I changed Firewall Proxy to IM Server :-) 
and RTP Media to IM Media :-) 
I think this case scenario provides for more specific answers to your
questions. 
I agree with you that we need an Internet draft that will specify all the
details of 
how to initialize IM sessions with SIP and carry IM messages over TCP, SCTP
or HTTP. 
The above examples indicate that such IM system is relatively easy to
design. 
I would be more than happy to help with the production of such ID. 
My question is, how would you expect this server to work, particularly in
the following area:1)    How would user X within domain X ensure that the
local server is aware that a session with user A in domain A has been
created.2)    How would the server know that a particular TCP connection
from domain A actually maps into a session with user X within the domain3)
How would the server authenticate that the TCP connection is actually from
user A within domain A4)    How does the server become aware that user X no
longer wishes to receive traffic for this session (ie user has closed IM
window 
>IM as a session with a TCP or HTTP transport is the right way moving 
>forward. 
> 
>> 
>> 
>> Rob O 
>>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Wed, 22 Aug 2001 02:45:21 -0700

Hi Jonathan,
I finally browsed through your ID (draft-rosenberg-sip-entfw-02.txt) and I have
the following comments:
This ID is solving the NAT issues related to SIP.
However IMO we should first specify how a SIP based IM service will work with an
IM/conferencing Server
and then analyze the NAT associated issues.
IMO it is not a good idea to mix these two topics since it will only create
additional confusion.

The following diagram describes the architecture and protocols that we want to
use in order to
define IM as a session protocol:
          Please view in a fixed-width font such as Courier.

                              +---------+
                              |SIP Proxy|
                              |         |
                            / +---------+ \\
                          //       |        \\
                        //         |          \\
                      //           |            \\
        SIP for IM signaling       |            SIP for IM signaling
                  //               |                \\
                 /                 |????              \\
               //                  |How do we           \\
             //                    |correlate transport   \\
           //                      |Sessions in the         \\
         //                        |IM Server?                \\
       //                          |                            \\
      /                            |                              \
 +-----+                      +---------+                       +-----+
 |IM UA|                      |IM Server|                       |IM UA|
 |  1  |<---IM-Transport----->|         |<----IM-Trasport-------|  2  |
 +-----+                      +---------+                       +-----+

As it was pointed out by Robert Osborne in the above case we need to specify
the binding for the IM transport legs.

One obvious solution is depicted in the following diagram:
           Please view in a fixed-width font such as Courier.

                               +---------+
         <---IM-Signaling----->|SIP proxy|<---IM-Signaling----->
  +-----+                      +---------+                       +-----+
  |IM UA|                      |IM Server|                       |IM UA|
  |  1  |<---IM-Transport----->|         |<----IM-Trasport-------|  2  |
  +-----+                      +---------+                       +-----+
Where the IM/conferencing Server includes SIP proxy functionality. The binding
in this case is
obvious and is similar to the one described in draft-ietf-sip-call-flows-05.txt
section 3.1.5
The following diagram depicts the message flow for the above case:
Please view in a fixed-width font such as Courier.

   IM UA 1          IM Server         Proxy 1          IM UA 2
     |                |                |                |
     |   INVITE F1    |                |                |

In addition we will need to address the following case scenario:
          Please view in a fixed-width font such as Courier.

+-----+          +----------+           +----------+           +-----+
|IM UA|          |IM Server |           |IM Server |           |IM UA|
|  1  |<-------->|Provider X|<--------->|Provider Y|<--------->|  2  |
+-----+          +----------+           +----------+           +-----+
How do we set IM media sessions between two different IM providers?

IMO it is critical for the protocol to allow for an IM Server (gateway or
conferencing server) in case the IM provider
chooses to deploy such architecture..
After all most of the commercial systems today include such an IM Server

Jonathan my main question is:
Does the draft-rosenberg-sip-entfw-02.txt handles all of the above mentioned
cases?
If the answer is yes please describe in detail your proposed solution for the
above mentioned cases.

Kind Regards,

-Vasilis Polychronidis