Menu Content/Inhalt
Home arrow Usage instructions arrow SIP accounts provisioning
SIP accounts provisioning
The provisioning is performed using the SOAP/XML functions present in the
Sip port described in NGNPro WSDL.

- Add at least one domain to the SIP Proxy (like example.com)
- Add SIP accounts under that domain

To enable different rights for SIP accounts, they must be part of specific
groups.

You can add or remove a SIP account from a group by using Sip.addToGroup()
and Sip.removeFromGroup() SOAP methods. The list of groups to which a SIP
account belongs can also be set using the `groups' attribute of the
SipAccount structure in Sip.addAccount() and Sip.updateAccount() methods.
When you're using a group list for modification, all the old groups will be
deleted and the new ones will be inserted in place.

To enable PSTN calls to a SIP account, that account must be in the
'free-pstn' group.

If you want to allow only limited access to PSTN, in the margins of a
predefined quota, the SIP account must have a positive value set for the
'quota' attribute in the SipAccount structure. In this case, the CDRTool
quota system blocks the user if the traffic exceedes the predefined quota by
adding the user to the 'quota' group, but the SIP account can still place
free calls. Beware that besides the per user quota, there is a platform wide
setting for maximum traffic of any user in the system even if it does not
have a quota defined. This global setting can be modified in CDRTool
configuration file globa.inc

A SIP account can be administratively blocked (cannot make any calls, cannot
register), if it's part of the 'blocked' group.

If you want a SIP account to make calls marked as anonymous, that SIP
account must be placed in the 'anonymous' group.

To mark a SIP account as prepaid, the `prepaid' attribute of the SipAccount
structure must be set to True. You can manage the prepaid settings for that
account using addBalance(), addBalanceFromVoucher(), getPrepaidStatus(),
getCreditHistory() methods.

SipAccount.properties store per-account information in the form of
name-value pairs and they can then be used on the client side for its own
purposes. Properties do not influence routing decisions. Their meaning
depends on the interpretation the client side gives them, for example they
can be used from a web-based interface to store settings like the display
language or the account type.