Subject: [Simple] Possible IM Message solution??

From: a c <[email-masked]>
Date: Wed, 10 Oct 2001 11:38:13 -0700 (PDT)

>1. Routing information of the MESSAGE signaling is
pushed back to SDP.

yes. SDP would contain additional media server fields 
 ms1=x.x.x.x/1234 
 ms2=x.x.x.y/2345

>2. Based on the routing information of the MESSAGE
signaling path, one needs to find out the media
routing path over the message servers.

yes. shouldn't be a problem since each proxy would
know which media servers it controls. 

One shot IMs/Paging mode:
------------------------
When an IM session starts, the messages are relayed by
the proxy but ms keeps track of the number of messages
(or size) sent/received, if it exceeds a certain
threashold, then it informs the proxy. Proxy can then
do a re-invite(something like that) to switch the
media stream over to the ms.*** MS should already know
who the parties are in the session.

Assumptions:

- Number of media servers <= Number of proxies
- If media server in call then proxy in call (is 
  this a valid assumption?). Since you need the 
  proxy to tell the media server to release 
  resources.

>Will this create conflicts with the already
established
notions in SDP? 

experts?

>Hi, Alex:

The way I understand your proposal is as follows:

1. Routing information of the MESSAGE signaling is
pushed back to SDP.

2. Based on the routing information of the MESSAGE
signaling path, one needs
to find out the media routing path over the message
servers.

The question is: Why can we not generalize it so that
we can see the big
picture where this proposal will lead us analyzing all
implications? For
example, there can be multiple proxies and multiple
media servers. It will
not be used for point-to-point communications, but
will also be for
multipoint communications. Why can this principle not
be used for other
media as well? Will this create conflicts with the
already established
notions in SDP?

Radhika

-----Original Message-----
From: a c [mailto:[email-masked]]
Sent: Monday, October 08, 2001 4:43 PM
To: [email-masked]
Subject: [Simple] Possible IM Message solution?? 

hello Radhika,

>(I hope that you are NOT proposing routing of media
via network layer devices like routers.)

no. This is an application server which processes 
IM messages and routes them to their endpoints. 
It cannot be used for voice due to the realtime
constraints. But it can definetly be used for 
IM traffic. It can do much more than  just 
passing traffic. For example : language 
translation,  calea, etc..

The only requirement is that it talks to 
the proxy. The proxy can instruct the 
application server to implement a certain feature 
per call. 

other advantages:

- drastically cuts down on header tags (no header 
  tags. Why do we need them when signalling 
  is taking care of it). 
- If no headers in the message, then it is easier 
  to convert to other protocols (e.g. cpim). No 
  parsing of headers for each message
- congestion control (app server initiated 
  congestion control)
- capability to do end to end or thru server

Addresses Brian Rosen's 4 variables:

        Direct UA-to-UA routing - can do both
        TCP transport - / udp
        SIP Headers - not necessary
        cpim Body - no problem

alex

__________________________________________________

__________________________________________________
Do You Yahoo!?
Make a great connection at Yahoo! Personals.
http://personals.yahoo.com