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

From: [email-masked]
Date: Wed, 24 Jul 2002 11:30:16 +0300

I agree in removing the proxy modifying the SDP part in the spec. But we need session-policy and message-session to complete in parallel.

There is a requirement for messages to do through intermediaries and session-policy should fix that.

Regards,
Hisham

> -----Original Message-----
> From: ext Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 11:41 PM
> To: Robert Sparks
> Cc: Paul Kyzivat; Sean Olson; James Undery; SIMPLE (E-mail)
> Subject: Re: [Simple] Message Transport Protocol (SIP vs IMTP)
> 
> 
> inline.
> 
> Robert Sparks wrote:
> > <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?
> 
> 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.
> 
> > 
> > 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.
> 
> 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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 24 Jul 2002 08:56:06 -0400

[email-masked] wrote:
> I agree in removing the proxy modifying the SDP part in the spec. But we
> need session-policy and message-session to complete in parallel.

Not really. Message sessions will work without session policy, and you 
will be able to use intermediaries too. You will just need to muck with 
SDP, as we have always been doing (and will continue to be done, I 
suspect).

> session-policy should fix that.

Session-policy is one way to fix that.

-Jonathan R.