Subject: RE: [Simple] IM: A session or not

From: Robert Sparks <[email-masked]>
Date: Wed, 2 May 2001 14:54:19 -0400

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, May 02, 2001 11:03 AM
> To: 'Robert Sparks'; [email-masked];
> [email-masked]
> Subject: RE: [Simple] IM: A session or not
> 
> 
> > From: Robert Sparks [mailto:[email-masked]]
> > 
> > >>Is it sufficient for the MESSAGE requests in the chat session 
> > >>to follow the Route established by the INVITE/BYE bounding it? 
> > >> 
> > >>  Proposal : 
> > >>   Yes - 
> > >>   In the normal case, proxies that don't truly need to be in the 
> > >>   path of subsequent requests won't record route, so we should 
> > >>   end up with a minimal path for these requests. 
> ... 
> > Adam Roach replied:
> > >Personally, I *really* prefer another approach Jonathan presented
> > >at the SIMPLE meeting during the 50th IETF: the INVITE contains SDP
> > >using UDP or TCP as the transport, and message/sip as the 
> media type.
> ...
> > Lets explore the details of this a little then.
> > 
> > We are assuming that there is enough information in the
> > setup that things in the middle affecting end-end
> > visibility (SIP aware firewalls or nats for example) can 
> > do what they need to do, at least as well as they do for rtp
> > streams today. This is almost a no-brainer for sip over UDP,
> > but are we still ok if the chat session needs to take place over
> > TLS? 
> 
> The exact same way we do it for RTP.
> 
> Alright, that's sort of flip; my point is: whatever you do to secure
> RTP traffic can be done for IM "media." If it's sufficient for one,
> it's sufficient for the other. If it's insufficient for one, it's
> insufficient for the other.

I agree with you here, at least on the approach to the solving the
problem. I do want to reinforce that more work would have to be done
to support things like signalling that the chat session should take
place using SIP over TLS and providing enough information. That is
different enough from the mainstream work done to date that we need
to look at it closely for dragons.

> 
> > How will this impact environments that restrict all SIP traffic
> > across thier boundaries to proxies? How can you get the chat
> > session through them? Or are we _only_ going to support chat
> > if we can get e-e with no proxies (this has some appeal - we
> > don't have to worry about a chat MESSAGE getting forked).
> 
> The exact same way it does for RTP.
> 
> And that's *not* intended to be flip. Firewalls break media; for
> normal SIP sessions to work through them, we expect them to fix
> the mess they've created: open holes or modify the SDP.
> 
> Firewalls break SIP-IM messages as media; for SIP-IM sessions to
> work through them, we expect them to fix them mess they've
> created: open holes or modify the SDP.
>  
> Remember, our job is **NOT** trying to figure out ways to
> circumvent measures put in place by firewall administrators. 
> If you're concerned about getting the messages through a
> firewall regardless of local policy, we should really be putting
> together a draft on running SIP IM sessions over HTTP (a la RFC3093).

And you missed my point altogether here. I wasn't talking about
circumventing policy. I was talking about being able to actually
_comply_ with it if I wanted to. Firewall like behavior is the
cheap and easy answer for why one might want SIP traffic to be
forced to go through a proxy - there are others (though I can't
at the moment come up with a truly compelling application for
any of them with respect to a chat session). What you are suggesting
is that a chat session be _only_ point to point, ala the use of RTP,
and that in no circumstance would it involve a SIP proxy. I'm not
comfortable making that strong a statement yet.

> 
> > How much of the call-leg identifier used by the chat session
> > itself do you signal with the INVITE? 
> 
> Good question. My inclination is to use exactly the same correlation
> information so that matching up of different messaging "sessions"
> is trivial. Can anyone think why this might be a bad idea?

By same correlation information, you mean same to, from, and call-id,
counting on the INVITE arriving on a different transport than the 
MESSAGEs (at least on different ports) so you don't get into CSeq
mismatch errors? At its best, this will make for great debugging pain.
What about the other end of the spectrum, where you pass the a whole
new call-leg tuple as part of the SDP, or at least a new Call-ID?

RjS

---

From: [email-masked]
Date: Wed, 2 May 2001 14:22:47 -0500

...
> any of them with respect to a chat session). 

Pie-in-the-sky answer: babelfish.

> What you are suggesting

Ah. I see what you're getting at. If you want to do that, it's quite
acheivable without changing my original proposal: The IP address I
publish in my SDP is the public address of my local outbound proxy
for reception of SIP messages. When I send messages to the address
in your SDP, I indicate that address in the request URI, but send it
to my local outbound proxy. Yes, it takes some client configuration --
but so does any use of a local outbound proxy.

/a