- Can I install kronas/smpp-client-bundle in a Laravel application?
- Not as a Laravel package. It is a Symfony2 bundle whose real value is Symfony dependency-injection wiring: AppKernel registration, a configuration tree, and a container-managed client service, none of which Laravel understands. Composer resolution will typically fail on modern Laravel because of its PHP 5.4-5.6 and Symfony 2.x constraints. The only reusable part is the vendored SM\SMPP / SM\SMPPClient code, which is framework-agnostic and can be wrapped in your own Laravel service provider.
- What PHP and Laravel versions does this package support?
- It targets PHP 5.4 through 5.6 and Symfony 2.x, both of which are end-of-life. Modern Laravel 8+ requires PHP 7.3 or newer, and Laravel 10 requires PHP 8.1+, so there is no supported install path. If forced onto a newer runtime, the code is likely to hit removed or deprecated language constructs and conflict with contemporary dependency constraints.
- How do I send an SMS over SMPP from Laravel without using this bundle?
- Define your own MessageSender interface in the application, then write a single SmppMessageSender adapter that uses the vendored SM\SMPPClient classes. Bind that adapter as a singleton or connection manager in a service provider, and drive it from a queue consumer or dedicated daemon that owns the long-lived session. Keep the transport swappable so a commercial HTTP SMS API can substitute later without touching call sites.
- Does this package handle delivery receipts and long or multipart messages?
- Yes, the bundle advertises long-message support, character encoding, delivery receipts, and asynchronous response handling. In practice, DLR correlation, UDH multipart assembly, and GSM-7 versus UCS-2 data_coding mapping are work you must own. The package has no observability, so silent failures and unmatched receipts become bespoke debugging unless you add logging and correlation IDs yourself.
- Is kronas/smpp-client-bundle maintained and safe for production?
- Treat it as high risk. It has roughly four stars, zero dependents, no issue activity, and is a fork of a fork of onlinecity/php-smpp, with a bus factor near one. The PHP 5 runtime it targets is unsupported and has known vulnerabilities with no security response. At most, vendor and audit the SM\* classes behind an interface rather than declaring the bundle as a dependency.
- Which SMPP connection settings can I configure with this bundle?
- The Symfony configuration tree covers host, port, system credentials, and bind mode for the SMPP connection. In Laravel that configuration tree does not exist, so you would put the same values in config/services.php or a dedicated config/smpp.php file. Pass them into the client constructor, ideally with environment variables so credentials stay out of source control.
- How do I test an SMPP integration in a Laravel application?
- Use SMPPSim to exercise real protocol behavior such as bind, submit_sm, enquire_link, and deliver_sm. In unit tests, fake your own MessageSender interface so no socket is opened. Keep simulator-based tests separate from the default suite and avoid hitting a production SMSC or aggregator from CI.
- Should I use direct SMPP bind or an HTTP SMS API like Twilio or Vonage in Laravel?
- It depends on volume, throughput, and delivery-receipt latency requirements rather than on this package. At low volume, a maintained HTTP API is simpler and removes the ownership burden of sockets, reconnect, and keepalive. Direct bind only clears the unit-economics case at scale, so design a swappable transport interface first and let the numbers decide.
- What are maintained alternatives to this bundle for SMPP in PHP?
- The upstream onlinecity/php-smpp library and its active forks are the closest library-level options. Async SMPP clients built on ReactPHP or Swoole fit long-lived sessions better than a synchronous request/response design, and managed SMPP services or aggregators avoid the code entirely. Many Laravel teams instead pair an HTTP SMS API with a custom notification channel.
- How should I structure a Laravel service provider for an SMPP client?
- Bind a MessageSender interface to one SmppMessageSender implementation as a singleton or connection manager in a service provider. Let a queue worker or supervised daemon own the long-lived session, since SMPP is stateful and does not fit PHP-FPM request handling. Add reconnect with backoff, keepalive via enquire_link, DLR correlation IDs, and structured logging so failures are diagnosable.