Subject: [Simple] IM over the signaling connection

From: "Petri K. Koskelainen" <[email-masked]>
Date: Fri, 5 Oct 2001 14:58:38 -0400 (EDT)

I guess you are talking about SIP over UDP.
SIP MESSAGE sessions over TCP does not lack congestion control.
Can you clarify that statement?

Only real problem left seems to be that there are 2-3 extra SIP
headers which are overhead (if SIP is used only as an encapsulation).

I don't see this as a major problem.

--
Petri

----- Original Message -----
From: "Dean Willis" <[email-masked]> 

That is correct. I have held further converse with the AD (Allison Mankin)
on the topic, and the position is that SIP is not and has not been designed
as an effective transport protocol, and it is therefore innapropriate to
transport multi-message sessions over SIP. It's simply too dangerous to turn
loose a protocol that lacks effective congestion avoidance.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 5 Oct 2001 15:15:47 -0400

> -----Original Message-----
> From: Petri K. Koskelainen [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 2:59 PM
> To: [email-masked]
> Subject: [Simple] IM over the signaling connection
> 
> 
> 

Somehow my last point has not come across.

Forget about the syntax. Just, forget about it. 

THe ***>>>***!!!>>>MAIN<<<!!!***<<<*** issue is how you are handling
forwarding of these things through intermediaries. If you are saying that
SIP MESSAGE is used for transport, then SIP proxies do the forwarding, and
things work using normal SIP proxy rules. THis means that you cannot predict
the transport, as it may change to UDP between proxies. 

-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: "Rosen, Brian" <[email-masked]>
Date: Fri, 5 Oct 2001 16:00:22 -0400

We're getting wrapped around the axle because there are 4, 
not 3, not 2, not 1 variables. They aren't completely independent, 
but there are FOUR (4) of them!

1) Message format
2) Encapsulation
2) Transport protocol
3) Routing

We really do have a lot of combinations, but we should make
decisions independently for the four variables.

a) Do we want SIP MESSAGE, or CPIM?
Please don't confuse this with transport or routing.
If you want to talk about message choice, fine, we can do that.
For a while, I really thought Ben was wrong and we didn't need
to support CPIM in all cases.  If he is right, one format works
best, wouldn't you all agree?  So, if Ben is right, can we stop 
with the "Message" idea?

b) Do we want to wrap the message with SIP headers, or use something
like BXXP, or invent something new?  Somewhat related to format.
Seems to me if you do decide on cpim, then having the basic SIP
headers is duplicative.  Is that a big problem?  Probably not,
but it's really annoying.  You can turn it around and say use
SIP headers and Message, but you may ALSO have to deal with
cpim.  Even messier IMO.  Do we want anything that BXXP gives us?
There are some nice features -- do we care?
All we really need is a message delimiter if you use CPIM.  
Two CRLFs anyone?

Please keep in mind that pager mode is a given. 
Need one solution that works for both.  
This affects choices - argues for not using BXXP for example.

c) Do we agree on TCP for transport?  There is no other real choice
on the table unless folks want to argue with the ADs on UDP.
Can we just settle on TCP now?

d) Do we want to route on the SIP signalling path, or direct
UA-to-UA?  This is an independent problem folks, treat it like one.
My opinion here is that we want direct UA-to-UA.  The firewall
argument looms large, but we have to solve it for SIP, and the
same solution works for IM.  Yes, it's related to some of the
above, because if you DO want to route via the signalling
path, then you need SIP headers, and that pushes you in
a particular direction.  Maybe that implies we have to settle
this one first, BUT IT'S AN INDEPENDENT PROBLEM.

Now, are we all thinking clearly????

So, IMO:
	Direct UA-to-UA routing
	TCP transport
	SIP Headers
	cpim Body

Brian

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, October 05, 2001 3:16 PM
> To: 'Petri K. Koskelainen'; [email-masked]
> Subject: RE: [Simple] IM over the signaling connection
> 
> 
> 
> 
>  
> 
> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple
>

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Sun, 7 Oct 2001 11:55:33 -0400

Hi, Brian:

I like to add other dimensions to yours one (Message format, Encapsulation,
Transport protocol, and Routing): a. Signaling and b. Media.

I. Paging Mode

A confusion is that both "signaling" and "message as media" can be
considered as "data." (For example, we are sending some data in the form of
paging as a part of signaling messages. This is also creating confusions.)

In paging mode, the "paging data" is sent over the signaling (MESSAGE) path
by "default" and, a SIP proxy is able to manipulate the routing of the
signaling messages. Indirectly, the "paging data" also gets the benefits of
"application layer routing " over the SIP signaling proxies. However, the
signaling message (plus, indirectly, the "paging data") is still carried
over a transport protocol (e.g., TCP or UDP). In this mode, the signaling
message (and paging data) is getting the benefits two types of
control/routing: 1. Application layer control/routing that SIP provides on
the top of the transport protocol (e.g. TCP or UDP) and 2. Transport layer
control/routing that TCP/IP (or others) provides.

II. Session  Mode

In session mode, there are two separate things: 1. Establishment of MESSAGE
session using the SIP signaling messages and 2. Sending of message as media
(media like audio or video). The first thing is that the SIP signaling
messages will be routed via SIP proxies using the usual SIP rules (however,
unlike paging, no data is sent). It will have the benefits of
control/routing of both SIP and TCP/IP layer as discussed in the case of
paging model.

But, in session mode, the message as "media [data]" is sent end-to-end (as
it is done in the case of audio or video in SIP). No SIP header is required
to send the media between the source and destination. Unlike paging mode,
"message as data" is not controlled using the SIP rules or not routed over
the SIP signaling proxies. "Message as data" is controlled/routed using the
TCP/IP or other transport rules (no application layer SIP rules for control
or routing are applicable).

The question that has been raised whether the "message as data" can also be
routed over the SIP signaling path as it has been done in the case of paging
mode (in addition to the end-to-end). This is something new in SIP model.
Let us talk about this why we need to do this. Then we can suggest some
solutions along with their pros and cons.

III. Reconciliation between Paging and Session Mode

There can be several ways to reconcile these two modes of communications.
Some of the solutions may be radical in nature and may invite to reconsider
some fundamental aspects of SIP defining new methods. I would like to keep
this discussion away until such time when we can establish the clear needs
for reconciliation between these two schemes. In the meantime, let us
consider that the paging mode is a special case of one-way "data" transfer
in SIP.

IV. SIP as Transport?

I could not clearly understand the buzzword like "SIP as Transport." Can
anyone clearly define this with technical specifications before we interpret
it? Unless it is clearly define in technical terms, we will remain subject
to misinterpretations.

I have just expanded the discussion of "transport protocol" and "routing"
part only. If we could clarify these two aspects first, the rest can also be
addressed later.

Best regards,

Radhika R. Roy
[email-masked]

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Friday, October 05, 2001 4:00 PM
To: 'Jonathan Rosenberg'; 'Petri K. Koskelainen';

1) Message format
2) Encapsulation
2) Transport protocol
3) Routing

So, IMO:
	Direct UA-to-UA routing
	TCP transport
	SIP Headers
	cpim Body

Brian

---

From: Michael Hammer <[email-masked]>
Date: Mon, 08 Oct 2001 10:30:29 -0400

Jonathan,

Those that describe SIP as Transport do not have a proper understanding of 
the protocol stack.  You could likewise talk about SMTP as Transport.

I think the real issue here is addressing the congestion question.  For 
that, I think the main discriminator is why UDP or TCP or SCTP is used as 
the Transport Layer.  I believe that there is not an objection to using UDP 
for signaling and real-time media, as that is a requirement of the 
application.  While instant messaging is NEAR-real-time, it is not 
necessary to be real-time.  If TCP (or equivalent) was required for any 
MESSAGE (or equivalent) IM media transfer, would this not answer the 
congestion question?  We can dance around this question many ways, but I 
believe that until we come to that conclusion, the IESG will not be happy.

As for the MESSAGE headers question, I think that an adequate justification 
of the need for whatever parameters are used will answer that issue.

Mike

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Mon, 8 Oct 2001 10:57:37 -0400

Hi, Mike:

I agree with you. Please see my comments below [RRR].

Best regards,
Radhika

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Monday, October 08, 2001 10:30 AM

Jonathan,

application.

[RRR] I agree with you. I think that we can provide a preferred transport
(e.g., TCP) for IM, but provisions should be kept for using other transports
as well.

While instant messaging is NEAR-real-time, it is not 

[RRR] If a MESSAGE session is established using SIP signaling schemes, the
media (IM) is sent over the transport network using a transport protocol
(e.g., TCP/IP). The transport protocol needs to be able to take care-of the
congestion control as it does for all other application and, no application
layer SIP headers will be allowed to control the lower layer transport
protocol. Because it will be violation of the protocol layering. (By the
way, options also be allowed to send the media [IM] using UDP/IP or other
transports).

[RRR] All required information will be provided in MESSAGE headers while the
session will be established. You are right that proper justification needs
to be provided why the other parameters are needed. For example, people can
expect that a centralized data bridge is needed for multi-party message
chat. The SIP signaling layer SHOULD be good enough to provide indication
that the media (IM) needs to go via a centralized bridge, and the media (IM)
will be transferred accordingly using the transport protocol (and, no
additional SIP headers are needed).

Mike

---

From: Michael Hammer <[email-masked]>
Date: Mon, 08 Oct 2001 13:46:04 -0400

Christian,

The only problem with this comparison is that the SMS messages are limited 
in size, I believe, to 256 octets, maybe less.  If volume is not restricted 
this could be a problem.  This could be an interworking issue.

Is CPIM limited in any way?

Mike

At 10:06 AM 10/8/2001 -0700, Christian Huitema wrote:
>There are two points that I keep in mind in this debate:
>
>1) SMS, the messaging service of cell phones, uses the page mode and is
>carried at least in part over the signaling channel.
>
>2) CPIM's Message function looks a lot like the page mode.
>
>It seems that the first step forward is to recognize this and assume
>that we will indeed use "MESSAGE over SIP" in the page mode for a
>significant fraction of our exchanges. I suggest that the first order
>action of SIMPLE is to just nail this one, so it be behind us.
>
>The page mode has well known limitations: it creates a lot of overhead
>in long sessions, and it does not extend easily to multi-party
>operation. This is the rationale for the "IM session" extensions, i.e.
>IM after INVITE. However, whatever we do in the session mode, we will
>have to go on interworking with SMS and with CPIM; this means that we
>will have to bring in the session some members who can only use the page
>mode. Obviously, a "session of messages" makes this very easy.
>
>-- Christian Huitema

---

From: Brazier Lachlan <[email-masked]>
Date: Tue, 9 Oct 2001 10:32:42 +0200

Hi,

there are websites where you can enter more than 256 octets (I think it's
restricted to 160 octets)
These "long" messages result into several SMS's at the receiver point.

Lachlan

> -----Ursprüngliche Nachricht-----
> Von: Michael Hammer [mailto:[email-masked]]
> Gesendet am: Montag, 08. Oktober 2001 19:46
> An: Christian Huitema
> Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
> Jon; [email-masked]; [email-masked]
> Betreff: RE: [Simple] IM over the signaling connection
> 
> Christian,
>

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 9 Oct 2001 09:12:30 -0400

Hi, All:

The idea would be to limit the "maximum" size of data in paging mode.

The longer message will create multiple paging streams, and let the
application take care-of this (although it will be discouraged to make the
message size longer).

Radhika

-----Original Message-----
From: Brazier Lachlan [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 4:33 AM
To: 'Michael Hammer'; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon; [email-masked]; [email-masked]
Subject: AW: [Simple] IM over the signaling connection

Hi,

Lachlan

---

From: Michael Hammer <[email-masked]>
Date: Tue, 09 Oct 2001 11:50:29 -0400

All,

I still think there is the issue of volume, be it in one message or
many.  I don't think you want the signal path flooded with media
messages.  With SMS it may have initially been limited to how fast
people could keypress in data, and even then it affected signaling.
This could be further harmed by automatons transmitting large messages at
an even faster rate.  While the router network may carry both
together and have capacity, the delay within the signaling proxy may be
an issue.

If a proxy path is needed, is there any thought to having media proxies
separate from signaling proxies?  This could be discovered
separately or identified by certain (but not all) signaling
proxies.

Mike

At 09:12 AM 10/9/2001 -0400, Roy, Radhika R, ALCTA wrote:

Hi, All:

The idea would be to limit the "maximum" size of data in paging
mode.

application take care-of this (although it will be discouraged to make
the

message size longer).

Radhika

-----Original Message-----

From: Brazier Lachlan
[mailto:[email-masked]]

Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
Peterson,

Hi,

there are websites where you can enter more than 256 octets (I think
it's

These "long" messages result into several SMS's at the receiver
point.

Lachlan

> The only problem with this comparison is that the SMS

> messages are limited

> in size, I believe, to 256 octets, maybe less.  If volume is

> not restricted

> >1) SMS, the messaging service of cell phones, uses the page

> mode and is

> >The page mode has well known limitations: it creates a lot

> of overhead

> >operation. This is the rationale for the "IM session"

> extensions, i.e.

> >will have to bring in the session some members who can only

> use the page

simple mailing list

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 9 Oct 2001 12:14:02 -0400

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 11:50 AM
To: Roy, Radhika R, ALCTA
Cc: Brazier Lachlan; [email-masked]
Subject: RE: [Simple] IM over the signaling connection

All,

I still think there is the issue of volume, be it in one message or many.  I
don't think you want the signal path flooded with media messages.  With SMS
it may have initially been limited to how fast people could keypress in
data, and even then it affected signaling.  This could be further harmed by
automatons transmitting large messages at an even faster rate.  While the
router network may carry both together and have capacity, the delay within
the signaling proxy may be an issue.
[Roy, Radhika R, ALARC]  Yes, this danger is always there - how soon a given
mechanism can be mis-used once people will have the option to do so.  This
danger is real. (In fact, the "sending of media [data] over the signaling
path is breaking the "original" SIP model where media and signaling path
need to be separated.)

If a proxy path is needed, is there any thought to having media proxies
separate from signaling proxies?  This could be discovered separately or
identified by certain (but not all) signaling proxies.
[Roy, Radhika R, ALARC] Media proxies (severs) can be thought a kind of
media application servers. As I mentioned earlier in response to Alex's
email, it will open a new area in SIP/SDP. However, SIP is also solving the
problems of media servers indirectly (as I mentioned in an example of data
bridge where media is bridged). One way of doing is: Let the signaling
messages indicate how the media will be passed (as if, media servers are
becoming parties [directly or indirectly]). It is entirely a new area to
explore.

Mike

Hi, All:

Radhika

-----Original Message-----
From: Brazier Lachlan [ mailto:[email-masked]
<mailto:[email-masked]> ]
Sent: Tuesday, October 09, 2001 4:33 AM
To: 'Michael Hammer'; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon; [email-masked]; [email-masked]
Subject: AW: [Simple] IM over the signaling connection

Hi,

Lachlan

> Von: Michael Hammer [ mailto:[email-masked] <mailto:[email-masked]>
]

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 9 Oct 2001 13:21:17 -0400

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
[email-masked]; [email-masked]
Subject: RE: [Simple] IM over the signaling connection

Note that my point was not to ignore the lessons of the past, but to point
out that widely deployed systems such as SMS are not going to disappear in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.
  
[Roy, Radhika R, ALARC]  Agreed. 
 
Also note that if the usage is actually a page, then a "message" is less
taxing on the infrastructure than an "invite" + the necessary session
clean-up. Let's compare:
 
1) Message: one signalling message + one response per IM.
 
2) Session: INVITE + response; ACK; BYE+response; + additional cost of
setting the message channel; IM messages on channel.
 
From a pure signalling point of view, the session mode is only beneficial
when there are at least 3 IM exchanged in a session.

[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but it has a
real danger as well: 1. People might mis-use it overloading the signaling
path through sending the larger messages or increasing the frequency of
shorter messages (had been explained earlier) and 2. It also breaks the
original SIP model - separation between signaling and media path. Proposals
need to be there to address these two concerns.
 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
[email-masked]; [email-masked]
Subject: RE: [Simple] IM over the signaling connection

Hi, Vasilis:
 
Good that you have reminded the very important lesson from the past.
 
Would please let us know your opinion what do we do in the case of "Paging"
in SIP?
 
Of course, we have another scheme: MESSAGE as session.
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
[email-masked]; [email-masked]
Subject: Re: [Simple] IM over the signaling connection

Christian Huitema wrote: 

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as the
transport. 
I understand that this is a difficult point to understand with some people
in the list. 
Let me remind you that the telephony people with more than hundred years of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport - 
that is the current case for all the analog lines going from home to the
local switch --> DTMF) and they created SS7 and ISUP. 
Actually people invented SIP using ISUP as their guide. 
That was one of the initial arguments of SIP: separate proxies from
transport of user data. 
It seems to me that certain people want to regress in time and mix signaling
and user data. 
Let us please learn from the history and lets try not to repeat the same
mistakes. 

-- Christian Huitema

---

From: "Roy, Radhika R, ALCTA" <[email-masked]>
Date: Tue, 9 Oct 2001 15:55:07 -0400

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 3:40 PM

I agree with Christian here--I really want to discourage session mode 
unless one expects a stream of messages. One shot text messages should 
normally be page mode.

[RRR] No one is disagreeing with the benefits for transferring the paging
mode text messages via signaling path, I guess. The two concerns
(implications of mis-usage and breaking of original SIP model) mentioned
earlier also need to be addressed appropriately.

[RRR] Implications of mis-use: Can we avoid the mis-use of this by putting
appropriate restrictions for not overloading the signaling path?

[RRR] Breaking of original SIP Model: Can we make appropriate suggestions
that this is a special case in SIP for sending the paging text data only?

[RRR] Will these suggestions be acceptable to all to clarify all issues?

Christian Huitema wrote:

> Note that my point was not to ignore the lessons of the past, but to 
> point out that widely deployed systems such as SMS are not going to 
> disappear in a day, or in a year -- they are with us for at least one or 
> two upgrade cycles, i.e. at least 4 to 6 years.
> 
>  
> 
>  From a pure signalling point of view, the session mode is only 
> beneficial when there are at least 3 IM exchanged in a session.
> 
>  
> 
> -- Christian Huitema
> 
>  
> 
> *From:* Roy, Radhika R, ALCTA [mailto:[email-masked]]
> *Sent:* Tuesday, October 09, 2001 6:23 AM
> *To:* Vasilis Polychronidis; Christian Huitema
> *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, 
> *Subject:* RE: [Simple] IM over the signaling connection
> 
>     Hi, Vasilis:
> 
>      
> 
>     Would please let us know your opinion what do we do in the case of
>     "Paging" in SIP?
> 
>      
> 
>         *From:* Vasilis Polychronidis
>         [mailto:[email-masked]]
>         *Sent:* Monday, October 08, 2001 4:43 PM
>         *To:* Christian Huitema
>         *Cc:* Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne;
>         Peterson, Jon; [email-masked]; [email-masked]
>         *Subject:* Re: [Simple] IM over the signaling connection
> 
>         Christian Huitema wrote:
> 
>         Correct. However Operators realized that SMS was the wrong (was
>         very successful financially) technical solution for messaging.
>         Remind you that when the people designed (late 80s) SMS they did
>         not have any idea of how successful commercial service will be.
>         That is why the next generation of multimedia messaging is using
>         HTTP as the transport.
>         I understand that this is a difficult point to understand with
>         some people in the list.
>         Let me remind you that the telephony people with more than
>         hundred years of experience realized in the late seventies that
>         in order to scale and have very reliable networks you had to
>         separate signaling from transport (initially signaling was mixed
>         with transport -
>         that is the current case for all the analog lines going from
>         home to the local switch --> DTMF) and they created SS7 and ISUP.
>         That was one of the initial arguments of SIP: separate proxies
>         from transport of user data.
>         It seems to me that certain people want to regress in time and
>         mix signaling and user data.
>         Let us please learn from the history and lets try not to repeat
>         the same mistakes.
> 
>              
>

---

From: "Rosen, Brian" <[email-masked]>
Date: Tue, 9 Oct 2001 16:20:28 -0400

I think that the "usual" IM usage is many more than 3 messages per session.
I think the problem is distinguishing the cases based on user input; you
don't
want the user to decide, you want the system to decide.
 
I think that, without needing standardization, some simple heuristic like
two or
three messages in a minute means start a session.
 
Please remember that the problem with congestion control is NOT an
individual
user.   The problem is a system supporting millions of users.   What is 3 or
4 IMs in a minute is 6-12 protocol messages times millions per minute.
You need flow control for that.  Millions of page messages will be
problematic
for a single system.  Millions of end-to-end messages between pairs of
endpoints
with flow control won't.
 
Brian

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

 

 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

Hi, Vasilis:

 
 
Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

Christian Huitema wrote: 

-- Christian Huitema

---

From: Brazier Lachlan <[email-masked]>
Date: Tue, 9 Oct 2001 22:59:09 +0200

Hello,

I believe that IM should be set up through an INVITE request, because this
way we seperate signalling and content information.

BUT:
1) Sending ANY message with ANY content in not forbidden in SIP. Nobody can
stop me sending anything. UAS can complain about my request because of
several reasons (size, kind of request, security, ...), but it still has to
handle my request.

2) Sometimes it makes more sense to send a single message, than building a
whole session. Example: An operator wants to inform a user who just
registered at it's registrar, how many calls were missed, how many calls are
on the awnsering machine, how much money the user won in the national
lottery, etc.. I really believe, a lot of applications will want to send
information without starting a session.

3) Generating and handling of simple Messages is absolutely easy to
implement and use.

For these reasons I think people will use simple messages to send data. So I
believe, we should have a well defined way of handling it properly.

There was the argument that requests with huge data in the body could block
proxies on the signaling path (if I understood that argument). This is
another reason, we should define how to handle these requests, otherwise we
will always have problems with load balancing or server availability.

Hm, I think that's what I wanted to say. Please note again, that for IM I
vote for setting it up through an INVITE. Still we need to deal with
messages, not belonging to a session.

Lachlan

-----Originalnachricht-----
Von: Roy, Radhika R, ALCTA
An: Christian Huitema; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;
[email-masked]; [email-masked]
Gesendet: 09.10.01 19:21
Betreff: RE: [Simple] IM over the signaling connection

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;

Note that my point was not to ignore the lessons of the past, but to
point
out that widely deployed systems such as SMS are not going to disappear
in a
day, or in a year -- they are with us for at least one or two upgrade
cycles, i.e. at least 4 to 6 years.

 

beneficial

[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but it
has a
real danger as well: 1. People might mis-use it overloading the
signaling
path through sending the larger messages or increasing the frequency of
shorter messages (had been explained earlier) and 2. It also breaks the
original SIP model - separation between signaling and media path.
Proposals
need to be there to address these two concerns.
 
-- Christian Huitema
 
-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;

Hi, Vasilis:

"Paging"
in SIP?

Radhika

-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson,
Jon;

Christian Huitema wrote: 

Correct. However Operators realized that SMS was the wrong (was very
successful financially) technical solution for messaging. 
Remind you that when the people designed (late 80s) SMS they did not
have
any idea of how successful commercial service will be. 
That is why the next generation of multimedia messaging is using HTTP as
the
transport. 
I understand that this is a difficult point to understand with some
people
in the list. 
Let me remind you that the telephony people with more than hundred years
of
experience realized in the late seventies that 
in order to scale and have very reliable networks you had to separate
signaling from transport (initially signaling was mixed with transport -

It seems to me that certain people want to regress in time and mix
signaling

-- Christian Huitema

---

From: [email-masked]
Date: Tue, 9 Oct 2001 19:35:39 -0500

you are both correct - BUT in many cases two domain MESSAGE proxies will
maintain a long-lived session that will multiplex multiple messages
from multiple users, and of course this becomes even more common in
message clearinghouses (which do exist in the SMS world).

DOMAIN A                                    DOMAIN B
=====================..........=====================

UA1 <----> ++++++++++          ++++++++++ <----> UA4
           +        +          +        +
UA2 <----> + PROXY1 + <------> + PROXY2 + <----> UA5
           +        +          +        +
UA3 <----> ++++++++++          ++++++++++ <----> UA6

...To establish-a-TCP (or anything else that has congestion control) per
message <because it may extend into a conversation> does not make sense
between proxies - most modern app protocols multiplex (which can be done
using simple <to> and <from>) at proxy2proxy links, have some timeout
mechanism to close the connection if it not used for <some> time, and
potentially open multiple parallel sessions based on some
users/messages/sec/session logic.  You can also imagine maintaining several
sessions between the proxies, each with a different QoS SLA etc.

It is possible that UAs will use page mode on the UA-PROXY leg and the
PROXY-PROXY leg will multiplex into an existing session (and back to a page
mode on the other side)

[slight subject change]

and - I don't see a problem with using TCP with some HTTP/SIP framing as
the
transport - run it as a separate TCP session but have as much commonality
between the two models (page/session) as possible.

- gur

Gur Kimchi
Chief Architect
VocalTec Communications

> Ben Campbell wrote:
> clean-up. [snip]

---

From: Michael Hammer <[email-masked]>
Date: Wed, 10 Oct 2001 16:06:18 -0400

All,

Random thought:  Is this discussion of connection-oriented versus
connectionless any different than the one that resulted in the Fast
Select procedure used in X.25 networks?  Small amount of data
carried in the connection request (Invite) which is then declined for
connection setup purposes, but the data gets delivered.  If the
receiving party wishes to reply with data, connection is accepted.

Mike

At 10:59 PM 10/9/2001 +0200, Brazier Lachlan wrote:

Hello,

I believe that IM should be set up through an INVITE request, because
this

BUT:

1) Sending ANY message with ANY content in not forbidden in SIP. Nobody
can

stop me sending anything. UAS can complain about my request because
of

several reasons (size, kind of request, security, ...), but it still has
to

handle my request.

2) Sometimes it makes more sense to send a single message, than building
a

registered at it's registrar, how many calls were missed, how many calls
are

on the awnsering machine, how much money the user won in the
national

lottery, etc.. I really believe, a lot of applications will want to
send

implement and use.

For these reasons I think people will use simple messages to send data.
So I

There was the argument that requests with huge data in the body could
block

proxies on the signaling path (if I understood that argument). This
is

another reason, we should define how to handle these requests, otherwise
we

will always have problems with load balancing or server
availability.

Hm, I think that's what I wanted to say. Please note again, that for IM
I

vote for setting it up through an INVITE. Still we need to deal
with

Lachlan

-----Originalnachricht-----

Gesendet: 09.10.01 19:21

-----Original Message-----

From: Christian Huitema
[mailto:[email-masked]]

Jon;

Note that my point was not to ignore the lessons of the past, but
to

point

out that widely deployed systems such as SMS are not going to
disappear

in a

day, or in a year -- they are with us for at least one or two
upgrade

Also note that if the usage is actually a page, then a
"message" is less

taxing on the infrastructure than an "invite" + the necessary
session

clean-up. Let's compare:

2) Session: INVITE + response; ACK; BYE+response; + additional cost
of

beneficial

[Roy, Radhika R, ALARC]  Yes, there is also a clear efficiency, but
it

has a

signaling

path through sending the larger messages or increasing the frequency
of

shorter messages (had been explained earlier) and 2. It also breaks
the

Proposals

-- Christian Huitema

-----Original Message-----

From: Roy, Radhika R, ALCTA
[mailto:[email-masked]]

Jon;

Hi, Vasilis:

Good that you have reminded the very important lesson from the
past.

"Paging"

in SIP?

Radhika

-----Original Message-----

From: Vasilis Polychronidis
[mailto:[email-masked]]

To: Christian Huitema

Jon;

Christian Huitema wrote:

very

not

have

That is why the next generation of multimedia messaging is using HTTP
as

the

transport.

people

in the list.

Let me remind you that the telephony people with more than hundred
years

of

separate

signaling from transport (initially signaling was mixed with transport
-

that is the current case for all the analog lines going from home to
the

transport of user data.

signaling

and user data.

Let us please learn from the history and lets try not to repeat the
same

mistakes.

that we will indeed use "MESSAGE over SIP" in the page mode for
a

will have to bring in the session some members who can only use the
page

-- Christian Huitema

simple mailing list

simple mailing list

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Oct 2001 12:05:12 -0400

Just for the sake of education, people should be aware that SIP does indeed
support persistent connections between servers. This is described (although
not well) in the current bis; bis-05 will be substantially clearer in its
usage. My own companies proxy ships with this capability today. As Gur
suggests, we maintain the connections until some period of inactivity after
which they are closed.

However, I am not suggesting that we use SIP proxies for message transport.
Using Brian's decomposition, I think a reasonable path is:

format: some subset of sip headers (From, Content-Type, Content-Length)
encapsulation: no additional encapsulation layer
transport: tcp or sctp

Routing is the hard one. If we use SIP proxies, we have two choices. Choice
1 is that we reuse the SIP proxies we already have, and that a IM during a
session is sent over the same set of proxies which record-routed. I.e., in
this case, the IMs are sent over the same path as a re-INVITE would be.
However, I expect that:

(1) many proxies will record-route for reasons that have nothing to do with
firewall traversal, but rather for signaling and services, so we get
increased message traffic and worse performance from our proxies.
(2) many of the hops between proxies for a route set will be UDP, not TCP

Thus, using the route set from the signaling path will not provide
sufficient congestion control in many cases. I believe that is the primary
problem.

So, if we deploy separate proxies, which ALWAYS use tcp/sctp, and then use
them for routing, we are already incurring the additional cost of such
deployment. We also get the following drawbacks:

(1) sheer message/s rate of a sip proxy forwarding logic will be far less
than could be accomplished with pure transport layer routing logic (i.e.,
based on IP/ports or something else)
(2) these elements cannot support routing of other media types, so we will
need to deploy a third component as well.

The key is to focus on system cost for a complete communicatins system, not
IM alone. Anyone doing IM these days is also doing voice already at least.

I would further argue that if we want muxing of messages between proxies,
SCTP is probably the best solution for that. Indeed, it provides the nice
benefit of a demux within a connection, using stream IDs. I believe (someone
correct me if I am wrong) that you do not need to set up a stream, you can
simply use a stream ID within an association. This means that we can do the
routing at the IP/port layer for non-multipexed transports, and use
IP/port/stream ID for muxing. Let me give an example:

User A ------- proxy A ------ proxy B ----- user B

Between proxy A and proxy B is SCTP. user A sends an INVITE to proxy A, and
indicates usage of comedia. That invite indicates he'd like to receive IM
via a tcp connection made to IP/port A1/A2 (thus, he's passive). THis goes
to proxy A. Proxy A rewrites the SDP, so that it indicates that IM for this
call should be received on SCTP assocation on IP/port/streamID A3/A4/A5.
THis goes to proxy B, which rewrites the SDP to indicate that IM for this
session should be received on TCP with IP/port B1/B2. User B gets this, and
sends a 200 OK, indicating that he's active for this (and therefore, no
IP/ports are provided). The 200 OK is propagated back to user A. B then
opens a TCP connection to B1/B2 on the proxy. The proxy receives this, and
maps data received on B1/B2 to SCTP association connection to A3/A4 (which
already exists) with streamID A5. Proxy A opens a tcp connection to B1/B2
and associates it with data received/sent on the SCTP connaction with stream
ID A5. Now, B sends data, and it travels to A using the shared SCTP
association between proxy A and proxy B.

There is no reason this TCP/SCTP shuffling function needs to be co-resident
in the proxy, and it can be moved off of it if you like. Add UDP shuffling
and it works for RTP traffic as well. Now, we have a generic element for
supporting all media types. It scales independently of the proxy. We get
shared connections between enterprises. We get reasonable congestion control
w/o HOL blocking, which is really good for IM, IMHO. The solution also will
result in direct e2e IM when there are no firewalls, since if the proxies do
nothing instead that will be the result.

If you do split off this TCP/SCTP shuffler, you need to control it from the
proxy. There are many ways to do that, including megaco, mgcp, and whatever
midcom eventually looks like.

-Jonathan R.
---

> From: [email-masked] [mailto:[email-masked]]
> Sent: Tuesday, October 09, 2001 8:36 PM
> To: Ben Campbell
> Cc: [email-masked]; Henning Schulzrinne; Christian Huitema;
> Jonathan Rosenberg; Peterson, Jon; Roy, Radhika R, ALCTA;
> [email-masked]; [email-masked];
> Vasilis Polychronidis

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 11 Oct 2001 12:10:51 -0400

One additional thing to consider is a point raised by Gur on the list.

Do we need to provide a way to correlate IMs sent in page mode with IMs sent
through a session that is later established? If not, the user experience
might not be so great. It seems like we might want to provide a correlation
capability so that usage of sessions can be done in such a way that a client
can be built for whom the transition is natural. 

To some degree, we are doing the wrong thing by providing two ways of
solving the same problem; IETF guidelines general advise to "pick one". I do
think there are sufficient use case scenarios to warrant both page and
session models, but to make up for having done both we probably need to
consider a story on how they can be correlated.

Adding some kind of correlation ID to the message meta-data is the simplest
way. For sessions, its right there with the other headers, for page mode, it
could be a SIP header, or a meta-data header like the CPIM headers are.

-Jonathan R.

---
  
-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 4:20 PM
To: 'Christian Huitema'; Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

Brian
-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: Tuesday, October 09, 2001 1:09 PM
To: Roy, Radhika R, ALCTA; Vasilis Polychronidis
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

-- Christian Huitema

-----Original Message-----
From: Roy, Radhika R, ALCTA [mailto:[email-masked]] 
Sent: Tuesday, October 09, 2001 6:23 AM
To: Vasilis Polychronidis; Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

Hi, Vasilis:

Radhika
-----Original Message-----
From: Vasilis Polychronidis [mailto:[email-masked]]
Sent: Monday, October 08, 2001 4:43 PM
To: Christian Huitema
Cc: Ben Campbell; Jonathan Rosenberg; Henning Schulzrinne; Peterson, Jon;

Christian Huitema wrote:

---

From: [email-masked]
Date: Thu, 11 Oct 2001 19:52:53 -0500

Paul -

not having the Session-ID and only relaying on the <In-Reply-To> has
some increased statfullness requirements on proxies - and again, my
original
point that while we --hope-- many IM sessions will be end2end, in
reality many inter-domain IM sessions will traverse some DMZ
IM or SIP proxy that will provide authentication and authorization -
domain policy ("this user is blacklisted", "translate between English and
French")
should be done when entering the network, not by the UA.

And of course if the proxy is no longer needed it can replace the u2p2u
session
with an u2u one - another advantage of using standard SIP setup for IM
sessions.

Also - I believe messages, regardless if sent using pages or in sessions,
should be associated with a "thread-of-messages ID" - this makes for a much
cleaner design - not needed in every case mind you, but in many
person2person
scenarios.  Also this provides a stateless way for both UAs and Proxies
to continue past sessions - just choosing some arbitrary time for a session
to expire -because the transport closed- or -some timer fired- is less
then optimal.  I may, as a user, as I do many times, continue a
conversation
I finished last night - and it should contextually be the same "thread" -
while clearly the transport will be replaced and a new session created.

so while I am not objecting to an additional optional <in-reply-to> header,
I dont think it replaced <Thread-ID>.

- gur

> Paul Kyzivat Wrote:
>
> In addition to <Message-ID> and <Thread-ID>, it would be useful to have
> an <In-Reply-To> header, so that proper message ordering can be
> achieved. In theory the <In-Reply-To> is sufficient to define a thread,
> but in practice it probably isn't, so having both is useful.
>
> On the other hand, having <Thread-ID> might encourage abuse of paging
> mode by providing another way to implement sessions. Just having
> <Message-ID> and <In-Reply-To> would be sufficient to tie a new session
> to a preceding page mode message.
>
>
>> [email-masked] wrote:
>>
>> Providing messages with two optional headers: <Message-ID> and
<Thread-ID>
>> allows the sender to choose to
>>
>> (1) provide message identification for later processing (if this is not
>> clear then imagine some message indexing at the server to allow message
>> access by non-SIP elements, like web-browsers via an App Server, WAP
etc)
>>
>> and
>>
>> (2) to associate a specific message with a thread-of-messages - this way
>> if a message arrives using page mode, and a later session is established
>> and a new message arrives with the same Thread-ID, the UA knows it is
part
>> of the same session - this also allows muxing multiple threads within a
>> session without any transport muxing.
>>
>> (of course both IDs are generated by the originating UA, the two headers
>> should
>> be optional - many apps do not need them).

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 22:49:15 -0400

One thing I do want to note.... I think that whatever we do for thread IDs,
in-reply-to's or whatever should not hold up the basic paging model. All of
those things are primarily needed to facilitate integration with a session
model, and therefore we should worry about those things later. Lets get the
basic paging model done. 

-Jonathan R.

---

> Sent: Thursday, October 11, 2001 8:53 PM
> To: Paul Kyzivat
> Cc: [email-masked]; Ben Campbell; 'Rosen, Brian'; Henning
> Schulzrinne; 'Christian Huitema'; Jonathan Rosenberg; Peterson, Jon;
> Roy, Radhika R, ALCTA; [email-masked];
> [email-masked]; Vasilis Polychronidis

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 22 Oct 2001 21:13:55 -0400

> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Thursday, October 11, 2001 7:29 PM
> To: [email-masked]
> Cc: Jonathan Rosenberg; [email-masked]; Ben Campbell; 'Rosen,
> Brian'; Henning Schulzrinne; 'Christian Huitema'; Peterson, Jon; Roy,
> Radhika R, ALCTA; [email-masked];

SIP actually has an In-Reply-To, which lists the call-id of the message that
this request is "replying" to. Effectively, this means that the call-id acts
as our message ID in the paging model. Based on the sip definition, call-id
is globally unqiue for each request outside of a call-leg. Since paging mode
doesn't set up a leg, this has the desired property.

-Jonathan R.

---

---

From: Ben Campbell <[email-masked]>
Date: Wed, 24 Oct 2001 16:53:56 -0500

If we had those headers, would you expect them to be in SIP headers or 
in the meta-data of message/cpim? It seems to me the second makes more 
sense, as this is information that may need to be delivered end-to-end 
across a CPIM boundery.

[email-masked] wrote:

> Jonathan -
> 
> I agree we should not hold up the basic page mode - but I feel the ability
> to associate MESSAGEs with a "thread of MESSAGES" is needed regardless if
> it in a page or in an INVITE-established session - again I am not asking
> for
> anything mandatory - but I do feel unique optional <Message-ID> and
> <Thread-ID>
> headers should be in the draft now.
> 
> I think the use of these optional headers (+In-Reply-To) is obvious, and
> documenting them should not be controversial - but I have been wrong
> before...
> 
> at the same time, I have not heard an objection yet to their inclusion.
> 
> - gur
> 
> 
>>>-Jonathan R. Wrote:
>>>
>>>One thing I do want to note.... I think that whatever we do for thread
>>>
> IDs,
> 
>>>in-reply-to's or whatever should not hold up the basic paging model. All
>>>
> of
> 
>>>those things are primarily needed to facilitate integration with a
>>>
> session
> 
>>>model, and therefore we should worry about those things later. Lets get
>>>
> the
> 
>>>basic paging model done.
>>>
> 
> 
>

---

From: [email-masked]
Date: Thu, 25 Oct 2001 01:47:17 +0200

>> Ben Campbell Wrote:

out of the two choices It does makes more sense to put it into the
individual
cpim header - with multipart mime I could see multiple messages in one
MESSAGE body
(think forwarding/aggregating proxy).

>> Ben Campbell Wrote:
>>
>> I think I should have said "series" of messages, rather than "stream" of

>> messages, because I think I conveyed the wrong idea. The current draft
>> assumes a one to one correspondence between MESSAGE requests and IMs. It

>> does mention that if you want to send something larger than the maximum
>> UDP size, you should use TCP.
>>
>> If we are talking about MESSAGE as a file transfer protocol, I think
>> this would be better modeled using an INVITE initiated file transfer
>> session of some sort.

There is no problem limiting the size of IMs to some very small size-
the usual solution when needing to send large amounts of data is to send
"by reference" - e.g. send a URL to the file you want the other side to
get,
instead of the file itself.  I see no problem with limiting sizes of IMs to
under
512 bytes, allowing both UDP and TCP to be used.

remember that on the largest IM system in the world (GSM-SMS) the maximum
size
is 160 chars - I dont think we are here to solve file/image/XYZ transfer
problems,
if you want to send anything that is not an IM (and the definition is
clear) -
INVITE to a specific-media session or MESSAGE a URL of where the resource
can be found.

(http://www1.ics.uci.edu/pub/ietf/uri/draft-antti-gsm-sms-url-04.txt)

- gur