Real Time Communications
Users configure their devices (IP phones, AV conferencing tools, Instant Messaging tools) to connect to a selected SIP Server when they go on-line. The Server registers the users by remembering their "SIP identifier" and the network (IP) addresses they use.
Each user has a unique "SIP identifier", also called AOR (Address of Record).
Each user may have several registrations active if that user has several communication devices in the on-line mode (an office IP Phone, a desktop computer, an instant messaging program on a laptop, etc.).
Registrations allow SIP users to communicate with each other without the knowledge of the network addresses being used, using just the "SIP identifiers" (AORs).
AORs have the same form as E-mail addresses: username@domainName. The CommuniGate Pro user AOR is the full name of the user Account, so the user SIP AOR name is exactly the same as the user E-mail address.
CommuniGate Pro uses the Router component for all Real-Time Communication operations, so Aliases, Forwarders, and other Routing methods work for Real-Time Communications, too.
The sending entity composes a Request object and sends it to the CommuniGate Pro Signal module. The Signal module processes the Request, optionally sends Requests to other entities, and returns a Response object to the sending entity.
Many CommuniGate Pro modules and components can use Signals:
The following diagram illustrates the Signal flow inside the CommuniGate Pro Server:
The Rules control how the Request is processed: they can direct it to a different destination, or they can reject the Request.
Only the Dialog-initiating Requests are processed with the Automated Rules.
When a 2xx response is received while processing any AOR, AOR processing stops. If the Request was an INVITE request, all outstanding Requests relayed to other AORs are cancelled.
When all AORs have been processed, the module returns the "best" processing result to the Request source.
When an AOR to be processed is Routed to a non-local address, that address is placed into the Contact set.
When an AOR to be processed is Routed to a local Group, all Group members are added to the AOR set.
When an AOR to be processed is Routed to a local Account, all Account active Registrations (registered addresses of the Account user devices) are added to the Contact set.
If an AOR already exists in the AOR set, it is not added to the AOR set.
If an address already exists in the Contact set, it is not added to the Contact set.
The Signal module checks each address it adds to the Contact set.
If the new Contact address is a Local Node address, the Request is passed to that Node for processing.
If the new Contact address is an external address, the Request is passed to the SIP Module for relaying.
When a local or an external entity returns a redirect-type Response, the module checks the initial AOR (the Request URI).
To specify these settings, open the Account settings page using the WebAdmin Interface, and follow the RealTime link.
An Account user can also modify these settings using the WebUser Interface. See the PBX section for more details.
This feature allows users to dial a *nnnn number to request a service from the Server. The Request is routed to the user's own Account, where it starts the Self-Call application. The application provides the requested service using the Request To: address to learn the dialed "service option" number.
When requests are sent remotely (via SIP), authentication is performed with the SIP module server component.
The SIP module implements the BASIC, DIGEST, and NTLM authentication methods.
Registration Requests require user authentication.
One Account credentials can be used to modify registrations for a different Account, if the authenticated Account has the CanImpersonate access right for the target Account Domain.
To configure the Registrar Service options, open the SIP page in the WebAdmin Settings realm.
The Signal module maintains "tuple" states for each Account, for each Event Package it supports. The module allows one or several entities to update the "tuples", and it aggregates them into one Account "state information" for the Package. When the aggregated "state information" changes, the module sends NOTIFY requests with the updated state to all subscribed entities.
The Signal module allows external entities to modify "tuples" using PUBLISH requests.
The Signal module allows external entities to modify "tuples" for certain Packages using non-standard SERVICE requests.
The Signal Module provides special processing for the REGISTER requests. If an external
entity (a SIP device) indicates support for the SUBSCRIBE method, the module establishes
a presence subscription dialog with that entity.
The module then processes all NOTIFY requests sent by that entity to maintain its Presence "tuple" or "segment".
A Presence segment value is a string from a fixed set, listed here starting from the lowest priority value to the highest priority one:
The event aggregated value is a segment value with the highest priority, or offline if no segment exists.
When a NOTIFY request is composed, the aggregated value is converted into a presence document in one of the supported formats.
The Server itself maintains the "INBOX" tuple/segment for this Event package. The segment value is set to an array:
The event aggregated value is an array containing the by-element sum of all segment array values.
When a NOTIFY request using the simple-message-summary Information format
is composed, the first aggregated array element value is used as the number of new voice messages,
and the difference between the second and the first elements is used as the number of old voice messages.
If the first array element value is not zero, the Messages-Waiting element is set to yes, otherwise it is reset to no.
A Node is an internal CommuniGate Pro Server object that can receive Signal Requests and produce Responses for those Requests. A Node can also send Requests and process Responses.
Various CommuniGate Pro components and modules use Nodes to implement Signalling functions:
You can use the WebAdmin Interface to configure the Nodes component. Open the RealTime page in the Settings section, and follow the Nodes link:
CDRs can be generated and stored in CDR Log files. CDR Log files are text files, with each record stored as a separate line. Each line has the following format:
When the External CDR Processor Helper application is enabled, the Signal Module generates CDRs and sends them to that application.
CDR data text has the following format: