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

From: Robert Sparks <[email-masked]>
Date: Wed, 2 May 2001 11:39:36 -0400

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

Sean Olsen replied:
>This does not compute. If you are treating the MESSAGEs as 
>"media" for the INVITE session, then the routing of the 
>MESSAGE should be independent from the routing for the INVITE and 
>ideally should be directly end-to-end. If you want something different, 
>then you need a different mechanism than INVITE. (You are speaking 
>about the option of using SDP to describe a application/sip "session", 
>right?) 

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.
>
>What you seem to be proposing really sets the idea of sessions as
>we've previously known them on its head. On the other hand, if we
>use the body to *describe* the session, it is extremely in line
>with everything INVITE has meant so far.

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? 

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

How much of the call-leg identifier used by the chat session
itself do you signal with the INVITE? 

RjS

---

From: [email-masked]
Date: Wed, 2 May 2001 11:02:56 -0500

> From: Robert Sparks [mailto:[email-masked]]
> 
... 
> >using UDP or TCP as the transport, and message/sip as the media type.
...
> but are we still ok if the chat session needs to take place over

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.

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

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

/a