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

From: Adam Roach <[email-masked]>
Date: Tue, 23 Jul 2002 16:09:45 -0500

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]
>
> 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.

Okay. I like consistency. Sounds good to me.

>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.

And, as has been demonstrated by our experience in VoIP,
people are going to do this. There's nothing we can do
to stop them. I don't think it deserves any more endorsement
than we've done for the same technique WRT voice. (That is,
none).

> 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.

And I think that solving this problem only once makes a whole
lot more sense.

Is there a *requirement* that message sessions can go through
intermediaries? Basically, as you've pointed out, they're
just media. We have SIP with voice and video media deployed
just fine without such a mechanism, so I can't imagine that
this would be a legitimate *requirement* of a messaging solution.

That said, it's certainly a "nice to have", and the session-policy
draft makes a good start at defining requirements and mechanisms
for a solution.

So, would it be possible to pull the routing attribute out of
the message session draft altogether, get it out the door
(it's extremely important!), and then work on a general media
routing technique after we have it in the RFC editor's queue?

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

---

From: Sean Olson <[email-masked]>
Date: Tue, 23 Jul 2002 14:42:49 -0700 (PDT)

> routing technique after we have it in the RFC

I'm all for having the message session work completed
as quickly as possible. But I think the routing
aspects need to be fleshed out before this can be
a really useful mechanism. In particular, NAT/firewall
traversal can be a bit thorny otherwise.

/sean

__________________________________________________
Do You Yahoo!?
Yahoo! Health - Feel better, live better
http://health.yahoo.com
_______________________________________________
simple mailing list
[email-masked]
http://mailman.dynamicsoft.com/mailman/listinfo/simple