Subject: RE: [Simple] Sessions of MESSAGEs

From: Michael Hammer <[email-masked]>
Date: Mon, 20 Aug 2001 13:22:24 -0400

Jonathan,

Based on the other comments about sending MESSAGE over SIP signaling paths, 
it would then be necessary to segregate and prioritize SIP traffic to 
prevent 1M IM messages from delaying SIP session setup traffic.

We don't need to repeat the problems that GSM systems had with SMS traffic 
interfering with call setup!

Mike

At 12:55 PM 8/20/2001 -0400, Jonathan Rosenberg wrote:

>
>
> > -----Original Message-----
> > From: Ben Campbell [mailto:[email-masked]]
> > Sent: Monday, August 20, 2001 10: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.
>
>I agree.
>
> >
> > 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.
>
>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?
>
>-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
>
>_______________________________________________
>simple mailing list
>[email-masked]
>http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Theodore Havinis" <[email-masked]>
Date: Mon, 20 Aug 2001 15:20:39 -0700

One could over-provision with extra C7 signalling trunks and handle the
extra traffic created
by sms.

I think the problem of failure, in my mind arose from the fact, given a
single switch, the same
connection management software in that same switch handled both call setup
and sms setup.
That caused congestion, slowing down switches, before anything else.

Unfortunately in mobile telephony (GSM) one switch has to handle both sms
and calls due to
user mobility and also because mobility and connection management is tightly
coupled.

I think whatever the solution may be, if a single SIP server is used to
handle both IM traffic+whatever
else, it will inevitably experience congestion.

Cheers
Theo

>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Michael Hammer
>Sent: Monday, August 20, 2001 10:22 AM
>To: Jonathan Rosenberg
>Cc: Ben Campbell; Peterson, Jon; [email-masked]'
>Subject: RE: [Simple] Sessions of MESSAGEs
>
>
>Jonathan,
>