| Overview |  |
Introduced in: 25 Oct 2004 by Fredrik Thulin <ft@it.su.se>
Behaviours: gen_server.
Authors: Fredrik Thulin (ft@it.su.se).
Appserver glue between sipproxy and server transaction.
During a fork of a request, we typically have the following components working together :
-------
| UAS |
---+---
|
------------------
| appserver glue |
------------------
|
------------------
| sipproxy |
------------------
| | |
----- ----- -----
|UAC| |UAC| |UAC| ...
----- ----- -----
In this module, the UAS is called the callhandler and
the sipproxy is called forkpid.
This process does the following :
1) Makes sure we deliver one, and only one, final response to the UAS (with one exception, see below)
2) Statelessly forwards any 'late' 200 OK responses to INVITE that the sipproxy delivers to us. This is necessary because the UAS terminates right after it sends the first 200 OK response (if the request was an INVITE).
3) Tells sipproxy to CANCEL all pending transactions if the UAS is cancelled (the transaction layer receives a CANCEL that matches the UAS transaction).
for CPL processing, things work a bit differently. When we process a CPL script, we don't pass final responses to the UAS but rather to the CPL engine so that it can decide what to do.
Signals handled :
From UAS :
{servertransaction_cancelled, FromPid, ExtraHeaders}
the UAS has been cancelled.
{servertransaction_terminating, FromPid}
the UAS is terminating right now.
From sipproxy :
{sipproxy_response, FromPid, Branch, Response}
a response has been received from one of the
client transactions, that the sipproxy decided
should be forwarded upstreams.
{sipproxy_all_terminated, FromPid, FinalResponse}
All the call actions provided to the sipproxy have
completed.
{sipproxy_no_more_actions, FromPid}
The sipproxy has cancelled all pending client
transactions, and is now just staying alive to
forward any 200 OK responses.
{sipproxy_terminating, FromPid} state() = #state{}
no description
| start_link/3 | Start an appserver_glue gen_server. |
start_link(Request, Actions, Surplus) -> term()
Start an appserver_glue gen_server. One is started for each forked request - acting as glue between a sipproxy process and a server transaction.
Generated by EDoc, Oct 17 2007, 16:48:23.