|
|
|
YXA architectureYXA is both an Erlang SIP stack, and a collection of SIP applications. It should be possible to create a UAS/UAC/B2BUA with this code as well, but that has not been our primary interest as of yet.
StackRFC3261 specifies a clearly layered model to handle SIP transactions. The first attempt of transaction support in YXA did not follow this model, but it became apparent that it was a bad idea to not follow the RFC-model. Hence, YXA is now transaction stateful with module names and functions named very intuitively.
 The transport layer receives requests and responses from the network and pass them on to the transaction layer. It also receives requests to send requests and responses to the network. These requests come from the transaction layer, except in special cases where they might come directly from the transaction user (or application). These special cases are 2xx responses to INVITE, and ACKs of these 2xx responses to INVITE.
The most complicated part of a SIP-stack (besides parsing SIP messages)
is the transaction layer.
It filters out resends received from the transport layer, and takes care
of delivering requests and responses reliably even over unreliable transports
(like UDP). This requires a rather complicated state machine, lots of timers and
other things.
Request processing detailsClick here for a sequential diagram of how the YXA SIP-stack receives an INVITE (note: this diagram is a bit outdated since Poseidon was unusable for modifying an existing diagram, and I haven't had time to re-do the diagram in another editor).A number of assumptions are made about the diagram :
As you can see by the yellow note in the diagram, the application has a central role but is a really small part of the process of proxying an INVITE to a users registered location. The annoying mythological image in the background will go away once I re-do the drawing in an sequential diagram editor for which I actually have a license.
Between transport and transaction layerBefore a request or response is passed to the transaction layer, a number of checks are performed to ensure some basic level of sanity (and thereby avoiding excessive error checking later on).
Response checks:
ApplicationAll current YXA applications (incomingproxy, outgoingproxy, pstnproxy and appserver) are really just function librarys. The idea is that you should only have to write a small application, and the YXA stack should handle everything at the transport and transaction layer for you.Your application must export the following three functions :
%% Standard YXA SIP-application exports
-export([init/0,
request/3,
response/3]).
Your application should have an application specification file (example : your-application.app) that specifies {mod, {sipserver, [your-application]}}
This makes erlang run the sipserver:start/1 function with your-application as
argument. Sipserver:start() will start the basic YXA processes seen here in the
OTP supervisor tree.If you are thinking 'what is OTP?' then follow this link to the Erlang OTP design principles for more information the Open Telecom Platform.
YXA startup stable state
In this figure, squares represent OTP supervisors and circles OTP worker processes. transaction_layer and tcp_dispatcher has double edges because they track exit signals from their linked processes (both of them maintain a list of their children, and need to remove data from these lists when the child processes die/exit. directory is the LDAP client. If you haven't configured an LDAP server then this process will just sit there. logger is the log file writing process. As you (hopefully) can see, there might be multiple tcp_listener processes. Each one does accept() on a different socket. TCP sockets can be of different protocols (SIP socket protocols) :
$Id: architecture.html,v 1.9 2007/12/12 07:40:59 ft Exp $ |
|
|
