Subject: RE: SIP 3rd-party call creation

From: [email-masked]
Date: Tue, 21 Dec 1999 17:31:49 -0700

[email-masked] noted:
> This has come up a few times.
> 
> Although the current instantiation of the call control spec doesn't
> cover this, it was something that we had considered supporting. The way
> one could envision doing it is that C sends an OPTIONS to A, with an
> Also header in the OPTIONS indicating B. This causes A, presuming its
> acceptable, to send an INVITE to B. Since OPTIONS is effectively a no-op
> as far as call state is concerned, the result is that a call is
> established between A and B but not between A and C. As with the Also
> mechanism in general, the UA should generally authenticate the sender of
> the request and ask the user whether they'd like to proceed. 
> 
> This isn't in there now because the focus isn't really on third party
> control as much. Besides, there is a long slippery slope for third party
> control, and the Also mechanism gets you so far, but its not really an
> ideal control protocol.
> 

I know what you mean about a slippery slope. I suppose I am thinking about
third-party session initiation (3PSI?) as a special case that can be
separated from 3PCC, insofar as 3PCC entails device management, event
supervision and so forth. But certainly even the technique alluded to above
(using the Also header) begets questions about C's continuing relationship
with A and B - if C is essentially cc'd on methods passing between B and A,
and if C were then to introduce variations into the signaling, we're back at
3PCC. Next thing you know C will be collecting DTMF digits sent via INFOs
between B and A... ugh... 

But perhaps 3PSI can be segregated from 3PCC - session initiation -is-
distinct from call control, third party or first party. I could equally well
imagine C in the above scenario -not- being involved in subsequent
signaling. I'm not sure how snugly 3PSI could be integrated into the
existing SIP paradigm, but I do think the issue is worth exploring to the
extent that it should be deemed engineerable, without damaging SIP, or no. 

> 
> There have been proposals for completely separate, megaco-ish control
> protocols where the signaling function still lives in the controlled
> device. For example:
> 
> http://search.ietf.org/internet-drafts/draft-kanai-spcp-00.txt
> 
> I have heard there may be another protocol proposal on a similar topic
> coming shortly.

This goes back to the question of focus. Is it the consensus of the group
that some other protocol or system should be responsible for 3PSI, or should
it be done with SIP?

IMHO, the core issue is whether or not 3PSI would violate the end-to-end
model. Consider by way of analogy that the PSTN has no end-to-end model to
violate - operators control switches that control handsets, and they can
arbitrarily construct calls between two users like connecting the dots on a
switchboard. With SIP, however, you can't just inject a call into the
'system', constructing two call legs which will join somewhere in the middle
- there isn't really any such middle, or 'system', between IP endpoints.

Is it really a -session- (something that an INVITE should be sent for) that
C is initiating when it instructs B to send an INVITE to A? Or is B acting
as a provisional proxy? What sort of session description, if any, would be
associated with C's INVITE to B? Maybe answers to these sorts of questions
would provide hints as to the compatibility of SIP and 3PSI.

> 
> I'm guessing you are interested in some kind of operator services
> features? I'd very much be interested to hear if you had some other
> application in mind.
> 

That depends on how broad your understanding of the term 'operator services'
is.

For example, I am considering cases in which A's user has informed C
out-of-band (that is, without using SIP) of the desired session. C has the
intelligence to know the session requires that B connect to A. This might
take a while to explain, but...

Consider, to make the example concrete, a multiplayer game which has a pair
of client-side applications. One is the actual game 'client', which
comprises a UA and some game-media processing system; the other is a
server-discovery application that determines the appropriate server for this
client - given network conditions, desired transactions/rules, or what have
you. 

There is actually an application similar to this for first-person shooters
(Quake, Unreal, etc) called 'GameSpy', which downloads massive lists of
servers and calculates the client-host's ping time to each and then launches
a chosen session. 

In our example, the server-discovery application is C, the client is A, and
B is a server (some sort of conferencing system for clients); we'll say that
Joe is the user who controls both C and A. Now, Joe interacts with C (by
launching the application and clicking the 'find best server' button) in
order to discover the proper server. C performs its analysis and learns that
B is the proper server for A. 

Now, if it were the GameSpy application, C would then launch A, notifying A
as it is invoked of the proper server B. But we'll place an arbitrary
restriction on this game architecture and say that C cannot launch A
because, for example:

- C is actually a network-remote application that Joe is accessing (so
rather than launching C, Joe would log into it, or whatnot)
- B is a limited and contested resource that doesn't want to be flooded by
hopeful campers, so it collects INVITEs from Cs, queues them, and deals with
them as resources become available (rather than constantly receiving INVITEs
from As)
- B's network has a policy that prevents it from receiving unsolicited port
5060 traffic from A, but it can send arbitrarily to A (and presumably B is
reachable by C)
- Billing strictures associated with the session require that B initiate

So instead, C asks B to begin a session with A - perhaps with a SIP INVITE,
OPTIONS and Also headers, or however we might want 3PSI to work. At this
point, C's responsibilities could very well end - if B and A are unable to
connect, Joe will have to go through C again.

In this case, Joe is interacting with C out-of-band, looking for a session
to associate with A (this assumes that Joe has given C enough information
that C can tell B how to reach A), C discovers B and requests that B start a
session with A. Whew.

I suppose the question is: does the example I describe violate the SIP
paradigm, or otherwise lead to undesirable consequences?

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 24 Dec 1999 15:26:43 -0500

> extent that it should be deemed engineerable, without damaging SIP, or no.

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.

> - there isn't really any such middle, or 'system', between IP endpoints.

True, you can't just create a call. But, I think it is well within the
scope of the model for one host to ask another to make a call. Of
course, the host which has been asked to make the call should know that
it has been asked, have the right to refuse, and be able to verify the
identity of the entity that has requested the call to be made. 

> as a provisional proxy? 

No, it is not an INVITE, and B is not a proxy. Its a UA. The mechanism
from C to B is just a request protocol that asks it to take some action.

What sort of session description, if any, would be
> would provide hints as to the compatibility of SIP and 3PSI.

None. There is no session between B and C in this case. B would decide
on the session that will take place between it and A.

> paradigm, or otherwise lead to undesirable consequences?

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.

It seems to me, IMHO, a very different service where some user C asks
some other user B to make a call to another user A. The trust
relationships are quite different (C and B are not run by the same
administrative authority), and the nature of control is much different
(its not reasonable to expect C to ask B to hang up the call, and for B
to do so if it doesn't want to). This kind of "control", which is more
like a "request" is within the purview of SIP, I think.

-Jonathan R.