SIP TABANLI KONFERANS S NYALLE ME S STEM ALTYAPISI GERÇEKLE T R M

EGE ÜN VERS TES FEN B L MLER ENST TÜSÜ (YÜKSEK L SANS TEZ ) SIP TABANLI KONFERANS S NYALLE ME S STEM ALTYAPISI GERÇEKLE T R M lker KUKÇU Bilgisayar Mühendisli i Anabilim Dal Bilim Dal Kodu: 619.01.00 Sunu Tarihi: 22.02.2008 Tez Dan man : Yrd. Doç. Dr. Aylin Kantarc Bornova- ZM R

III lker KUKÇU taraf ndan yüksek lisans tezi olarak sunulan SIP Tabanl Konferans Sinyalle me Sistemi Altyap s Gerçekle tirimi ba l kl bu çal ma E.Ü. Lisansüstü E itim ve Ö retim Yönetmeli i ile E.Ü. Fen Bilimleri Enstitüsü E itim ve Ö retim Yönergesi nin ilgili hükümleri uyar nca taraf m zdan de erlendirilerek savunmaya de er bulunmu ve 22/02/2008 tarihinde yap lan tez savunma s nav nda aday oybirli i/oyçoklu u ile ba ar l bulunmu tur. Jüri Üyeleri: mza Jüri Ba kan : Yrd. Doç. Dr. Aylin KANTARCI.. Raportör Üye : Prof. Dr. Levent TOKER... Üye : Yrd. Doç. Dr. Cengiz Güngör...

V ÖZET SIP TABANLI KONFERANS S NYALLE ME S STEM ALTYAPISI GERÇEKLE T R M KUKÇU, lker Yüksek Lisans Tezi, Bilgisayar Mühendisli i Bölümü Tez Yöneticisi: Yrd. Doç. Dr. Aylin Kantarc ubat 2008, 172 sayfa Bu tez çal mas nda, SIP (Session Initiation Protocol) protokolü kapsam nda, mesajla ma ak ve konferans yap s incelenmi ve örneklerle literatürde yer alan çal malar tart lm t r. Bu çal malar temel al narak SIP protokolü ile uygulama yazabilmek için gerekli olan SIP format ve mesajla ma ak ara t r lm t r. Tan mlanan konferans yap lar do rultusunda, a daki mesajla ma trafi ini azaltacak olan bir konferans topolojisi önerilmi tir. Bu tez kapsam nda Köprü (Bridge) ve Uçnokta (Endpoint) modelleri birle tirilerek, yeni bir konferans mimarisi olu turulmu tur. Ayr ca yeni konferans yap s topolojosini olu turabilen ve olu an topoloji do rultusunda metin bazl mesajla may sa layan uygulama geli tirilmi tir. Anahtar Sözcükler: SIP ve Konferans Yap s, Internet Konferans Yap s, SIP ile Geli tirilmi Konferans Uygulamas, SIP Tabanl Konferans Sinyalle me Sistemi Altyap s.

VII ABSTRACT IMPLEMENTATION OF A CONFERENCE SIGNALLING FRAMEWORK BASED ON SIP PROTOCOL KUKÇU, lker MSc in Computer Engineering Supervisor: Yrd. Doç. Dr. Aylin KANTARCI February 2008, 172 pages In this thesis, SIP (Session Initiation Protocol) protocol and the transactions between the SIP users and the conference architecture are studied. The requirements for writing SIP applications are examined by discussing the related work in the literature. Based on this survey, the SIP messaging format and SIP message types are defined. For application development according to the survey of conference architecture, a new conference topology that reduces messaging traffic is proposed. In this thesis, Bridge and Endpoint conferencing models have been combined to form a new conferencing architecture. Additionaly, an application for instant messaging that can create the proposed topology and provides exchanging text based messages over that topology is implemented. Keywords: Session Initiation Protocol, SIP and Conference Architecture, Internet Conference Architecture, A SIP Conference Application.

IX TE EKKÜR Bu çal mam süresince her türlü deste i sa layan çok de erli dan man m Say n Yrd. Doç. Dr. Aylin Kantarc ya te ekkürü bir borç bilirim. Çal mam s ras nda desteklerini hiç bir zaman esirgemeyen aileme te ekkür ederim.

XI Ç NDEK LER ÖZET... XI ABSTRACT... XI TE EKKÜR... XI Ç NDEK LER... XI EK LLER D Z N... XVI S MGELER VE KISALTMALAR... XXIII 1 G R... 1 2 INTERNET ÇOKLUORTAM KONFERANS ALTYAPISI... 3 2.1 Katmanl nternet Altyap s... 3 2.1.1 LET M KATMANI PROTOKOLLER... 4 2.1.2 Internet Üzerindeki Gerçek Zamanl Servisler... 6 2.1.3 Internet Çokluortam Konferans Altyap s... 8 2.2 Ço ayay m (Multicast)... 8 2.2.1 Birden Çok Al c n n Oldu u Sistemlerde Mesajlar n Yönlendirilmesi... 9 2.2.2 Ço ayay m Yönlendirmenin Avantajlar... 11 2.2.3 Ço ayay m Yönlendirme Protokolleri... 12 2.2.4 IGMP... 15 2.2.5 Mbone... 16 2.3 Gerçek Zamanl Veri letimi... 17 2.3.1 Jitter ve Paketlerin S ralanmas... 17 2.3.2 Gerçek Zamanl letim Kontrol Protokolü ( Real-Time Transport Control Protocol )... 19 2.4 Servis Sa lanmas : Bütünle ik (Integrated) ve Farkl la t r lm (Differentiated) Servisler... 20 2.4.1 Bütünle ik Servisler (Integrated Services)... 20 2.4.2 Farkl la t r lm Servisler (Differentiated Services)... 24

XII 2.5 Session Announcement Protocol (SAP)...25 2.5.1 Oturum Özellikleri...26 2.6 Session Description Protocol (SDP)...27 2.6.1 SDP Format...27 2.6.2 SDP Next Generation (SDPng)...31 2.7 Real-Time Streaming Protocol (RTSP)...31 2.8 Internet Çokluortam Konferans Sisteminin Çal mas...32 3 SESSION INITIATION PROTOCOL ( SIP )...33 3.1 TAR HÇE...33 3.1.1 Session Invitation Protocol : SIPv1...34 3.1.2 SCIP: Simple Conference Invitation Protocol...35 3.1.3 Session Initiation Protocol : SIPv2...35 3.2 SIP Taraf ndan Sunulan Fonksiyonlar...37 3.2.1 Oturum Ba lat lmas, De i iklik Yap lmas ve Sonland r lmas 37 3.2.2 Kullan c Yer De i kenli i...39 3.3 SIP Elemanlar...41 3.3.1 Kullan c Etmenleri...41 3.3.2 Tekrar Yönlendirme Sunucular (Redirect Servers)...43 3.3.3 Vekil Sunucu (Proxy Servers)...45 3.3.4 Kay tç lar (Registrars)...47 3.3.5 Konum Sunucular...47 3.4 SIP Protokolünün yi Özellikleri...49 3.4.1 SIP Protokolü IETF nin Standart d r...49 3.4.2 Oturumun Yarat lmas ile Oturumun Tan mlanmas n n Ayr Olmas 50 3.4.3 Son Sistemlerin Ak ll Olmas ve Uçlar Aras Bir Protokol Olmas 50 3.4.4 Birlikte Çal abilirlik...51 3.4.5 Ölçeklenebilirlik...51 3.4.6 SIP Çe itli Servislerin Yarat lmas na Olanak Sa layan Bir Platformdur...51 4 SIP:PROTOKOL OPERASYONU...56 4.1 stemci-sunucu Mesaj Ak...56 4.1.1 SIP Cevaplar...56 4.1.2 SIP stemleri...58

XIII 4.2 Vekil Sunucu Türleri... 67 4.2.1 Oturum Bazl Haf zal Vekil Sunucular (Call Stateful Proxy) 68 4.2.2 Haf zal Vekil Sunucular (Stateful Proxy)... 68 4.2.3 Haf zas z Vekil Sunucular (Stateless Proxy)... 70 4.2.4 Vekil Sunucular n Da t lmas... 70 4.3 SIP Mesajlar n n Format... 70 4.3.1 SIP stek Format... 72 4.3.2 SIP Cevap Mesaj Format... 73 4.3.3 SIP Mesaj Ba l klar... 75 4.3.4 SIP Veri Bölümü... 85 4.4 letim (Transport) Katman... 86 4.4.1 INVITE Mesajlar... 87 4.4.2 CANCEL Mesajlar... 93 4.4.3 Di er Mesajla ma Ak lar... 93 4.5 Örnek Bir Uygulama... 95 4.5.1 Vekil Sunucu Üzerinden SIP Aramas... 95 5 SIP SERV S ÖRNEKLER... 103 5.1 Me gulken Ça r Yönlendirme... 103 5.2 Arama Bekletme Uygulamas... 110 5.3 Konferans Uygulamas... 119 5.4 Otomatik Arama Ba latma... 126 5.5 Bilgisayar Üzerinden Arama Ba latma... 133 6 SIP VE KONFERANS YAPISI... 138 6.1 Konferans Yap s ndaki SIP Sinyalle me li kisi... 138 6.1.1 Merkezi Yakla m... 138 6.1.2 Karma k (Mesh) Yap Yakla m... 140 6.2 Konferans Yap s nda SIP Veri Da t m... 140 6.2.1 Köprü (Bridge) Yakla m... 140 6.2.2 Uç Nokta (Endpoint) Yakla m... 141 6.2.3 Karma k Yap (Mesh) Yakla m... 142 6.3 Sistemlerin Sinyalle me li kisi ve Veri Da t m Aç s ndan Kar la t r lmas... 142 6.3.1 Sinyalle me li kisi Aç s ndan Kar la t rma... 142 6.3.2 Veri Da t m Aç s ndan Kar la t rma... 143

XIV 7 SIP PROTOKOLÜ LE GEL T R LM KONFERANS UYGULAMASI...144 7.1 Geli tirim Ortam ve Kullan lan Programlar...144 7.2 Program Aç klamas...144 7.3 Kullan lan Konferans Yakla m...146 7.4 Program çerisinde Kullan lan S n flar ve De i kenler...148 7.4.1 Sip.Java...148 7.4.2 Main.Java...148 7.4.3 Sender.Java...151 7.4.4 Thread_Array.java...151 7.5 Program çerisinden Ekran Görüntüleri...151 7.5.1 Kullan c n n Sisteme Kay t Olmas...151 7.5.2 Kullan c n n Ba ka Bir Kullan c ya Oturum Açmas...155 7.5.3 Konferans Grubu Yarat lmas...157 7.5.4 Mesaj Gönderilmesi...161 7.6 Ayn Soruna Getirilen Farkl Çözümler...163 8 SONUÇ...168 KAYNAKLAR D Z N...170 ÖZGEÇM...1

XVI EK LLER D Z N ekil Sayfa ekil 2.1 TCP/IP Protokol Kümesi Katmanlar 4 ekil 2.2 Katmanl Yap Üzerinde Servis Olu turulmas 4 ekil 2.3 IP Paketlerinin lgili Uygulamaya Gönderilmesi 6 ekil 2.4 Etkile im ( nteraktif) ve Ak t m (Streaming) Gerçek Zamanl Uygulamalar 7 ekil 2.5 nternet Çokluortam Konferans Altyap s 8 ekil 2.6 Bireyay m (Unicast) Yönlendirme 9 ekil 2.7 Kullan c lara Mesajlar n Bireyay m (Unicast) Yöntem ile Gönderilmesi 10 ekil 2.8 Ço ayay m (Multicast) Yönlendirme 11 ekil 2.9 131.160.1.112 Göndericisi çin Olu turulan A aç Yap s 13 ekil 2.10 138.85.27.10 Göndericisi çin Olu turulan A aç Yap s 13 ekil 2.11 153.88.251.19 Göndericisi çin Olu turulan A aç Yap s 14 ekil 2.12 Da t m A aç Yap s 14 ekil 2.13 Kullan lan Ortak A aç Yap s ve Ortak Da t m Noktas 15 ekil 2.14 IGMP Protokolü 16 ekil 2.15 Ses letiminde Jitter Etkisi 18 ekil 2.16 Yönlendiricilerdeki Paket Filtreleri 21 ekil 2.17 Gönderici Olan 131.160.1.112 Kullan c s çin Da t m A ac 22 ekil 2.18 138.85.27.10 Kullan c s çin Servis Kalitesi (QoS) Sa lanmas 22 ekil 2.19 153.88.251.19 Kullan c s n n Yapt Servis Kalitesi (QoS) Talebi 23 ekil 2.20 RSVP Mesaj Ak 24 ekil 2.21 Farkl la t r lm Servis (DiffServ) ve RSVP Protokollerinin Beraber Çal mas 25 ekil 2.22 SAP Oturum Özelliklerinin Kullan c lar Aras nda Da t lmas 26 ekil 2.23 SDP Türleri 30 ekil 2.24 RTSP Protokolü le Çokluortam Sunucular n Yönetilmesi 32 ekil 3.1 SIP Protokolü ile Ki ilerin Oturuma Kat lmas 34 ekil 3.2 SIPv2 Protokolü 36

XVII ekil 3.3 SIP Temel Özellikleri ve laveleri 37 ekil 3.4 Oturum Kurulmas 38 ekil 3.5 Ses Oturumunun Kurulmas 39 ekil 3.6 Sunucuya Kay t Olmak 40 eki 3.7 SIP Vekil Sunucu 41 ekil 3.8 SIP Tekrar Yönlendirme (Redirect) Sunucusu 42 ekil 3.9 SIP Kullan c Etmeni (User Agent) çeren Ayg tlar 43 ekil 3.10 ki Tekrar Yönlendirme Sunucusunun (Redirect Server) Birlikte Çal mas 45 ekil 3.11 ki Vekil Sunucu çeren Senaryo 46 ekil 3.12 Döngüsel Vekil Sunucu (Forking Proxy) ve Arama Yönlendirme 47 ekil 3.13 Kay tç (Registrar) Sunucuya Kay t Olmak 48 ekil 3.14 Kay tç (Registrar) Sunucu ve Konum Sunucu 48 ekil 3.15 Vekil Sunucu ve Konum Sunucu 49 ekil 3.16 SIP ve HTTP Protokolü Birle imi 52 ekil 3.17 SIP Kart ve SIP adresi 53 ekil 3.18 Ses Mesaj B rakmak ve E-mail Göndermek 54 ekil 4.1 SIP Cevap Mesaj S n flar 57 ekil 4.2 SIP Cevap Kodlar 58 ekil 4.3 SDP Mesaj Örne i 59 ekil 4.4 Oturum Kabul Mesaj Örne i 60 ekil 4.5 200 OK Mesaj ve Oturumun Kabul Edilmesi 61 ekil 4.6 3 Yönlü leti im ( INVITE - 200 OK - ACK ) 62 ekil 4.7 2 Yönlü Bir leti im Olsayd? 63 ekil 4.8 CANCEL Mesaj 64 ekil 4.9 Vekil Sunucu ve CANCEL Mesaj 65 ekil 4.10 BYE Mesaj 66 ekil 4.11 REGISTER Mesaj 66 ekil 4.12 OPTIONS Mesaj 67 ekil 4.13 Haf zal Vekil Sunucu (Stateful Proxy) 68 ekil 4.14 Haf zal Döngüsel Vekil Sunucu (Stateful Forking Proxy) 69

XVIII ekil 4.15 A n ç K sm ve Haf zas z (Stateless) Sunucular 71 ekil 4.16 SIP stek Format Bölümleri 72 ekil 4.17 Request-URI Alan 73 ekil 4.18 Mesaj Cevap Format Bölümleri 73 ekil 4.19 SIP Protokolü ve Ara Mesajlar 74 ekil 4.20 SIP Mesaj Ba l klar 75 ekil 4.21 SIP Mesaj ve Call-ID Alan 76 ekil 4.22 Contact Ba l k Bilgisi ve Vekil Sunucu 77 ekil 4.23 SIP Mesaj ve Cseq Alan 79 ekil 4.24 Cseq Ba l k Mesaj ve Fonksiyon smi 80 ekil 4.25 Route Mesaj Ba l klar 81 ekil 4.26 Record-Route Mesaj Örne i 83 ekil 4.27 Mesaj Ba l ve To Alan 84 ekil 4.28 Via Ba l k Bilgisi 85 ekil 4.29 Farkl letim Katman Protokolleri 88 ekil 4.30 INVITE Mesajlar ve Tekrar letim 88 ekil 4.31 Ara Mesajlar n n letiminin Garanti Edilmemesi 89 ekil 4.32 ACK Mesaj Gelinceye Kadar Mesajlar n Tekrar letilmesi 90 ekil 4.33 Döngüsel Vekil Sunucu (Forking Proxy) ve 404 Not Found Mesaj 91 ekil 4.34 Ba ar l Sonuç Mesajlar n n letiminin Garanti Edilmesi 92 ekil 4.35 Oturumun Kurulma Mesajla mas 92 ekil 4.36 CANCEL Mesaj ve Mesaj Ak 93 ekil 4.37 Güvenilir letim Katman 94 ekil 4.38 Ara Mesajlar ve Tekrar letim Mekanizmas 95 ekil 4.39 SIP Vekil Sunucu Üzerinden SIP Aramas 96 ekil 5.1 Me gulken Ça r Yönlendirmede Mesaj Ak 103 ekil 5.2 Me gulken Ça r Yönlendirme- INVITE Mesaj 104 ekil 5.3 Me gulken Ça r Yönlendirme- Busy Mesaj 105 ekil 5.4 Me gulken Ça r Yönlendirme- ACK Mesaj 105 ekil 5.5 Me gulken Ça r Yönlendirme- Forward Mesaj 106

XIX ekil 5.6 Me gulken Ça r Yönlendirme- Ringing Mesaj 107 ekil 5.7 Me gulken Ça r Yönlendirme- OK Mesaj 108 ekil 5.8 Me gulken Ça r Yönlendirme- ACK Mesaj 2 108 ekil 5.9 Me gulken Ça r Yönlendirme- BYE Mesaj 109 ekil 5.10 Me gulken Ça r Yönlendirme- 200 OK Mesaj 110 ekil 5.11 Me gulken Arama Bekletme Uygulamas Mesaj Ak 111 ekil 5.12 Me gulken Arama Bekletme- INVITE Mesaj 111 ekil 5.13 Me gulken Arama Bekletme- Ringing Mesaj 112 ekil 5.14 Me gulken Arama Bekletme- OK Mesaj 112 ekil 5.15 Me gulken Arama Bekletme- ACK Mesaj 113 ekil 5.16 Me gulken Arama Bekletme- INVITE Mesaj-2 113 ekil 5.17 Me gulken Arama Bekletme- 200 OK Mesaj -2 114 ekil 5.18 Me gulken Arama Bekletme- INVITE Mesaj -3 114 ekil 5.19 Me gulken Arama Bekletme- 200 OK Mesaj -3 115 ekil 5.20 Me gulken Arama Bekletme- ACK Mesaj -2 115 ekil 5.21 Me gulken Arama Bekletme- ACK Mesaj -3 116 ekil 5.22 Me gulken Arama Bekletme- BYE Mesaj 116 ekil 5.23 Me gulken Arama Bekletme- 200 OK Mesaj -4 117 ekil 5.24 Me gulken Arama Bekletme- INVITE Mesaj -4 117 ekil 5.25 Me gulken Arama Bekletme- 200 OK Mesaj -5 118 ekil 5.26 Me gulken Arama Bekletme- ACK Mesaj -4 118 ekil 5.27 Konferans Uygulamas Mesaj Ak 119 ekil 5.28 Konferans Uygulamas INVITE Mesaj 120 ekil 5.29 Konferans Uygulamas Ringing Mesaj 120 ekil 5.30 Konferans Uygulamas 200 OK Mesaj 121 ekil 5.31 Konferans Uygulamas ACK Mesaj 122 ekil 5.32 Konferans Uygulamas INVITE Mesaj -2 122 ekil 5.33 Konferans Uygulamas 200 OK Mesaj -2 123 ekil 5.34 Konferans Uygulamas ACK Mesaj -2 123 ekil 5.35 Konferans Uygulamas INVITE Mesaj -3 124

XX ekil 5.36 Konferans Uygulamas Ringing Mesaj -3 125 ekil 5.37 Konferans Uygulamas 200 OK Mesaj -3 125 ekil 5.38 Konferans Uygulamas ACK Mesaj -3 126 ekil 5.39 Otomatik Arama Ba latma Uygulamas 127 ekil 5.40 Otomatik Arama Ba latma- INVITE Mesaj 127 ekil 5.41 Otomatik Arama Ba latma- Busy Mesaj 128 ekil 5.42 Otomatik Arama Ba latma- ACK Mesaj 128 ekil 5.43 Otomatik Arama Ba latma- SUBSCRIBE Mesaj 129 ekil 5.44 Otomatik Arama Ba latma- 200 OK Mesaj 129 ekil 5.45 Otomatik Arama Ba latma- NOTIFY Mesaj 130 ekil 5.46 Otomatik Arama Ba latma- 200 OK Mesaj -2 130 ekil 5.47 Otomatik Arama Ba latma- INVITE Mesaj -2 131 ekil 5.48 Otomatik Arama Ba latma- Ringing Mesaj 131 ekil 5.50 Otomatik Arama Ba latma- ACK Mesaj -2 132 ekil 5.51 Bilgisayar Üzerinden Arama Ba latma Uygulamas 133 ekil 5.52 Bilgisayar Üzerinden Arama Ba latma- REFER Mesaj 134 ekil 5.53 Bilgisayar Üzerinden Arama Ba latma- Accepted Mesaj 134 ekil 5.54 Bilgisayar Üzerinden Arama Ba latma- Notify Mesaj 135 ekil 5.55 Bilgisayar Üzerinden Arama Ba latma- 200 OK Mesaj 135 ekil 5.56 Bilgisayar Üzerinden Arama Ba latma- INVITE Mesaj 136 ekil 5.57 Bilgisayar Üzerinden Arama Ba latma- Ringing Mesaj 136 ekil 5.58 Bilgisayar Üzerinden Arama Ba latma- 200 OK Mesaj -2 137 ekil 5.59 Bilgisayar Üzerinden Arama Ba latma- ACK Mesaj 137 ekil 6.1 Köprü (Bridge) Yakla m 139 ekil 6.2 Uç Nokta (Endpoint) Yakla m 139 ekil 6.3 Karma k Yap (Mesh) Yakla m 140 ekil 6.4 Veri Da t m nda Köprü (Bridge) Yap s 141 ekil 6.5 Veri Da t m nda Uç Nokta (Endpoint) Yakla m 141 ekil 6.6 Veri Da t m nda Karma k (Mesh) Yap 142 ekil 7.1 Kullan lan Konferans Yap s 146

XXI ekil 7.2 Kullan c n n Sisteme Kay t Olmas 152 ekil 7.3 Vekil Sunucu (Proxy) Adresi Belirleme Formu 152 ekil 7.4 Kullan c Bilgileri Girme Formu 153 ekil 7.5 Kay t (Register) Kabul Formu 154 ekil 7.6 Ana Menü Formu 154 ekil 7.7 Ana Menü Formu ve Arkada lar m Formu 155 ekil 7.8 Arkada lar m Menüsü Formu 156 ekil 7.9 SIP Oturumu Açma Ekran 156 ekil 7.10 SIP Oturum Kabul Ekran 157 ekil 7.11 Gruplar m Menüsü Ekran 158 ekil 7.12 Grup Ekleme lemi 158 ekil 7.13 Konferans Grubu Olu turma Kabul Formu 159 ekil 7.14 Konferansa Ki i Ekleme lemi 160 ekil 7.15 Konferansa Ki i Ekleme Kabul Formu 160 ekil 7.16 Mesaj Gönderme lemi 161 ekil 7.17 Mesajlar m Ekran 162 ekil 7.18 Mesaj Gönderme Kabul Formu 162 ekil 7.19 Mesaj Görüntüleme Formu 163 ekil 7.20 Microsoft Office Communicator ve Windows Messenger Yakla m 164 ekil 7.21 Click to Meet Uygulamas Yakla m 165 ekil 7.22 Empatiq leti im Teknolojileri Konferans Yakla m 166 ekil 7.23 GSM de Konferans Uygulamas 166

XXII

XXIII S MGELER VE KISALTMALAR K saltmalar BGMP Border Gateway Multicast Protocol CBT Core Based Trees CCP Connection Control Protocol Diffserv Differentiated Services DVMRP Distance Vector Multicast Routing GSM Global System for Mobile Communications HTTP Hypertext Transfer Protocol IETF Internet Engineering Task Force IGMP Internet Group Management Protocol IMAP Internet Message Access Protocol IMS Internet Multimedia Subsystem IP Internet Protocol ITU-T International Telecommunication Union Telecommunication Standardization Sector IVS INRIA Video Konferans LDAP Lightweight Directory Access Protocol MGCP Media Gateway Control Protocol MIME Multipurpose Internet Extensions MMCC Multimedia Conference Control MMUSIC Multiparty Multimedia Session Control OSI Open Systems Interconnection PCM Pulse Code Manipulation PIM-DM Protocol Independent Multicast-Dense Mode PIM-SM Protocol Independent Multicast-Sparse Mode QoS Quality of Service RFC Request For Comments

XXIV RSVP RTCP RTSP RTP SAP SCIP SCTP SDP SDPng SIP SMTP TCP UDP URL Reservation Protocol Real-time Transport Control Protocol Real-time Streaming Protocol Real-time Transport Protocol Session Announcement Protocol Simple Conference Invitation Protocol Stream Control Transmission Protocol Session Description Protocol Session Description Protocol Next Generation Session Initiation Protocol Simple Mail Transfer Protocol Transmission Control Protocol User Datagram Protocol Uniform Resource Locators

XXV

1 1 G R Günümüzde internetin geli imi ile birlikte internet kullan c say s ndaki art, internet çokluortam servislerinin geli tirilmesinde art a neden olmu tur. Mobil sistemlerdeki veri ve internet kullan m n n art ve 3G mobil sistemlerin geli imi, internet ile cep telefonlar n n birbirlerine yak nla mas n sa lam t r. 3G sistemlerinin IP çokluortam servisleri için ihtiyaç duydu u protokol gereksinimi, çok zaman önce geli tirilmi olan SIP (Session Initiation Protocol) protokolünün yeniden do mas na neden olmu tur. Geli tiricilerin ve kullan c lar n SIP protokolüne olan ilgisi 3G sistemleri ile birlikte artm t r. SIP protokol yap s, katmanl OSI (Open Systems Interconnection) yap s n ve tekrar kullan labilirli i desteklemesi nedeniyle ve basit ve okunabilir mesajla ma format sayesinde, k sa zamanda program geli tiricilerin ilgisini çekmi tir. Bu protokol sayesinde program geli tiriciler servis hakk nda uzman bilgiye sahip olarak, kolayl kla servisler geli tirebilmi lerdir. SIP protokolünün basit bir protokol olmas nedeniyle, protokol hakk nda detayl teknik bilgi k sa zamanda kolayl kla sa lanabilmi tir. SIP protokolünün geli imi ve yayg nla mas ile birlikte, bu protokol internet çokluortam uygulamalar nda yerini alm t r. SIP protokolü ile birlikte, kolay ve basit SIP konferans yap lar k sa zamanda internet dünyas nda yer bulmu tur. SIP protokolünün gezingenli i (mobility) desteklemesi sonucu, kullan c lar konumdan ba ms z servisler yaratabilmi tir. Ayr ca SIP protokolü ile birlikte cep telefonlar ve internet dünyas ndaki bilgisayarlar tek bir çat alt nda, ayn dili konu abilir düzeye gelmi lerdir. Daha önceden iki farkl ortam olan internet ve cep telefonu dünyas, SIP protokolü ortak dilini kullanarak tek bir çat alt nda toplanm t r. Bu tezde, literatürde SIP protokolü yap s ile birlikte internet konferans yap s üzerine yap lan çal malar incelenmi tir. Bu çal malar

2 nda SIP protokolü ile bant geni li inde etkin kullan m sa layan bir konferans yap s olu turulmu tur. 2. bölümünde, internet çokluortam konferans yap s incelenmi tir. Bu bölümde anlat lan çokluortam konferans yap s kavramlar ve tan mlar, SIP protokolünün konferans yap s ndaki yerinin anla lmas için gerekli olan temel bilgileri içermektedir 3. bölümde, SIP protokolünün geli imi ve SIP protokolünün kullan m n n sa lad yararlar incelenmi tir. Ayr ca SIP protokolü elemanlar da bu bölüm içerisinde incelenmi tir. SIP protokolünün sa lad yararlar n incelenmesi sonucu di er protokoller ile kar la t r lmas sa lanm t r. 4. bölümde, SIP protokolünün operasyonel özelliklerinden bahsedilmi tir. SIP mesaj formatlar, SIP mesaj türleri, SIP mesaj ak lar bu bölümde ayr nt l olarak incelenmi tir. Bir SIP uygulamas n n mesajla ma ak n n incelenmesi ile SIP protokolü daha iyi anla labilmi tir. 5. bölümde, günlük ya ant m zda kullan lan SIP servis örneklerinden bahsedilmi tir. SIP servis örneklerinin tüm mesaj ak ayr nt l olarak anlat larak, SIP protokolünün çal ma prensibinin daha iyi anla lmas amaçlanm t r. 6. bölümde, SIP ve konferans yap s incelenmi tir. Farkl konferans yap lar sinyalle me ili kisi ve veri da t m aç s ndan birbirleri ile kar la t rmal olarak anlat lm t r. Farkl konferans topolojilerinin sa lad yararlar ve zararlar daha ayr nt l anlat lm t r. 7. bölümde, yeni geli tirilen SIP konferans uygulamas program hakk nda bilgi verilmi tir. Program içerisinde kullan lan tan mlamalar ayr nt l olarak aç klanm t r. Ayr ca program n ekran görüntüleri bu bölümde verilerek, program n kullan m n n anla lmas kolayla t r lm t r. 8. bölümde, tez çal mas n n sonuçlar belirtilmi tir.

2 INTERNET ÇOKLUORTAM KONFERANS ALTYAPISI 3 Internet çokluortam konferans altyap s internet protokollerinin, internet üzerinde çokluortam servisi sa layabilmesi amac yla biraraya gelmesiyle olu ur. SIP protokolü de bu altyap n n bir parças d r. SIP protokolü ile di er protokollerin etkile imi sonras fonksiyonel özellikleri payla labilmi tir. SIP protokolü Internet çokluortam konferans elemanlar kümesinin önemli bir eleman d r (Carpenter, 1996). 2.1 Katmanl nternet Altyap s Internet protokolünün en önemli özelli i, servis yaratmak için kullan lan bir protokol olmas d r. IETF (Internet Engineering Task Force) grubu bu amaçla katmanl internet yap s n tercih etmi tir. ekil 2.1 de gösterildi i gibi, katmanl internet yap s fiziksel katman üzerine kurulan 4 katmandan olu maktad r. Bu katmanl yap, TCP/IP protokolü ad ile bilinmektedir (Carpenter, 1996). letim katman, IP katman n n üzerine yerle tirilmi tir ve uygulama katman elemanlar farkl iletim katman protokolleri ile çal abilmektedir (Carpenter, 1996). Örnek olarak Web taray c uygulamas internet üzerinde dola mak için ve e-mail lar n okunmas için kullan l r. nternet içerisinde dola mak için HTTP (Hypertext Transfer Protocol) [RFC 2068] protokolü kullan l rken, sunucu üzerinden e-mail indirmek için IMAP (Internet Message Access Protocol) [RFC 2060] protokolü kullan l r. ekil 2.2 de gösterildi i gibi, her iki protokolde TCP (Transmission Control Protocol) [RFC 793] protokolü üzerinde çal maktad r (Carpenter, 1996).

4 Uygulama Katman letim Katman A Katman Veri Ba lant Katman Fiziksel Katman ekil 2.1 TCP/IP Protokol Kümesi Katmanlar ekil 2.2 Katmanl Yap Üzerinde Servis Olu turulmas 2.1.1 LET M KATMANI PROTOKOLLER Uygulamalar servis verebilmeleri için bir uygulama protokolünü kullanmaktad rlar. Uygulama katman protokolleri de iletim katman üzerinde çal maktad rlar. letim katman protokolleri de IP katman üzerinde çal maktad r. letim katman protokolleri olarak genellikle TCP [RFC 793] ve UDP (User Datagram Protocol) [RFC 768] protokolleri kullan l r. SCTP

(Stream Control Transmission Protocol) protokolü de günümüzde kullan lmaya ba lam t r (Carpenter, 1996). a) Transmission Control Protocol (TCP) TCP protokolü, kullan c lar aras mesajlar n güvenilir ve s ral bir ekilde iletilmesini sa lar. Mesajlar n üretilen s rada al c ya ula mas için zamanlama, tekrar iletim ve mesaj s ra numaras mekanizmalar kullan lmaktad r. TCP protokolü ayr ca ak kontrolü ve hata düzeltimi mekanizmalar n da içerir (Postel, 1981). Örnek olarak lker Ayça ya Nas ls n? mesaj n TCP ba lant s üzerinden gönderirse, TCP protokolü mesaj n do ru formatta Ayça ya ula mas n sa lar. TCP protokolü uç noktalar aras protokol oldu u için, mesaj n en son nokta taraf ndan do ru formatta al nd n bilmek ister. Al c taraf geriye mesaj al nd bilgisini gönderir ve gönderici taraf da gelen al nd mesaj n n içeri inden ak kontrolünü ve hata düzeltimini yapabilir (Postel, 1981). TCP protokolü, gelen IP paketlerini farkl uygulamalar aras nda da tabilir. ekil 2.3 de gösterildi i gibi, gelen paketlerin hepsi ayn oldu undan dolay mesajlar uygulamalar aras nda da tabilmek için farkl bir alan gerekmektedir. Bu alan TCP port numaras d r ve her uygulama için ayr bir TCP port numaras kullan l r. Örnek olarak al c TCP port numaras 80 ise, gelen mesaj HTTP uygulamas na gönderilir. Gelen mesaj n TCP port numaras 23 ise, gelen mesaj telnet uygulamas na yönlendirilir (Postel, 1981). b) User Datagram Protocol (UDP) UDP protokolü [RFC 768] güvenilir olmayan veri iletimi sa lar ve verinin al c sistem taraf ndan al nd n garanti etmez. UDP protokolü gelen paketin hangi uygulamaya gönderilece ini UDP port numaralar ile belirler. UDP ve TCP protokolleri 16 bitlik port numaralar n kullan r. UDP protokolünde al c taraf gelen mesaj n hangi uygulamaya gönderilece ini belirledikten sonra hata kontrolü yaparak, mesaj n kar tarafa do ru ula p ula mad n belirler (Postel, 1980). 5

6 Örnek olarak lker Ayça ya UDP protokolü ile bir mesaj gönderirse, mesaj n Ayça ya ula t n bilemez. Bir UDP paketi yolda kaybolur ise, ayn paketi lker in tekrar göndermesi gerekmektedir. UDP protokolü tekrar iletimi gerçekle tirmez (Postel, 1980). ekil 2.3 IP Paketlerinin lgili Uygulamaya Gönderilmesi 2.1.2 Internet Üzerindeki Gerçek Zamanl Servisler Kullan c servisleri uygulama katman protokolleri kullan larak geli tirilirler. En çok kullan lan iki Internet servisi web ve e-mail servisleridir. Web uygulamalar HTTP uygulama katman protokolünü kullan r, e-mail uygulamalar ise SMTP (Simple Mail Transport Protocol) [RFC 821] ve IMAP (Internet Message Access Protocol) [RFC 2060] protokollerini kullan r (Schulzrinne et al., 1996). Bütün bu servisler internet in geli imine katk da bulunmu tur. nternet geli en zamanda senkron ve asenkron servisler geli tirilmek için kullan lm t r. nternet üzerinden video konferans ve IP üzerinden canl yay n uygulamalar, gerçek zamanl servislere örnek olarak gösterilebilir. Gerçek zamanl uygulamalar zamana duyarl d r. Gerçek zamanl uygulamalar n verisi, al c tarafa belirlenen zaman diliminde iletilmelidir. E er mesaj kar tarafa kabul edilebilir zaman diliminden daha fazla sürede iletilirse, uygulaman n kalite de eri dü er (Schulzrinne et al., 1996).

ekil 2.4 de gösterildi i gibi, gerçek zamanl servisleri, ak t m (streaming) ve etkile imli (interaktif) servisler olarak iki kategoride inceleyebiliriz. Ak t m servisleri, etkile imli servislerden daha az gereksinime ihtiyaç duyar (Schulzrinne et al., 1996). 7 ekil 2.4 Etkile im ( nteraktif) ve Ak t m (Streaming) Gerçek Zamanl Uygulamalar Ak t m servislerine örnek olarak internet üzerinden iletilen futbol maç dü ünülebilir. Sesin olmad zamanlardaki gecikmeler ve gecikmenin kabul edilebilece i büyüklükteki resimlerin iletiminde meydana gelen gecikmeler kabul edilebilirdir. Ayr ca kullan c lar maç içerisinde gol at ld ktan 1 veya 2 saniye sonra golü ekranlar nda görmek ister (Schulzrinne et al., 1996). Etkile imli servisler di er servislere gore daha fazla gereksinime ihtiyaç duyarlar. nternet üzerinde yap lan bir ses konferans nda gecikmenin çok az olmas gerekmektedir. Aksi takdirde kaliteli bir

8 konu ma yap lamaz. Etkile imli servisler için maksimum kabul edilebilir gecikme zaman birçok faktöre ba l d r, ama genel olarak ak t m servislerinden daha k sa bir süredir. ITU-T(International Telecommunication Union Telecommunication Standardization Sector) taraf ndan belirlenen kritere gore, ses konferans için maksimum kabul edilebilir gecikme zaman 300 ms dir (Schulzrinne et al., 1996). 2.1.3 Internet Çokluortam Konferans Altyap s Gerçek zamanl servisler birden çok veri türü içerir. Örnek olarak video konferans uygulamalar video ve ses veri türlerini içerir. IETF grubu taraf ndan çokluortam servisleri için birçok protokol yarat lm t r. Çokluortam uygulamalar bu protokollerden kendileri için en kullan l olanlar gruplayarak kullan rlar. SIP protokolü de internet çokluortam konferans yap s n n bir eleman d r. ekil 2.5 de internet çokluortam konferans altyap s gösterilmi tir (Handley et al., 1996). Uygulama Katman letim Katman A Katman ekil 2.5 nternet Çokluortam Konferans Altyap s 2.2 Ço ayay m (Multicast) Ço ayay m (multicast) internet protokolü mesajlar n en h zl ve en iyi ekilde kullan c lar aras nda iletilmesini sa lar. Bir IP paketi, IP adresi

içerir ve a üzerindeki yönlendiriciler mesajlar bu IP adresine göre yönlendirir. IP adresi a üzerindeki elemanlar niteleyen bir adrestir. Bu mekanizma a üzerinde iki kullan c n n mesaj iletimine izin verir ve bu iki sistem gönderici ve al c olarak isimlendirilir. Bu mekanizmada al c taraf gönderici taraf n IP adresini paket içerisinden al p, cevap mesaj gönderebilir. ekil 2.6 da gösterildi i gibi, bir al c ve bir göndericiden olu an ileti ime bireyay m (unicast) ileti im denir (Handley et al., 1996). 9 ekil 2.6 Bireyay m (Unicast) Yönlendirme 2.2.1 Birden Çok Al c n n Oldu u Sistemlerde Mesajlar n Yönlendirilmesi Basit bir senaryo olan bireyay m (unicast) ileti im senaryosu, birden çok kullan c mesajla mak istedi inde karma kla r. Bir IP paketini N kullan c l k bir konferans sisteminde tüm kullan c lara göndermek için, N-1 IP paketi haz rlan p gönderilir. Her IP paketi içerisinde al c n n kendi IP adresi vard r. (Handley et al., 1996)

10 Bu tür bir sistem çok kullan c l bir sistem için elveri li de ildir. Sistem içerisindeki kullan c say s artt kça, a içerisindeki mesaj trafi i giderek artar. Çok kullan c l bir sistemde N-1 adet mesaj ayn içerik ile gönderilir. Gönderilen mesajlar n sadece al c adresleri de i iktir. Bu mesajlar n birço u ayn noktalara u rarlar ve ayn içeri e sahip birden çok mesaj ayn yönlendiriciler üzerinden geçer (Handley et al., 1996). ekil 2.7 Kullan c lara Mesajlar n Bireyay m (Unicast) Yöntem ile Gönderilmesi ekil 2.7 de 131.160.1.112 adresinden 138.85.27.10 adresine gönderilen paketler ile 131.160.1.112 adresinden 153.88.251.19 adresine gönderilen mesajlar ayn yolu izleyerek R isimli yönlendiriciye u rar. Bu nedenden dolay 131.160.1.12 adresi ile R yönlendiricisi aras ndaki hatlar iki kat yüklenir. Ço ayay m (multicast) yönlendirme methodu yukar daki tür bir yüklenme problemini, kullan c lar gruplayarak çözer. Bu durumda yönlendiriciler gelen paketleri ço ayay m adreslerine yönlendirir.

Ço ayay m adresi, mesajlar alacak olan bir grup kullan c y simgeleyen bir grup adresidir. Bir kullan c bir grubun ço ayay m adresine mesaj gönderebilir, fakat sadece o grubun üyesi olan ki iler gelen paketleri alabilirler. IPv4 yap s nda 224.0.0.0 ile 239.255.255.255 aras ndaki IP adresleri, ço ayay m adresleri olarak ayr lm t r (Handley et al., 1996). 11 2.2.2 Ço ayay m Yönlendirmenin Avantajlar Ço ayay m (multicast) yönlendirme ölçeklenebilirdir çünkü her hat üzerinden birkez geçilir. Ço ayay m yönlendiriciler IP paketlerini sadece gerekli ise ço ullarlar (Handley et al., 1996). ekil 2.8 Ço ayay m (Multicast) Yönlendirme ekil 2.8 de ço ayay m yönlendirmenin kullan ld senaryo gösterilmektedir. 131.160.1.112 adresinden 138.85.27.10 adresine gönderilen mesajlar ile 131.160.1.112 adresinden 153.88.251.19 adresine gönderilen mesajlar ço ayay m yönlendirme ile gönderilmi tir.

12 131.160.1.112 adresi ile R yönlendiricisi aras ndaki hatlar sadece bir kez yüklenmi tir. R yönlendiricisi kendisine gelen mesaj ço ullayarak 138.85.27.10 ve 153.88.251.19 adreslerine gönderir. ekil 2.8 deki örnek iki önemli avantaj göstermektedir; 131.160.1.112 adresinden R yönlendiricisine gönderilen mesajlar %50 daha az bant geni li i kullanm t r. Son sistemler mesaj gönderirken, grup içerisinde hangi ki ilerin oldu unu bilmelerine gerek kalmaz. Gönderici sistemler mesaj, grup içerisinde kimlerin oldu unu bilmeden ço ayay m adresine gönderirler. Sadece al c sistemlere ba l olan yönlendiriciler grup içerisindeki ki ilerden haberdard r. Ço ayay m gruplar ile ilgili bilgiler merkezi sistemlerde tutulmaz. Bütün bilgiler ço ayay m yönlendiriciler aras nda payla l r (Handley et al., 1996). Ço ayay m yönlendiriciler grup içerisindeki ki inin hangi arayüz üzerinden ula labilir oldu unu ö renir ve mesaj ilgili ki iye ilgili arayüz üzerinden gönderir (Handley et al., 1996). 2.2.3 Ço ayay m Yönlendirme Protokolleri Ço ayay m yönlendiriciler göndericiden al c ya do ru da t m a aç yap s n olu turabilmek için ço ayay m yönlendirme protokollerini kullan rlar. Bu protokoller iki kategoride incelenebilir; sparse mode ve dense mode. Bu iki method a aç yap s n olu turabilmek için farkl algoritmalar kullan r. Dense Mode Ço ayay m Yönlendirme Protokolleri Dense Mode ço ayay m yönlendirme protokolü, bir a içerisinde herkes ço ayay m gruba üye ise çok iyi çal r (Deering et al., 1988). Dense Mode ço ayay m yönlendirme protokolü, göndericiler için en k sa yol a aç yap s n olu turur. Bu nedenden dolay verinin nereden

geldi ine ba l olarak birden fazla da t m a aç yap s olu turulabilir. Bu a aç yap s na gönderici kaynakl a aç yap s da denilir. ekil 2.9, ekil 2.10 ve ekil 2.11 de 3 farkl gönderici için 3 farkl a aç yap s n n nas l olu tu u gösterilmi tir (Deering et al., 1988). Dense Mode ço ayay m yönlendirme protokollerine örnek olarak Distance Vector Multicast Routing (DVMRP)[RFC 1075] ve Protocol Independent Muiticast-Dense Mode (PIM-DM) protokolleri gösterilebilir (Deering et al., 1988). 13 ekil 2.9 131.160.1.112 Göndericisi çin Olu turulan A aç Yap s ekil 2.10 138.85.27.10 Göndericisi çin Olu turulan A aç Yap s

14 ekil 2.11 153.88.251.19 Göndericisi çin Olu turulan A aç Yap s Sparse Mode Ço ayay m Yönlendirme Protokolü Sparse Mode ço ayay m yönlendirme protokolleri, ço ayay ma kat lan al c lar n az say da bulundu u a lar için uygundur. Bu protokol genellikle ortak noktalar belirler ve ortak bir a aç yap s olu turur. Tüm göndericiler bu ortak a aç yap s üzerinden verilerini gönderir (Estrin et al., 1998). ekil 2.12 de da t m a ac n n olu turulmas gösterilmektedir. Bu a aç yap s nda ortak nokta gönderici olarak belirlenir ve di er bütün grup elemanlar al c olarak belirlenmi olur. ekil 2.13 de gösterildi i gibi, ortak a aç yap s olu turulduktan sonra grubun göndericileri taraf ndan olu turulan mesajlar ortak noktaya gönderilir, belirlenen ortak nokta da gelen mesaj a aç yap s na göre gönderir (Estrin et al., 1998). ekil 2.12 Da t m A aç Yap s

A aç yap s ndaki ortak nokta belirlendi inde bütün dü ümler bu nokta üzerinden mesaj gönderir. Bütün dü ümler bu a aç yap s üzerinden mesajlar göndermi olur. ekil 2.13 de 138.85.27.10 ve 153.88.251.10 adreslerine sahip olan sistemler için haz rlanm olan a aç yap s ve kullan lan ortak nokta gösterilmektedir. Sparse mode protokollere örnek olarak Protocol Independent Multicast Sparse Mode (PIM-SM) [RFC 2362] ve Core-Based Trees (CBTs) [RFC 2189] gösterilebilir (Estrin et al., 1998). 15 ekil 2.13 Kullan lan Ortak A aç Yap s ve Ortak Da t m Noktas 2.2.4 IGMP Bir kullan c ço ayay m gruptan mesaj alabilmek için, ço ayay m gruba üye olmal d r. Internet Group Management Protocol (IGMP) [RFC 2236] bu amaçla kullan lmaktad r. Kullanc lar gruba üye olmak ve gruptan ç kmak için mesaj gönderirler. Ço ayay m yönlendirici üye bilgisini kullanarak, bir kullan c n n ço ayay m veri isteyip istemedi ini ö renir. Bir a parçac içerisindeki kullan c lar ço ayay m gruba üye de ilse, bu a parçac da t m a ac na eklenmez. Bir a parçac içerisindeki kullan c ço ayay m gruba üye olmak istedi inde bu a parçac, tüm a a ba layan yönlendiriciler taraf ndan da t m a ac na eklenir (Fenner, 1997).

16 ekil 2.14 de IGMP protokolü gösterilmektedir. ekil 2.14 IGMP Protokolü 2.2.5 Mbone nternet in ço ayay m ileti imini destekleyen bölümüne Mbone denir. Mbone di er a lardan ayr lm bir a de ildir. Mbone yönlendiriciler nternet in bir parças d r ve hem bireyay m hem de ço ayay m trafikleri destekler. Birbirine ba l olmayan ço ayay m yönlendiriciler aras nda IP tünelleri olu turulur ve Mbone a a dahil edilir. SIP protokolleri ilk olarak Mbone a larda, kullan c lar ço ayay m oturumlara davet etmek için kullan lm t r (Thaler et al., 2000). IETF a lar aras yönlendirme protokollerinin geli imine sponsor olmu tur. Border Gateway Multicast Protocol bu protokollere örnek olarak gösterilebilir. BGMP protokolü kullan larak daha geni leyebilir ço ayay m yönlendirme trafikleri olu turulabilir (Thaler et al., 2000).

17 2.3 Gerçek Zamanl Veri letimi Farkl tür trafik, farkl sistem gereksinimlerine ihtiyaç duyar. Örnek olarak e-mail uygulamas nda gönderici taraf mail haz rlar ve gönderir. Gönderici bu durumda, sadece al c n n yaz lan do ru bir ekilde almas n ister ve mesaj n kar tarafa ula ma zaman ile ilgilenmez. E-mail uygulamalar nda verinin kar tarafa gecikmeli olarak iletilmesi kabul edilebilir fakat verinin kar tarafa zaman nda hatal bir ekilde iletilmesi kabul edilemez (Schulzrinne et al., 1996). Daha öncedeki bölümlerde de bahsedildi i gibi gerçek zamanl uygulamalar n farkl gereksinimleri vard r. Örnek olarak ses konferans n n internet üzerinden yap ld durumda, kar tarafa gecikmeli olarak ula an bir paket kabul edilemez (Schulzrinne et al., 1996). 2.3.1 Jitter ve Paketlerin S ralanmas Gerçek zamanl uygulamalar için önemli iki konu, Jitter ve paketlerin s ralanmas d r. IP a lar mesajlar n dola mas için belli bir gecikme belirtir. Gecikmenin arkas nda birçok faktör vard r. Örnek olarak i lemci yükü çok fazla olan bir yönlendiriciye gelen mesajlar kuyru a eklenecektir. E er kuyrukta bekleyen çok fazla paket var ise, meydana gelen gecikme fazla olacakt r (Schulzrinne et al., 1996). Bir yönlendiricinin durumu her zaman ayn olmad için, bir ak n bütün mesajlar farkl zamanlarda kar tarafa varabilir. Gecikme zamanlar ndaki de i ime Jitter denir. Jitter de eri yüksek ise, bir paket kendinden önce gelen bir paketten daha önce al c ya ula abilir (Schulzrinne et al., 1996).

18 ekil 2.15 Ses letiminde Jitter Etkisi Jitter de erini dü ürebilmek için Real-time Transport Protocol (RTP) [RFC 1889] geli tirilmi tir. RTP paketleri Jitter ve mesajlar n kar tarafa s ras z olarak varmas na önlem olarak, zaman etiketi ve mesaj ba l klar na s ra numaras verme mekanizmas n kullan r. RTP mesaj ba l ndaki mesaj numaras sayesinde al c taraf RTP paketlerini do ru s rada s ralayabilir. RTP pakatlerinin içerisindeki zaman etiketi de erleri de kullan larak, RTP paketlerinin al c taraf ndan ne zaman oynat lmaya ba lanmas gerekti i belirtilir. Payload Type alan ile RTP paketleri içerisinde ne tür veri ta nd anla l r, örnek olarak PCM (Pulse Code Manipulation) kodlama ile kodlam ses (Schulzrinne et al., 1996). RTP paketleri ayr ca RTP paketlerinin kim taraf ndan gönderildi ini içeren kaynak alan içerir. Örnek olarak sesin RTP paketleri ile gönderildi ini dü ünelim. Gönderici, içerisinde kodlanm ses verisini ta yan RTP paketini haz rlar. Al c taraf gelecek olan RTP paketlerini alabilmek için gerekli olan tampon bellek alan n ay r r. Gelen paketler s ra numaras na göre s ralan r. RTP paketleri üzerindeki zaman

etiketi alan na bakarak hangi paketin hangi zamanda çal naca belirlenir (Schulzrinneet al., 1996). Gelen RTP paketin içerisindeki zaman etiketi alan içerisindeki zaman, o anki zamandan daha önceyi i aret ediyor ise gelen RTP paketi yok edilir. Bu nedenden dolay al c taraf n tampon bellek alan yeteri kadar büyük olmal d r. Aksi takdirde gelen mesaj n içerisindeki zaman o anki zamandan eski bir zaman gösterir ve paketler yok edilir. Ayr ca tampon bellek alan çok da büyük olmamal d r, e er çok büyük olur ise mesajlar tampon bellek alan nda çok bekler ve yine gecikme ya an r (Schulzrinne et al., 1996). Bir ses paketi gelmesi gereken zamandan daha sonra geliyor ise arada ba ka sesler çal nabilir. Baz teknikler kullan larak gelmeyen paketler yerine ilave sesler çal nabilir ve mesajlar n eksik geldi i anla lmaz (Schulzrinne et al., 1996). 19 2.3.2 Gerçek Zamanl letim Kontrol Protokolü ( Real-Time Transport Control Protocol ) Bir önceki ekilde sadece ses veri iletimi yap lm t r. Zaman etiketi mekanizmas mesaj içerisinde birden fazla veri türü ta nd durumlarda da kullan l r. Ayn anda birden fazla veri türü iletilecek ise, bu mekanizma her veri türü için ayr ayr çal t r l r. Örnek olarak video konferans içerisindeki video zaman etiketi, videonun ne zaman oynat laca n belirler. Video konferans içerisindeki ses zaman etiketi ise, sesin hangi zamanda çal naca n belirtir. Ak lar n senkron çal mas için Real-time Transport Control Protocol (RTCP) [RFC 1889] mekanizmas kullan l r. Bu protokol zaman etiketi bilgisi ile gerçek zaman ili kilendirir (Schulzrinne et al., 1996). Her RTP oturumunun bir de RTCP oturumu vard r. RTCP protokolü medya senkronizasyonunun yan s ra, oturum içerisindeki kullan c lar n özelliklerini ve ileti imin kalitesini belirler. RTCP paketleri oturum s ras nda kaç adet paketin kayboldu unu ve al c n n veriyi alma kalitesinin ne oldu unu belirtir (Schulzrinne et al., 1996).

20 2.4 Servis Sa lanmas : Bütünle ik (Integrated) ve Farkl la t r lm (Differentiated) Servisler nternet modelinde a n içerisindeki trafik miktar dü ük iken bir çok uygulama en iyi çal r. Fakat a içerisindeki trafik yo unlu u artt kça uçtan uca servis kalitesi dü meye ba lar. Gecikme miktar ndaki art kalitenin dü mesine neden olur. IP paketleri yönlendiricinin i leyebilece inden daha h zl bir ekilde yönlendiriciye ula nca kuyruktaki veri miktar artar. Kuyruktaki veri miktar çok art nca yönlendirici paketleri yok etmeye ba lar. TCP trafi i için paketlerin yok olmas, tekar iletim mekanizmas n n çal mas n sa lar ve bu da dü ük performans ile birlikte kötü kalite (QoS) de erinin olu mas na neden olur. Gerçek zamanl uygulamalar n paketleri kaybolmaya ba lar ise mesajlar kar tarafa ula amayacakt r ve tekrar iletim olmayacakt r. Sa lanabilenden daha iyi servis kalitesi isteyen servisler için iki farkl mekanizma geli tirilmi tir. Bunlar bütünle ik servisler (integrated services) [RFC 1633] ve farkl la t r lm servisler (differentiated services) (Diffserv) [RFC 2475] dir. 2.4.1 Bütünle ik Servisler (Integrated Services) Bütünle ik servis (integrated services) mekanizmas, farkl ak lara ait paketlere yönlendiricilerde farkl davran sergiler. Örnek olarak gerçek zamanl bir uygulaman n verileri, dü ük öncelikli verilere göre öncelik sahibidir. Mesaj alan yönlendiriciler, mesaj n hangi ak a sahip oldu unu belirlemek ve mesaja hangi tür bir davran n gösterilece ini belirlemek için ek bilgiye ihtiyaç duyar (Braden et al., 1994). Yönlendirici belli bir IP adresi ve UDP portuna giden paketleri di er paketlere göre önceliklendirebilir. Yönlendiricinin farkl ak lar yürüttü ü durumda, paketleri filtreleyecek bir mekanizmaya ihtiyaç duyulur (Braden et al., 1994).

Sa lanan servisler Bütünle ik servis yap s iki tür servis sa lar. Bunlar kontrollü yük (controlled load) ve garantilenmi servislerdir (guaranteed services). Bu iki servis türü normalden daha iyi kalite sa layan servislere örnektir (Braden et al., 1994). 21 ekil 2.16 Yönlendiricilerdeki Paket Filtreleri Kontrollü yük servisler, en iyi çaba (best-effort) servislerden daha önceliklidir. Bu nedenden dolay e er a da yo unluk ya an yor ise, kontrollü yük servislerin paketleri en iyi çaba servislerin paketlerinden önce gönderilir. Fakat bu servis türünde belli bir bant geni li i de eri veya gecikme de eri garanti edilmez, sadece paketler di er paketlere göre önceliklendirilir (Braden et al., 1994). Garantilenmi servisler belli bir bant geni li i ve gecikme de eri garanti eder. Bu nedenden dolay garantilenmi servislerde Jitter de eri normalden daha azd r. Yönlendiriciler paketlere yüksek öncelik veremedi i için, yönlendiriciler kabul kontrol (admission control) ve kaynak rezarvasyon mekanizmalar na ihtiyaç duyar (Braden et al., 1994). Bir yönlendirici yeni bir ak iste i ald nda, istenilen kaynak miktar n n rezerve edilip edilemeyece ini kontrol eder. E er istenilen kalite de eri sa lanabiliyorsa istem kabul edilir (Braden et al., 1994).

22 Rezarvasyon Mekanizmas Ço ayay m gruplarda rezervasyon yap labilir. ekil 2.17 de 131.160.1.112 kullan c s gönderici durumundad r, 153.88.251.19 ve 131.160.1.112 adresli kullan c lar al c durumundad r. ekil 2.17 Gönderici Olan 131.160.1.112 Kullan c s çin Da t m A ac ekil 2.18 de 138.85.27.10 al c s, gelen ak lar için belli bir kalite de eri (QoS) istemektedir. Bu nedenden dolay yönlendiriciler önemli bilgileri kendi paket filtrelerinde saklarlar ve istenilen kalite (QoS) de erini sa lamaya çal rlar. ekil 2.18 138.85.27.10 Kullan c s çin Servis Kalitesi (QoS) Sa lanmas

153.88.251.19 kullan c s da kendi alaca ak için belli bir servis kalitesi de eri istemi tir. Fakat ikinci servis kalite istemi göndericiye kadar ula t r lmaz çünkü daha önceden ayn ak için yol üzerinde bir servis kalite istemi yap lm t r. Bu nedenden dolay 153.88.251.19 kullan c s servis kalite de erini istedi inde, yönlendiriciler üzerinde saklanan bilgilerden daha önce, bu ak için rezervasyon yap ld görülür. Daha önceden ayn ak için talep yap ld ndan dolay, yeni talep 153.88.251.19 kullan c s ile ana da t m a ac aras nda bir rezervasyon yap lmas n sa lar. 23 ekil 2.19 153.88.251.19 Kullan c s n n Yapt Servis Kalitesi (QoS) Talebi Rezervasyon Protokolü (Reservation Protocol (RSVP)) Rezervasyon protokolü (RSVP) [RFC 2205] a üzerinde kaynak rezervasyonu yap lmas için kullan l r. RSVP protokolü önemli bilgileri yönlendiriciler üzerinde tutar ve bu bilgileri periyodik olarak yeniler. Bir ak için yap lan rezervasyon talepleri al c taraf ndan gerçekle tirilir. Al c dan göndericiye gönderilen mesajlar RESV mesajlar olarak bilinir (Gerard Roca Mallofré). Al c dan göndericiye gönderilen mesajlar, göndericiden al c ya gönderilen mesajlar ile ayn yolu izlemez. Göndericiden al c ya gönderilen RSVP mesajlar kaynak rezervasyonuna göre gönderilir. PATH mesajlar, RESV mesajlar n n hangi yoldan geri gönderilece ini yönlendiriciler üzerinde belirler. ekil 2.20 de RSVP mesaj ak gösterilmi tir (Gerard Roca Mallofré).

24 ekil 2.20 RSVP Mesaj Ak A üzerinde de i iklik meydana geldi inde yönlendiriciler üzerindeki gereksiz bilgiler silinir. E er yönlendirme protokolü de i ikliklerine göre de i iklik farkedilir ise, yol yeniden olu turulur ve mesajlar yeni yoldan gönderilir. Periyodik olarak gönderilen PATH mesajlar yeni yolu belirler. Eski yol üzerindeki yönlendiriciler yeni PATH mesaj alamayaca için, RESV mesajlar n da almazlar. Bu nedenden dolay kullan lmayan bu yönlendiriciler üzerindeki eski bilgiler bir süre sonra silinir (Gerard Roca Mallofré). 2.4.2 Farkl la t r lm Servisler (Differentiated Services) RSVP mekanizmas ve bütünle ik servis (integrated service) yap s, yönlendiricilerde farkl ak lara farkl öncelik tan yordu. Gelen RSVP mesajlar na göre yönlendiriciler paketleri filtrelemektedir. Ak lar kar taraf n adresleri ve kar taraf n port numaralar ile tan mlanmaktad r. Bu nedenden dolay bu bilgiler ile yönlendiriciler üzerindeki bilgiler e le tirilir. Farkl la t r lm servis (DiffServ) [RFC 2475] mekanizmas, birden fazla servis s n f n birden fazla öncelik seviyesi ile ili kilendirir. Paketler a n en ucunda istenilen öncelik de erine göre i aretlenir. Yönlendiriciler bu alan inceleyerek paketi ilgili yoldan gönderir. Bu yakla m, noktadan noktaya yakla m ( Per-Hop- Behavior ) ad ile an l r (Blake et al., 1998).

Farkl la t r lm servis mekanizmas, bütünle ik servis mekanizmas na göre daha iyidir. Çünkü ak bazl mesaj yönlendirmesi yap lmaz. Farkl la t r lm servis mekanizmas da kabul kontrol (Admission Control) mekanizmas na ihtiyaç duyar. Çünkü a büyük öncelikli mesajlar n çoklu u durumunda yine kötü servis verebilir. RSVP protokolü kabul kontrol (admission control) mekanizmas olarak da kullan labilir. Bu nedenden dolay RSVP ve Diffserv protokolleri beraber kullan labilir (Blake et al., 1998). 25 ekil 2.21 Farkl la t r lm Servis (DiffServ) ve RSVP Protokollerinin Beraber Çal mas 2.5 Session Announcement Protocol (SAP) Televizyon üzerinden bir program seyretmek istedi imizde televizyon program n inceleyip, hangi yay nlar n hangi kanalda tümeyay m edildi ine bakar z. Hangi program seyretmek istedi imize karar verdi imizde, ilgili kanala geçeriz. Açt m z kanal üzerinde yay n tüm seyircilere iletilir. nternet ortam nda da benzer bir yöntem kullan l r. nternet üzerinde kat lmak istedi imiz en uygun oturumu seçeriz. Ayr ca ilgili oturum özelliklerini alabilece imiz programlar kullan r z. Örnek olarak kat laca m z oturumun ses veya video oturumu oldu unu bilmemiz gerekmektedir.

26 SAP (Session Announcement Protocol) [RFC 2974] protokolü ço ayay m oturumlar içerisindeki kullan c lara bilgileri da t r. SAP protokolü bu ço ayay m da t m i levini, belli bir ço ayay m adrese ve porta verileri göndererek yapar. Ço ayay m yöntem güvenilir bir yöntem olmad için, SAP protokolü gönderimleri de güvenilir de ildir. Ve mesajlar periyodik olarak tekrarlanmal d r (Handley et al., 2000). SAP mesajlar sabit bant geni li i de erine ihtiyaç duyar. Bu nedenden dolay bir kullan c di er bütün mesajlar ilgili ço ayay m adresini ve portunu dinleyerek alabilir. Gönderilen mesaj say s na ba l olarak SAP protokolü, oturum içerisindeki tekrar iletim h z n belirler. Oturum say s artt kça, tekrar iletim zamanlar aras ndaki fark artar (Handley et al., 2000). ekil 2.22 SAP Oturum Özelliklerinin Kullan c lar Aras nda Da t lmas SAP mesajlar ifrelenebilir ve baz mekanizmalar kullan larak güvenilirli i sa lanabilir. Kullan lan mekanizmalar sayesinde mesajlar n istenilmeyen ki ilere ula mas engellenebilir (Handley et al., 2000). 2.5.1 Oturum Özellikleri SAP protokolü oturum özelliklerini kullan c lara ço ayay m olarak da t r fakat oturum özelliklerinin format n belirlemez. IETF görü üne gore, birden çok protokol kullan larak SAP protokolünün oturum özellikleri formatlanabilir ve kar tarafa iletilebilir. Önerilen protocol SDP ( Session Description Protocol) [RFC 2327] protokolüdür. SAP protokolü bütün oturum özelliklerini iletir ama kar l kl kullan c lar bu

özellikler üzerinde anla amazlar. Bu nedenden dolay al c taraf oturum format n destekleyemiyorsa, oturum sonlan r. Al c taraf kendisinin destekledi i formatta verinin iletiminin gerçekle tirimini isteyemez (Handley et al., 2000). 27 2.6 Session Description Protocol (SDP) Session Description Protocol (SDP) [RFC 2327] oturum özelliklerinin nas l tan mlanaca n belirler. SDP protokolü herhangi bir aktar m mekanizmas veya kar l kl anla ma mekanizmas içermez. SDP özellikleri, bir sistemin bir oturuma kat labilmek için kulland veri grubudur. Örnek olarak bir SDP mesaj, IP adresinden, port numaras ndan ve zaman tan mlamalar ndan olu ur (Handley and Jacobson, 1998). Tekrar televizyon program örne ine dönersek, oturum özelli i Saat ak am 9 da 5. kanalda futbol maç var, Saat ak am 5 de 2.kanalda film var gibi aç klamalar içerir. SDP protokolü, ilgili yay n tümeyay m eklinde nas l ve saat kaçta alabilece imizi belirtir. lerleyen bölümlerde de görece imiz gibi, SIP protokolü oturumun özelliklerini tan mlayabilmek için SDP protokolünü kullan r. 2.6.1 SDP Format SDP mesajlar birçok SIP mesaj içerisinde gönderilir. SDP oturum mesajlar metin bazl mesajlard r. Bir SDP oturum özelli i a a daki formattaki birden fazla sat rdan olu ur (Handley and Jacobson, 1998). Tür=De er Tür alan bir karakter uzunlu undad r. De er alan ise mesaj n türüne göre de i mektedir. SDP oturum özellikleri mesaj, oturum bazl bilgi ve iletilen veri türü bazl bilgi içerir. Oturum bazl bilgi alan tüm oturumu tan mlar. Örnek olarak oturumun kim taraf ndan ba lat ld bilgisi, oturum bazl bilgi alan nda belirtilir. Veri bazl bilgi alan ise iletilen verinin türünü belirler. Örnek olarak hangi tür verinin hangi tür