Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)

From: "James Undery" <[email-masked]>
Date: Tue, 23 Jul 2002 16:47:36 +0100

I think you may be missing the point of this. The reason for not using SIP originally was the worry IM would be used to transfer huge files such as mp3s. To counter this Jonathan created a cut down version of SIP called IMTP, once loose routing and TCP requirements were introduced into the bis spec this cut down version wasn't required. The crunch is it's obviously still required for non 3261 entities to prevent UDP and old Record Route nastiness occurring. Proxy-Require, new Protocol or some other solution something needs to be done.

James

P.S. If rfc2543 proxies are a non-issue can't we just deprecate UDP while we're at it ;-)

-----Original Message-----
From: Sean Olson [mailto:[email-masked]]
Sent: 23 July 2002 16:33
To: 'Sriram Parameswar'; 'Paul Kyzivat'; James Undery
Cc: 'SIMPLE (E-mail)'
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)

I don't see the benefits of using IMTP as a protocol identifier in this case. In fact, I think it negates
some of the benefits of using SIP as the underlying protocol altogether. What you really want in this case
is MESSAGE-specific behavior. Or did people have the notion of sending something other than MESSAGE
in this "IMTP" transport? I really dislike the notion of receiving a 420 in this situation. Because a session
was explicitly established with a policy to route MESSAGEs through some set of intermediaries, it seems
a bit odd that these intermediaries wouldn't be able to handle MESSAGE (or for that matter, loose routing
if needed)

/sean
-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Sriram Parameswar
Sent: Tuesday, July 23, 2002 7:55 AM
To: 'Paul Kyzivat'; James Undery
Cc: SIMPLE (E-mail)
Subject: RE: [Simple] Message Transport Protocol (SIP vs IMTP)

Wouldn't a 'Proxy-Require: message_session' cause the proxy to send back a 420 Bad Extension? Is this the behavior we want? After all we want the IM Session to succeed in most cases.
Regards, 
Sriram 
__________________________________________ 
Sriram Parameswar              Phone: 972-685-8540 
Interactive Multimedia Server (IMS) Fax: 972-684-3986 
Nortel Networks, Richardson USA  Email: [email-masked] 

-----Original Message----- 
From: Paul Kyzivat [mailto:[email-masked]] 
Sent: Tuesday, July 23, 2002 8:09 AM 
To: James Undery 
Cc: SIMPLE (E-mail) 
Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP) 

James Undery wrote: 
> 
> Hi, 
> 
> At the SIMPLE meeting I believe the consensus was to go with a SIP based message transport, however, it was unclear if this should be SIP or IMTP. The argument for SIP is because of rfc3261 we can now use SIP as is, IMTP was complicated due to all the requirements of messaging that couldn't be addressed easily; I'd definitely agree with that, however, I believe that won't work, rfc2543 proxies may still do all the bad things IMTP was designed to avoid. The suggestion made by Rohan (that I strongly agree with) was to take  rfc3261 and just swap SIP/2.0 for IMTP/1.0 every time the protocol is mentioned in the spec. This has the advantage that you know older proxies aren't going to misbehave and the draft specifying it should be trivial modification to Jonathan's latest draft.
To avoid misbehaving proxies, shouldn't it be sufficient to do something like 
        Proxy-Require: message_session 
or something to that effect? Changing the version requires much more mucking in the stack. 
        Paul 
_______________________________________________ 
simple mailing list 
[email-masked] 
http://mailman.dynamicsoft.com/mailman/listinfo/simple

---

From: Sean Olson <[email-masked]>
Date: Tue, 23 Jul 2002 09:39:08 -0700 (PDT)

Actually, I completely understand the point
of the original IMTP proposal :) And BTW,
calling it IMTP does *NOTHING* to fix these problems.
(By this, I mean changing the protocol identifier to
IMTP)

Sure, you can define a new profile for SIP, label
it IMTP and assume everything goes well. 
But let's be honest. Calling it IMTP will NOT 
stop people from sending large files via IM. It
will NOT solve the congestion control problem.
It will NOT allow you to magically work with non-3261
entities. 

I'm not claiming that 2543 proxies are a non-issue.
I am claiming that you can't take a 2543 proxy out
of the box and run IMTP or any other new profile of
SIP through it. If you want to support "IMTP"
(or whatever we label it), you are going to have to
do some work. I don't think it's unreasonable to 
make 3261 compliance part of that work. You can
still route the INVITE for the message session through
the older 2543 proxies, you will just need something
new for the "media". 

/sean

P.S. While I'm the last person to admit, I think UDP
for SIP is on its deathbed ;-)

--- James Undery <[email-masked]> wrote:
> 
> I think you may be missing the point of this. The
> reason for not using SIP originally was the worry IM
> would be used to transfer huge files such as mp3s.
> To counter this Jonathan created a cut down version
> of SIP called IMTP, once loose routing and TCP
> requirements were introduced into the bis spec this
> cut down version wasn't required. The crunch is it's
> obviously still required for non 3261 entities to
> prevent UDP and old Record Route nastiness
> occurring. Proxy-Require, new Protocol or some other
> solution something needs to be done.
> 
> James
> 
> I don't see the benefits of using IMTP as a protocol
> identifier in this case. In fact, I think it negates
> some of the benefits of using SIP as the underlying
> protocol altogether. What you really want in this
> case
> is MESSAGE-specific behavior. Or did people have the
> notion of sending something other than MESSAGE
> in this "IMTP" transport? I really dislike the
> notion of receiving a 420 in this situation. Because
> a session
> was explicitly established with a policy to route
> MESSAGEs through some set of intermediaries, it
> seems
> a bit odd that these intermediaries wouldn't be able
> to handle MESSAGE (or for that matter, loose routing
> if needed)
> 
> /sean
> From: [email-masked]
> [mailto:[email-masked]] On
> Behalf Of Sriram Parameswar
> Wouldn't a 'Proxy-Require: message_session' cause
> the proxy to send back a 420 Bad Extension? Is this
> the behavior we want? After all we want the IM
> Session to succeed in most cases.
> Regards, 
> Sriram 
> > At the SIMPLE meeting I believe the consensus was
> to go with a SIP based message transport, however,
> it was unclear if this should be SIP or IMTP. The
> argument for SIP is because of rfc3261 we can now
> use SIP as is, IMTP was complicated due to all the
> requirements of messaging that couldn't be addressed
> easily; I'd definitely agree with that, however, I
> believe that won't work, rfc2543 proxies may still
> do all the bad things IMTP was designed to avoid.
> The suggestion made by Rohan (that I strongly agree
> with) was to take  rfc3261 and just swap SIP/2.0 for
> IMTP/1.0 every time the protocol is mentioned in the
> spec. This has the advantage that you know older
> proxies aren't going to misbehave and the draft
> specifying it should be trivial modification to
> Jonathan's latest draft.

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Jul 2002 13:20:32 -0400

> the older 2543 proxies, you will just need something

I'm not sure I get your point - I suspect we are in violent agreement.

Is anyone arguing that you don't need something new for message sessions? If all you currently have is 2543 based, then of course you do. But it would be nice if the only
new thing you needed was a path through 3261 compatible proxies.

	Paul

---

From: Sean Olson <[email-masked]>
Date: Tue, 23 Jul 2002 10:35:00 -0700 (PDT)

I think we are saying the same thing then.
The one (I believe small) difference of opinion
I have with Rohan's proposal is that I don't
think we should call this IMTP. I think it should
be labelled "SIP/2.0"

/sean

--- Paul Kyzivat <[email-masked]> wrote:
> Is anyone arguing that you don't need something new
> for message sessions? If all you currently have is
> 2543 based, then of course you do. But it would be
> nice if the only

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 23 Jul 2002 13:58:35 -0400

> think we should call this IMTP. I think it should

Well (sorry Rohan) I don't like that much either. To support it I have to hack every proxy to accept either "SIP/2.0" or "IMTP/1.0", remember it, and put it into responses.
This is a pretty invasive change to the stack. If I have a 3261 compatible stack, it ought to be easier than that. Hence my suggestion for Proxy-Require - it has exactly
the right semantics: proxies that don't support it are supposed to complain. And the hooks to handle it should be easy in most stacks.

(Of course non-compliant stacks could ignore it. But they could ignore the version too. You can't protect against all forms of stupidity.)

	Paul

---

From: Robert Sparks <[email-masked]>
Date: 23 Jul 2002 14:47:11 -0500

<wg member hat>
I'm a little confused about this whole discussion.

The mechanism described in
draft-rosenberg-simple-message-sessions-00.txt
uses information collected in the INVITE to build
a route set that is used as as preloaded route in
each message in the session.

This preloaded route is going to contain only
elements that will process these MESSAGE requests
in a congestion-safe fashion. (Otherwise, somebody
violated the protocol).

So, why is it we're wringing our hands over one of
these hitting a 2543 proxy?

IMHO, this is a non-issue and our time would be 
better spent inspecting and improving on the mechanism
in the draft for collecting that preloaded route.

RjS
</wg member hat>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 23 Jul 2002 16:40:32 -0400

inline.

> these hitting a 2543 proxy?

I am collecting my thoughts on this issue; I think there is more here in 
this IMTP vs. SIP/2.0 debate than whether the proxies are 3261 compliant 
or not.

> in the draft for collecting that preloaded route.

Well, while we are on that subject, let me make a radical proposal.

I would propose that, if we truly believe that IM sessions are NO 
different than voice sessions, we should have the same explicit support 
here for intermediaries as we do for RTP - which is NONE.

That leaves several options for routing through intermediaries:

1. Proxies modify the SDP, as they do today for VoIP, replacing the URI 
in there with the URI that points to an intermediary which contains a 
mapping to the next hop. In this case, there is no preloaded route. What 
about congestion control? Well, we would mandate that message sessions 
MUST be sent over a congestion controlled transport, enforced with 
Proxy-Require: congestion-safe in the MESSAGE, used in all cases. 
Forking/redirection can still be avoided, but becomes an issue of proper 
implementation of the intermediaries. I suspect it would never happen in 
practice, since the URI inserted into the SDP would be some random 
string that is created for this mapping (i.e., 
sip:[email-masked]).

2. If there is a mechanism for discovering loose routes for media, it be 
applicable for all media types, not just messaging, and not require 
proxies to muck with SDP. My session policy proposal:
http://search.ietf.org/internet-drafts/draft-rosenberg-sipping-session-policy-00.txt
provides one such mechanism. However, it would be a mistake to more or 
less invent that mechanism for each media type and hack it into the SDP 
for that type. If we believe in the concept of loose routing of media, 
and I do, we should solve the problem generally.

Flame away....

-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