Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 SIP TABANLI TELEFON SERVİSLERİNİN IPTV SİSTEMİNE BÜTÜNLEŞTİRİLEBİLMESİ İÇİN YENİ BİR PROTOKOL ÖNERİSİ * Hasan YÜKSELTEN ** Sait Eser KARLIK ** Güneş YILMAZ Özet: Bu çalışmada, oturum başlatma protokolü (SIP) tabanlı çağrı sunucusuyla sağlanan telefon servislerinin IPTV sistemiyle bütünleşmesini sağlayacak yeni bir mimari yapı önerilmiş ve bu amaca yönelik yeni bir proto- kol (Bağımsız Bildirim Protokolü) tasarlanarak geliştirilen mimari yapının avantajları incelenmiştir. Önerilen mimari yapı ve bunu destekleyen protokoller, bildirim mimarisinde arabirim katmanına (middleware) olan ge- reksinimi ortadan kaldırmaktadır. Böylece, bildirim mimari yapısı bir katman azaltılmakta, arabirim katmanına olan bağımlılık sona ermekte, her türlü arabirim katmanı ile bildirim mimarisi kurulabilmektedir. Geliştirilen mimari yapı ve protokolün testleri sonucunda, bildirim bant genişliğinin, mevcut bildirim mimari yapılarındaki- nin %10’una kadar düştüğü ve önerilen mimari yapının başarılı bir şekilde çalıştığı görülmüştür. Anahtar Kelimeler: IPTV, Bağımsız Bildirim Protokolu, Telefon Servisleri, VoIP, SIP A Novel Protocol Proposal For Integration of Sip Based Telephony Services To Iptv System Abstract: In this study, a novel architecture that will provide integration of session initiation protocol (SIP) based call server telephony services with IPTV system has been proposed, a novel protocol (Independent Notifi- cation Protocol) has been designed for this aim and advantages of the developed architecture have been ana- lyzed. The proposed architecture and supporting protocols eliminate the need for a middleware layer in the noti- fication architecture. Therefore, one layer is reduced from the notification architecture and dependence to a spe- cial middleware finishes, i.e. the notification architecture can be built up with any kind of middleware layer. Test results for the proposed architecture and the protocol have showed that notification bandwidth reduces to 10 % of that of conventional notification architecture and the proposed architecture works successfully. Key Words: IPTV, Independent Notification Protocol, Telephony Services, VoIP, SIP 1. GİRİŞ Gelişen teknolojiyle birlikte bilgi ve iletişim sistemlerinde hızlı aktarım teknolojileri ortaya çıkmış, bütünleşik sistemlere doğru geçiş hızlanmıştır. Internet Protokolü’nün (IP) yaygınlaşması sa- yesinde geleneksel haberleşme sistemleri aracılığı ile daha önce sunulamayan birçok hizmet günümüz- de mümkün hale gelmiş ve bu durum yeni fırsatları ortaya çıkarmıştır. Altyapı ve hizmetlerin değişim içerisinde olduğu bu dönemde IP uygulamaları arasında en çok öne çıkan uygulamaların VoIP (Voice over IP) ve IPTV olduğu görülmektedir. SIP (Session Initiation Protocol) protokolü de en yaygın kul- lanılan VoIP protokolü olarak haberleşme dünyasındaki yerini almıştır. VoIP’den daha sonra ortaya çıkan ve henüz ortak bir protokolü oluşturulmayan IPTV ise yakın gelecekte TV yayıncılığının yapısı- nı tamamen değiştirecek bir hizmet olarak görülmektedir. Servis sağlayıcıların ve kablo TV operatörlerinin yakın gelecekte IPTV sistemine geçmesi beklenmektedir. Gelişen teknolojiyle birlikte VoIP, video konferans, vb zengin servis içeriğiyle IPTV geleceğin TV teknolojisi olacaktır. Özellikle üçlü oyun (triple-play) denen ses, veri ve görüntü hizmet- lerinin IPTV ile tek platforma taşınıyor olması, tek abonelik ile maksimum uygulamaya erişilebilmesi * TTNET A.Ş., Esentepe Mahallesi, Salih Tozan Sk, Karamancılar İş Mkz, D Blok, No:16, 34394 Şişli, İstanbul. ** Uludağ Üniversitesi, Mühendislik-Mimarlık Fakültesi, Elektronik Mühendisliği Bölümü, 16059 Görükle, Bursa. 83 Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi IPTV’ nin başlıca avantajlarındandır. IPTV sistemiyle kullanıcılara temel TV servisleri, isteğe bağlı video (VoD), dijital kayıt (PVR), ses hizmetleri, internet erişimi gibi hizmetler verilebileceği gibi, çağrı bildirimi (caller-ID), TV ekranında e-posta, sesli mesaj servisi, çoklu kamera seçenekleri, canlı anket, bölgesel reklâm gibi servisler de verilebilecektir (Yarali ve Cherry, 2005, Friedrich ve diğ., 2008). Sistem yaygınlaştıkça, yeni servisler ortaya çıkacak ve IPTV, insan hayatında vazgeçilmez bir yer alacaktır. 2. IPTV BİLDİRİM GELİŞTİRMELERİ SIP protokolünü kullanan IMS (IP Multimedia Subsystem) ile IPTV bütünleşmesi gerek servis sağlayıcılar, gerekse birçok servise tek abonelikle sahip olabilecek kullanıcılar için büyük avantajlar içermektedir (Lin ve diğ., 2010). Bu bütünleşmeyle, STB’a cep telefonları, SIP tabanlı kablo- lu/kablosuz telefonlar, PC’ler ve diğer IP konuşabilen cihazlar eklenebilecektir. IMS ve IPTV bütün- leşmesiyle elde edilebilecek servislerin ve avantajların başlıcaları şunlardır:  Gelen çağrı bilgisinin ekranda gözükmesi ve çağrı ile ilgili yönlendirmelerin kumanda ile sağlanabilmesi  TV’den kumanda ile çağrı başlatılabilmesi (Click to Call)  TV’ye monte edilen web-cam vasıtasıyla görüntülü konuşma yapılabilmesi  Veri servislerinin, anlık mesajlaşma, sohbet, resim paylaşımı, e-posta, SMS/MMS gibi uy- gulamaların TV ortamına taşınabilmesi  TV servislerinin kablosuz ortama taşınmasının sağlanması ve mobil cihazların (dizüstü bil- gisayar, PDA, cep telefonu vb.) IPTV’nin bir parçası haline gelmesi (Marnik, 2007, Medi- na ve diğ., 2008) Chatras ve Said (2008)’de, IPTV ile IMS bütünleşmesi için bir mimari yapı önerilmiş ve bu mimari yapıyla SIP tabanlı IPTV uygulamasının IPTV’ye dörtlü oyun özelliğini kazandırabileceği savunulmuştur. Bu bütünleşmenin faydaları şu şekilde sıralanmıştır:  Ortak mimari yapı (infrastructure)  Ortak kimlik ve yetkilendirme mekanizması  Ortak kaynak yönetimi  Çoklu girişli çözüm (multi-access solution)  Ortak faturalandırma sistemi Hsieh (2008)’de, üçlü-oyun (triple-play) için terminal arabirim katman mimari yapısı öneril- miştir. Bildirimler için TCP protokolünü kullanan bu yapıda 6 bileşen bulunmaktadır. Haberleşme bileşeni, HTTP, RTSP, SIP, TCP gibi protokollerden sorumludur. VoIP servisleri SIP protokolünü kullanmaktadır. Bu mimaride Caller-ID ve C2C servisleri test edilerek başarılı bir şekilde çalıştıkları gözlenmiştir. Simoes ve diğ. (2009)’da, IMS ile MPEG standartlarını bütünleştirmeye yönelik yeni bir mi- mari yapı önerilmiş ve IMS ile IPTV görüntü servisleri entegre edilmiştir. Daha verimli bir iletim ve daha düşük bant genişliği sağlaması açısından MPEG–2 yerine MPEG-4/MPEG-7 üzerinde çalışılmış- tır. Futbol karşılaşmalarında anlık istatistik ve interaktif reklâm gibi uygulamalar geliştirilmiştir. Beck ve Ensor (2007)’de, IPTV arabirimi yazılımı geliştirilmiş ve bu yazılım ile IMS IPTV bütünleşmesi sağlanmıştır. Bu yazılımın fonksiyonları şöyle sıralanabilir:  IMS ile IPTV arasında bağlantı kurulumu  SIP ve http mesajlarının koordinasyonu  Telefon çağrı durumunun takibi Bu çözümde, STB (Set Top Box)’a web tarayıcı uygulaması eklenmiştir. Bu tarayıcı, STB ile web sunucu arasında HTTP bağlantısı kurabilir. Her STB yeniden başlatmada (boot), web tarayıcı önceden biçimlendirilmiş ana sayfayı otomatik olarak yükler. Ancak bu çözümün bazı dezavantajları bulunmaktadır. Öncelikle birçok STB kısıtlı işlemci gücüne sahiptir ve web tarayıcı sadece bir pence- reyi destekleyebilir. Dolayısıyla bu çözüm sadece tarayıcı destekli STB’larda kullanılabilir. Mesaj giriş/çıkış kapasitesi de ayrı bir kısıtlayıcı unsurdur. Bunun için de yeterli hafıza gereklidir. Her bir bağlantı için, sunucuda 20 KB hafıza bulunması gerekmektedir. IPTV servisleri üzerinde yapılacak 84 Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 geliştirmeler ile yeni bütünleştirme metodları ortaya çıkacak ve daha basit mimari yapılar gelişecektir. Ayrıca bu alanda uluslararası standartların oluşturulması da bu çalışmaların gelişmesini hızlandıracak- tır. Bu çalışmada, SIP tabanlı telefon servislerinin IPTV sistemiyle bütünleşmesinde mevcut uy- gulamalardan daha verimli çalışacak yeni bir mimari yapı ve bu mimari yapıyı destekleyen yeni bir protokol önerilmektedir. Önerilen geliştirmelerle, bildirim mimari yapısında arabirim katmanına olan gereksinimi ortadan kaldırmak suretiyle bildirim mimari yapısı bir katman azaltılmaktadır. Böylece bildirim mimari yapısında arabirim katmanına bağımlılık kalmamakta, her türlü arabirim katmanı ile bildirim mimari yapısı kurulabilmektedir. Çalışma kapsamında geliştirilen BBP (Bağımsız Bildirim Protokolü) ile bildirim kaydı ve gösterimi doğrudan BGY (Bağımsız Geçit Yolu) üzerinden yapılmak- tadır. Geliştirilen protokol bağlantısız UDP protokolünü kullandığı için, STB ile BGY arasındaki ileti- şim UDP protokolü ile yapılmaktadır. Böylece bağlantılı TCP protokolünü kullanan mimari yapıya kıyasla çok daha verimli bir mimari elde edilmiş ve hafıza gereksinimi olmayan daha az sunucuyla, sadece UDP konuşma kapasitesi olan STB’larda da bildirim servislerinin çalışması sağlanmıştır. 3. ÖNERİLEN MİMARİ YAPI 3.1. Mevcut Bildirim Mimari Yapısı Günümüzde temel olarak kullanılan mevcut bildirim mimari yapısında, IPTV abonesi için bil- dirim kaydı, arabirim katmanında yapılmakta ve abone ID’si burada tutulmaktadır. Aboneye herhangi bir bildirim geldiğinde, BGY bu bildirimi önce arabirim katmanına bildirmekte, arabirim katmanı da, kendisinde kayıtlı olan abone ID’sine göre ilgili STB’a iletmekte ve STB’tan da IPTV abonesinin ekranına bildirim bilgisi gönderilmektedir. Şekil 1: Mevcut Bildirim Mimarisi Şekil 1’de mevcut IPTV- STB bildirim mimari yapısı görülmektedir. Bu mimari yapıda, abo- neler arabirim katmanı üzerinden sisteme kayıt olmakta ve buradan aldıkları ID numaraları vasıtasıyla 85 Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi BGY ile haberleşmektedir. Bu mimari yapıda, sistem donanıma çok bağımlıdır. Her farklı arabirim katmanı için farklı yazılıma ihtiyaç duyulmaktadır. Bunun yanı sıra, STB ile arabirim katmanı arasın- daki iletişim TCP protokolü ile yapıldığı için, TCP yetkinliği olan STB cihazlarına ihtiyaç duyulmak- tadır. Bu da yüksek bildirim bant genişliği gereksinimine, sunucu tarafında hafıza gereksinimine ve mesajlaşma trafiğinin artmasına sebep olmaktadır. 3.2. BBP Mimari Yapısı Şekil 2’de bu makale kapsamında önerilen mimari yapı görülmektedir. Bu protokol ve mimari yapı ile abonelerin bildirim için BGY üzerinden sisteme kayıt olmaları sağlanmaktadır. Bu durumda, abonelerin IP ve port bilgileri BGY üzerinde bulunduğundan, bildirim servislerinin kullanılmasında herhangi bir arabirim katmanına gerek kalmamaktadır. Bu şekilde bildirim mimari yapısı bir katman azaltılarak, mimari yapının arabirim katmanından bağımsız olması sağlanmaktadır. Ayrıca, geliştirilen BBP protokolü UDP protokolünü kullandığı için, STB ile BGY arasındaki iletişim UDP protokolü ile yapılmaktadır. Böylece TCP kullanan mimariye kıyasla daha az trafik mesajlaşması içeren verimli bir mimari elde edilmektedir. BBP protokolü ile ilgili ayrıntılı bilgi Ek-1’de verilmiştir. Şekil 2: Önerilen Bildirim Mimarisi 86 Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 4. TEST SONUÇLARI Şekil 2’deki mimari yapı kullanılarak test edilen protokol sonucunda beklenen sonuçlar alt başlıklarda belirtildiği üzere, başarılı bir biçimde elde edilmiştir. Geliştirilen protokol ile yapılan testler sonucu, IPTV sistemine bildirim kaydı başarılı bir şe- kilde yapılabilmiş ve bildirimler protokolde tanımlanan kodlar ile doğru olarak alınabilmiştir. Testlerin yapılabilmesi için, öncelikli olarak BBP protokolünün parametrelerine göre BBP bil- dirim arayüzü yazılmış ve BGY üzerinde çalıştırılmıştır. Ayrıca BBP istemci programı da yazılarak STB üzerinde çalıştırılmıştır. Böylelikle BGY ve STB birbirleriyle BBP protokolü üzerinden konuşa- bilmiştir. Yapılan testlerdeki amaç, öncelikli olarak önerilen mimaride, IPTV abonesinin bildirim kay- dını başarılı bir şekilde yapabileceğini test etmektir. Bunun başarılı bir şekilde çalıştığı gözlendikten sonra, IPTV abonesine gelen bir çağrının Caller ID bilgisinin de BBP protokolündeki parametrelere göre başarılı bir şekilde iletildiği test edilmiştir. Test ortamında kullanılan mimaride, IPTV sistemi, çağrı sunucusunun bir abonesi gibi tanım- lanmıştır. Yani, çağrı sunucusu, IPTV abonesini kendi SIP hatlarından biri olarak görmektedir. IPTV abonesine bir çağrı geldiğinde, hem abonenin telefonu çalmakta hem de BGY’de tanımlı olan aboneye çağrı bilgisi gönderilmektedir. BGY, bu çağrı bilgisini BBP protokolünü kullanarak STB’ye iletmekte, ve buradan da IPTV abonesinin ekranına arayan bilgileri gönderilmektedir. Kullanılan SIP telefon hattının IPTV sistemine kaydı BGY tarafından yapılmaktadır. BBP, BGY birimine uygulama programlama arabirimi (API) yazılarak uygulanmıştır. BGY istemcisi olarak UDP Telnet, SIP çağrılarını başlatmak ve yönetmek için EyeBeam istemcisi, bant genişliği ölçümleri içinse Wireshark yazılımı kullanılmıştır. 4.1. Bildirim Kayıt Cevabı BBP mimarisi kullanılarak, IPTV abonesinin IPTV sistemine bildirim kayıt istemi test edil- miştir. Bildirim kayıt isteminin mesaj sırası Şekil 3’te görülmektedir. UDP Telnet ile gönderilen abone kayıt istemi BGY’e iletilmekte ve burada BBP API üzerinden abonenin STB cihaz (device) bilgisi veritabanına kaydedilmektedir. Şekil 3: Bildirim Kayıt İstemi Mesaj Akışı IPTV sisteminde tanımlı bir abone için, bildirim kayıt istemi gönderildiğinde, BBP protokolü için Ek-1’de tanımlanan cevap kodları tanımlarında belirtildiği gibi, ‘returnCode’ değeri olarak, 0x0000 değeri gelmiştir. Bu cevabın gelmiş olması, bildirim kayıt isteminin başarılı bir şekilde yapıl- dığını göstermektedir. 87 Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi IPTV sisteminde tanımlı olmayan bir abone için bildirim kayıt istemi gönderildiğinde, bu kez Ek-1 Tablo 3’te gösterilen cevap kodları tanımlarında belirtildiği gibi 0xE002 değeri gelmiştir. Başarılı bildirim kayıt istemi cevap mesajı Ek-2’de, başarısız bildirim kayıt istemi cevabı me- sajı da Ek-3’te gösterilmiştir. 4.2. Çağrı Bildirimi (Caller ID) BBP mimarisi kullanılarak, IPTV abonesinin telefonu aranarak gelen çağrı bildiriminin (Caller ID) gelip gelmediği test edilmiştir. Bunun için çağrı sunucusunda kayıtlı bir numaraya Eye- Beam istemcisinden erişilerek, IPTV abonesinin SIP telefonu aranmıştır. Çağrı bildiriminin mesaj sırası Şekil 4’te görülmektedir. Şekil 4: Caller ID Mesaj Akışı Yapılan test sonucunda, çağrı bildirim mesajının BBP parametrelerine uygun olarak başarılı bir şekilde alındığı görülmüştür. Çağrı bildirim mesajı Ek-4’te gösterilmiştir. 4.3. Kayıt (Registration) Bant Genişliği BBP protokolu ile normal metotlara kıyasla çok daha küçük bir bant genişliği, bildirim kaydı için yeterli olmaktadır. BBP mimarisi ve mevcut mimari ile yapılan testlerin sonuçları aşağıdaki şekil- lerde görülmektedir. 160 140 120 100 80 138 60 40 20 14 0 BBP Mevcut Mimari Mimari Yapı Şekil 5: Bildirim Kayıt Test Sonuçları 88 Kayıt Bant Genişliği (bps) Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 Şekil 5’te görüldüğü üzere, BBP ile bildirim kaydı için 14 bps bant genişliği yeterli olurken, mevcut mimaride 138 bps bant genişliği gerekmektedir. 4.4. Bildirim Bant Genişliği BBP protokolu ile normal metotlara kıyasla çok daha küçük bir bant genişliği, bildirim için yeterli olmaktadır. Wireshark ile ölçülen bildirim bant genişliği değeri ile normal metotla ölçülen de- ğer aşağıdaki grafikte görülmektedir. 1400 1200 1000 800 600 1213 400 200 218 0 BBP Mevcut Mimari Mimari Yapı Şekil 6: Bildirim Bant Genişliği Test Sonuçları Şekil 6’da görüldüğü üzere, BBP ile bildirim için 218 bps bant genişliği yeterli olurken, nor- mal mimaride 1213 bps bant genişliği gerekmektedir. Ayrıca BBP, UDP protokolü kullandığı için, sunucuda bir hafıza gerektirmemekte ve mesaj- laşma trafiğini de TCP kullanan mimarilere göre çok büyük oranda düşürmektedir. 5. SONUÇ Bu makalede, SIP tabanlı telefon servislerinin IPTV sistemine uyarlanabilirliği araştırılmış ve bu amaca dönük, alternatif bir mimari önerilmiştir. Bu mimaride çalışabilecek yeni bir protokol tasar- lanarak, bu protokolün temel kayıt ve bildirim kabiliyeti test edilmiştir. Geliştirilen mimari yapı ve protokolün testleri sonucunda, bildirim bant genişliğinin, mevcut bildirim mimari yapılarındakinin %10’una kadar düştüğü ve önerilen mimari yapının başarılı bir şekilde çalıştığı görülmüştür. Bu pro- tokol sayesinde IPTV sistemindeki telefon bildirimleri, daha basit bir mimaride ve daha küçük bant genişliği ile hızlı bir şekilde sağlanabilmiştir. Bu protokol ve mimari ile abonelerin bildirim için BGY üzerinden sisteme kayıt olmaları sağ- lanmıştır. Böylelikle, abonelerin IP ve port bilgileri BGY üzerinde tutulmuş, bildirim servislerinin kullanılmasında herhangi bir ara katman yazılımına gerek kalmamıştır. Bu şekilde bildirim mimarisi bir katman azaltılarak, mimarinin arabirim katmanından bağımsız olması ve sadece UDP konuşabilen daha düşük kapasiteli STB’ larda da bildirim servislerinin çalışabilmesi sağlanmıştır. Bununla birlikte, BBP protokolünün çift yönlü TCP protokolü yerine tek yönlü UDP protokolünü kullanması, güvenlik ve veri kaybı açısından bazı riskler taşımaktadır. Bu çalışmada geliştirilen protokolle sadece bildirim kayıt ve çağrı bildirimi servisleri üzerinde çalışılmıştır. Bundan sonraki çalışmalar için, yine bu protokol temelinde, çağrı yönlendirme, çağrı red- detme, sesli mesaj bildirimi, tıkla konuş, SMS/MMS alma/gönderme, vb servisler için de geliştirmeler yapılabilir. Ayrıca SIP haricindeki işaretleşme protokolleri için de farklı geliştirmeler yapılabilir. Öne- rilen mimarinin sunucu trafik analizleri de, bundan sonra yapılabilecek geliştirmeler arasında olacaktır. 89 Bildirim Bant Genişliği (bps) Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi KISALTMALAR API - Uygulama Programlama Arabirimi (Application Programming Interface) BBP - Bağımsız Bildirim Protokolü BGY - Bildirim Geçit Yolu (Notification Gateway) HD - Yüksek Çözünürlük (High Definition) IMS - IP Çokluortam Alt Sistemi (IP Multimedia Subsystem) IP - Internet Protokolü (Internet Protocol ) IPTV - Internet Protokolü Televizyonu (Internet Protocol Television) MMS - Çokluortam Mesaj Servisi (Multimedia Message Service) SD - Standart Çözünürlük (Standart Definition) SIP - Oturum Başlatma Protokolü (Session Initiation Protocol) SMS - Kısa Mesaj Servisi (Short Message Service) STB - Masa Üstü Cihazı (Set Top Box) TCP - İletim Kontrol Protokolü (Transmission Control Protocol) TDM - Zaman Bölümlemeli Çoğullama (Time Division Multiplex) UDP - Kullanıcı Datagram Protokolü (User Datagram Protocol) URI - Internet Kaynak Belirteci (Uniform Resource Identifier) URL - Örün Adresi (Universal Resource Locator) VoIP - IP üzerinden Ses İletimi (Voice over IP) EKLER Ek-1 Bağımsız Bildirim Protokolü (BBP) BBP bir istemci-sunucu protokolü olarak tasarlanmıştır. BBP sözdizimi bayt paketlemeli olup iletimde UDP kullanmaktadır. IPTV yayınları, güvenli bir özel ağ üzerinden iletildiği için, BBP proto- kolünde güvenlik özellikleri minimum seviyede tutulmuştur. 1.1. Mesaj Formatı (Message Format) Bir BBP mesajı Tablo 1’de belirtilen kısımlardan oluşmaktadır. Bu kısımlar, 1.2-1.8 altbölüm- lerinde açıklanmıştır. Tablo 1. Genel düzen UDP Mesaj Baslığı Mesaj Uzunluğu Sürüm Dizi (Sequence) Numarası Mesaj Tip Kodu Zorunlu sabit kısım Zorunlu değişken kısım İsteğe bağlı kısım 1.2. Mesaj Uzunluğu (Message Length) Mesaj uzunluğu alanı iki sekizlikten (octet) oluşmaktadır. Bu uzunluk, 1500 - 42 = 1458 baytı geçemez (standart Ethernet çerçeve boyutu = 1500 bayt, IP üstbilgisi boyutu = 20 bayt, TCP başlığı boyutu = 20 bayt, Mesaj uzunluğu boyutu = 2 bayt). 90 Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 1.3. Sürüm Bilgisi (Version) Sürüm alanı iki sekizlikten oluşmaktadır; ana sürüm numarası ve bir alt sürüm numarası. İs- temciler mesajın geri kalanını işleme koymadan önce bu değeri okumalıdır. 1.4. Dizi Numarası (Sequence Number) Dizi numarası, aygıt başına tutulan iki-sekizlik mesaj sayacıdır. Bu değer ilerideki geliştirme- ler için konulmuştur. Bu çalışmada, varsayılan değer 0 (0x0000) olacaktır. 1.5. Mesaj Tipi (Message Type) Mesaj tip kodu bir sekizlik alandan oluşur ve tüm mesajlar için zorunludur. 1.6. Zorunlu Sabit Kısım (Mandatory Fixed Part) Belirli bir mesaj tipi için zorunlu olan sabit uzunluklu parametreler, zorunlu sabit kısım içeri- sinde yer alacaktır. Parametrelerin konum, uzunluk ve sırası, mesaj tipi tarafından benzersiz şekilde tanımlanır. Böylece parametrelerin isimleri ve uzunluk göstergeleri mesaja dahil edilmez. 1.7. Zorunlu Değişken Kısım (Mandatory Variable Part) Değişken uzunluklu zorunlu parametreler, zorunlu değişken kısımda yer alacaktır. Mesaj, her bir parametre adını, uzunluk göstergesini ve parametre içeriğini kapsayacaktır. Parametre kodları her parametrenin başlangıcını belirtmek için kullanılır. 1.8. İsteğe Bağlı Kısım (Optional Part) İsteğe bağlı kısım, herhangi bir mesaj tipinde isteğe bağlı konulan/konulmayan parametrelerin bitişik bloğunu oluşturur. İsteğe bağlı kısım zorunlu sabit kısım veya zorunlu değişken kısımdan sonra başlayabilir. Bu kısım sabit uzunluklu ve değişken uzunluklu parametreleri içerebilir. Zorunlu değiş- ken uzunluklu parametreler ile isteğe bağlı parametreler arasında tek fark vardır. Zorunlu parametre mesajın içerisinde mutlaka yer almalıdır ancak isteğe bağlı olan yer almayabilir. 1.9. Bayt Dizilim Formatı Bir sekizlikten daha fazla yer kaplayan alanlar için, en önemli sekizlik (MSB) ilk olarak ileti- lecektir. 1.10. Boş Bitlerin Kodlanması (Coding of Spare Bits) Boş bitler, gönderici tarafta aksi belirtilmedikçe 0 olarak kodlanır. 1.11. İletim (Transport) BBP mesajı UDP payload verisiyle iletilir. UDP içeriği UDP, IP ve Ethernet üst bilgi (header) toplamı standart Ethernet çerçeve boyutu olan 1500 bayt’ı geçemez. Bir BBP mesajı her zaman bir UDP paketi tarafından iletilir. 1.12. Karakter Dizisinin Kodlanması (Coding of Strings) Bazı dizi parametreleri protokolde yerelleştirilmiş olarak kullanılmıştır. İstemci ile sunucu arasında kullanılan bütün stringler için UTF-8 (Unicode Transformation Format-8) kullanılmıştır. 1.13. Mesaj Tipi Kodları (Message Type Codes) Mesaj tip kodları Tablo 2’de gösterilmiştir. Bunlar sabit uzunluklu (1 sekizlik) parametreler- dir. Tablo 2, ayrıca kullanılan mesajların yönlerini de belirtmektedir. (I : İstemci ve S : Sunucu). Tablo 2. BBP Mesaj Tipleri Mesaj Tipi Mesaj Yönü Mesaj Tip Kodu (Decimal) Mesaj Tip Kodu (Hex) Kayıt Talebi I  S 1 0x01 Kayıt Cevabı S  I 2 0x02 Kayıt Süresi Dolmuş S  I 3 0x03 Bildirim S  I 12 0x0C 91 Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi 1.14. Cevap Kodu Cevap kodu, dönüş sebebini açıklar. 2 sekizlik sabit uzunluk parametresidir. Cevap kodları Tablo3’te verilmiştir: Tablo 3. Cevap Kodları Cevap Kodu Tanım 0x0000 İstem başarıyla işleme kondu 0xE001 Doğrulama Hatası 0xE002 Hatalı client-ID 0xE003 Hatalı Sürüm 0xE004 Veritabanı hatasından ötürü istem uygulanamadı 0xE005 Auto-login için birincil kullanıcı bulunamadı 0xE006 Kullanıcı hesabı devre dışı bırakıldı 0xE007 Servis devre dışı 0xE008 Servis yok 0xE009 Desteklenmeyen parametre değeri 0xE010 Geçersiz parametre değeri 0xE011 Hatalı mesaj Ek-2 Doğru Bildirim Kayıt Cevabı UDPServer listening on port 1314 Session created...: /43.135.125.38:2070 Session Opened...: /43.135.125.38:2070 ****************** OUTGOING POJO MESSAGE ****************** RegistrationRequestMessage[version=0x0100, sequence=0x00, type=0x01, clientID=hasdev, password=1234, IP:PORT= :] *********************************************************** ****************** OUTGOING HEX MESSAGE ****************** 00 13 01 00 00 00 01 01 06 68 61 73 64 65 76 19 04 31 32 33 34 *********************************************************** ****************** INCOMING HEX MESSAGE ****************** 00 0D 01 00 00 00 02 00 00 02 04 00 01 3D 1A *********************************************************** ****************** INCOMING MESSAGE HEADER ****************** Message Length: 0x0d Message Version: 0x0100 Message Sequence: 0x00 Message Type: 0x02 *********************************************************** ****************** INCOMING POJO MESSAGE ****************** RegistrationResponseMessage[version= 0x0100, sequence= 0x00, type= 0x02, returnCode= 0x0000, ttl= 81178] *********************************************************** RegistrationResponseMessage[version= 0x0100, sequence= 0x00, type= 0x02, returnCode= 0x0000, ttl= 81178] 92 Uludağ Üniversitesi Mühendislik-Mimarlık Fakültesi Dergisi, Cilt 16, Sayı 1, 2011 Ek-3 Yanlış Bildirim Kayıt Cevabı UDPServer listening on port 1314 Session created...: /43.135.125.38:2070 Session Opened...: /43.135.125.38:2070 ****************** OUTGOING POJO MESSAGE ****************** RegistrationRequestMessage[version= 0x0100, sequence= 0x00, type= 0x01, clientID= hasdevxx, password= 1234, IP:PORT= :] *********************************************************** ****************** OUTGOING HEX MESSAGE ****************** 00 13 01 00 00 00 01 01 06 68 61 73 64 65 76 19 04 31 32 33 34 *********************************************************** ****************** INCOMING HEX MESSAGE ****************** 00 07 01 00 00 00 02 E0 02 *********************************************************** ****************** INCOMING MESSAGE HEADER ****************** Message Length: 0x07 Message Version: 0x0100 Message Sequence: 0x00 Message Type: 0x02 *********************************************************** ****************** INCOMING POJO MESSAGE ****************** RegistrationResponseMessage[version= 0x0100, sequence= 0x00, type= 0x02, returnCode= 0xe002] *********************************************************** RegistrationResponseMessage[version= 0x0100, sequence= 0x00, type= 0x02, returnCode= 0xe002] Ek-4 Caller ID Bildirimi NotificationMessage[version=0x0100, sequence=0x00, type=0x0c, eventType 0x00, clientID= hasdev, EventToAddress= (305) 335-0012, EventFromName= HASAN, EventFromAddress= (305) 335-0011, EventFromAddressUri= sip:3053350011@abcd.com, *********************************************************** NotificationMessage NotificationMessage[version= 0x0100, sequence= 0x00, type= 0x0c, eventType 0x00, clientID= hasdev, EventToAddress= (305) 335-0012, EventFromName= HASAN, EventFromAddress= (305) 335-0011, EventFromAddressUri= sip:3053350011@abcd.com, Session closed...: /43.135.125.38:2070 93 Yükselten, H., Karlık, S.E., Yılmaz, G.: SIP Tabanlı Telefon Servislerinin IPTV Sistemine bütünleştirilebilmesi KAYNAKLAR 1. Beck A., Ensor B. (2007) IMS and IPTV Service Blending Lessons and Opportunities, International Con- ference on Intelligence in Networks (ICIN2007), Bordeaux, France. 2. Chatras B., Said M. (2008) Delivering Quadruple Play with IPTV over IMS, The Journal of The Institute of Telecommunications Professionals, 1(2): 9-14. 3. Friedrich O., Seeliger R., Al-Hezmi A., Arbanowski S. (2008) User Equipment for Converged IPTV and Telecommunication Services in Next Generation Networks, Human System Interactions Conference, pp. 879-883, Krakow, Poland. 4. Hsieh C. Y. (2008) Design of Triple Play Terminal Middleware for Service Convergence, International Computer Symposium (ICS2008), Taiwan. 5. Lin J., Yu D., Xiao S. (2010) Design and Implementation of Service Control Server in IMS-Based IPTV, International Conference on Internet Technology and Applications, pp.1-6, Wuhan, China. 6. Marnik M. (2007) Redefining the Quad Play with IPTV and IMS, International Engineering Consortium (IEC). 7. Medina B., Lohi M., Madani K. (2008) Investigation of Mobile IPv6 and SIP Integrated Architectures for IMS and VoIP Applications, International Conference on Telecommunications (ICT 2008), pp. 1-6, St. Pe- tersburg, Russian Federation. 8. Simoes J., Riede C., Magedanz T. (2009) New Interactive Experiences with IPTV Services Using an IMS Infrastructure, 6th IEEE Consumer Communications and Networking Conference (CCNC 2009), pp. 1-5, Las Vegas, USA. 9. Yarali A., Cherry A. (2005) Internet Protocol Television (IPTV), IEEE TENCON 2005, pp.1-6, Melbourne, Australia. Makale 13.12.2010 tarihinde alınmış, 14.04.2011 tarihinde düzeltilmiş, 28.04.2011 tarihinde kabul edilmiştir. İletişim Yazarı: S.E.Karlık (ekarlik@uludag.edu.tr). 94