Subject: RE: [Simple] Sessions of MESSAGEs

From: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Aug 2001 10:03:04 -0500

Yes, we will still keep MESSAGE for non-session messaging.

Jon Peterson
NeuStar, Inc

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Monday, August 20, 2001 8:57 AM
To: Peterson, Jon
Cc: [email-masked]'
Subject: Re: [Simple] Sessions of MESSAGEs

I assume we would still keep MESSAGE for non-session messaging. After 
writing the draft on using MESSAGE in sessions, I am probably its 
biggest critic. I think we should abandon that effort completely.

As far as the message stream itself, I have heard some support for the 
idea of doing pure message/cpim over TCP and TLS. Personally, this 
sounds better the more I think about it.

Peterson, Jon wrote:

> After the SIMPLE session last week in London, the SIMPLE chairs received
> some feedback from the IESG with regards to the use of the MESSAGE method
> end-to-end when an IM session has been established with an INVITE (as
> described in draft-ietf-simple-im-session-00).
> 
> The IESG has some concerns that this mechanism constitutes the use of SIP
as
> a transport protocol. In other words, once the session has been
established
> between the two endpoints by the INVITE, if the MESSAGEs can only go
> directly end-to-end, then their headers and related protocol apparatus are
> entirely superfluous and may do more harm than good. We saw during the
> meeting last week that there were definitely some pitfalls to allowing
> methods other than MESSAGE across the IM stream (as well as questions
about
> overlapping transactions, redirection, forking, and so forth), and it
isn't
> clear that the overhead is justified if MESSAGE is just an envelope for
its
> encapsulated MIME payload. The IESG was particularly concerned, in
addition
> to the protocol overhead, with congestion characteristics of the messaging
> session and with the precedent that could be set by using SIP in this
> fashion.
> 
> For these reasons, the IESG is not inclined to look favorably on that
> direction for our protocol work. They also weren't enthusiastic about the
> potential use of RTP text for message transmission (significant concerns
> were also raised on the floor in London about message framing, especially
at
> CPIM gateways). The recommendation we've been given is to focus on a
> standard transport protocol with understood congestion properties such as
> TCP or SCTP. In London, Ben Campbell took an action item to begin
> investigating alternatives along these lines given the significant
concerns
> that arose on the floor with regards to the other approaches. It seems
that
> the primary question about this approach is what runs over the transport
> protocol in question; i.e. MIME headers and bodies, pure message/cpim,
BEEP,
> plain text, etc.
> 
> If anyone feels strongly that we should continue to pursue the use of the
> MESSAGE method for direct end-to-end IM signaling, or has input about how
> the transport should operate, let's get this discussion underway promptly
so
> we can meet our projected September deliverables.
> 
> Jon Peterson
> NeuStar, Inc
> SIMPLE co-chair
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

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

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 12:32 PM
> To: [email-masked]
> Assuming that the SIMPLE protocol will develop over time to 
> give the same
> functionality as current IM systems, the
> restrictions imposed by inheritance from SIP bother me.
> 
> What I am bothered about is that SIMPLE inherits the 
> separation between
> signaling and media of SIP. It assumes a different transport for the
> signaling and the media. For example, in a conference the signaling
> (INVITEs/REFERs) should be done on a single TCP connection 
> while a new TCP
> connection should be created for sending the text messages of the
> conference.
> 
> I am not sure if creating a new TCP connection for each IM 
> (when it is done
> by a session) or conference will scale. Maybe MESSAGE should 
> be allowed to
> be carried on the same transport as the INVITE message was sent on?

Why would  you create a new TCP connection for each IM? No one is advocating
that. Rather, one would set up an IM "session" with INVITE, just as you
would setup an audio session. A TCP/SCTP connection is then established to
carry all the IMs within that session, and then torn down when its done.

The benefits of such a separation between data and signaling are well known,
and include scalability (signaling servers no longer need to see all that
voluminous IM traffic, so they scale better), better congestion control,
better latency, etc. This is why all other media types are done that way.
Can you point out a specific problem with this separation?

-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: "Peterson, Jon" <[email-masked]>
Date: Mon, 20 Aug 2001 12:10:14 -0500

Again, please do understand that this is not an argument for deprecating the
original intended use of MESSAGE within the signaling stream - rather, the
consensus of the group (and the will of the IESG) seems to be that the use
of MESSAGE directly end-to-end between SIP user agents outside of the
conventional signaling stream (aka sessions of MESSAGEs) is wasteful since
an INVITE will have already been used to establish a persistent session.
Outside of sessions established with an INVITE, MESSAGE will still be
permitted in the 'paging' mode for precisely the sorts of architectures that
you list below.

Jon Peterson
NeuStar, Inc

-----Original Message-----
From: Robert Osborne [mailto:[email-masked]]
Sent: Monday, August 20, 2001 10:55 AM
To: [email-masked]; [email-masked]
Subject: RE: [Simple] Sessions of MESSAGEs

Hi,

I agree with Avshalom that MESSAGE should be allowed to be
carried over the normal SIP signalling transport, for several reasons

*	Creating a seperate TCP connection for a IM Session would
	be expensive, especially when going across firewalls
*	Allowing for the MESSAGE to travel along the normal
	signalling channel improves the authentication and
	security between domains

Rob O

>Sent: Monday, August 20, 2001 9:32 AM
>What I am bothered about is that SIMPLE inherits the separation between
>-Avshalom
>Sametime/Lotus
>                    "Peterson, Jon"                            
>                    <[email-masked]>        To:     
>"[email-masked]'"                                
>                    Sent by:                          
><[email-masked]>                               
>           
>                    [email-masked]        cc:      
>                                                                 
>                    icsoft.com                        Subject: 
>    [Simple] Sessions of MESSAGEs                                
>                                                               
>                                                                 
>                                                               
>                                                                 
>                    20/08/2001 17:47                           
>                                                                 
>                                                               
>                                                                 
>                                                               
>                                                                 
>
>
>
>
>a transport protocol. In other words, once the session has 
>been established
>methods other than MESSAGE across the IM stream (as well as 
>questions about
>overlapping transactions, redirection, forking, and so forth), 
>and it isn't
>clear that the overhead is justified if MESSAGE is just an 
>envelope for its
>encapsulated MIME payload. The IESG was particularly 
>concerned, in addition
>investigating alternatives along these lines given the 
>significant concerns
>that arose on the floor with regards to the other approaches. 
>It seems that

---

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

Actually I was referring to the session of MESSAGEs and not the
paging of MESSAGEs. 

The scenario that always strikes me as being a priority is that a employee
of Company A, wishes to communicate with an employee of Company X, who supplies
parts to Company A. Irrespective of wether this IM session is paging or not,
both employees will want to ensure that it is secure, encrypted and 
authenticated session that easily traverses firewalls.

Rob O

>From: Peterson, Jon [mailto:[email-masked]]
>Sent: Monday, August 20, 2001 10:10 AM
>To: Robert Osborne; [email-masked]; [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 13:48:45 -0400

> Sent: Monday, August 20, 2001 1:17 PM
> To: Peterson, Jon; [email-masked]; [email-masked]

I agree with those requirements (and in fact included them in my list of
requirement), but I do not see why the solution has to be "send IM over the
proxy networks". The security story is probably better with the session
model, using a separate transport, since you can negotiate session keys e2e
for the stream. I agree that the fw/nat traversal is important; I think
there are sensible ways to deal with it which do not require using the SIP
proxies for message transport.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 13:50:02 -0400

> Sent: Monday, August 20, 2001 1:04 PM
> To: Jonathan Rosenberg
> Cc: Peterson, Jon; [email-masked]'
> Do we need to select MIME type on a per-message basis, or 
> just once per 
> session?

Definitely per-message. Within a conversation, people should be able to send
a picture or something like that.

-Jonathan R.

---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 20 Aug 2001 14:03:56 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Monday, August 20, 2001 1:52 PM
> To: Jonathan Rosenberg
> Cc: Ben Campbell; Peterson, Jon; [email-masked]'
> Comments below.
> 	Paul Kyzivat
> 	Cisco Systems
> Jonathan Rosenberg wrote:
> > 
> > Even that is wasteful, IMHO. CPIM will carry things like 
> the From/To fields,
> > which are superfluous within a session.
> > 
> > I think there is only one sensible way to solve this 
> problem. Rather than
> > starting from protocols, lets start from requirements. What 
> do we need this
> > transport to do for us? From there, we can select the 
> option which best
> > meets the requirements.
> > 
> > Here is my start:
> > 
> > 1. reliable, sequenced delivery of messages
> > 2. support for messages of arbitrary size, from 1 byte to 
> megabytes (think aimster)
> > 3. congestion control
> > 4. framing
> > 5. content typing (text/html, text/plain, etc.)
> > 6. support for e2e privacy, authentication, integrity
> > 7. natability (i.e., can be made to work through nats 
> without major headaches)
> > 8. rapid delivery (one the order of hundreds of 
> milliseconds to a second)
> > 9. relatively lightweight (will need to be implemented in 
> phones and other
> > smaller devices)
> > 
> > others, anyone?
> 
> 10. provision for IM conferences. A primary need here is to permit a
> media endpoint to act as a mixer. This in turn requires the ability to
> send messages attributed to others. Encoding the messages as 
> CPIM would
> seem to provide this capability, while sending raw MIME content would
> not.

Excellent point. This is a capability provided for audio/video through RTCP
(the CSRC within the RTP packet indicates who sent the data). We need a
rough equivalent here as well, for certain. 

-Jonathan R.
---

---

From: "Robert Osborne" <[email-masked]>
Date: Tue, 21 Aug 2001 11:21:16 -0700

Questions below!
-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Tuesday, August 21, 2001 2: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     | 
    |<-------------->|<----------+----------------+---------------| 

[Robert Osborne] How does B<y> know to connect to IM Srv X? My 
assumption is that SIP Proxy X would intercept the INVITE and modify
the SDP?

    |                |           |                |               | 
    | TCP to home IM |    TCP connection is established           | 
    |<-------------->|<----------+----------------+-------------->| 
 
[Robert Osborne] Actually, in order to get through Y's firewall I 
would assume there would be an IM Srv Y for that B<y> would connect 
to, and there would be a connection between IM Srv X and IM Srv Y.
This adds to the complexity ;-).
 
    |                |           |                |               | 
    |                |           |                |               | 
    |                |           |                |               | 
    |        BYE                 |                |               | 
    |--------------------------->|       BYE      |               | 
    |                            |--------------->|     BYE       | 
    |                            |                |-------------->| 
    |                            |                |               | 
    |                            |                |<----200-------| 
    |         200                |<------200------|               | 
    |<---------------------------|                |               | 
    |                            |                |               | 

[Robert Osborne] I also assume there would need to be some communication
between the end points and the relevant IM Srv to ensure the session
is terminated?

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. 

[Robert Osborne] So basically would this mean sending another form 
of INVITE with almost the same set of information?

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. 

[Robert Osborne] As per comment above, wouldnt it require all the information
that has previously been sent to the SIP Srv?

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. 

[Robert Osborne] How does IM Srv X know this authentication information, as it
was not part of the original INVITE? I assume that A<x> would need to forward
everything it receives via the session initiation?

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. 

[Robert Osborne] I assume that it would not just tear down the connection
as there would need to be a chain of servers (IM Srvr X, IM Srvr Y) that
would need to tear down the relevant connection? Therefore it would need
to send an equivalant of a BYE to IM Srv X, which would send an equivalant
of a BYE to IM Srvr Y.

<Removed other diagram>

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. 

[Robert Osborne] At the high level it appears easy to design, but I still have a 
lot of reservations about how the "media servers" understand that a session has
been created, authenticate any users attempting to connect to this "media server",
ensure security, allow clients to communicate session information etc. 

My belief is that as you have to solve these issues at the signalling layer,
why re-invent the wheel. I admit there is a concern that MESSAGEs could become
large and therefore clog the server, but these could easily be solved by
introducing a limit. Also this problem still exists if you allow paging
of MESSAGEs, where a client could just send large MESSAGEs without establishing
a session previously.

Rob O

---

From: "Robert Brown" <[email-masked]>
Date: Tue, 21 Aug 2001 11:57:45 -0700

One of the other possible issues with this approach is that if TLS is
desired, end points will need server certificates so they can terminate
TLS connections.  I suspect this will be a considerable deployment
limitation.

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 6:24 AM
> To: 'Vasilis Polychronidis'; Robert Osborne
> 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.
> 
> 
> ---
> From: Vasilis Polychronidis
[mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 5:38 AM
> To: Robert Osborne
> [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.
> 3. For simplicity lets assume that each provider has each one domain
that
> servers all of its users
> 4. Each user can be addressed by a SIP URL. It is assumed that the
> operators
> have deployed a SIP
> Now under these assumptions each operator will have its own IM Server
in
> order to solve the following issues:
> 1. NAT issues
> Operators are very reluctant to deploy a peer to peer model for
various
> reasons that I will not analyze here.
> So under the above logic and assuming that the operators do not wish
to
> deploy a peer to peer IM system
> 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>
> For additional security OperatorX can deploy a gateway IM Server X' in
> order
> to allow
> This is is the most complicated case so for any other case you should
be
> able to analyze it using the above mentioned analysis.
> 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.
> 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)?
> 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
>    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.
> 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: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Aug 2001 15:07:53 -0400

> From: Robert Brown [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2001 2:58 PM
> To: Jonathan Rosenberg; Vasilis Polychronidis; Robert Osborne

Huh? TLS does not require me to have the cert of the server I'm connecting
to. It only requires that we share a common root CA. The certs are exchanged
during the initial handshakes. If you think thats not deployable, then you
must conclude that the web is not deployable, since this is exactly how it
works there.

I don't see how TLS cert management differs in what I am proposing from any
other approach which uses a server in the public net for routing traffic.

-Jonathan  R.

---

---

From: "Robert Brown" <[email-masked]>
Date: Tue, 21 Aug 2001 12:12:55 -0700

Huh?

I don't see how this is anything like how the web works.  Very few web
users have certs for TLS, except for a very few specialized cases where
they are used for user auth.

A TLS server cert is the cert that must be at the terminating node of
the TLS connection.  Are you suggesting that each client have a server
cert so it can terminate TLS?

> Sent: Tuesday, August 21, 2001 12:08 PM
> To: Robert Brown; Jonathan Rosenberg; Vasilis Polychronidis; Robert
> Osborne
> I don't see how TLS cert management differs in what I am proposing
from
> any

---

From: "Robert Brown" <[email-masked]>
Date: Tue, 21 Aug 2001 17:27:00 -0700

OK.  I understand your proposal.  Yes, I think we were talking past each
other.

However, I am concerned that such an approach will not be widely
deployed, as it also requires deployment of a firewall/NAT traversal
server (such as draft-rosenberg-sip-entfw-02) adjacent to every
firewall/NAT that exists between two end points.  In other words, if the
assumption is that there is a server in the public network, this will
only work for Internet-based services (like MSN and AOL) or for
organizations with liberal-minded firewall administrators (rare by
definition).

An in-band solution will be far more deployable, as it requires all the
common problems (like routing, authentication, firewall configuration,
etc) to be solved only once.

> Sent: Tuesday, August 21, 2001 12:23 PM
> > Sent: Tuesday, August 21, 2001 3:13 PM
> I think we are talking past each other.
> 
> In my proposal, there *is* a server in the public network. This server
is
> needed for nat traversal if both are behind a nat. In that case, each
> client
> would have a tls connection to that server, and it is only the server
> which
> needs to have a cert. This is standard web stuff, and thats what I was
> talking about.
> 
> In the case of direct communication between clients, yes, this will be
an
> issue for TLS as it would require client certs, which is not that
common.
> This is a problem shared by all e2e encryption/authentication
mechanisms.
> There is work on defining SDP extensions for negotiation of session
keys
> (primarily for SRTP), and some of the key management mechanisms don't
> require certs, but rather, just shared secrets. It would be nice to be
> able
> to use that key management stuff for transport beyond SRTP, such as
> whatever
> we define for IM.
> 
> However, if you want secure IM and trust that server in the cloud, you
can
> simply elect not to use direct communications even if possible. The
> signaling mechanisms in entfw and the drafts it depends on (i.e.,
comedia)
> support that.
> 
> So, you get best of both worlds, from what I can tell....
> 
> -Jonathan R.
> ---

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Aug 2001 09:53:58 -0400

> Sent: Wednesday, August 22, 2001 9:32 AM
> There is a related issue that I have not seen discussed much: how a
> Session of MESSAGEs is established and managed in the context of call
> control. 
> 
> draft-ietf-simple-im-sdp-00 proposed some SDP extensions so that a
> Session of MESSAGEs could be negotiated like any other medium. But I
> have seen no further discussion of that in this context. Do the
> proponents of Sessions of MESSAGEs agree that use of
> draft-ietf-simple-im-sdp-00 or something similar should be required to
> establish a session?

Yes. By definition, the idea behind the "session model" is that messaging is
just another media stream established by SIP, using normal SIP call control,
with some SDP extension that describes the media stream.

> 
> Regardless of whether IM Sessions are carried via Sessions of Messages
> or some other way, I think there is a essential requirement that those
> sessions be established via a standard INVITE sequence exchanging a
> session description in SDP.

Yes. That is the session model by definition.

-Jonathan R.

---

---

From: [email-masked]
Date: Mon, 27 Aug 2001 20:19:03 +0300

How do we know the consensus of the group?

avshalom
Sametime/Lotus/IBM

                    Vasilis Polychronidis                                                                                       
                    <Vasilis.Polychronidis@Ope        To:     Robert Osborne <[email-masked]>                    
                    nwave.com>                        cc:     Jonathan Rosenberg <[email-masked]>, "Peterson, Jon"     
                                                      <[email-masked]>, [email-masked],                          
                    21/08/2001 00:12                  [email-masked]                                            
                                                      Subject:     Re: [Simple] Sessions of MESSAGEs                            

Hi Rob,
Reading the mailing list is apparent to me that the consensus in the group
is not to use the MESSAGE method and consequently SIP as the transport
protocol for IM sessions.
I hope the above answer your first question.

As far as your second question (about presence events) it seems to me that
presence events are more closely related to signaling (SIP) however I agree
that
they may create congestion issues.
I think the group should seriously consider the proposal put forward by
Michael Hammer.
Personally I think assigning different priorities to presence messages is
an
excellent idea.

BR,

-Vasilis Polychronidis

Robert Osborne wrote:

> Hi,
>
> I still do not understand why we need to force sessions of
> MESSAGEs to have to go via a special media channel. Using the current
> draft if you wish to avoid congestion or server load, it is possible
> for the MESSAGEs to go peer to peer. If there is a firewall in
> between the peers, then the traffic can be forced to go through
> the signalling path.
>
> 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.
>
> In reality the amount of traffic caused by an IM session is
> insignificant when compared with that of presence, so why is there
> such a major concern? Why not force a NOTIFY to have it's own
> connection?
>
> Rob O
>
> >Sent: Monday, August 20, 2001 10:49 AM
> >To: Robert Osborne; Peterson, Jon; [email-masked];

---

From: Akers Ron-WRA001 <[email-masked]>
Date: Thu, 30 Aug 2001 10:15:52 -0500

Hi David:

 <snip>
   > I find the logic behind this conclusion utterly 
   > incomprehensible. First of all, for "enterprise IM" the 
   > firewall/NAT issue doesn't even arise because the 
   > communication stays within the enterprise. If there are 
   > multiple sites interconnected, they tend to use VPN 
   > technology for precisely the reasons of not wanting to 
   > deal with the NAT/FW bull.... for their own internal communication.
   > 
   > Therefore, it seems completely wrongheaded to burden the 
   > IM protocols with IM-specific mechanisms for firewall/NAT 
   > traversal when this is know to hurt robustness, limit 
   > scalability, and introduce gratuitous complexity.
   > 
I disagree with your conclusion about "Enterprise IM." But I guess it depends on your definition of what the pronoun "Enterprise" really means.

I know in my company that IM is used more and more by our Product Groups to talk to their customers. This typically takes place with our guys behind our firewall, and them most likely behind an additional firewall. The dual firewall problem has caused no end of searching for commercial IM solutions (AOL, Yahoo, etc.) that work correctly and reliably in such a situation.

Secondly, many of us do work from home. More and more these days companies are requiring this home work be on home networks secured behind a NAT/Firewall. Now, admittedly we can temporarily setup a VPN to the corporate Intranet to use IM, but it would be great if I could use IM from my laptop at home through BOTH firewalls to talk to colleagues.

So, NATs may be ugly...but I feel it's important to deal with them.

Regards,

Ron

  <snip>

---

From: "Jeremy Buch" <[email-masked]>
Date: Thu, 30 Aug 2001 08:19:20 -0700

It should also be noted that many of our customers, advocates and
internal IT staff advocate that enabling VPNs for the purpose of tying
communications between companies is not even recommended (if there are
any alternatives).  IT staff even advocates to many of our customers
that utilizing application-level gateways that enable open (or closed)
communications via the Internet are preferred to sharply-defined VPNs
that need additional management (as needs change).

We must (and will) build something that is manageable AND deployable for
existing corporate network systems.  We need to define and attempt to
move forward on an overall architectural goal, but we can not leave
existing customers and networks out in the cold.

-----Original Message-----
From: Robert Brown 
Sent: Wednesday, August 29, 2001 11:59 AM
To: David R. Oran; Patil Basavaraj (NET/Dallas); [email-masked];

> I find the logic behind this conclusion utterly incomprehensible.
First
> of all, for "enterprise IM" the firewall/NAT issue doesn't even arise
> because the communication stays within the enterprise. If there are
> multiple sites interconnected, they tend to use VPN technology for
> precisely the reasons of not wanting to deal with the NAT/FW bull....
> for their own internal communication.

I find the fictional world described in this paragraph to be utterly
incomprehensible.

Have you ever used email?  Have you heard of B2B e-commerce?  You and I
work in enterprises, and I don't believe a VPN exists between you and I,
but many firewalls do, and you can still read this mail...

---

From: "Fuxbruner, Amihay" <[email-masked]>
Date: Tue, 4 Sep 2001 16:12:58 +0300

Can this support e2e encryption ?

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

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:

                         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.

---

---

From: "Avshalom Houri" <[email-masked]>
Date: Wed, 5 Sep 2001 14:03:29 +0200

I agree with Robert. Given the experience we had in implementing and
deploying Sametime the concerns about firewalls are more then valid.

I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE,
given the detail/schema option and the human readable comment. We differ
between NOTIFY and MESSAGE in that we allow a session of NOTIFYs (created by
SUBSCRIBE) to be transferred over the same the control transport and not a
session of MESSAGEs (created by INVITE).

I think that we should define that the MESSAGE can be sent on the control
transport as NOTIFY even when there is a session. We should also limit the
size of the MESSAGE that can be sent and enable partial NOTIFYs as discussed
in a separate tread.

avshalom

Sametime/Lotus/IBM

        "Robert Brown" <[email-masked]>

      Sent by: [email-masked]

      05/09/2001 04:51

      To: "Jonathan Rosenberg" <[email-masked]>, "'David R. Oran'"
<[email-masked]>, "'Patil Basavaraj \(NET/Dallas\)'"
<[email-masked]>, <[email-masked]>,
<[email-masked]>

      cc:

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]>;

Sent: Thursday, August 30, 2001 9:01 AM

> I accept as a requirement that the solution needs to support

communications

> 3. it is feasible and acceptable to deploy elements within the

enterprise

> I think that, so long as a solution meets these requirements, Robert and

the

> The generic solution is what we lovingly call a "B2BUAWM", which is a

B2BUA

> manipulation of sip messages, initiation of sip messages, and so on. In

this

> deploy a nat/fw. S1 and S2 are B2BUAWM. A sends an INVITE to establish an

IM

> connections for its IM stream, say 10.0.1.1:9988. This INVITE goes to S1.

S1

> admin to allow a single IP address of S1 to be visible to the outside).

So,

> 10.0.1.1:9988, which goes to UA A. This succeeds. Now, either side can

send

> 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

> If neither sides have nats/firewalls, the TCP connection is direct from

UA

> Now, this little trick of rewiring SDP will also work for RTP, with the

same

> For security purposes, one can also specify the use of TLS instead of TCP

on

> component from the IM forwarding component. In that case, there needs to

be

> that role, using third party call control (I will send a separate note

with

> Another option is MGCP/megaco, but I am not sure if MGCP/megaco support

TCP

> another possibility, and would result in the fastest performance and

lowest

> All of these things will work for IM and RTP, and the benefit of the

session

> above, there will be multiple connections. Thats because I am using the

TCP

simple mailing list

---

From: "Sean Olson (EUS)" <[email-masked]>
Date: Wed, 5 Sep 2001 10:33:03 -0500

>session of MESSAGEs (created by INVITE).

Well, the NOTIFY is different than the INVITE
case. For the INVITE case, the MESSAGE is the media. 
This is different from the NOTIFY case where the NOTIFY
is signalling.

>size of the MESSAGE that can be sent and enable partial 

Several comments on this:

1) The size of the MESSAGE should be as flexible as
   it is for any SIP Request. No special cases please.

2) The MESSAGE *can* be sent on the control transport.
   If you send a MESSAGE that has the same call leg
   information as a previously established call leg,
   then by default the MESSAGE will be routed on the same
   control transport (according to the Contact:/Record-Route: 
   headers). Nothing special needed here. This is an
   alternative to the MESSAGE as media idea. Nest the
   messages within an INVITE or SUBSCRIBE session.

3) On the subject of partial NOTIFYs, what about a 
   Last-Modified: header coupled with a "digest"
   sub-package? You could do a one-shot subscribe to
   the "digest" sub-package and receive a complete 
   state update. Then subscribe to the base package 
   and receive deltas.

>Sametime/Lotus/IBM

Sean Olson
Ericsson Inc.

---

From: [email-masked]
Date: Thu, 6 Sep 2001 09:42:26 -0500

inline

> From: Avshalom Houri [mailto:[email-masked]]
> Sent: Thursday, September 06, 2001 9:17 AM
> I think that you touch the point of difference in this long 
> thread, what is
> SIMPLE? Is it only an extension of SIP for IMPP which should 
> support IMPP
> with the minimal contradictions to SIP nature or should it be 
> a protocol
> that can support IMPP but in a way that is convenient to deploy and
> requires less servers and other elements for scalability.

yes it really hasn't changed much.  It's still the same discussion: why not
use SIP for message sessions that need to traverse the signal path.

> 
> I also do not understand why a media of non-session MESSAGE 
> is allowed on
> the control connection while the media of MESSAGEs in a session are
> prohibited. If MESSAGE is a media then go all the way. If not 
> or a one-time
> MESSAGE was allowed since there was no other choice I do not 
> see the harm
> in session of MESSAGEs.

I believe it's acceptable to allow one-off messages between the UA1 and UA2.
Back on 8/24 JR postulated several technical reasons why it's okay.  I
completely agree that SIP is great for IM (based on my exp.), but when the
messages start to use the signal path for back and forth sessions of
messages, it seems futile to use SIP?

The solution then is to go end2end, but this has draw backs in certain
secure environments where perimeters have been configured.  Perimeter
establishment is most of the world, outside of carriers, like mobile phones,
as they would like messages to go ME2ME. (ME is Mobile Equipment, fyi)

However, if you are targeting Enterprise you want to go E2E in the
enteprise, but outside the enterprise you may want to traversE the SIP PROXY
SIGNALING or UA1 <-> proxyA <-> proxyB <-> UA2.  This is where the problem
sets in and begins the foundation for using SIP SIGNALING path for SESSIONS
of messages.

I believe you could argue that the sessions of messages should use the
signal path when necessary, but e2e in other cases.  

So rather than defining a sepearate 'refractor/reflector' server you could
target the sip signaling path, which ONE could arguably rationalize as
'signaling' and 'rendevous' setup.  Although it is an IM specific solution.
ON that same front, IM is a specific communications method outside of voice,
email, data conferencing, video conferencing etc, where etc might be a
telepathy rendevous mechanism (TRM). ;) (that's a joke, if those aren't
allowed I'll refrain from using them in future list-posts)

Joshua

---

From: "Robert Brown" <[email-masked]>
Date: Thu, 6 Sep 2001 11:10:15 -0700

I agree - there is certainly an inconsistency in the treatment of
MESSAGE.

> Sent: Thursday, September 06, 2001 7:17 AM
> I think that you touch the point of difference in this long thread,
what
> is
> SIMPLE? Is it only an extension of SIP for IMPP which should support
IMPP
> with the minimal contradictions to SIP nature or should it be a
protocol
> I also do not understand why a media of non-session MESSAGE is allowed
on
> prohibited. If MESSAGE is a media then go all the way. If not or a
one-
> time
> MESSAGE was allowed since there was no other choice I do not see the
harm
> in session of MESSAGEs.
> 
> avshalom
> Sametime/Lotus/IBM
> 
> 
> 
> 
>                     "Sean Olson
>                     (EUS)"                 To:     "'Avshalom Houri'"
> <[email-masked]>,
>                     <sean.olson@eri
>                     csson.com>             cc:
>                     05/09/2001
>                     18:33

---

From: [email-masked]
Date: Fri, 7 Sep 2001 12:02:08 -0500

> Sent: Thursday, September 06, 2001 1:14 PM
> To: wireless; [email-masked]; [email-masked]
> > I completely agree that SIP is great for IM (based on my exp.), but
> when the
> Joshua, I'm clear on how you drew the conclusion of futility here?

I didn't. :)  I ended my sentance with a question mark.  My point is, there
are critical similarities that make SIP for IM sessions of MESSAGEs between
perimiter networks viable and usuable.

> Signaling can be e2e.  There is no reason to use the same path as the
> INVITE unless a route has been recorded.

Okay - this I understand.  The SIP PROXY works great, but what do you do
when the UA1 lives behind a NAT/router and UA2 lives behind a NAT/router
with both communicating with different SIP proxies (nwtraders and contoso,
fictional) and the proxies exist outside the NAT/router.  How does the SIP
singaling path fix that problem?

I really liked dean's point a few days ago about when to look at using e2e
vs. proxying.

> all apply to messaging. This include firewall traversal, 
> retransmission
> delegation, network validation of identity, privacy 
> mechanisms, gateways
> between administrative domains, and so on.

So does one say, well if your behind a NAT it "just doesn't work for your
client to offer services like RTCP".

Esentially, does one really want to spend time defining a standard for
backwards compatiblity with IPV4/NAT regarding a forward thinking solution
like converged IP services vs just saying the newer technology will require
e2e/IPv6 for ubiquitous support?

I.E., Linksys is adding support for MSN/XP file transfer (along with basic
firewall) this month and they will follow up with better SIP support.

Joshua

---

From: [email-masked]
Date: Wed, 5 Sep 2001 11:33:31 +0300

I would like to emphasize that NOTIFY can be arbitrary long as MESSAGE,
given the detail/schema option and the human readable comment. We differ
between NOTIFY and MESSAGE in that we allow a session of NOTIFYs (created
by SUBSCRIBE) to be transferred over the same the control transport and not
a session of MESSAGEs (created by INVITE).

I think that we should define that the MESSAGE can be sent on the control
transport as NOTIFY even when there is a session. We should also limit the
size of the MESSAGE that can be sent and enable partial NOTIFYs as
discussed in a separate tread.

avshalom
Sametime/Lotus/IBM

                    "Robert Brown"                                                                                              
                    <[email-masked]>           To:     "Jonathan Rosenberg" <[email-masked]>, "'David R. Oran'" 
                    Sent by:                          <[email-masked]>, "'Patil Basavaraj \(NET/Dallas\)'"                      
                    [email-masked]        <[email-masked]>, <[email-masked]>,                       
                    icsoft.com                        <[email-masked]>                                          
                                                      cc:                                                                       
                                                      Subject:     Re: [Simple] Sessions of MESSAGEs                            
                    05/09/2001 04:51                                                                                            

and acceptable to deploy elements within the enterprise that are
application

sockets.  As you point out below, this is more difficult because it
requires

very valid requirement.  Imagine you're a large IM service provider (such

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'"

communications
enterprise
the
B2BUA
this
IM
S1
So,
send
either
S1
UA
same
on
be
with
TCP
lowest
session
TCP

---

From: [email-masked]
Date: Thu, 6 Sep 2001 15:51:32 +0300

I think that you touch the point of difference in this long thread, what is
SIMPLE? Is it only an extension of SIP for IMPP which should support IMPP
with the minimal contradictions to SIP nature or should it be a protocol
that can support IMPP but in a way that is convenient to deploy and
requires less servers and other elements for scalability.

I also do not understand why a media of non-session MESSAGE is allowed on
the control connection while the media of MESSAGEs in a session are
prohibited. If MESSAGE is a media then go all the way. If not or a one-time
MESSAGE was allowed since there was no other choice I do not see the harm
in session of MESSAGEs.

avshalom
Sametime/Lotus/IBM

                    "Sean Olson                                                                                      
                    (EUS)"                 To:     "'Avshalom Houri'" <[email-masked]>,                         
                    <sean.olson@eri        [email-masked]                                            
                    csson.com>             cc:                                                                       
                                           Subject:     RE: [Simple] Sessions of MESSAGEs                            
                    05/09/2001                                                                                       
                    18:33                                                                                            

Sean Olson
Ericsson Inc.

---

From: [email-masked]
Date: Mon, 10 Sep 2001 08:43:14 -0500

inline

> Sent: Wednesday, September 05, 2001 3:34 AM
> 
> 
> 

interesting argument and appears to be valid, it is like the kettle calling
the pot black.

> discussed in a separate tread.

We shouldn't arbitrarily set a cap on the size of IM's.  This should be
implementable via a server policy by the IM vendor, but setting a cap on
this is likened to limiting the max. size of an email or length of a phone
call.  It's not the role of the WG to do this.

I like the rest of what you say, obviously ;)

Joshua

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 20 Sep 2001 02:04:35 -0400

Comments inline.

> Sent: Tuesday, September 04, 2001 9:52 PM
> To: Jonathan Rosenberg; 'David R. Oran'; 'Patil Basavaraj 
> (NET/Dallas)';

No one is saying RTP is the right solution for IM. I think we had consensus
that it wasn't.  I also agree that IM is different in many ways from audio
and video, primarily in the latency requirements. I will note, however, that
that doesn't mean its not a "media stream" in the same sense that audio and
video are. The definition of a stream is that its a mode of communications
that exists between one or more participants. Even games are considered
"media streams" in the SIP model, and these have different characteristics
from audio and video as well.

I certainly understand the argument that using SIP MESSAGE along the
signaling path will make nat and firewall traversal easier. Recall that I
did propose this initially, in fact, primarily for that reason. I spend a
lot of my time worrying about nats and firewalls, I can assure you.

The solution I proposed, of what is effectively a "b2bua for messages" has
much the same characteristics of sending the IM over a proxy, especially
once support for multiplexed connections between elements is added. The
similarities are the ability to run on a single port for incoming
connections, the ability for a single server to play the role of entry/exit
from the network, and the ability to hide the addresses of the sender. The
difference lies in the layer at which this forwarding is done. The cost of
processing a SIP message in a proxy is much higher than something that
merely relays bytes between connections based on some identifier. I can
therefore deploy these things as separate boxes even, allowing the proxy
scaling to be decoupled from the scaling needed for message forwarding.

The usage of SIP proxies for message forwarding also has an implication for
traditional voip calls. Large messages will increase overall latencies
through proxies, causing potentially drastic increases in call setup times.
That kind of interaction is something you don't need to worry about in a
pure IM system, but is an issue in a system supporting IM, voice, video, and
so on.

> encoding at a higher layer.

Agreed that they would only open a single port.

> whatever, will be the firewall traversal solution.

My proposal makes no such dependency. For the inter-enterprise case, it can
be done with this b2bua thing that doesn't require any additional elements.
Its only when you split the message forwarding component off that you need
some kind of interface between the proxy and the message forwarding box.

> TLS - how many cycles do you want to burn on session establishment?

Agreed.

> and NOTIFY than they ever will be with MESSAGE. 

The frequency of these is definitely greater, yes. However, proxies are less
likely to record-route on a subscribe than they are on an invite, so I
assume fewer proxies would be seeing the subscribe. Its also the size of the
IM that concerns me. I suspect subscribe and notify messages to almost
always be small, whereas an IM could conceivably contain a huge attachment. 

> Why not 
> INVITE my buddies

INVITE is more than just establishing an association between two points, its
about initiating a communications session. There are real differences
between the two, IMHO. Things like conferencing and transfer make sense for
any type of communications session, but have no meaning for SUBSCRIBE.

-Jonathan R.
---