Subject: SIP 3rd-party call creation?

From: [email-masked]
Date: Mon, 20 Dec 1999 16:46:48 -0700

Has any consideration been given to uninvolved third parties originating
sessions between two SIP endpoints?

If I might provide a clarifying example without endorsing the described
implementation - given two users A and B, each of whom has a SIP phone, and
an automated entity C (the third party): C somehow decides that a session
should be initiated between A and B, and thus sends an INVITE to A which,
due to special properties and/or headers, does not result in a session
between A and C, but rather prompts A to send a new INVITE to B after some
sort of approval on A's part. Subsequently C might or might not maintain a
relationship with A throughout the session establishment, and so forth.

I haven't been able to find any existing work that addresses this sort of
situation; has something been written on this that I've missed? The SIP Call
Control Services document covers some nearby territory (the Requested-By and
Also headers could be relevant), but I don't think, from my reading of the
document, that it endorses third-party call setup unless the third party is
a participant in the session.

If this hasn't been explored to date, what is the prevailing opinion on
third-party session initiation? Is it something to which SIP can and should
be applied? Are the accounting and security issues too damaging?

Jon Peterson
Level(3) Communications

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 21 Dec 1999 00:13:32 -0500

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.

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.

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.

-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: Laurent-Walter Goix <[email-masked]>
Date: Wed, 22 Dec 1999 13:38:05 +0100

Hi

I'm currently working on a project which ables to initiate voice communications on
computer using a SIP proxy and communicate then through a PSTN network with
classical phone terminals (using a Dialogic board interface). I currently have
doubts on how ending the SIP session in case of a phone hang-up. When the Dialogic
board detect the hang-up, could the SIP proxy generate a BYE (or other...) message
to close the session (on first INVITE, the session is set to the maximum time) ?
Similar situation appears using asymetrical VoIP/PSTN scenario on VoIP endpoint's
crash to end the SIP session.

Generally, as a third-party could initiate a session, could it end it also, or at
least generate an ending procedure between the two SIP endpoints (on computer) ?

Laurent-Walter Goix

CSELT : [email-masked]
Politecnico di Torino : [email-masked]
INSA de Lyon : [email-masked]

---

From: Jonathan Rosenberg <[email-masked]>
Date: Wed, 22 Dec 1999 09:07:47 -0500

> crash to end the SIP session.

I assume we are talking about the following scenario:

PC  ------------- PROXY -------------- GATEWAY

Where the PC initiates a call by sending an INVITE to the proxy, which
forwards it to the gateway. To answer, the gateway sends a 200 OK back
to the proxy, which forwards it to the PC. The PC then sends an ACK.
Now, if the gateway discovers that the user on the PSTN side has hung
up, it sends a BYE, and sends it to the PC, possibly through the proxy,
if the proxy inserted Record Route in the INVITE. This terminates the
session with the PC.

Should the PC crash, this can be detected at the gateway either using
absence of RTCP (presuming the PC is using RTCP), or through the session
timer extension:

http://www.ietf.org/internet-drafts/draft-ietf-sip-session-timer-00.txt

> least generate an ending procedure between the two SIP endpoints (on computer) ?

As we are discussing on another thread, the SIP call control mechanisms
right now don't quite support third party call initiation. In the
scenario you describe, though, there is no need for third party call
initiation or termination.

-Jonathan R.