VaxVoIP SIP Server SDK attack-detection methods

EXPORTED • METHODS • EVENTS

Attack-detection methods exported by SIP Server SDK

AttackDetectScanSIP() validates incoming SIP traffic against the configured SIP domain and reports requests that do not satisfy that rule through OnAttackDetectedScanSIP().

AttackDetectFloodSIP() monitors the incoming SIP request rate and raises OnAttackDetectedFloodSIP() when the configured request limit is exceeded.

AttackDetectBruteForceSIP() monitors authorization failures within a defined interval and raises OnAttackDetectedBruteForceSIP() after the configured failure limit is reached.

These methods are called after SDK initialization. Their exact signatures, parameter types and event arguments are documented in the SIP Server SDK Technical Manual.

DOMAIN • VALIDATION

AttackDetectScanSIP() exported method

AttackDetectScanSIP() associates accepted SIP requests with the configured domain URI. Requests that do not match the expected domain can be discarded without returning a SIP response, while OnAttackDetectedScanSIP() notifies the SIP server application.

Typical detection flow

1. Initialize the SDK and open the required SIP transports.
2. Call AttackDetectScanSIP(Domain-URI) with the domain accepted by the service.
3. Record the source address, transport and request details when OnAttackDetectedScanSIP() is raised.
4. Correlate repeated events before applying a temporary network restriction.

Domain validation should match the deployment model. A server that legitimately accepts several domains must account for each expected domain to avoid rejecting valid traffic.

RATE • MONITORING

AttackDetectFloodSIP() exported method

AttackDetectFloodSIP() configures a limit for incoming SIP requests. When traffic exceeds the configured request threshold, OnAttackDetectedFloodSIP() alerts the SIP server application so it can log, rate-limit or isolate the source.

Typical detection flow

1. Initialize the SIP Server SDK.
2. Call AttackDetectFloodSIP(ReqRecvLimit) with the permitted incoming SIP request limit.
3. Call the other required methods that enable VaxVoIP network communication.
4. Confirm that VaxVoIP initialization completes successfully.
5. Monitor for a source that sends more SIP requests than ReqRecvLimit permits.
6. Record the source IP address, port and request details when OnAttackDetectedFloodSIP() is raised.
7. After validating the event, rate-limit the source or apply a temporary IP and port block through a firewall such as Microsoft Windows Defender Firewall.

Measure normal registration, keep-alive and call traffic before setting the limit. Include expected peaks, failover events and NAT environments where many devices may share one public address. Start with monitoring, review the events and tighten the policy only after the normal traffic profile is understood.

AUTHENTICATION • PROTECTION

AttackDetectBruteForceSIP() exported method

AttackDetectBruteForceSIP() monitors failed authorization attempts within a configured interval. When failures exceed the limit, OnAttackDetectedBruteForceSIP() reports the condition to the SIP server application.

The method accepts a failure count and failure interval. These values should allow for occasional user mistakes and devices retaining an old password, while still identifying concentrated attempts against one or more accounts.

Typical detection flow

1. Call AttackDetectBruteForceSIP(FailureCount, FailureInterval) after SDK initialization.
2. Log the account, source address and event time when the detection event occurs.
3. Apply a short lockout or temporary network block when the evidence supports it.
4. Alert an administrator when attempts continue or affect several accounts.

EVENTS • RESPONSE • CONTROL

Handle the exported attack-detection events

Detection events should feed a response policy rather than automatically creating permanent firewall rules. A production policy can combine the event type, source address, account, event frequency and recent call activity before deciding what to do.

• Log first: retain timestamps, source addresses, transports, accounts and event types for investigation.
• Rate-limit when possible: temporary throttling may preserve service while reducing harmful traffic.
• Use time-limited blocks: short blocks reduce damage from false positives and shared public addresses.
• Escalate repeated behavior: extend restrictions only when the activity continues or multiple signals agree.
• Monitor the result: verify that legitimate registrations and calls remain healthy after a policy change.

Firewall automation must run with controlled permissions and validated input. Do not insert untrusted event text directly into a system command.

DEPLOYMENT • CHECKLIST

SIP server security checklist

• Expose only the SIP transports and management ports required by the deployment.
• Use strong, unique SIP account credentials and remove unused accounts.
• Restrict administrative access by network, identity and role.
• Enable scan, flood and authentication-failure monitoring with tested thresholds.
• Centralize logs and alert on repeated or correlated security events.
• Keep the operating system, firewall rules and application dependencies current.
• Test call setup, registration, failover and emergency access after security changes.

Exact method parameters and event signatures are available in the SIP Server SDK Technical Manual.

SIP • SECURITY • FAQ

Frequently Asked Questions