Conferencing

PortaSIP enables you to provide voice-conferencing services to your customers. Multiple customers can simultaneously use the conferencing service, and each customer has access to their own set of virtual conference rooms. In addition, the customer can manage all of their conferences (virtual conference rooms) via the account self-care interface.

A conference can be scheduled for a specific time, or a continually functioning conference (i.e. meeting room) can be created. Each conference is identified by a pair of unique access codes (one for the conference host, the other for conference guests). Although multiple conferences can be created in PortaSIP, its resources are only used when a conference is in progress (i.e. at least one participant is present).

For a customer to utilize the conferencing service, the PortaBilling administrator assigns a separate tariff for this service in the customer’s product configuration, and the owner of the meeting room is then billed for each incoming call of a conference session.

For example, if your conference rate is $0.03/min and a customer organizes a conference for two participants where he (the host) stays connected for 30 minutes and his two partners stay connected for 25 and 20 minutes, respectively, then there will be three charged transactions in total, for $0.90, $0.75 and $0.60. To prevent potential service abuse by guests, customers may create a moderated conference. A single conference can have several moderators, yet only one owner. A participant can be appointed as a moderator when added to the conference. Such moderated conferences only begin once the moderator joins in and they last until the last moderator leaves the call.

When mixing the audio from several participants during a conference, the system carries out intensive calculations and requires significant amounts of CPU power. However, since conference rooms are distributed among PortaSIP processing nodes, the CPU load is balanced. This enables your other IVR services (voicemail, auto attendant, self-care, etc.) to continue to run properly.

• The service provider wants to allow customers to access the audio conferencing service. The number to be dialed by users (e.g., 18665552637 – 1866-555-CNFR) is purchased from the DID provider.
• The administrator creates a new voice application of the “Conferencing” type on the Voice applications page in PortaBilling, and specifies the 18665552637 as the entry point for this application. If necessary, the administrator configures the parameters of the application.
• When a customer signs up for a conference service, an account for managing the service is created in PortaBilling (e.g., conf1234) and provided to the customer. The customer then logs into their account self-care interface and creates particular conferences (i.e. virtual meeting rooms).
• The customer distributes the conference access information (access phone number and access code) to the intended conference participants.
• A participant (connected to a network of some other telco) wishes to join the conference so he dials 18665552637 from his mobile phone.
• The call is routed through the cellular carrier’s telecom network or via several transit operators that provide services to the participant. Eventually the call is delivered to the DID consolidator X-Telecom, which supplies incoming DID calls to the service provider. The call is then sent to the PortaSIP cluster from X-Telecom’s gateway.
• When an incoming call arrives to the PortaSIP (1), it checks the call handling rules to determine how this call should be authorized, based on the remote IP address or by using the username and password. After gathering the required information, the processing node sends an authorization request to PortaBilling (2).
• PortaBilling detects that 18665552637 is a special IVR application access number. The authorization confirmation is sent back to the processing node (3).
• Within the processing node, the call is passed to the Media Server (4).
• The Media Server connects the incoming call and, based on the number called (18665552637), launches the "Conferencing" application.
• The application prompts the user to enter the conference access code and validates it within the internal database (5).
• If a valid conference code is provided, the ID of the account that owns this conference room (conf1234) is retrieved. An authorization request is sent to PortaBilling (6) to check that usage is permitted for this particular conference number (18665552637) and that the account has sufficient balance to cover the costs.
• If authorization is successful, the participant is permitted to join the conference.
• If the conference room is running on another processing node, the INVITE request is sent to that node (7) which continues to process the call.
• When the participant hangs up, an accounting request is sent to PortaBilling (8), so that account conf1234 (and the customer who owns it) is charged based on the price per minute associated with this access number.

Conferencing services are fully supported for the site-redundant installations. Information about a conference room and its participants is stored in the database and shared among the sites. This makes it possible for users registered on different sites to talk with each other within the same conference room.

If one of the sites is down or for some reason unavailable, the system creates a "local" conference room for new users who dial the conference access number. For example, a conference room is enabled on site A of your geo-redundant installation and for some reason (power outage, lost connectivity, etc.), this site becomes unavailable. Users registered on site B would dial the access number to enter the conference room. The PortaSIP of site B verifies that the site A conference room is unavailable and therefore creates a site B conference room that permits users to talk with each other.

When the connection between the sites is restored, calls already in progress are handled by site B until they are completed; meantime, all new calls to the conference room are routed to site A.

Thereby is the conferencing services you provide have an additional layer of high-availability and security.

Normally, PortaSIP sends pre-converted voice prompts to a user as a byte stream, so no codec licenses are involved. In the case of conference calls, the audio-stream (with each participant’s voice) is decoded in real time and then sent back to each participant as an encoded audio-stream mixed in with sound. The following codecs with an 8 kHz sampling rate are supported for conferencing services: PCMA, PCMU, G.723.1, G.729, iLBC, DIV4, G.726, GSM, LPC, Speex, Opus.

In future releases, video conferencing will also be supported.