SMS API ve SMPP Karşılaştırması: Hangi Bağlantı?

Bu rehber, bir SMS sağlayıcısına HTTP/REST SMS API ile, SMPP ile ya da her ikisiyle bağlanmaya karar veren mühendisler ve teknik liderler için hazırlandı. İkisinin hat üzerinde ve operasyonda gerçekte nasıl farklılaştığını açıklar; böylece her trafik türü için doğru arayüzü seçebilir ve ilk tercihinizi aşarsanız bir geçiş planlayabilirsiniz.

Webhook'lar ve idempotency dahil entegrasyon desenlerine daha geniş bir bakış için mesajlaşma API entegrasyon rehberimize bakın.

SMS API ile SMPP arasındaki fark nedir?

Bir REST SMS API her mesajı ayrı bir HTTPS isteği olarak gönderir ve bir mesaj kimliği döndürür. SMPP (Short Message Peer-to-Peer) ise uzun ömürlü, kimliği doğrulanmış tek bir oturum açık tutar ve üzerinden iki yönde PDU adı verilen ikili mesajlar alışverişi yapar. REST basitlik için, SMPP sürekli SMS hacmi için optimize edilmiştir.

REST SMS API nasıl çalışır?

Bir token ve JSON gövdesiyle bir HTTPS POST yaparsınız ve sağlayıcı bir kimlikle yanıt verir. Her istek bağımsızdır; bu yüzden bir bağlantı yönetmeden herhangi bir sunucudan, fonksiyondan veya konteynerden gönderebilirsiniz.

API'mizle tipik bir gönderim şöyle görünür:

curl -X POST https://api.broadnet.me/sms/sendSms \
  -H "Authorization: Bearer $BROADNET_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{
    "senderId": "OmniDemo",
    "destinationNumber": "971500000000",
    "message": "Your OmniDemo code is 482913",
    "messageType": "TEXT"
  }'

Yanıt, mesaj kimliğinin düz metin olarak döndüğü 200 OK'tir. Nihai durum daha sonra webhook'unuza SUBMITTED, SENT, DELIVERED, FAILED veya REJECTED olarak gelir. Alan adları ve seçenekler SMS API referansındadır.

REST'in güçlü yanları:

• Tanıdık araçlar: her dil, her HTTP istemcisi, RFC 9110'da tanımlandığı gibi standart durum kodları.
• Kolay güvenlik: her yerde TLS ve Authorization başlığında bir token.
• Bağlantısız toplu gönderim: bir oturum açmak yerine alıcı dosyasını tek istekte yükleyin.
• Birçok kanal için tek API: aynı desen WhatsApp şablonlarını veya RCS kartlarını gönderir.

REST'in sınırları: her mesaj veya her toplu iş bir HTTP gidiş dönüşüne mal olur ve herhangi bir operatör limitiyle karşılaşmadan önce saniye başına istek limitiyle karşılaşırsınız. Çoğu uygulama trafiği için bu hiç önemli olmaz.

SMPP nasıl çalışır?

SMPP, SMPP Developers Forum (sonradan SMS Forum) tarafından yayımlanan ve hâlâ en yaygın dağıtılan sürüm olan SMPP v3.4 belirtimiyle tanımlanan ikili bir protokoldür. ESME (External Short Message Entity) olarak adlandırılan sisteminiz, sağlayıcının SMSC'sine (Short Message Service Centre) bağlanır ve bind adı verilen bir oturum açar.

Bind türleri

• bind_transmitter kullanan Transmitter (TX): yalnızca mesaj gönderir.
• bind_receiver kullanan Receiver (RX): yalnızca iletim raporları ve gelen mesajları alır.
• bind_transceiver kullanan Transceiver (TRX): tek oturumda ikisi birden. Olağan tercih budur.

Oturum yaşam döngüsü

1. Sağlayıcınızın verdiği ana bilgisayara ve porta bir TLS bağlantısı açın.
2. system_id ve parolanızla bind_transceiver gönderin ve command_status 0 olan bir yanıtı bekleyin.
3. Mesajları submit_sm ile gönderin. Her submit_sm_resp bir message_id döndürür.
4. İletim raporlarını deliver_sm olarak alın ve her birini deliver_sm_resp ile yanıtlayın.
5. Boştayken iki tarafın oturumun canlı olduğunu bilmesi için periyodik olarak enquire_link gönderin.
6. unbind ile kapatın ve unbind_resp bekleyin.

Her PDU bir sıra numarası taşır ve yanıtlar aynı numarayı taşır; bir submit_sm_resp'i gönderdiğiniz mesajla eşleştirmenin yolu budur. SMPP dokümantasyonumuz her adımı kendi ayarlarımızla kapsar.

SMPP pencerelemesi nedir ve neden önemlidir?

Pencereleme, yanıtları gelmeden önce birkaç submit_sm PDU'su göndermek demektir. Yolda izin verilen onaylanmamış PDU sayısı penceredir. SMPP'nin her seferinde tek HTTP isteğinden daha yüksek aktarım hızını sürdürmesinin ana nedeni budur.

1 penceresiyle istemciniz bir mesaj gönderir, yanıt için tam bir gidiş dönüş bekler, sonra bir sonrakini gönderir. Aktarım hızı, anlaşılan hızınızla değil ağ gecikmesiyle sınırlanır. Daha büyük bir pencerede yanıtlar gelirken bağlantı meşgul kalır.

Genel kurallar:

• Sağlayıcınızın sizinle anlaştığı pencere boyutunu kullanın ve asla aşmayın; fazla PDU'lar reddedilebilir.
• Bind başına anlaşılan hıza uyun. ESME_RTHROTTLED alırsanız yavaşlayın ve geri çekilmeyle yeniden deneyin.
• Bekleyen sıra numaralarını izleyin, böylece bir kopma hangi mesajların kabul edildiğini kaybettirmez.
• Sürekli büyüyen bir pencereyle değil, hesabınız için anlaşılan sayıya kadar daha fazla bind ile ölçeklendirin.

REST API'miz ve SMPP bind'ları için varsayılan limitler hatalar ve limitler sayfasında listelenir; hesabınızın limitleri erişim tahsis edildiğinde teyit edilir.

İletim raporları nasıl farklılaşır?

REST'te sağlayıcı webhook'unuza bir JSON olayı gönderir. SMPP'de rapor, esm_class içinde rapor biti ayarlı olarak oturumda bir deliver_sm PDU'su olarak gelir. İkisi de asenkrondur; ne 200 OK ne de submit_sm_resp, cihazın mesajı aldığı anlamına gelir.

SMPP v3.4 belirtimi rapor metin biçimini örnek olarak verir ve kesin biçimi SMSC tedarikçisine bırakır, ancak çoğu sağlayıcı onu izler:

id:2603121407537573731 sub:001 dlvrd:001 submit date:2610100914 done date:2610100915 stat:DELIVRD err:000 text:Your OmniDemo code

Sistemleriniz her iki arayüzü de tüketiyorsa SMPP durumlarını tek bir durum modeline eşleyin. Tipik bir eşleme:

Biçimden daha önemli iki pratik fark:

• Onay. Bir SMPP istemcisi her deliver_sm'e yanıt vermelidir. Onaylanmamış raporlar yeniden gönderilir ve bind'ı yavaşlatabilir. Bir webhook işleyicisi de aynı nedenle hızlıca 2xx yanıt vermelidir.
• Kurtarma. SMPP istemciniz bağlantıyı kaybederse raporlar bir sonraki bind'ı bekler veya sağlayıcının kuyruğunda zaman aşımına uğrayabilir. REST'te bir sağlayıcı, bir tarih aralığı için raporları yeniden iletme olanağı sunabilir. Her birinin nasıl çalıştığını sorun.

Her durumun ne anlama geldiğini mesaj iletim durumları açıklaması yazısında okuyun.

Kodlama nasıl ele alınır?

Her iki arayüz de GSM-7 ile Unicode arasında seçim yapmalı ve her ikisi de uzun mesajları segmentlere böler. Fark, işi kimin yaptığıdır.

• REST: messageType gibi bir alanı TEXT veya UNICODE olarak ayarlarsınız ve platform uzun mesajları segmentlere böler. API'mizde ayrıca önce karakterleri ve segmentleri saymak için POST /sms/identify vardır.
• SMPP: data_coding değerini (varsayılan GSM-7 alfabesi için 0, UCS-2 için 8) ayarlar ve baytları kendiniz kodlarsınız. Uzun mesajlar için ya her parçaya bir User Data Header ekler ve esm_class değerini 0x40 yaparsınız ya da sağlayıcınız izin veriyorsa tüm metni message_payload alanında gönderirsiniz.

3GPP TS 23.040 uyarınca tek bir SMS 140 oktet taşır: 160 GSM-7 karakteri veya 70 UCS-2 karakteri; başlık eklendiğinde parça başına 153 veya 67'ye düşer. Tek bir Arapça harf veya emoji tüm mesajı Unicode yapar. Kodlama hataları en yaygın SMPP entegrasyon arızasıdır; bu yüzden Arapça, emoji ve uzun metinlerle test edin. Karakter sınırları rehberimize bakın.

Güvenlik modelleri nasıl karşılaştırılır?

REST, TLS'e ve istek başına bir bearer token'a dayanır. SMPP v3.4'ün kendi şifrelemesi yoktur ve kimlik bilgilerini bind içinde gönderir; bu yüzden etrafındaki aktarım ve ağ kontrollerine bağlıdır.

SMPP için:

• TLS kullanın (TLS 1.3, RFC 8446'da tanımlanmıştır) veya özel bir hat; genel internet üzerinden asla düz SMPP kullanmayın.
• Yalnızca sunucularınızın bind yapabilmesi için kaynak IP adreslerini kaydedin.
• system_id ve parolayı gizli bilgi olarak saklayın, ortam başına ayrı tutun ve açığa çıkarlarsa yenileyin.
• Yanlış yapılandırmaya veya kimlik bilgisi kötüye kullanımına işaret edebilen bind hatalarını izleyin.

REST için:

• Token'ı yalnızca sunucularda tutun, asla mobil uygulamalarda veya tarayıcı kodunda değil.
• Kullanıcı adı ve parolayı günlüklerde son bulduğu URL içinde geçiren eski HTTP arayüzlerinden kaçının.
• Webhook'u HTTPS, tahmin edilemez bir yol ve sıkı gövde doğrulamasıyla koruyun.

Her seçenek işletme açısından size neye mal olur?

REST neredeyse hiç operasyonel yük eklemez: istekler ya başarılı olur ya da yeniden deneyebileceğiniz bir hata döndürür. SMPP ise izlemeniz ve bakımını yapmanız gereken uzun süre çalışan bir bileşen ekler.

Bir SMPP istemcisinin ihtiyaçları:

1. sıkı bir döngü yerine geri çekilme ve jitter ile yeniden bağlanmayı içeren bağlantı yönetimi;
2. keep-alive'lar ve sessiz, yarı açık bağlantıların tespiti;
3. bind başına pencere ve hız kontrolü;
4. kopmalardan sonra sıra takibi ve mutabakat;
5. rapor onaylama ve saklama;
6. kodlama ve birleştirme mantığı;
7. bind durumu, aktarım hızı, kısıtlama hataları ve rapor gecikmesinin izlenmesi.

Olgun açık kaynak kütüphaneler protokolü yönetir, ancak sağlayıcının gece 3'teki bakım penceresi dahil, çevresindeki davranışın sahibi yine ekibinizdir.

Her biri ne zaman kullanılmalı?

SMPP eklemek için net bir nedeniniz yoksa REST kullanın.

REST SMS API'yi şu durumlarda seçin

• Uygulamalardan OTP, uyarı, bildirim veya kampanya gönderiyorsanız;
• SMS'in yanı sıra WhatsApp, RCS veya diğer kanallara ihtiyacınız varsa;
• platformunuz sunucusuz fonksiyonlarda veya kısa ömürlü konteynerlerde çalışıyorsa;
• ekibinizin SMPP deneyimi yoksa ve onu kurmaya ihtiyaç duymuyorsa.

SMPP'yi şu durumlarda seçin

• yüksek ve sürekli SMS hacmi gönderiyorsanız ve REST limitlerine ulaştıysanız;
• zaten bir SMPP ağ geçidi veya mesajlaşma platformu işletiyorsanız;
• bir aggregator, operatör veya kendi müşterilerinizin SMS trafiğini bağlayan bir bayiyseniz;
• birkaç yukarı akış sağlayıcıda aynı protokole ihtiyaç duyuyorsanız.

Karma bir kurulum nasıl görünür?

Birçok işletme tek hesapta ikisini birden kullanır: çok kanallı ve uygulama trafiği için REST, toplu SMS için SMPP. Tuzak, iki ayrı iletim modeline sahip olmaktır.

• Kullanım senaryosuna göre yönlendirin, rastgele değil: örneğin OTP ve WhatsApp REST üzerinden, toplu SMS ekstreleri SMPP üzerinden.
• Webhook'lardan ve deliver_sm'den gelen durumları normalleştirin, mesaj kimliğiyle anahtarlanan tek bir tabloya yazın.
• Kayıtlar hangi arayüzü kullanırsanız kullanın geçerli olduğundan, her ikisinde de tek bir SMS başlığı (Sender ID) politikası kullanın.
• Her iki arayüze bölünmüş bir kampanya tek sonuç göstersin diye birlikte raporlayın.

Bir SMS API'sinden SMPP'ye nasıl geçersiniz?

Her iki arayüz çalışırken kademeli ilerleyin ve hacmi kaydırmadan önce ölçün.

1. İhtiyacı doğrulayın: REST'in karşılamadığı hacmi veya aktarım hızını belgeleyin.
2. Tahsis isteyin: hedef ülkeleri, SMS başlıklarını, beklenen tepe aktarım hızını ve kaynak IP adreslerini paylaşın.
3. Yığınızda olgun bir istemci kütüphanesi seçin ve kendi gönderim arayüzünüzle sarın.
4. Webhook'larınızla aynı durum modeline eşlenmiş şekilde önce rapor işlemeyi kurun.
5. Kodlamayı test edin: gerçek cihazlarda GSM-7, Arapça, emoji ve çok parçalı mesajlar.
6. Hatayı test edin: gönderim sırasında bağlantıyı öldürün, kısıtlamayı tetikleyin ve mutabakatı kontrol edin.
7. Paralel çalıştırın: bir trafik türünün küçük bir payını SMPP'ye taşıyın ve iletimi ve raporları karşılaştırın.
8. REST'i yedek yol olarak tutarak hacmi adım adım kaydırın.

Örnek bir bind yapılandırması şöyle görünür. Ana bilgisayar, port ve limitler yer tutucudur; gerçek değerler tahsis edilen kimlik bilgilerinizle gelir.

host:                 <provided with your bind>
port:                 <TLS port provided with your bind>
bind type:            transceiver
system_id:            <your system_id>
password:             <your password>
system_type:          (empty unless told otherwise)
interface_version:    0x34
source_addr_ton/npi:  5 / 0   (alphanumeric sender ID)
dest_addr_ton/npi:    1 / 1   (international number)
registered_delivery:  1       (request delivery receipts)
data_coding:          0 (GSM-7) or 8 (UCS-2)
enquire_link:         every 30 seconds while idle
window:               as agreed for your account

Uygulamalı örnek: Bölgesel bir perakendeci ekstreler için SMPP ekliyor

BAE, Mısır ve Ürdün'de faaliyet gösteren kurgusal bir çevrimiçi perakendeci olan "Souq Rafiq", OTP'leri ve sipariş güncellemelerini bir REST API üzerinden, WhatsApp şablonlarını ise aynı API üzerinden gönderiyor. Tüm müşteri tabanına SMS ile gönderilen aylık hesap ekstreleri, REST işinin işletmenin istediğinden daha uzun sürdüğü bir noktaya büyüdü.

• Karar: OTP, sipariş güncellemeleri ve WhatsApp REST'te kalıyor. Aylık ekstre SMS'i bir SMPP transceiver bind'ına taşınıyor.
• Tahsis: ekip iki kaynak IP kaydediyor, ülke başına SMS başlıklarını teyit ediyor ve aktarım hızı ile bind sayısı üzerinde anlaşıyor.
• Geliştirme: küçük bir SMPP servisi açık kaynak bir kütüphane kullanıyor, raporları webhook'un kullandığı durum tablosuna yazıyor ve REST yoluyla aynı dahili gönderim arayüzünü sunuyor.
• Test: Arapça ekstrelerin birkaç cihazda doğru birleştirmeyle UCS-2 olduğu doğrulanıyor.
• Devreye alma: önce bir ülke taşınıyor. İletim ve rapor zamanlaması REST referansıyla karşılaştırıldıktan sonra diğer ülkeler, REST yedek olarak tutularak izliyor.

Yaygın hatalar

• SMPP'yi gösteriş için seçmek. REST hacminizi karşılıyorsa SMPP yalnızca iş ekler.
• 1 pencereyle çalıştırıp düşük aktarım hızı için sağlayıcıyı suçlamak.
• Yeniden gönderilen raporlara ve kısıtlamaya yol açan deliver_sm'i onaylamamak.
• Bir kopmadan sonra saldırı gibi görünebilen sıkı bir döngüde yeniden bağlanmak.
• Uzunluk hatalarına yol açan, tek PDU'da short_message ile message_payload'u karıştırmak.
• Kimlik bilgilerini ve içeriği ifşa eden, internet üzerinden düz SMPP.
• Raporların birbirini tutmamasına yol açan, karma kurulumda iki durum modeli.
• Sınırlar: bu rehber yaygın uygulamayı anlatır. Pencere boyutları, hızlar, TLS portları ve rapor ayrıntıları sağlayıcıya ve hesaba göre değişir; bunları tahsis sırasında teyit edin.

OmniChannels.ai nasıl yardımcı olur?

OmniChannels.ai ikisini de sunar. https://api.broadnet.me adresindeki REST API bir Bearer token kullanır ve SMS'in yanı sıra WhatsApp, RCS, Messenger, Instagram, Telegram, e-posta ve push'u kapsar; iletim durumları webhook'unuza tek bir biçimde gönderilir. Yüksek hacimli SMS için TLS üzerinden SMPP 3.4 bind'ları hesap bazında, izin verilen kaynak IP'lerle tahsis edilir ve BroadNet'in doğrudan operatör bağlantısı üzerindeki aynı SMS rotalarını kullanır. Bayiler ve toptan iş ortakları için ayrılmış bind'lar mümkündür. SMPP dokümantasyonu veya hızlı başlangıç ile başlayın ya da geliştirici genel bakışına göz atın.