FortiGate SIP ALG ve VoIP Troubleshooting: ALG Kapatıldıktan Sonra Sorun Neden Devam Eder?

01 / PROBLEM

Problem

Bir FortiGate devreye alındıktan, firmware güncellendikten veya SIP/VoIP trafiğinin geçtiği policy üzerinde değişiklik yapıldıktan sonra şu belirtilerden biri görülebilir:

Tek taraflı ses (One-Way Audio)

Çağrının yaklaşık 32 saniye sonra düşmesi

SIP REGISTER paketlerinin beklenen şekilde tamamlanmaması

İlk refleks çoğu zaman:

SIP ALG'yi kapat

olur.

Ancak sorun her zaman burada bitmez.

FortiGate üzerinde SIP trafiğinin gerçekte hangi mekanizma tarafından işlendiğini doğrulamadan yalnızca arayüzde bir seçeneği değiştirmek, problemi eksik analiz etmeye neden olabilir.

SIP troubleshooting'de ilk soru “ALG açık mı?” değil, “Bu SIP oturumunu şu anda hangi mekanizma işliyor?” olmalıdır.

02 / ÖNCE SIP VE RTP'YI BIRBIRINDEN AYIR

Önce SIP ve RTP'yi Birbirinden Ayır

VoIP trafiğini tek bir akış gibi düşünmek troubleshooting'i zorlaştırır.

Basitleştirilmiş yapı:

                SIP Signaling
PBX -------------------------------- SIP Provider
 |          REGISTER / INVITE / ACK       |
 |                                         |
 |                                         |
 +--------------- RTP Media ---------------+
              Ses paketleri

SIP signaling genellikle çağrının kurulmasını yönetir.

RTP ise ses trafiğini taşır.

Bu nedenle:

Çağrı kuruluyor ama ses tek yönlü

ile:

Çağrı hiç kurulmuyor

aynı problem değildir.

03 / BELIRTILER BIZE NE SÖYLER?

Belirtiler Bize Ne Söyler?

One-Way Audio

Çağrı kuruluyor ancak ses yalnızca bir yönde gidiyorsa öncelikle RTP media path incelenmelidir.

Kontrol alanları:

SDP içindeki IP adresi
RTP portları
NAT çevirisi
Return path
Firewall policy
VIP / DNAT
SIP ALG tarafından yapılan SDP değişiklikleri

SIP mesajlarının geçmesi RTP'nin de doğru geçtiği anlamına gelmez.

Yaklaşık 32 Saniyede Call Drop

Bir çağrının yaklaşık 32 saniye civarında düşmesi önemli bir ipucudur.

Özellikle packet capture'da şu yapı görülüyorsa:

INVITE
   ↓
200 OK
   ↓
200 OK tekrar
   ↓
200 OK tekrar
   ↓
ACK yok / yanlış yere gidiyor

SIP signaling path ve NAT davranışı incelenmelidir.

Bu belirti otomatik olarak “SIP ALG hatası” anlamına gelmez; ancak ACK'nin doğru hedefe ulaşmaması veya SIP header'larındaki adres bilgisinin NAT sonrasında yanlış kalması güçlü adaylardır.

REGISTER Problemleri

REGISTER başarısız olduğunda şu akış karşılaştırılmalıdır:

PBX
 |
 | REGISTER
 v
FortiGate
 |
 | NAT
 v
SIP Provider
 |
 | Response
 v
FortiGate
 |
 v
PBX

Burada şu sorular sorulur:

• REGISTER FortiGate'e geliyor mu?
• WAN tarafından çıkıyor mu?
• Source NAT beklenen IP/port ile mi yapılıyor?
• Provider cevabı geri geliyor mu?
• Cevap doğru internal host'a dönüyor mu?
• SIP Contact / Via alanlarında beklenmeyen private/public adres değişimi var mı?

04 / FORTIGATE SIP TRAFIĞINI NASIL İŞLER?

FortiGate SIP Trafiğini Nasıl İşler?

FortiGate üzerinde iki kavram sıkça birbirine karıştırılır:

SIP ALG
SIP Session Helper

Bunlar aynı mekanizma değildir.

SIP ALG

Yeni FortiOS sürümlerinde varsayılan ve önerilen SIP inspection mekanizmasıdır.

Basitleştirilmiş olarak:

SIP packet
   ↓
SIP ALG / Proxy
   ↓
SIP + SDP inspection
   ↓
NAT / dynamic pinhole işlemleri

SIP ALG application layer'da SIP ve SDP içeriğini anlayabilir ve gerektiğinde NAT bilgilerini düzenleyebilir.

SIP Session Helper

Session helper daha eski bir mekanizmadır ve kernel tarafında çalışır.

SIP packet
   ↓
Kernel Session Helper
   ↓
Basic SIP / RTP NAT assistance

Modern FortiOS tasarımında session-helper daha çok legacy compatibility mekanizması olarak değerlendirilmelidir.

05 / 1. ÖNCE HANGI SIP MEKANIZMASININ AKTIF OLDUĞUNU BUL

1. Önce Hangi SIP Mekanizmasının Aktif Olduğunu Bul

Troubleshooting'in en önemli adımı budur.

Önce sistem ayarını kontrol et:

show full system settings | grep default-voip-alg-mode

Genel olarak:

proxy-based

SIP ALG tarafını,

kernel-helper-based

ise session-helper tarafını işaret eder.

Ancak sadece bu satıra bakmak da yeterli değildir.

Policy üzerinde VoIP profile bulunuyorsa gerçek işleme davranışı değişebilir.

Bu nedenle session tablosunu da kontrol etmek gerekir.

Örneğin SIP provider veya PBX adresine göre filtrele:

diagnose sys session filter clear
diagnose sys session filter dport 5060
diagnose sys session list

Gerekirse source port tarafı da kontrol edilir:

diagnose sys session filter clear
diagnose sys session filter sport 5060
diagnose sys session list

Session çıktısında helper=sip, redir, local veya ALG/helper ile ilişkili bilgiler aktif işleme mekanizması hakkında ipucu verebilir.

06 / 2. SESSION HELPER VARSA ID'YI TAHMIN ETME

2. Session Helper Varsa ID'yi Tahmin Etme

Sık görülen hatalardan biri şu komutu doğrudan uygulamaktır:

delete 13

Bazı örneklerde SIP helper ID'si 13 olabilir.

Ancak bu değer her FortiGate'te aynı olmak zorunda değildir.

Önce mevcut helper tablosunu görüntüle:

config system session-helper
show
end

Aranan kayıt mantığı:

edit <SIP_HELPER_ID>
    set name sip
    set protocol 17
    set port 5060
next

Silme kararı verilecekse gerçek ID önce buradan doğrulanmalıdır.

07 / 3. `SIP-NAT-TRACE` NE YAPAR, NE YAPMAZ?

3. sip-nat-trace Ne Yapar, Ne Yapmaz?

Bu ayar sıkça yanlış yorumlanır.

set sip-nat-trace disable

komutu SIP ALG'yi veya session-helper'ı kapatan ana switch değildir.

sip-nat-trace, session-helper kullanılırken NAT sırasında orijinal SIP source IP bilgisinin kaydedilmesiyle ilgili davranışı kontrol eder.

Dolayısıyla:

sip-nat-trace disable

uygulandı diye:

SIP inspection tamamen kapandı

sonucuna varılamaz.

Bu ayrım özellikle eski troubleshooting notlarında çok önemlidir.

08 / 4. GERÇEKTEN SIP INSPECTION OLMADAN ÇALIŞMAK İSTENIYORSA

4. Gerçekten SIP Inspection Olmadan Çalışmak İsteniyorsa

Bazı PBX veya SIP provider tasarımları FortiGate'in SIP payload üzerinde değişiklik yapmasını istemeyebilir.

Bu durumda amaç:

FortiGate SIP/SDP'yi değiştirmesin
        |
        v
SIP + RTP klasik firewall/NAT policy ile geçsin

olabilir.

Ancak bu yaklaşım uygulanacaksa kritik bir sonuç vardır:

SIP ALG veya helper dynamic RTP pinhole oluşturmuyorsa, gerekli SIP ve RTP portlarının firewall/NAT tasarımında açıkça karşılanması gerekir.

Kontrol edilmesi gerekenler:

SIP signaling portları
RTP UDP port aralığı
VIP / DNAT
Source NAT
Bidirectional policy
Return routing
PBX tarafındaki RTP port range
Provider beklentileri

FortiGate üzerinde tamamen inspection dışı bir test tasarlanacaksa önce:

1. 01

   Policy üzerinde VoIP profile olup olmadığı doğrulanır.

2. 02

   Aktif ALG mode belirlenir.

3. 03

   Session-helper tablosu kontrol edilir.

4. 04

   Değişiklikten sonra yeni bir SIP session ile test yapılır.

Bu işlem üretim ortamında değişiklik kontrolü ve geri dönüş planıyla yapılmalıdır.

09 / 5. PACKET CAPTURE ILE NAT ÖNCESI VE SONRASINI KARŞILAŞTIR

5. Packet Capture ile NAT Öncesi ve Sonrasını Karşılaştır

SIP troubleshooting'de yalnızca configuration okumak yeterli değildir.

PBX üzerinden capture:

diagnose sniffer packet any 'host <PBX_IP>' 6 0 l

Provider üzerinden capture:

diagnose sniffer packet any 'host <SIP_PROVIDER_IP>' 6 0 l

Sadece signaling kontrolü için:

diagnose sniffer packet any 'host <PBX_IP> and port 5060' 6 0 l

Amaç aynı SIP mesajını FortiGate'in iki tarafında karşılaştırmaktır.

Örneğin:

LAN tarafı REGISTER
        |
        v
     FortiGate
        |
        v
WAN tarafı REGISTER

Şu alanlar karşılaştırılır:

• Source IP / port
• Destination IP / port
• Contact
• Via
• SDP connection address
• SDP media port

10 / 6. ONE-WAY AUDIO İÇIN RTP'YI AYRI YAKALA

6. One-Way Audio İçin RTP'yi Ayrı Yakala

SIP signaling sağlıklı görünüyorsa sonraki adım RTP'dir.

Basitleştirilmiş kontrol:

Remote RTP
    |
    v
FortiGate
    |
    v
PBX

ve ters yön:

PBX
 |
 v
FortiGate
 |
 v
Remote RTP

İki yönden biri eksikse şu alanlar kontrol edilir:

RTP port range
NAT
VIP
Return route
SDP'de advertised IP
SDP'de advertised media port
Firewall session

SIP inspection tamamen devre dışı bırakılmışsa FortiGate'in RTP için otomatik expectation/pinhole oluşturmasını beklememek gerekir.

11 / 7. 32 SANIYELIK CALL DROP NASIL OKUNUR?

7. 32 Saniyelik Call Drop Nasıl Okunur?

Yaklaşık 32 saniyede düşen çağrıda packet capture son derece değerlidir.

Örnek problemli akış:

PBX                  Provider
 |                       |
 |------- INVITE ------->|
 |<------ 200 OK --------|
 |                       |
 |       ACK ?           |
 |                       |
 |<------ 200 OK --------|
 |<------ 200 OK --------|
 |                       |
 |------ Call Drop ------|

Bu durumda odak:

ACK hangi IP'ye gidiyor?
Contact header doğru mu?
Via bilgisi doğru mu?
NAT sonrası signaling path simetrik mi?

olmalıdır.

Yaklaşık 32 saniye güçlü bir signaling ipucu olsa da tek başına root cause değildir.

12 / 8. NPU OFFLOADING'I DOĞRUDAN SUÇLAMA

8. NPU Offloading'i Doğrudan Suçlama

FortiGate, uygun session'ları NP/NPU donanımı üzerinde offload edebilir.

Bunun troubleshooting açısından önemli sonucu şudur:

Offload edilmiş trafik normal packet sniffer'da beklediğiniz şekilde görünmeyebilir.

Bu nedenle capture eksik görünüyorsa hemen:

FortiGate paket düşürüyor

sonucuna varılmamalıdır.

Gerekirse sadece problemli firewall policy üzerinde ve yalnızca kontrollü test süresince offload kapatılabilir:

config firewall policy
    edit <POLICY_ID>
        set auto-asic-offload disable
    next
end

Sonra çağrı yeniden üretilir ve packet capture alınır.

Test tamamlandıktan sonra ayar geri alınır:

config firewall policy
    edit <POLICY_ID>
        set auto-asic-offload enable
    next
end

13 / 9. SIP ALG / SESSION HELPER AKTIVITESINI KONTROL ET

9. SIP ALG / Session Helper Aktivitesini Kontrol Et

Session-helper aktivitesi için:

diagnose sys sip status

kullanılabilir.

SIP ALG tarafında ise:

diagnose sys sip-proxy stats

istatistikleri yararlı olabilir.

Amaç:

Configuration ne diyor?
        +
Session ne diyor?
        +
Counters ne diyor?

üçlüsünü birlikte değerlendirmektir.

14 / SISTEMATIK TROUBLESHOOTING AKIŞI

Sistematik Troubleshooting Akışı

Bu tip bir VoIP vakasında izlenebilecek sıra:

1. Belirtiyi sınıflandır
   |
   +-- REGISTER problemi
   +-- Call setup problemi
   +-- 32 sn drop
   +-- One-way audio
   |
   v
2. SIP ve RTP'yi ayır
   |
   v
3. SIP ALG mi Session Helper mı kullanılıyor?
   |
   v
4. Session table kontrolü
   |
   v
5. LAN/WAN packet capture karşılaştırması
   |
   v
6. NAT + SIP/SDP adreslerini kontrol et
   |
   v
7. RTP'yi iki yönde doğrula
   |
   v
8. Capture görünürlüğü şüpheliyse NPU offload testi
   |
   v
9. Değişiklik sonrası yeni session ile doğrulama

15 / SIK YAPILAN HATALAR

Sık Yapılan Hatalar

“GUI'den SIP ALG'yi kapattım, artık FortiGate SIP'e dokunmuyor”

Her zaman doğru değildir.

Aktif SIP processing mode session üzerinden doğrulanmalıdır.

Session Helper ID'sini sabit kabul etmek

delete 13

her cihaz için doğru değildir.

Önce helper tablosu kontrol edilmelidir.

sip-nat-trace disable ile inspection'ın tamamen kapandığını düşünmek

Bu ayar SIP inspection'ın ana enable/disable kontrolü değildir.

Sadece UDP/5060 açmak

Çağrı signaling'i ile RTP media farklı akışlardır.

SIP inspection kapalıysa gerekli RTP aralığının policy/NAT tarafında ayrıca karşılanması gerekebilir.

NPU offload'u kalıcı olarak kapatmak

Offload öncelikle troubleshooting visibility açısından test edilmelidir.

İlk adımda reboot etmek

Reboot öncesi session table, packet capture ve aktif SIP processing mode bilgileri toplanmazsa önemli kanıtlar kaybolabilir.

16 / KARAR TABLOSU

Karar Tablosu

17 / DOĞRULAMA

Doğrulama

Sorunun çözüldüğünü yalnızca “çağrı açıldı” diyerek doğrulamak yeterli değildir.

Kontrol listesi:

[ ] SIP REGISTER başarılı
[ ] INVITE doğru hedefe gidiyor
[ ] 200 OK geri geliyor
[ ] ACK doğru hedefe ulaşıyor
[ ] RTP iki yönde akıyor
[ ] SDP'deki IP/port bilgileri doğru
[ ] NAT dönüşümü beklenen şekilde
[ ] Çağrı 32 saniye sonrasında devam ediyor
[ ] Birden fazla test çağrısında aynı sonuç alınıyor

18 / SONUÇ

Sonuç

FortiGate üzerindeki VoIP problemlerinde en kritik hata, bütün sorunu tek bir “SIP ALG açık/kapalı” ayarına indirgemektir.

Gerçekte analiz edilmesi gereken zincir şudur:

SIP Signaling
      +
Active SIP Inspection Mode
      +
Session Helper / ALG
      +
NAT
      +
SDP
      +
RTP Media
      +
Session Table
      +
Hardware Offload Visibility

Bu nedenle en değerli yaklaşım:

Önce FortiGate'in SIP oturumunu nasıl işlediğini doğrula; sonra signaling, NAT ve RTP'yi ayrı ayrı izle. NPU offload'u ise root cause varsayımı olarak değil, gerektiğinde kontrollü bir diagnostic karşılaştırma olarak kullan.

Bu yöntem one-way audio, REGISTER problemi ve yaklaşık 32 saniyelik call drop gibi belirtileri tek bir ayara bağlamak yerine, gerçek packet flow üzerinden analiz etmeyi sağlar.