Platform general architecture

General diagram

Following diagram shows the global architecture of IvozProvider solution, with all its components:

../_images/flows.png

This is a more conceptual diagram:

../_images/conceptual.png

SIP signalling flow

The first diagram shows the SIP signalling traffic involved in the establishment, modification and termination of sessions following the SIP RFC 3261 and any related RFCs.

These are the external SIP entities involved:

  • UACs: users hardphones, softphones, SIP-capable gadget.
  • SIP carriers: carriers used to interconnect IvozProvider with external SIP networks (and, probably, with PSTN).

All the SIP traffic (in any of the supported transports: TCP, UDP, TLS, WSS) they send/receive is to/from this two internal SIP entities of IvozProvider:

In fact, users UACs only talks to Users SIP Proxy and ‘SIP carriers’ only talks to Trunks SIP Proxy.

Inside IvozProvider these two proxies talk to Application Servers running Asterisk, but no external element is allowed to talk to Application Servers directly.

RTP audio flow

Sessions initiated by SIP signalling protocol imply media streams shared by involved entities.

This media streams use RTP to send and receive the media itself, usually using UDP as a transport protocol.

External entities involved in RTP sessions can be divided in:

  • Users.
  • Carriers.

Both entities exchanges RTP with the same IvozProvider entity: media-relays.

IvozProvider implements media-relays using both RTPengine and RTPproxy.

Similar to SIP, these media-relays exchanges RTP when is needed with Application Servers, but external entities never talk directly to them.

HTTPS traffic

HTTPS is the third traffic type exchanged between IvozProvider and external world.

HTTPS traffic is used for:

  • Terminal provisioning: several hardphones ask for their configuration when they wake up and this configuration files can be served through HTTPS.

  • Web portals: IvozProvider has 4-level web portals for all the platform roles.

    Both of these traffics are handled by Web portals IvozProvider entity.

Additional elements

IvozProvider has multiple elements that are not exposed to the external world but play a crucial task.

The most remarkable profile is database profile that gathers all the information of the platform and shares it between the majority of software packaged. IvozProvider uses MySQL database engine for this task.

Another remarkable task is asychronous tasks handler: CDR must be parsed, calls must be billed, recordings must be encoded, etc.

Auxiliar elements

Aux profile runs software that, even though is not vital for calls placing, makes IvozProvider mantainer’s life much more easier.

In fact, without them, debugging problems would be much harder and the quality of given service would be damaged.

IvozProvider ships:

  • Homer SIP capture: This amazing software lets us capture all the SIP traffic for later analysis, for obtaining statistics, call quality measuring, etc. Visit SIP Capture website for more information.
  • Graylog log viewer: All logs of all IvozProvider profiles are stored and shown with Graylog and divied in brands.
  • Grafana graph dashboard: Grafana lets us graph everything. Literally.