Traces İle Mesajlaşmalarda Uyumsuzluk Sorununun Kaldırılması

SIP ağ geçitlerinden alınan izlentiler (traces) ile uyumsuzluk sorunun mesajlaşma yapısı içerisinde 488 hata koduyla gerçekleştiği görülmüştür. Bu durumdan yola çıkılarak 488 ve 606 SIP hata kodlarının uyumsuzluk sorunlarına referans olabileceği düşünülebilir.

Bir diğer SIP sorunu başlığı olarak sunulan SIP ses kodlayıcı anlaşmasında ise farklı ses kodlayıcı kombinasyonları ile kodlayıcı anlaşmasının nasıl gerçekleştiği ve karşılaşılan sorunlar ortaya konulmuştur. Yine uyumsuzluk senaryosunda olduğu gibi öncelikle başarılı ses kodlayıcısı anlaşması örnek gösterilerek referans alınacak bir çağrı akışı ortaya konmuştur.

Bu senaryoda ise SIP vekil sunucusu kullanılarak, SIP ağ geçitleri ya da SIP son kullanıcılar ile SIP vekil sunucularının nasıl mesajlaşma akışı gerçekleştirdikleri de görülmüştür. Yine WireShark programı ile her bir senaryo için izlentiler toplanarak VoIP çağrısı akış diagramı elde edilmiş ve üzerinde analizler gerçekleştirilmiştir.

Öncelikle aynı markaya ait her iki ağ geçidinde G.711 ve G.729 ses kodlayıcılarına izin verilerek, SIP protokolünün nasıl davrandığı analiz edilmiştir. Ardından bir ağ geçidinde sadece G.711 ses kodlayıcısına izin verilmişken, diğer ağ geçidinde hem G.711 hem de G.729 kodlayıcılarına izin verilmiş ve protokolün nasıl bir mesajlaşma akışı gerçekleştirdiği gözlemlenmiştir. Oturumu başlatan kullanıcının konuşabileceği G.711 ses kodlayıcısını gönderdiği ve karşı tarafından da G.711 ile konuşmayı kabul ettiği görülmüştür. Ancak gerçekleşen senaryo yine geniş alan ağı üzerinden olmasına rağmen, bant genişliğinin yeterli olması bu senaryoyu başarılı kılmıştır. Bu senaryoya bir ağ geçidi İstanbul laboratuarında yer alırken diğer ağ geçidi Maidenhead/İngiltere laboratuarında yer almaktadır.

Burada sorun olarak adlandırılabilecek durum şudur: Şayet bant genişliği anlık olarak yetersiz seviyeye ulaşsaydı, karşı taraf G.711 ile konuşamayacağını, sadece G.729 ile ses paketlerini gönderebileceğini söyleyecek, ancak çağrıyı başlatan kullanıcı G.729 desteklemediği için sinyalleşme sorunu meydana gelecekti. SIP senaryosunda bu anlaşmanın çoğu zaman böylesi şansa bağlı olması, gerek sistem sorunlarını analiz ederken gerek çağrı kalitesi ölçümlerinde zorluklara neden olmaktadır. Ayrıca bir önceki senaryodan farksız bir şekilde, aynı ağdan çağrının gitmiş olmasına rağmen, ağ geçicinin farklı bir ses kodlayıcı kullanması, SIP çağrılarında hangi ses kodlayıcılarının kullanılacağının öncesinde pek kestirilemeyeceği yorumunu da beraberinde getirmektedir.

Son senaryoda, her iki ağ geçidinde sadece G711 ses kodlayıcısına izin verilmiş ve kullanılabilir bant genişliği kısılmıştır. Bu durumda ağ geçitleri G.711 ile konuşmaya yeterli olacak bant genişliğini bulamadığı için 503 hata koduyla hizmetin mevcut olmadığını sunucuya bildirdiği gözlemlenmiştir. Bu hata kodunun özel olarak sorunu işaret etmediği düşünüldüğünde, bu tip ses kodlayıcı anlaşması sorunları için ürün bazlı araştırma yapmak gereksinimi olduğu ortaya çıkmaktadır.

Başarılı Mesajlaşma ve Çağrı Senaryosu Nasıl Yapılır?

Yönlendirme sunucu ile mesajlaşmasını gerçekleştiren istemci, hedef IP adresini öğrendikten sonra yeni bir oturum başlatmak üzerede INVITE mesajını bu adrese göndermiştir. Aşağıdaki Şekil III.10’da görülen mesajlaşma yapısı 10.0.13.2 IP adresli X marka ağ geçidi üzerinden çıkan 5000 numaralı kullanıcı ile 10.11.25.25 IP adresli Y marka ağ geçidinden hizmet alan 3223 numaralı kullanıcı arasında gerçekleşen SIP mesajlaşmasına aittir.

5000 kullanıcısı tef.com alanı içerisinden başka bir alanda tanımlı olan 3223 kullanıcısına INVITE mesajını göndermiştir. INVITE mesajı içerisinde aynı zamanda SDP protokolü kullanarak gerçekleşen bu çağrının G.729 ses kodlayıcı kullanarak yapılmasını istediğini belirtmiştir. İki kullanıcı arasındaki bant genişliğinin kısıtlı olması sebebiyle, daha az bant genişliğinde yüksek performans gösteren bu ses kodlayıcısı tercih edilmiştir.
Burada gönderilen SIP INVITE mesajının yapı olarak bir önceki başlıkta SIP Yönlendirme Sunucusuna gönderilen INVITE mesajından hiçbir farkı yoktur. Tek fark, INVITE mesajı hedef adres olarak sunucuyu değil, hedef IP adresi olarak 10.11.25.25 gösteriyor olmasıdır.

Ardından herhangi bir teyit almadan sabit olarak gönderilen 100 Trying (Deniyor) mesajı karşı tarafa gönderilmiştir. Burada 3223 kullanıcısının aramayı karşılayacak durumda olup olmadığı sorgulanmaz, amaç sadece karşı tarafa isteminin değerlendirildiğini bildirmektir ki karşı taraf isteminin sonuçsuz kaldığı şekilde yorumlamasın. X marka ağ geçidi 3223 numaralı kullanıcının yerinde ve çağrıyı karşılayabilecek durumda olduğunu teyit ettikten sonra çağrı bildirimini gerçekleştirmiş ve istemciye 180 Ringing (Çalıyor) mesajı göndermiştir. 100 Trying ve 180 Ringing mesajlarının ardından gönderilen PRACK mesajının amacı, arayan kullanıcının 1xx mesajlarının sorunsuz bir şekilde ulaştığını karşı tarafa bildirmesidir. PRACK mesajı arayan kullanıcıdan arayan kullanıcıya gönderilmektedir ve 200 OK yanıtı ile karşı taraftan onaylanmıştır.

Bir sonraki adımda gelen 200 OK SDP mesajı, INVITE mesajında gönderilen SDP paketinin kabul edildiğini ve karşı tarafın da G.729 ses kodlayıcısı kullanarak konuşabileceğini onayladığı anlamına gelir. Arayan kullanıcı ACK mesajı göndererek 200 OK yanıtını aldığını teyit etmiş ve artık her iki kullanıcı da birbirine RTP (Real Time Protokol) üzerinden ses paketleri göndererek konuşmayı başlatmıştır.

Görülen işaretleşme SIP ağ geçidi üzerinden alınıp VoIP sinyalleşme paketlerini gösterecek şekilde filtrelendiği için RTP paketlerini burada görememiş bulunmaktayız. RTP paketleri ağ geçidinde sinyalleşme kanalından farklı bir kanal olan konuşma kanalı üzerinden gönderilmiştir. 221. saniyeden 229. saniyeye kadar sürdüğünü görülen konuşma daha sonra arayan kullanıcının BYE mesajı göndererek oturumu sonlandırma talebini iletmiştir. Karşı taraf 200 OK göndererek kabul etmiş ve oturum sonlanmıştır.

Burada dikkat etmemiz gereken husus, SDP paketi içerisinde gönderilen G.729 ses kodlayıcısı Ses Algılama ve Bastırma özelliğini kullanma talebi ile karşı tarafa gitmiştir. Aşağıdaki Şekil III.11’de görülen ―annexb=yes‖ satırı bu anlama gelmektedir. Karşı taraf bu parametreyi okuyup yorumlayabildiği için oturum başarılı bir şekilde gerçekleşebilmiştir.

İnternet Protokolü Üzerinden Mesajlaşma Sorunlarının Giderilmesi

Teorik olarak 8 başlık altında toplanan ve anlatılan SIP sorunlarından SIP uyumsuzluk sorunu ve SIP ses kodlayıcı anlaşması sorunları uygulamalı olarak incelenmiştir.
Yapılan uygulamalarda SIP mesajlaşması farklı markalar arasında gerçekleşen protokol bazındaki uyumsuzluk sorunu ve aynı marka içerisinde ancak farklı ağ geçitleri arasında gerçekleşen ses kodlayıcısı anlaşma sorunları incelenmiş ve sorunların çözümüne ilişkin uygulamalı olarak nasıl değişiklikler yapılması gerektiği konusunda fikir verilmiştir.

SIP uyumsuzluk sorununu canlandırmak için gerçek bir VoIP ortamının kullanıldığı, uluslararası deniz nakliyatı yapan bir firmaya ait SIP ağ geçitleri kullanılmıştır. Bu senaryoda bahsi geçen X markasına ait ağ geçidi Danimarka’da yer alırken, Y markasına ait ağ geçidi İsveç’te bulunmaktadır. Yönlendirme sunucusu, Y markasına ait ağ geçidi ile aynı yerde bulunarak yerel ağ üzerinden haberleşmiştir. X markasına ait ağ geçidi ise yüksek bant genişliğine sahip geniş alan ağı üzerinden sunucu ile haberleşmiştir. Sunucu ve ağ geçitlerinin farklı yerlerde olması, uzaktan bağlantı yaparken bazı zorluklara da sebep olmuştur. Telnet ve SSH bağlantısı ile sunuculara ve ağ geçitlerine bağlanılarak, yazılımlar yüklenmiş, konfigürasyonlar değiştirilmiş ve sonuçları elde ettiğimiz veriler toplanılmıştır. Birçok durumda, daha hızlı veri transferi gerçekleştirmek için sahadaki mühendisle birlikte çalışılmıştır.

SIP mesajlarının toplanılması için Y marka ağ geçidi tarafından WireShark ücretsiz ağ paketi toplama ve analiz programı kullanılmıştır. Bir diğer ismi PCAP aracı olan bu programdan alınan anlık resimlerle uyumsuzluk sorunu gerçekleştiğinde SIP mesajlaşma yapısında nasıl bir değişikliğe uğradığı gözlemlenmiştir. Bu paket yakalama programları ağ geçidi üzerine kurularak paket toplayabildiği gibi, çoğu durumda ağ geçitlerinin bağlı olduğu veri anahtarlama (switch) ürünlerinde port aynalama (port mirroring) yöntemi ile kullanılmıştır. Böylelikle, Y ağ geçidine gelen tüm SIP paketleri, aynı zamanda port aynalama ile WireShark programının yüklü olduğu bilgisayara da kopyalanmıştır.

Basit arayüzü olması ve işlevsel kullanımı ile WireShark programının SIP sorunlarının analizi kolayca gerçekleştirilmiştir. Program vasıtasıyla, dinlenen ağ paketleri filtrelenerek sadece SIP paketleri elde edilmiş ve ardından bu paketler RFC’lerde anlatılan SIP mesajlaşma akışına uygun bir şekilde sıralanmış ve şekillerde de görüleceği üzere görsel bir kullanıcı arayüzü ile gösterilmiştir.

Uyumsuzluk senaryosuna gerçekleştirilmeden önce başarılı bir çağrı senaryosu örnek gösterilerek referans alınacak bir çağrı ile karşılaştırılması sağlanmıştır. Başarılı çağrı örneğinde RFC’lerde bahsedilen yapıya uyumluluk sağlanmıştır.

SIP uyumsuzluk sorununun gösterildiği başarısız çağrı senaryosunda SIP mesajlaşmasının detaylarında bu sorunun nasıl aksettiği incelenmiştir. Her ne kadar Sessizlik Algılama ve Bastırma özelliği basit ve sadece bant genişliğini etkileyebilecek bir değişken gibi düşünülse de, gerçekleştirilen senaryo ile aslında bu basit özelliğin SIP uyumsuzluklarına sorun teşkil edebileceği ortaya konmuştur. Bu gibi sorunların uygulamalı VoIP ortamlarında yama (patch) parçacıkları yazılarak, ürün bazında çözülebildiği gibi, konfigürasyonda gerçekleştirilen ve sistemin çalışmasını da etkileyebilecek önlemlerle de üstesinden gelindiği görülmüştür. Günümüz VoIP ortamında en verimli şekilde bant genişliğini kullanmak son derece önemli iken, Sessizlik Algılama ve Bastırma özelliğinin devredışı bırakılarak SIP uyumsuzluk sorununun çözülmesi, pek etkin bir çözüm olarak görülmemektedir.