Subject: RE: [Simple] Sessions of MESSAGEs

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

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

Huh?? Conferencing has nothing to do with it. IM conferencing is easy in the
session model. The whole point of using the session model is that we can
reuse media conferencing mechanisms defined for other media types, and apply
them to IM just as easily. draft-rosenberg-sip-conferencing-models goes
through several different conferencing mechanisms. I see no reason why any
of these aren't applicable to IM.

Establishing conferences is also orthogonal to the use of NAT. I don't see
what they have to do with each other. The server used for NAT traversal is
not a conferencing server; it is much simpler than a conferencing server.
Also, unlike conferencing, where you direct your call at some kind of group
ID ultimately, there is no notion of a group here.

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

This picture above does not correlate with the models in EITHER
draft-rosenberg-sip-entfw or draft-rosenberg-sip-conferencing-models. For
nat traversal, the proxy plays no role. IM UA1 would communicate directly
with the IM server, and obtain a binding. This binding is passed in the SDP
in the INVITE from IM UA1 to IM UA2, which would then initiate a connection
to the address provided. Since the IM server gave out the binding in the
first place, correlation is easy. 

As far as conferencing is concerned, creating a two party conference call
through a conferencing server is possible, but doesn't work the way you
describe. IM UA1 would INVITE to the conferencing server with a uniquely
chosen conference ID (in the request URI). It would then REFER IM UA2 to
contact this conference server. Alternately, it can use 3pcc to INVITE to IM
UA2 and provide a conference port to it directly.

The model you draw above is possible (as I describe below), but its not a
proxy there, rather a B2BUA. That communications protocol can be SIP,
MGCP/megaco or midcom, depending on how you implement the "conferecing" box.
I am not a fan of this model, as it has issues with scale and fault
tolerance.

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

Generally, I find the argument "yes, but this is how existing systems work"
less than compelling. Most of these systems are built on large centralized
servers with no interdomain operation or security, and limited scalability
(or at least, not cost effective scalability). The SIP model is that media
streams go end to end whenever possible. This has very, very good scaling
properties, and it is something that is accepted as a good thing for voice
and video. There seems to be pushback for this for text, but beyond the
slightly relaxed real time requirements, if we view IM as a media stream
(and there is agreement on that, right?), why all of a sudden does every
design decision get thrown out? The big idea with SIP is that we can use the
signaling infrastructure to set up all kinds of media sessions, including
audio, video, games, and so on (I have seen SIP used to set up quake
deathmatches). Now, it seems people want to say, "no, just kidding about
that session independence. Text sessions are different, and we need to
re-engineer SIP for them". I don't think so.

Is it possible in SIP for a provide to route media traffic through an
intermediary that they control? Sure, of course it is. Its possible for a
B2BUA (NOT a proxy) to get media routed through an intermediary of its own
choice. That can be done with 3pcc, and it has also been proposed to have
the B2BUA control the intermediary with MGCP and midcom. Both are workable,
but what the relative costs are is a different story. One of the benefits of
SIP and the session model is that all of the thinking thats happened for
these things for other media types is available for IM. 

Now, whether I would recommend such intermediaries is a separate question.
NAT traversal? Well, I have proposed a way to do that which avoids
intermediaries whenever possible (and thats been a design goal for other
media types). For reasons of scale and cost, I would argue you generally
don't want these things in your network. After all, have we not heard
complaints that the cost of SMS on signaling networks is large? Why would an
IM provider WANT to buy more equipment and access bandwidth if it doesn't
have to? I just must be missing something.

-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: Vasilis Polychronidis <[email-masked]>
Date: Wed, 22 Aug 2001 18:00:22 -0700

Hi Jonathan,
Please see my response below:

BR,

-Vasilis

Jonathan Rosenberg wrote:

> session model.

Great it will be easy then to describe it in an Internet draft.
Jonathan you wrote so many IDs that is hard for me to keep up :-)
Thank you for being patient with my ignorance.

> The whole point of using the session model is that we can

They are :-)
Actually I like the Dial-in Conference Server model (Section 4 of
draft-rosenberg-sip-conferencing-models)
and the Adhoc centralized Conference model (Section 4 of
draft-rosenberg-sip-conferencing-models)

>
>
> Establishing conferences is also orthogonal to the use of NAT.

Exactly my point. We were talking about different things.

> I don't see
> not a conferencing server;

Correct.

> it is much simpler than a conferencing server.

Well my preference is to treat an IM session as a mufti party session
where mufti party = 2, 3, ...,N IM users

> (and there is agreement on that, right?),

Yes I think there is agreement on that.

> why all of a sudden does every

I am not advocating reinventing any wheels here.
I am just trying to understand how IM will work in the Conference Server Model.
BTW can you explain to me how IM as a session will work using
the Conference Server model when you have two or more IM/Conference Servers?

+-----+          +----------+           +----------+           +-----+
|IM UA|          |IM/Conf   |           |IM/Conf   |           |IM UA|
|  1  |<-------->|Server    |<--------->|Server    |<--------->|  2  |
|     |          |Provider X|           |Provider Y|           |     |
+-----+          +----------+           +----------+           +-----+

> NAT traversal? Well, I have proposed a way to do that

Well frankly your proposal is technically correct but very complicated and
requires a lot of new functionality.
However if this is the only way to solve the VoIP NAT issues I will supported.
At this point of time I do not have enough data points to make a decision.
Maybe the experts in VoIP can shed some light here?
Question for the VoIP experts:
What is the preferred way of solving NAT issues with the minimum amount of
modifications on SIP and media protocols?

> which avoids
> don't want these things in your network.

Well we disagree at this point as I mentioned in a previous E-mail having a
IM/conferecing Server
makes it easy to achieve:

1. Universal access (mobile, PDA, PC, etc.)
2. Consistency and synchronization
3. Authorization/Authentication
4. "Mobility" of buddy lists
5. Security
6. NAT issues (IM/conferecing Server is not a NAT traversal server but it helps
to alleviate some of the NAT issues)

> After all, have we not heard
> have to?

Please refer to the above list. In addition many operators have Legal intercept
requirements which a peer to peer model is hard to satisfy.
Again we may have different views here but the proposed protocol
should allow for a  IM/conferecing Server model.
I think we should provide a flexible IM Session Protocol and let the market
decide which specific implementation
is optimal.

> I just must be missing something.
>
> -Jonathan R.
>
> ---
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple