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

From: Ben Campbell <[email-masked]>
Date: Tue, 1 May 2001 17:06:27 -0400

> From: Robert Sparks [mailto:[email-masked]]
> Sent: Tuesday, May 01, 2001 12:55 PM
> To: [email-masked]
> Subject: RE: [Simple] IM: A session or not
> 
> 
> Folks - we need to move this along so we can free our crucible
> for discussion on publishing and authentication.
> 
> I propose that we move ahead and develop the text around
> 
> *) session free "pages", very much like what we've already defined
> *) "chat" sessions consisting of MESSAGE requests bounded by
>    an INVITE/BYE
> 
> To address the discussions date:
> 
> 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. 
> 
> Would sip services (proxy/redirect servers) need to be able to
> distinguish INVITEs for MESSAGE sessions from INVITES from other
> streaming media.
> 
>   Proposal :
>    No - 
>    at least not any more than the services already need to be
>    able to differentiate between different types of media streams.
> 

On reflection, (and feel free to hit me for not bringing this up in our
discussion earlier today), I think I have to object to the
not-routing-by-media-type provision. Right now, I have both a PC and a SIP
phone on my desk. They have separate IP addresses. My SIP phone does not
support messaging (yet) and my PC makes a lousy phone because of windows
media considerations. Therefore I would prefer to route message sessions and
voice sessions differently.

I would still be able to do this by publishing a distinct URI for message
sessions and for voice sessions, but this is not very satisfying. I would
prefer to just tell everyone to use sip:[email-masked] for either
media. This is not an IM specific problem, as I am also likely to wish video
sessions to sip:[email-masked] to go to a different device than
voice sessions.

On the otherhand perhaps, according to CPIM discussions, my published URL
for messaging should instead be the abstract im:[email-masked],
and do an SRV lookup or some other DNS magic to convert that to an concrete
sip URL. I suppose one could set things up where that actually resolved to
sip:[email-masked], which could be routed differently to
sip:[email-masked]. This is less annoying than the first
situation, as I will typically tell my friends I am
[email-masked] and let them figure out what scheme to use based
on the application (mailto:, sip:, pres:, im:, etc.)

---

From: James Undery <[email-masked]>
Date: Wed, 02 May 2001 10:38:17 +0100

> voice sessions differently.

I will agree with Ben here, although I'd note I expect dumb phones to reject the
INVITE with a chat session in it, and the messaging UA to reject calls with
media (if I tell it to). An additional consideration is using callee prefs,
"page" messages and invites to "chat" sessions will be routed differently.

> on the application (mailto:, sip:, pres:, im:, etc.)

I don't think CPIM requires that the im: tag is used for anything other than
interworking. Using im: URLs will cause problems for proxies that don't know how
to route them, i.e. just like sip:.

On reflection I see this as a problem with caller preferences as it's a more
general problem. By this I mean tying a contact url to a method is a very course
filter, another example is where an end point handles SUBSCRIBE for "Event:
foo", I'd only want SUBSCRIBEs for "Event: foo" to go there and perhaps have
other SUBSCRIBEs to be handled at the proxy. Anyway I am typing aloud.

James Undery

---

From: [email-masked]
Date: Wed, 2 May 2001 10:49:08 -0500

> to route them, i.e. just like sip:.

I strongly agree.

/a

---

From: Vasilis Polychronidis <[email-masked]>
Date: Thu, 03 May 2001 16:03:35 -0700

Hi Ben,
I like your proposal makes a lot of sense.

Regards,

Vasilis

Ben Campbell wrote:

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