Subject: RE: SIP 3rd-party call creation

From: [email-masked]
Date: Tue, 28 Dec 1999 16:15:25 -0700

> -----Original Message-----
> From:	Jonathan Rosenberg [SMTP:[email-masked]]
> Sent:	Friday, December 24, 1999 1:27 PM
> To:	[email-masked]
> Cc:	[email-masked]
> Subject:	Re: SIP 3rd-party call creation
> 
> If you don't require C needing to be involved in the call from the point
> of 3rd party initiation forward, then I think this is something that
> generally fits within the SIP model, as its about initiation of
> sessions, not about device control or event reporting or other things.
> Using OPTIONS with Also certainly does this, although its a bit of a
> hack.
> 
	[Peterson, Jon]  

	Are there any SIP implementations today that would support this
OPTIONS/Also technique? I know this probably isn't a priority for
implementors, but I'd be interested to hear if anyone had actually tried it.

> In this example, why doesn't C just send the INVITE, but in the SDP,
> list B as the session endpoint? 
> 
> This is yet another example of a decomposition architecture. What you
> want to do is take a network service, in this case the gaming server,
> and decompose it into a control component (what you call C) and a
> session component (B). This decomposition could be done in the megaco
> fashion, with C handling control and signaling, and with B just handing
> the gaming session, RTP, and stuff like that. What you are suggesting is
> a different decomposition, with C performing control, but signaling
> still residing in B. I'd like to understand the needs which dictate this
> kind of decomposition rather than the megaco type of decomposition,
> especially for this application.
> 
	[Peterson, Jon]  

	I was justifiably worried that my example would be difficult to
understand. I tried to paint C as a truly 'third party' application that was
neither a component of A or B. I should clarify that under certain
circumstances, it -would- be legitimate for A to signal directly to B (like,
in our hypothetical game, when A and B are running on the same LAN,
perhaps), rather than having Joe (A's user) employ C to discover B and then
have B initiate a session with A (to give a brutal summation of my previous
mail). Similarly, I could imagine a game in which client-to-client
connections as well as client-to-server connections were feasible, and here
A could connect to its adjacent peers X, Y, and Z as it pleased - but when
it needed a server, it would go to C. 

	So, if this is not a mere semantic distinction, the suggested
architecture was not one in which a UA was decomposed, but rather one in
which a redundant accessory could be used for initiation in order to resolve
some application or network specific constraints. I could imagine a few
other examples that might benefit from this architecture, such as
telephone-style functions in the same spirit as PINT (without the PSTN
part), or maybe IRC clients' DCC rewritten with SIP (if anyone remembers
that). 

	To return to my previous analogy, Quake clients (A) and servers (B)
are completely enabled and functional without GameSpy (C). GameSpy is just a
tool that allows the user of a Quake client to find servers with low
ping-times and judge the number of users they house, what sort of game is
taking place there, and so forth. The user selects the game that he would
like to join, and GameSpy starts the Quake client and executes a script
which contacts the desired server (so this is a scenerio in which C would
send the OPTIONS/Also to A). Of course, the user could also just start Quake
and enter the address manually, as he did before GameSpy was released. (It
is worth noting, though, that the newly-released Quake III client has a
GameSpy-type server selection interface built into it - so id Software has
elected to recompose these elements).

	Ultimately, I'm not terribly biased about whether C sends the
proposed OPTIONS/Also to A or B - but I do recognize that certain game
architectures or network structures could favor a particular side initiating
the connection, and I think that would be an implementation-specific detail
of C and the overall network. When C and A are on the same machine,
certainly there's no reason why A shouldn't initiate the session. In my
example, C sent the OPTIONS/Also to B because restrictions prevented A from
initiating the connection. I briefly listed a few possible restrictions
along these lines: authentication, firewall policy, billing strictures,
server-side queuing with callbacks, and so forth.

	That much said, your point about C sending the INVITE (to A, I
presume) with an SDP pointing to B is well taken. My own limited familiarity
with SDP might show through here, but I would have thought that B would be
in the best position to describe a session it is initiating (if our game ran
over RTP, for example, and hence needed a pair of unidirectional sockets,
one of which B would advertise in its SDP - or some other host-specific
session data).

	Jon Peterson
	Level(3) Communications

> -Jonathan R.
> -- 
> Jonathan D. Rosenberg                       200 Executive Drive
> Chief Scientist                             Suite 120 
> dynamicsoft                                 West Orange, NJ 07052
> [email-masked]                     FAX:   (732) 741-4778
> http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
> http://www.dynamicsoft.com