Subject: RE: [Simple] Sessions of MESSAGEs

From: "Robert Osborne" <[email-masked]>
Date: Mon, 20 Aug 2001 20:53:17 -0700

-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Monday, August 20, 2001 4:54 PM
To: Robert Osborne
Cc: Zane Thomas; [email-masked]
Subject: Re: [Simple] Sessions of MESSAGEs

Hi Robert, 
Thank you for taking the time to explain to me the NAT issues related to the existing IM systems. 
I do not disagree with your analysis below however I disagree with you statement 
that this is not a simple solution.
  
[Robert Osborne]  I assume you meant you agree with my analysis, but not statement on simplicity

please see my comments below: 

BR, 

-Vasilis Polychronidis 

Robert Osborne wrote: 

>-----Original Message----- 
>From: Vasilis Polychronidis [ mailto:[email-masked]] 
>Sent: Monday, August 20, 2001 2:25 PM 
>To: Robert Osborne 
>Cc: Zane Thomas; [email-masked] 
>Subject: Re: [Simple] Sessions of MESSAGEs 
> 
> 
>Robert Osborne wrote: 
> 
>> Hi, 
>> 
>> what peer network are you referring to? I know of no organization 
>> that would like the idea of its internal clients IP addresses being 
>> revealed to the outside world. 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. 
>> 
>> Of course it could be argued that audio and video have the same 
>> issues. However IM is different in that the amount of traffic is 
>> causes is significantly less, and users have come accustomed due 
>> to MSN Messenger, Yahoo and AOL, that it is possible to send IMs 
>> between users within different companies. Therefore I favour the 
>> approach that makes it easier for IMs to be sent between domains 
>> in a simple fashion. I do not believe creating a special connection 
>> for each IM session is simple. 
> 
>Why? 
>Hmmm.... 
>TCP or HTTP is not simple?? 
>Most of the commercially deployed IM systems are using TCP or 
>HTTP as their 
>transport. 

I was not referring to TCP or HTTP causing any complexity (any fool 
can write Winsock code to create a TCP connection in 5 mins and it 
would be insulting to suggest that this is complex), but instead to 
deployment issues that create complexity, such as firewalls. 

Most deployed IM systems (MSN, Yahoo, AOL) today rely upon one huge 
cloud living out on the Internet. All clients create an outbound 
connection to this cloud. I am not an expert in all solutions are out 
there, but I doubt if there are any that rely upon creating a connection 
into the client. 

>Using TCP or HTTP solves all your firewall issues. 

Actually TCP or HTTP does not solve all my firewall issues in itself. 
If I wanted to send an IM to yourself, I would first have to negotiate 
past my local firewall, and then your firewall. I should easily be able 
to get outside of my firewall (some organizations lock the firewall 
down on everything but port 80, but lets ignore that for the moment). 

However, I would be suprised if OpenWave trusts any TCP connection 
that comes from the internet. I would also be suprised if I am able 
to directly connect to your client. Therefore there has to be 
some trusted server that I can connect to within the OpenWave 
DMZ, which can proxy my IM to yourself. 

Though it is always possible to create such a "media" proxy I would 
not call it a simple solution.

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.
 
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 domain
3)    How would the server authenticate that the TCP connection is actually from user A within domain A
4)    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 
>> 
>> >-----Original Message----- 
>> >From: Zane Thomas [ mailto:[email-masked]] 
>> >Sent: Monday, August 20, 2001 12:58 PM 
>> >To: [email-masked] 
>> >Subject: Re: [Simple] Sessions of MESSAGEs 
>> > 
>> > 
>> >Robert, 
>> > 
>> >> By forcing MESSAGEs to always go via a seperate connection we are 
>> >> introducing severe constraints that will block deployment of IM 
>> >> solutions. Why would a company deploy a server to allow for 
>> >> federated presence, have to deploy another server to get the IM 
>> >> through the firewall? In reality they shouldnt need to, 
>they should 
>> >> be able to use the same server. 
>> > 
>> >You're assuming a server-centric model, presence and IM could 
>> >be carrid 
>> >directly by a peer network having its own builtin firewall 
>> >solutions.  The 
>> >one thing p2p solutions need is some way to find at least 
>one peer, SIP 
>> >seems to me to serve that goal nicely. 
>> > 
>> >Zane 
>> > 
>> > 
>> >_______________________________________________ 
>> >simple mailing list 
>> >[email-masked] 
>> > http://mailman.dynamicsoft.com/mailman/listinfo/simple 
>> > 
>> _______________________________________________ 
>> simple mailing list 
>> [email-masked] 
>> http://mailman.dynamicsoft.com/mailman/listinfo/simple 
> 
> 
> 
>

---

From: Vasilis Polychronidis <[email-masked]>
Date: Tue, 21 Aug 2001 02:37:41 -0700

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:

>      [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
>