AvaritCall · Editör ekibi
SIP 403, 408, 486 ve 503: çağrı hatalarını incelemek
SIP hata kodu sorunun sınıfını gösterir; tek başına kök nedeni açıklamaz. 403, 408, 486 ve 503 yanıtlarını çağrı izi, zaman çizelgesi, Retry-After ve sağlayıcı sınırlarıyla birlikte inceleyin.
SIP 403, 408, 486 veya 503 gördüğünüzde önce yanıtın hangi çağrı bacağından ve hangi işlem için geldiğini bulun. Kod bir başlangıç noktasıdır; ayrıntılı neden için istek, yanıt, zaman çizelgesi ve ilgili tarafın açıklaması gerekir. Aynı kodun bütün görüşmelerde aynı yapılandırma hatasını anlattığını varsaymadan ilerleyin.
1. Dört kodun genel anlamıyla başlayın
RFC 3261, SIP yanıtlarının anlamlarını tanımlar. [1] Aşağıdaki tablo, bir incelemeyi başlatmak için kısa bir sınıflandırmadır. Bir ekrandaki son hata satırını okumakla yetinmeyin; yanıtın kaynağını ve o anda tamamlanmaya çalışılan çağrı adımını da belirleyin.
| Kod | Genel anlam [1] | İlk inceleme sorusu |
|---|---|---|
| 403 | İstek reddedildi | Ayrıntılı ret gerekçesi ve ilgili politika nedir? |
| 408 | Zaman aşımı | Beklenen yanıt hangi aşamada gelmedi? |
| 486 | Uç meşgul | Meşgul yanıtı hangi uçtan geldi? |
| 503 | Hizmet geçici kullanılamıyor | Ayrıntı geçici sorun veya sınır mı gösteriyor? |
403 için aynı isteği körlemesine tekrarlamayın. 408 için yalnız koddan ağın tamamen kapalı olduğu sonucunu çıkarmayın. 486’da bütün hedeflerin meşgul olduğu varsayımıyla ilerlemeyin. 503’te de tek bir sabit yeniden deneme aralığına bağlanmayın. Bu ayrımlar, hatayı doğru çağrı bağlamında araştırmaya yardım eder.
2. Çağrı izini doğru işlemle eşleştirin
Çağrı kimliği, istek yöntemi ve işlem sırasını aynı kayıtta tutun. SIP izi incelerken Call-ID ile çağrı bağlamını, CSeq ile ilgili isteği izleyin; gerekiyorsa Via bilgisini işlem eşleştirmesinde kullanın. Bir santral iki ayrı bacak kuruyorsa kimliklerin aynı kalacağını varsaymayın. Eşlemenin nasıl yapıldığını gözlenen çağrı akışından doğrulayın.
Birden fazla noktadan kayıt alındığında saat farkını ölçüm planına ekleyin. Farklı sistemlerde aynı görünen zaman damgaları aynı olayı aynı anda kaydetmeyebilir. Önce olay sırasını, sonra süre farklarını değerlendirin. Kayıp olduğu düşünülen yanıtın başka kayıt noktasında bulunup bulunmadığını kontrol edin. Yerel uygulamanın ürettiği zaman aşımıyla ağdan gelen 408’i ayrı işaretleyin; aynı kullanıcı mesajı bu iki durumu gizleyebilir.
3. 503, Retry-After ve sağlayıcı sınırlarını birlikte okuyun
503 yanıtındaki Retry-After varsa, belirtilen süre boyunca o sunucuya yeni istek yönlendirmemek önerilir; başlık yoksa RFC, 500 gibi işlemeyi ister. [1] Yeniden deneme kararını yanıtın tamamıyla ve kullanılan istemcinin davranışıyla birlikte inceleyin. Bir bekleme değerini bütün başka sunucular için otomatik kural haline getirmeyin.
Twilio’nun yayımlanmış hata rehberi, 503 için çağrı başlatma hızı ile eşzamanlı çağrı sınırını ayrı ele alır. [2] Buradan çıkarılacak pratik ders, yeni çağrı/saniye ile devam eden çağrı sayısını ayrı ölçmektir. Kullandığınız hizmetin güncel açıklamasını ve ilgili hesap sınırını kontrol edin; başka sağlayıcının örnek değerini kendi kapasiteniz saymayın.
Yoğun başarısızlıkta denemeleri hemen üst üste yığmak ek yük oluşturabilir. Deneme sayısını, bekleme süresini ve hangi çağrının hangi denemeye ait olduğunu açık tutun. Aynı kullanıcıya yinelenen çağrı başlatılmadığını da kontrol edin. Alternatif hedef kullanımı varsa, bunun sonucu ayrı kaydedilsin; hata kodunun değişmesi tek başına görevin tamamlandığını göstermez.
4. Yoğun bir resepsiyon denemesini araştırın
Örnek bir resepsiyon testinde sakin dönemde çağrılar kuruluyor, kısa bir başlangıç dalgasında bazıları 503 alıyor olsun. Ekip ilk olarak başarısız çağrıları aynı zaman aralığına göre toplar. Her denemenin başlama anını, aynı anda süren çağrıları, ayrıntılı yanıt metnini ve varsa Retry-After değerini kaydeder.
Sonraki deneme, toplam konuşma sayısını değiştirmeden çağrı başlangıçlarını daha geniş zamana yayar. Hata azalırsa bunu bir ipucu olarak tutar; kesin sınır değeri ilan etmeden ilgili hizmetin açıklamasıyla doğrular. Başka bir denemede tek değişken seçilir. Böylece başlangıç yoğunluğuyla konuşma eşzamanlılığı ayrı incelenir. Sonuç raporu gözlenen değişimi, tekrar sayısını ve açıklanamayan çağrıları birlikte gösterir.
5. Değişiklik öncesi kontrol listesi
- Son kodla birlikte ilgili istek, ayrıntılı yanıt metni, çağrı bacağı ve gözlem noktasını kaydedin.
- İzleri çağrı kimliği ve işlem sırasına göre eşleştirin; birden fazla saat kaynağının farkını belirtin.
- Yerel zaman aşımı, ağdan gelen hata ve kullanıcı arayüzündeki mesajı ayrı değerlendirin.
- 503 için Retry-After’ı ve hizmetin yayımladığı sınır açıklamasını inceleyin; başlatma hızıyla eşzamanlılığı karıştırmayın.
- Tek değişiklik yapın. Beklenen sonucu, yeniden deneme kapsamını ve geri dönüş adımını önceden yazın.
- Teknik incelemeye gereken alanları seçin; örnek paylaşırken gerçek numara, kimlik bilgisi ve ilgisiz başlık içeriğini azaltın.
6. Sık sorulan sorular
403 her zaman yanlış parola mıdır? Kod tek başına bunu göstermez. Ayrıntılı ret nedenini ve yanıtın hangi tarafta üretildiğini araştırın. İzin veya hedef koşullarını değiştirmeden aynı denemeyi tekrar etmek açıklama sağlamaz.
408, aranan kişinin cevap vermediği anlamına mı gelir? Önce hangi işlemin zaman aşımına uğradığını belirleyin. Çağrı kurulumundaki bekleme ile insanın telefonu açma süresini aynı olay gibi okumayın.
503 için her zaman yeniden aramalı mıyım? Yanıtın başlıkları, mevcut yük, hizmet açıklaması ve yinelenen çağrı riski birlikte değerlendirilmelidir. Yeni denemenin gerçekten yeni ve izlenebilir bir işlem olduğunu doğrulayın.
486’dan sonra bütün yönlendirmeleri iptal etmeli miyim? İlgili ucun yanıtını çağrı akışında inceleyin. Başka bir hedefin durumu için ayrıca kanıt gerekir; tek bir meşgul yanıtı tüm yolu açıklamaz.
- [1]RFC 3261: SIP: Session Initiation Protocol, response codes and Retry-After — IETF / RFC Editor, 2002-06 (erişim: 2026-10-01)
- [2]Troubleshooting your Trunk — Twilio (erişim: 2026-10-01)
