Bir SIP araması VPN üzerinden neden kayıt oluyor ama ses göndermiyor
Kayıt ve ses farklı yollar izler. Tek bir aramayı tünelden geçirerek PBX'in hangi adresleri kullanabileceğini ve RTP'nin gerçekte nerede durduğunu görün.
Başarılı bir kayıt ses hakkında neredeyse hiçbir şey söylemez. Bir softphone saatlerce ofis PBX'iyle geçerli bir bağlantı tutabilir ve yine de sessizlik iletir. Tünel yalnızca birinin bilerek içine gönderdiği paketleri taşır, ve bir arama üç ayrı yol kullanır: bağlantı, diyalog kurulumu ve RTP akışı. Bunları ayırdığınızda arıza VPN kelimesine değil tek bir yola düşer.
Ev Wi-Fi'sindeki bir dizüstü bilgisayarın onaylanmış bir tünelden ofis dahilisine numara çevirdiğini düşünün. PBX kullanıcıyı doğrular, REGISTER'ı kabul eder ve dahili kullanılabilir görünür, ama arama bir yönde tam sessizlikle bağlanır.
Kayıt bir kişiyi bağlar, medya yolunu değil
REGISTER isteği kayıt sunucusundan bir kayıt adresi ile bir veya daha fazla kişi URI'si arasında eşleme saklamasını ister. Bu eşleme, yeni diyaloğun şu anda nereye gönderilmesi gerektiğine dair dar bir soruyu yanıtlar. Medyanın nereye ait olduğu hakkında hiçbir şey söylemez ve kabul edilen kayıt, sonraki INVITE'ın ulaşılabilir bir medya adresi taşıdığını kanıtlamaz. Kayıtlar ayrıca bir zamanlayıcıyla sona erer, bu yüzden yenilemeyi bırakan telefon, tüneli hâlâ sağlıklı görünürken gelen aramaları kaybeder. Tünel durumu yerine kişinin sona erme süresini izleyin.
Softphone tünelin arkasındayken kişi başlığı özel bir adres taşıyabilir. Bunu başka bir uç noktaya yönlendiren PBX, aranan tarafın ulaşamayacağı bir ağa yönelmiş diyalog oluşturur. PJSIP uç noktasında rewrite_contact=yes ayarını yapmak PBX'in gözlemlediği kaynak adresi değiştirmesini sağlar ve bu genellikle çalma ile zaman aşımı arasındaki farktır.
INVITE ne sunar ve kim kullanabilir
SDP gövdesi olan bir INVITE, arayanın medyayı nerede almak istediğini önerir: bir adres, bir bağlantı noktası ve bir kodek listesi. Aranan taraf kendi adresi ve bağlantı noktasıyla yanıtlar, sonra her taraf diğerinin önerdiği yere RTP gönderir. Arayan, yalnızca ev ağında var olan 192.168.x.x gibi bir adres önerdiyse, sinyalleşme ne kadar temiz olursa olsun aranan tarafın ses gönderecek yeri yoktur. Maskeleme, paketler yönlendiriciden çıkarken IP başlıklarını yeniden yazar, ancak bir SDP gövdesinin içindeki metni asla yeniden yazmaz.
Bu boşluk klasik tek yönlü aramayı açıklar: sinyalleşme çalışır çünkü iki uç nokta da PBX'e ulaşır, ses ise başarısız olur çünkü bir uç noktaya başka bir NAT'ın arkasında var olan bir adrese göndermesi söylenmiştir.
| Path | Who picks the address | Typical failure |
|---|---|---|
| REGISTER | Softphone, rewritten by the registrar if configured | Binding expires or points at a private address |
| INVITE and SDP | Each endpoint in its own offer or answer | Offer names a media address nobody can route to |
| RTP | PBX relay policy or the two endpoints | Port range blocked, or no return path |
Sesi kimin taşıdığı bir yapılandırma seçimidir
Sinyalleşme ve medya ayrı rollerdir. Bir proxy tüm arama boyunca sinyalleşme yolunda kalabilir ve tek bir RTP paketine dokunmayabilir. PBX'in medya aktarıcısı olup olmayacağı tünelin varlığına değil yapılandırmaya bağlıdır.
Doğrudan medyada uç noktalar RTP'yi kendileri değiş tokuş eder; bu tek bir LAN'da iyi çalışır, bir taraf dar bir bağlantı noktası aralığının arkasındaysa kötü çalışır.
direct_media=no ayarını yapmak PBX'i medya yoluna iter, böylece iki bacak da onun denetlediği bir adreste sonlanır; bu, öngörülebilir adresleme karşılığında bant genişliği ve işlemci harcar. Aktarırken PBX yine de ulaşılabilir bir adres duyurmak zorundadır. Çok ağlı bir ana bilgisayarda pjsip.conf içindeki external_media_address ve external_signaling_address, SDP'de ve Via başlıklarında ne görüneceğini belirler. Bunları ayarlamadan bırakırsanız PBX, tek yolu tünelin uzak tarafı olan arayana kendi LAN adresini önerebilir.
Ayarlara dokunmadan önce her yönü izleyin
Arama etkinken PBX üzerindeki soket tablosuyla başlayın: ss -uanp | grep -E '5060|10000', RTP bağlantı noktalarının bağlı olup olmadığını ve hangi yerel adresi kullandıklarını gösterir. Medya aralığında hiçbir şey bağlı değilse aktarıcı devrede değildir ve uç noktalar doğrudan konuşur. Ardından softphone tarafında tcpdump -ni any -s0 udp portrange 10000-20000 -w rtp.pcap ile yakalayın. Gelen paket olmadan giden paketler sorunu dönüş yoluna veya uzak tarafa kullanması söylenen adrese daraltır, boş bir yakalama ise medyanın tünel arabirimine hiç ulaşmadığı anlamına gelir. sngrep ile sinyalleşme yakalaması, SDP bağlantı satırını gönderildiği gibi göstererek diğer yarıyı yanıtlar.
O bağlantı satırındaki adresi uzak tarafın gerçekten yönlendirebildiği adresle karşılaştırın. Bu tek karşılaştırma, tek yönlü ses raporlarının çoğunu herhangi bir yapılandırma incelemesinden daha hızlı çözer.
Şifreleme tünelin kenarında durur
TLS üzerinden SIP, yapılandırıldığı sinyalleşme atlamasını korur; SRTP, iki uç anlaştığında medyayı korur; tünel ise kendi uç noktaları arasındaki trafiği korur. Hiçbiri diğerlerini vermez. Tünel içinde şifrelenmiş bir arama, ağ geçidini PBX'e doğru düz metin olarak terk edebilir ve bu bir tasarım kararıdır, kusur değil.
Kaydı kapatmadan önce üç şeyi sırayla doğrulayın: kayıt taze, SDP uzak tarafın ulaşabileceği bir adres taşıyor ve paketler medya bağlantı noktalarında iki yönde akıyor. Bunlardan biri yanlışsa sorun tünelde değildir. Başarısız olan yolu düzeltin, ardından değişikliği doğrulamak için aynı yakalamayı yeniden çalıştırın. Önceki ve sonraki yakalamaları saklamak, bir sonraki tek yönlü raporu bütün bir öğleden sonra yerine beş dakikalık bir kontrole dönüştürür.