Subject: RE: [Simple] SIP & Presence - Joined@Hip?

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 27 Jul 2001 18:09:49 -0400

> -----Original Message-----
> From: Zane Thomas [mailto:[email-masked]]
> Sent: Thursday, July 26, 2001 5:11 PM
> To: [email-masked]
> Subject: Re: [Simple] SIP & Presence - Joined@Hip?
> 
> 
> "Instant messaging is defined as the exchange of content 
> between a set of
> participants in real time. Generally, the content is short 
> textual messages,
> although that need not be the case."
> 
> Aside from the admittedly not insignificant differences between the
> different types of "real time" data represented by IMs and audio, for
> instance, it's not clear to me what is so *fundamentally* 
> different that IM
> should have special status in SIP.

Indeed, which would explain why the group is using SIP to establish IM
exchanges as a session described in the SDP. This has been discussed on the
simple list, and is reflected in two drafts which sit on the SIMPLE web
page. I recommend you peruse them:

http://www.ietf.org/internet-drafts/draft-ietf-simple-im-sdp-00.txt
http://www.ietf.org/internet-drafts/draft-ietf-simple-im-session-00.txt

> 
> I realize there is some difficulty in defining exactly what a 
> Session is
> with IM but it seems to me that any particular IM application 
> might choose
> to define one in a number of different ways.  For instance, I 
> might define a
> Session (from the SIP perspective) as two peers knowing each other are
> online and establishing UDP ports to use for exchanging 
> messages. 

Sounds like you are arguing that presence and session initiation are
related.

> Another thing that occured to me is that if you provide an 
> arbitrarily large
> MESSAGE which can be sent over SIP proxys then it won't be 
> long before the
> SIP servers are carrying a lot of traffic containing MP3 files.

Which is why the current drafts discuss establishing message transport e2e
(nats and firewalls permitting), over TCP for such things.

-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: Fri, 27 Jul 2001 15:31:52 -0700

> (nats and firewalls permitting), over TCP for such things.

Do you mean over TCP or over SIP/TCP?
I definitely support the first case over TCP or UDP for that matter.
I do not see the value of extra overhead of using SIP as transport.
Do you?

> _______________________________________________
> simple mailing list
> [email-masked]
> http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: "Zane Thomas" <[email-masked]>
Date: Fri, 27 Jul 2001 17:29:01 -0700

Jonathan,

> I recommend you peruse them:
>

Thanks.

> > ... I might define a

They're certainly related, but the question in my mind is to what extent and
whether they should be tightly coupled in a protocol.  I like SIP - maybe
even a lot - for its ability to provide contact information and for its
elegant architecture and relative simplicity.  It seems to me that a
similarly focused Presence Server would be really great to have, since it
could be used in conjuction with SIP or on its own.  Sorry if this is
ancient history for you, but in the future as other newbies arrive on the
scene some may have the same concerns.

> (nats and firewalls permitting), over TCP for such things.

Got it - but the MESSAGE method does provide for using SIP as a transport,
and if it's there it will be used.  I might like to provide a SIP server,
and network with others, but I don't think I like the idea of it being used
for arbitrarily large MESSAGEs, or any messages at all really.  I think the
issue of providing proxy support for handling NATs and firewalls when it
comes to transporting content is another seperate issue, one which will have
associated bandwidth costs and will need a sustainable revenue model.

Zane