When receiving calls from external parties including PSTN gateways, make sure that the SIP address in the Request URI contains a valid user of your platform.

Yes, you may create multiple ENUM numbers and SIP aliases that point to the same SIP account.

MSP does not support forking to multiple different SIP accounts. The reason for this is the each of the multiple SIP accounts you want to fork has its own diversions and paralel forking that cannot be aggregated in the same machine. Such feature can be realiably realized with external PBX with call queue/ACD functionality that behaves like a b2bua, not with a SIP Proxy solution.

There are 3 kind of call filters in place. One for output and two for input.

1. The output filter is refered as call barring. If the dialed destination is in this
list it will be rejected with a 403 - "Forbidden - blocked destination" reply
and no voice prompt will be played to the caller. This call barring is only applied for
PSTN destinations. SIP destinations cannot be barred. Look at this as a way to protect
you from dialing expensive PSTN numbers. This can be managed using
setBarringPrefixes/getBarringPrefixes.

2. Reject list. This list applies to incoming calls and if a caller is in this list it
will not be allowed to call you. In such a case the call will be rejected with 488 -
"Not acceptable here" and no diversion (FUNV, RUNV) will be applied. Consider
this as an antispam filter. You don't want to talk with the people in this list, nor do
you want to get voicemail from them or send them to your mobile. This can be managed
using setRejectMembers/getRejectMembers.

3. Accept list. This list specifies how incoming calls will be permitted. You can specify
who can call you at a certain time in a certain day. If the caller is accepted by this
filter he will be allowed to call you. If not he will be directed to the FUNV diversion
if that is defined. If that is not defined RUNV will be checked if defined and if so he
will be redirected to that destination. If neither FUNV nor RUNV are defined the call
will be denied and the caller will receive back a 480 - "Temporarily
Unavailable" reply. This is a means to get calls only from the people you want to
receive calls at a specific time, but without denying the other possible callers to leave
you a message if they need to.

For incoming calls first the reject rules are checked and only if they pass the accept
rules are checked else call is rejected. After the accept rules are checked the call will
go either to the user's phone if accepted or to his unavailable diversion if not accepted.

If the unavailable diversion is not defined the call will just get a negative 480 reply.

There are 2 kinds of accept rules: persistent and temporary. The rules are applied for
groups which combine the contacts from the user's Phonebook. To use this you must first
define the groups and the associated SIP URI's (contacts) using
add/update/delete/getPhonebookEntry, and then call setAcceptRules/getAcceptRules. You can
find more details on the syntax of these functions in the WSDL:

The 'everybody' and 'nobody' groups can be used to accept (respectively reject) all
calls. The Temporary section consists in a list of groups and a duration (in minutes).
The Temporary rule is reset if either 'groups' or 'duration' parameters are set to nil.

The Persistent section contains a list of PersistentAccept rules. The 'start' and 'stop'
parameters of the PersistentAccept must be in the 'HH:MM' format. The 'days' parameter is
an 8 bit value which represents the days of the week for which the rule is set. The least
significant bit represents Monday, the most significant bit is ignored. The default
values for 'start', 'stop' and 'days' are '00:00', '23:59' and 127. If the 'temporary' or
'persistent' parameters of the AcceptRules structure are missing or set to nil, they will
not be modified.

This option though possible to build is not available in the platform for the following reason: 

 

You may use the SOAP/XML accept rules to decide when to reject calls. You can combine time of day with day of week conditions and allow selected groups of users to bypass the rules. The groups van be managed using SOAP/XML phonebook management functions.

 

To allow remote parties to transit your proxy without digest authorization you must add the source IP address of such parties in the list of trusted peers. You can do this using SOAP/XML related functions. 

A SIP account can be easily configured in multiple SIP devices. If the SIP account has access to dial the PSTN, a large volume of calls can be performed in a short time.

No. The design of a prepaid system assumes a unique balance per account that must be updated in real time when the call completes or when the balance is exceeded. These conditions cannot be met if multiple calls share the same balance.

 

 

No, this is not possible when using a SIP Proxy as a SIP routing engine as Multimedia Service Platform does.

 

The access numbers for changing call forwarding or access voicemail are configured in multiple files that must be correlated:

 

To customize the voice prompt played by the platform in various conditions replace the files located on the asterisk machine in /usr/share/asterisk/sounds/msp-*. The files must be recorded in gsm format sampled as 8000 Hz. You can use sox utility to convert wav files to gsm format.

 

 

Parallel forking is standard enabled in the SIP Registrar. You just need to configure the same SIP account on multiple SIP devices, all registered devices will ring in parallel.

On the sip proxy machine execute /etc/init.d/openser siptrace-off or /etc/init.d/openser siptrace-on