Real Time Communications

AORs Signals Signal Sources Processing Signals Forking Registrar Services and Authentication External PSTN Gateway Event Packages Presence Message Summary One of the main functions of the CommuniGate Pro Server is Real-time communication. Acting as a Signaling Center, the Server receives real-time signals from various sources (the SIP Module, internal sessions, and "call legs", internal kernel components, etc.). The Server either processes (terminates) these signals itself, or it delivers them to remote entities (via the SIP protocol), or it delivers them to internal sessions and "call legs".

AORs

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 unque "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.

Signals

A Signal is a basic real-time Task. One Real-time entity sends Signals to some other real-time entity to start, modify, or stop a communication dialog, to deliver a status update, etc.

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.

Signal Sources

Many CommuniGate Pro modules and components can use Signals. The most important one is the SIP Module. Its server-subcomponent receives Requests from external real-time entities using the SIP protocol. When the Signal Module generates a Response object, the SIP Module sends the response back to the external entity.

Processing Signals

When the Signal Module receives a Request, it calculates the target URI for it. It takes the Request URI (or the first Route URI in the Request Route set), and uses the Router component to detect the Request destination. There are several possible outcomes of this process:

• The Router returned an error code (for example, the Request URI addressed a local Account that does not exist). This error code is returned to the Signal source, and processing stops.
• The Router returned a non-local address (an address in a non-local Domain). The Request is passed to the SIP Module for relaying. The Response returned with the SIP module is passed to the Signal source.
• The Router returned an address of a local internal Real-time Node. The Request is passed to that Node for processing. The Response returned with the Node is passed to the Signal source.
• The Router returned a local Account address, and the Request can be processed with the Signal Module itself. The Request is processed, and the Response is returned to the Signal source. This case includes REGISTER-type Requests and other Requests which URIs target local Domains.
• The Router returned a local address, and the Request cannot be processed with the Signal Module itself. The the Forking process starts with the Request URI as the initial AOR set.

Forking

The Signal module maintains the AOR (Address-of-Record) and Contact sets for each Signal it processed. The module starts the Forking process by scaning the AOR set, processing each address in the set. When all AORs have been processed, the module returns the "best" processing result to Signal 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.
It the new Contact address is a local Real-time Node address, the Request is passed to that Node for processing.
If the new Contact address is an external Entity address, the Request is passed to the SIP Module for relaying it to that external Entity.

If an local or an external entity returned a "Redirect" Response, the addresses specified in the Response are added to the AOR set and the Forking process continues.

Registrar Services and Authentication

Communication devices used by CommuniGate Pro users should register themselves before they can receive Signals from other entities.

Registration (and some other SIP operations require) user authentication. All CommuniGate Pro Account passwords can be used for authenitcation.

The CommuniGate Pro Signal module implements the BASIC, DIGEST, and NTLM authentication methods.

To configure the Registrar Service options, open the SIP page in the WebAdmin Settings realm.

Authentication Advertise Digest AUTH Minimal Registration: 5 seconds7 seconds10 seconds15 seconds30 secondsminute2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour2 hours3 hours6 hours12 hoursday2 days3 days4 days5 daysweek Advertise NTLM AUTH

Advertise Digest AUTH

Select this option to inform SIP clients that the standard DIGEST authentication method is supported.

Advertise Digest NTLM

Select this option to inform SIP clients that the non-standard NTLM authentication method is supported.

Minimal Registration

Select this option to specify the minimal allowed Registration time. SIP clients trying to register themselves with a shorter expiration period will get an error message specifying the correct minimal time, so the clients can automatically extend their registration expiration periods.

An Account and its Domain must have the SIP Service enabled to be able use the Registrar Service.

External PSTN Gateway

You may want to use your CommuniGate Pro Server with an external SIP Gateway. The PSTN Gateways can be used to relay calls to the public telephony network (PSTN) and to relay PSTN calls to your Server. Their services are usually fee-based and communications with gateways require authentication.

Use the External PSTN Gateway panel to specify the gateway settings:

External PSTN Gateway Gateway Domain: Calls: Substitute From Authenticate Registration: Username: Password: Every: never10 seconds15 seconds30 seconds45 secondsminute90 seconds2 minutes3 minutes5 minutes10 minutes15 minutes30 minuteshour90 minutes2 hours3 hours6 hours12 hoursday2 days3 days Contact:

Gateway Domain

Use this setting to specify the address of the external gateway. This name is used as the domain name for the REGISTER requests.

Registration Username and Password

Use these settings to specify authentication name and password to use with the External Gateway.

Register every

Use this setting to specify how often the Signal Module should send REGISTER Requests to the External Gateway.

Contact

Use this setting to specify the address of to be registered with the External Gateway. When a PSTN call comes in, the PSTN Gateway sends it to this address.

Calls: Substitute From

When this option is selected, the From address (the caller name and address) of the INVITE requests is substituted with the Registration Name.

Calls: Authenticate

When this option is selected, an authentication header field is added to all INVITE requests send to the PSTN Gateway. This field uses the authentication "nonce" used for the last REGISTER call to the Gateway, so make sure your Register Every setting is shorter than the nonce "Time To Live" period of the PSTN Gateway.

In order to send SIP requests to the External Gateway, you need to specify Router records.

Sample 1.

All calls to 1number@main_domain should be directed to the Gateway as requests to number@sip.provider.dom
All calls to +1number@main_domain should be directed to the Gateway as requests to number@sip.provider.dom
all calls to 9number@main_domain should be directed to the Gateway as requests to 415number@sip.provider.dom
all calls to 011number@main_domain should be directed to the Gateway as requests to 011number@sip.provider.dom
all calls to +number@main_domain (where number does not start with 1) should be directed to the Gateway as requests to 011number@sip.provider.dom

Use the following Router records:

NoRelay:Live:<1*>   = *@sip.provider.dom
NoRelay:Live:<+1*>  = *@sip.provider.dom
NoRelay:Live:<9*>   = 415*@sip.provider.dom
NoRelay:Live:<011*> = 011*@sip.provider.dom
NoRelay:Live:<+*>   = 011*@sip.provider.dom

Note: you should use the NoRelay: prefix to avoid turning your Server into an open relay that would allow any external user to relay calls to the External Gateway on your behalf.

Event Packages

The Signal Module supports several Event Packages. When it receives a SUBSCRIBE Request targeting a local Account, it may process the Request itself, without forwarding it to the Account registered entities.

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.

Presence

The Signal Module implements a Presence Server. The Module supports the PIDF and XPIDF Presence Information formats.

The Signal Module provides special processing for the REGISTER requests. If the external entity (a SIP device) indicates support for the SUBSCRIBE method, the module establishes a subscription dialog with that entity. The module then processes all NOTIFY requests sent by that entity to maintain its Presence "tuple".

Message Summary

The Signal Module implements the MWI (Message Waiting Indication) Service. The Module supports the simple-message-summary Information format.