auviagatewayRequest a demo

Customer support

Practical help, before you report.

Short guides based on the documented platform, for the technical teams of operators and aggregators using Auvia Gateway.

Guides

12 guides found
01SMPP connection

Preparing your first SMPP connection

What to check before attempting a bind.

Steps

  1. Confirm you have the SMPP credentials, host and port supplied by your Auvia operator.
  2. Check that your source IP is in the allow-list tied to the credential.
  3. Choose the bind type: TX to send, RX to receive, TRX for both.
  4. Towards customers Auvia supports SMPP 3.4 and SMPP over TLS.
Supported protocols
02SMPP connection

Using SMPP over TLS

Encrypted connection to the platform.

Steps

  1. Use the TLS port given by your operator, not the plain one.
  2. Enable TLS in your client or SMSC before starting the bind.
  3. If the handshake fails, check system date and time and the certificate chain.
  4. Keep the IP allow-list even with TLS: the two controls add up.
Security in the FAQ
03SMPP connection

The bind is rejected or drops

An orderly path to isolate the cause.

Steps

  1. Read the bind_resp status: it tells whether the issue is credentials, bind or system.
  2. Check system_id and password for stray spaces and the requested bind type.
  3. Check the IP: repeated failed binds trigger an automatic IP block.
  4. Keep alive with enquire_link and reconnect with growing back-off.
Open the SMPP client
04SMPP connection

Testing a bind with the site SMPP client

Useful to reproduce an error with PDU logs.

Steps

  1. Use the client only against an SMSC whose credentials you are authorised to use.
  2. Pick TX, RX or TRX and watch the PDUs exchanged in the log.
  3. A real submission creates traffic and may cost money: never send to unauthorised numbers.
  4. Before sharing a log, remove passwords and recipient numbers.
SMPP client
05Routing and receipts

Understanding why a message took a route

The rule engine decides by cost, weight and quality.

Steps

  1. The rule engine picks the SMPP or SS7 supplier by cost, weight and quality.
  2. The message detail shows the pipeline with timings and linked PDUs.
  3. Operators can simulate the decision with the Routing Analyser without sending anything.
  4. The coverage check tests up to 500 destinations at a time.
Routing features
06Routing and receipts

Reading delivery receipts

Why the final status can arrive after acceptance.

Steps

  1. Acceptance confirms hand-over; the receipt closes the cycle with the final outcome.
  2. To match, use the message ID returned in submit_sm_resp.
  3. For a long message, each part is tracked individually.
  4. Repeated receipts or retransmitted parts do not cause a second charge.
Message detail
07Routing and receipts

Failed messages: what to collect

Data that makes a report verifiable.

Steps

  1. Note the message ID, time with timezone and the route or supplier involved.
  2. Copy the error code or PDU status unchanged.
  3. Tell a submission rejection from a failure reported in the receipt.
  4. Operators can configure reroute by error code.
Feature catalogue
08Reporting and billing

Usage, CDRs and traffic reports

Where to find numbers to reconcile traffic.

Steps

  1. The REST API exposes usage: messages, delivered, failed, parts and amounts per period.
  2. The CDR Export API exports call detail records, one per message.
  3. The Traffic Report API provides reports for any period.
  4. Always compare counts by parts, not only by messages.
Data and finance APIs
09Reporting and billing

Balance, credit limit and invoices

How to read an account’s financial picture.

Steps

  1. Balance, credit limit, available amount and currency are available via REST API.
  2. Invoices show number, dates, total, paid amount and status.
  3. The price is reserved at acceptance and each charge is recorded only once.
  4. Both prepaid and postpaid billing are supported.
Billing features
10Reporting and billing

Disputing a count difference

How to prepare a useful comparison.

Steps

  1. State the period with timezone: a different day boundary creates apparent gaps.
  2. Export the CDRs and spot the message IDs that do not match.
  3. Check whether the gap comes from multiple parts of long messages.
  4. Attach sanitised data only, without recipient numbers.
Message log
11Deployment

Cloud, on-premise and white-label

The documented deployment options.

Steps

  1. Auvia can be installed in the cloud or on-premise for large operators.
  2. On-premise uses the customer’s servers, domain and database.
  3. On-premise delivery is an image containing only the compiled application.
  4. White-label shows your own name and logo on panel and customer portal.
Deployment
12Deployment

Updates and cluster operation

What the documented architecture ensures.

Steps

  1. Database migrations are versioned with every release.
  2. Multiple processes share session state and coordinate scheduled jobs.
  3. A message is confirmed only after durable storage.
  4. Figures in screenshots are sample data, not service levels.
Console screens

How to report a problem

Existing customers

Use the channel and reference stated in your contract. Prepare these items to speed up the check:

  • Message ID of the affected message
  • Date and time with timezone
  • Sanitised PDU or error code
  • Affected route or supplier

Never share passwords, tokens or API keys, nor recipient numbers or personal data.

New prospective customers

Evaluating Auvia Gateway? Request a demo from the sales team.

Request a demo

Real traffic warning

The SMPP client sends real traffic that may cost money: use it only with an SMSC you are authorised for.

This page is public help: there is no login, ticketing or chat.

Related resources

The feature catalogue and the documented integrations answer in detail.

Feature catalogueIntegrationsScreensFAQ for evaluatorsSMPP client