Adiputri Kusuma Wardhani

1241160009

Perbandingan H323 dan SIP

Filsafat

H323

SIP

H.323 dirancang dengan

pemahaman yang baik
tentang persyaratan untuk
komunikasi multimedia
melalui jaringan IP,
termasuk audio, video, dan
data conferencing. Ini
mendefinisikan seluruh
sistem terpadu untuk
melakukan fungsi-fungsi
ini, memanfaatkan kekuatan
dari IETF dan ITU-T
protokol.

SIP dirancang untuk setup "sesi"

antara dua titik dan menjadi
modular, komponen fleksibel
arsitektur Internet. Memiliki
konsep longgar panggilan (yang
menjadi "session" dengan media
stream), tidak memiliki
dukungan untuk multimedia
conferencing, dan integrasi
standar kadang-kadang berbeda
sebagian besar diserahkan
kepada masing-masing vendor.

Akibatnya, mungkin masuk

akal bagi pengguna untuk
mengharapkan sekitar
tingkat yang sama
ketahanan dan
interoperabilitas seperti
yang ditemukan pada PSTN
saat ini, meskipun hal ini
diakui bervariasi di seluruh
dunia.

Akibatnya, SIP adalah protokol

sekarang berusia 14 tahun
dengan sejumlah besar masalah
interoperabilitas. Sementara SIP
telah berhasil digunakan di
beberapa lingkungan, mereka
umumnya "tertutup" lingkungan
di mana sarana interoperabilitas
telah gateway PSTN.

H.323 dirancang untuk skala

untuk menambahkan fungsi
baru. Penggunaan yang
paling banyak digunakan
dari H.323 adalah "Voice
over IP" diikuti dengan
"Videoconferencing", yang
keduanya dijelaskan dalam
spesifikasi H.323.
Complexity

H.323 terbatas pada

konferensi multimedia,

SIP awalnya difokuskan pada

komunikasi suara dan kemudian

sehingga kompleksitas
sistem dibatasi sesuai. Tidak
ada sistem komunikasi
sederhana, namun H.323
mencoba untuk jelas
mendefinisikan set dasar
fungsi bahwa semua
perangkat harus
mendukung.

diperluas untuk mencakup

video, berbagi aplikasi, instant
messaging, presence, dll
Dengan kemampuan masingmasing, kompleksitas
meningkat dan, sayangnya,
tidak ada pedoman yang ketat
seperti apa fungsi harus
mendukung perangkat tertentu.
Hal ini menyebabkan sistem
yang lebih kompleks dengan
masalah interoperabilitas yang
lebih. Sejak SIP "dipasarkan"
sebagai protokol sederhana,
meskipun kenyataan itu hanya
terlihat sederhana di permukaan.

Reliability

H.323 telah menetapkan

sejumlah fitur untuk
menangani kegagalan
entitas jaringan menengah,
termasuk "gatekeeper
alternatif", "endpoint
alternatif", dan cara untuk
memulihkan dari kegagalan
koneksi.

SIP belum ditetapkan prosedur

penanganan kegagalan
perangkat. Jika proxy gagal,
agen pengguna mendeteksi
melalui waktu berakhirnya. Ini
adalah tanggung jawab useragent untuk mengirim ulang
INVITE ke proxy lain,
menyebabkan penundaan yang
lama dalam pembentukan
panggilan.

Message Definition

ASN.1 , yang standar,

sangat tepat, mudah
dipahami notasi struktur
yang digunakan oleh banyak
sistem lain.

ABNF, atau Augmented

Backus-Naur Form, notasi
sintaksis. SIP menggunakan
ABNF sebagaimana
didefinisikan dalam RFC 2234 .

Message Encoding

H.323 mengkodekan pesan

dalam format biner kompak
yang cocok untuk
narrowband dan broadband
koneksi. Pesan secara
efisien dikodekan dan
diterjemahkan oleh mesin,
dengan decoder banyak
tersedia (misalnya,

Pesan SIP dikodekan dalam

format teks ASCII, cocok bagi
manusia untuk membaca.
Akibatnya, pesan yang besar
dan kurang cocok untuk
jaringan di mana bandwidth,
delay, dan / atau pengolahan
menjadi perhatian.

Ethereal).

Pesan SIP mendapatkan begitu

besar sehingga mereka kadangkadang melebihi ukuran MTU
ketika akan lebih WAN link,
yang mengakibatkan
penundaan, packet loss, dll
Akibatnya, upaya telah
dilakukan untuk biner encode
SIP (misalnya, RFC 3485 dan
RFC 3486 ).

Media Transport

RTP/RTCP, SRTP

RTP/RTCP, SRTP

Extensibility -

H.323 diperpanjang dengan

fitur non-standar sedemikian
rupa untuk menghindari
konflik antara vendor.
Secara global
pengidentifikasi unik
mencegah fitur dan elemen
data tabrakan.

SIP diperpanjang dengan

menambahkan baris header baru
atau badan pesan yang dapat
digunakan oleh vendor yang
berbeda untuk melayani tujuan
yang berbeda, sehingga
mempertaruhkan masalah
interoperabilitas.

Vendor Specific

Risiko ini memang kecil, tapi

masalah ini sudah terlihat di
dunia nyata dengan skema
ekstensi yang sama.
Extensibility Standard

Scalability Load Balancing

H.323 diperpanjang oleh

masyarakat standar untuk
menambahkan fitur baru
untuk H.323 sedemikian
rupa agar tidak berdampak
fitur yang ada. Namun,
revisi baru H.323 yang
diterbitkan secara berkala,
yang memperkenalkan
fungsionalitas baru yang
wajib, namun dilakukan
dengan sedemikian rupa
untuk melestarikan
kompatibilitas.

SIP diperpanjang oleh

masyarakat standar untuk
menambahkan fitur baru untuk
SIP sedemikian rupa agar tidak
berdampak fitur yang ada.
Namun, revisi baru SIP
berpotensi tidak kompatibel
(misalnya, RFC 3261 tidak
sepenuhnya kompatibel dengan
RFC 2543 ). Selain itu,
beberapa ekstensi yang "wajib"
dalam beberapa implementasi,
yang menyebabkan masalah
interoperabilitas.

H.323 memiliki kemampuan

untuk memuat endpoint
keseimbangan di sejumlah
gatekeeper alternatif untuk

SIP tidak memiliki gagasan load

balancing, kecuali "trial and
error" di perangkat praditetapkan atau perangkat

Scalability Call Signaling

Scalability Statelessness

Scalability Address Resolution

skala titik lokal kehadiran.

Selain itu, endpoint
melaporkan kapasitas yang
tersedia dan jumlah mereka
sehingga panggilan akan
satu set gateway, misalnya,
mungkin paling
didistribusikan di mereka
gateway.

belajar dari catatan DNS SRV.

Tidak ada cara untuk
mendeteksi beban pada gateway
tertentu atau untuk mengetahui
apakah perangkat telah gagal,
yang berarti bahwa proxy hanya
harus mencoba gateway PSTN,
menunggu panggilan untuk
batas waktu, dan kemudian
mencoba lagi.

Ketika gatekeeper H.323

digunakan, mungkin hanya
menyediakan resolusi
alamat melalui satu
pertukaran pesan RAS, atau
mungkin dengan semua
panggilan isyarat lalu-lintas.
Dalam jaringan yang besar,
model panggilan langsung
dapat digunakan sehingga
endpoint terhubung
langsung satu sama lain.

Bila menggunakan proxy SIP

untuk melakukan resolusi
alamat untuk perangkat SIP,
proxy diperlukan untuk
menangani setidaknya 3
pertukaran pesan penuh untuk
setiap panggilan. Dalam
jaringan yang besar, seperti IMS
jaringan, jumlah pesan pada
kawat mungkin berlebihan.
Panggilan dasar antara dua
pengguna mungkin memerlukan
sebanyak 30 pesan pada kawat!

Sebuah gatekeeper H.323

dapat berkewarganegaraan
menggunakan model
panggilan langsung.

Sebuah proxy SIP dapat

berkewarganegaraan jika tidak
garpu, menggunakan TCP, atau
menggunakan multicast.

H.323 mendefinisikan
sebuah antarmuka antara
titik akhir dan gatekeeper
untuk resolusi alamat
menggunakan ARQ atau
LRQ. H.323 gatekeeper
dapat menggunakan
sejumlah protokol untuk
menemukan alamat tujuan
dari callee, termasuk LRQs
ke gatekeeper lain,
Lampiran G / H.225.0 ,
TRIP , ENUM , dan / atau
DNS . Endpoint tidak perlu
khawatir dengan mekanisme

Sementara SIP tidak memiliki

protokol alamat resolusi, per se,
agen SIP pengguna dapat
rutenya INVITE pesan melalui
proxy atau mengarahkan server
untuk menyelesaikan alamat.
SIP Proxy dapat menggunakan
berbagai protokol untuk
menemukan alamat tujuan dari
callee, termasuk TRIP , ENUM ,
dan / atau | REFREF | 1035 ||
DNS |. Endpoint tidak perlu
khawatir dengan mekanisme
proses ini. Sayangnya,
persyaratan pengolahan

proses ini, dan persyaratan

pengolahan untuk resolusi
alamat ditempatkan pada
gatekeeper oleh H.323
adalah untuk hanya
pertukaran pesan tunggal.
Meskipun keluar dari ruang
lingkup H.323, H.323
endpoint dapat melakukan
resolusi alamat sendiri
menggunakan ENUM dan /
atau DNS dan kemudian
menempatkan panggilan
langsung ke alamat
diselesaikan atau
memberikan alamat
memutuskan untuk
gatekeeper sebagai "alias".
Addressing

Mekanisme pengalamatan
fleksibel, termasuk URI,
alamat e-mail, dan nomor
E.164.

H.323 mendukung alias ini:

E.164 keluar digit

generik H.323 ID
URL

Alamat transportasi

alamat email

Jumlah partai

ponsel UIM

Nomor ISUP

H.323 juga mendukung

ditempatkan pada proxy SIP

lebih tinggi daripada dengan
H.323 karena setidaknya 3
pertukaran pesan harus
berlangsung antara perangkat
SIP, SIP proxy, dan hop
berikutnya.
Meskipun keluar dari ruang
lingkup SIP, agen pengguna SIP
dapat melakukan resolusi alamat
sendiri menggunakan ENUM
dan / atau DNS dan kemudian
menempatkan panggilan
langsung ke alamat diselesaikan
atau melalui proxy.

SIP hanya mengerti alamat URI

gaya. Ini bekerja baik untuk
perangkat SIP-SIP, tetapi
menyebabkan beberapa
kebingungan ketika mencoba
untuk menerjemahkan berbagai
Keluar digit. Konvensi resmi
adalah bahwa tanda "+"
dimasukkan dalam SIP URI
(misalnya, "sip:
+18005551212@example.com")
untuk menunjukkan bahwa
nomor tersebut dalam format
E.164, versus ID pengguna yang
mungkin menjadi numerik.
SIP memiliki dukungan untuk
sinyal tumpang tindih
didefinisikan dalam RFC 3578 ,
meskipun digit tambahan yang
diterima memerlukan transmisi
tiga pesan pada kawat (INVITE
baru, respon 484 untuk
menunjukkan bahwa alamat

tumpang tindih pengiriman

tanpa overhead tambahan,
kecuali penyampaian angka
baru diterima dalam satu
pesan.

tidak lengkap, dan ACK).

Billing

Bahkan dengan model

panggilan langsung H.323
yang, kemampuan untuk
berhasil tagihan untuk
panggilan tidak hilang
karena laporan endpoint ke
gatekeeper awal dan akhir
waktu panggilan melalui
protokol RAS. Berbagai
potongan informasi
penagihan dapat hadir
dalam ARQ dan DRQ pesan
pada awal dan akhir
panggilan.

Jika proxy SIP ingin

mengumpulkan informasi
penagihan, ia tidak memiliki
pilihan selain untuk tinggal di
panggilan jalur sinyal untuk
seluruh durasi panggilan
sehingga dapat mendeteksi
ketika panggilan selesai. Bahkan
kemudian, statistik yang miring
karena sinyal panggilan
mungkin telah tertunda. Jika
tidak, tidak ada mekanisme di
SIP untuk melakukan fungsi
akuntansi / penagihan.

Call Setup

Panggilan dapat dibentuk

dalam sedikitnya 1,5
perjalanan pulang
menggunakan UDP:

Panggilan dapat dibentuk dalam

sedikitnya 1,5 perjalanan pulang
menggunakan UDP:

Setup ->
<- Connect
Ack ->

Capability Negotiation

INVITE ->
<- 200 OK
Ack ->

Tentu saja, prosedur

pendirian panggilan yang
lebih rumit mungkin
diperlukan untuk
bernegosiasi kemampuan
yang kompleks, negosiasi
mode video yang kompleks,
dll

Kebanyakan arus dunia nyata

yang lebih kompleks, karena
mereka sering melewati satu
atau lebih perangkat proxy,
memiliki pesan respon
perantara, dan "bernegosiasi"
kemampuan melalui "trial and
error" proses yang jauh dari
ilmiah. Berikut adalah lebih
nyata aliran panggilan SIP .

Entitas H.323 dapat bertukar

kemampuan dan
bernegosiasi yang saluran
untuk membuka, termasuk

Entitas SIP telah sarana

kemampuan bertukar terbatas.
RFC 3407 adalah keadaan seni,
yang merupakan mekanisme

audio, video, dan saluran

data. Saluran individu dapat
dibuka dan ditutup selama
panggilan tanpa
mengganggu saluran
lainnya.

"deklarasi" lebih atau kurang,

bukan prosedur negosiasi. Hasil
akhirnya adalah masih "trial and
error" pendekatan dalam kasus
dipanggil pihak tidak
mendukung media yang
diusulkan.

Call Forking

H.323 gatekeeper dapat

mengontrol sinyal panggilan
dan garpu panggilan untuk
sejumlah perangkat secara
bersamaan.

Proxy SIP dapat mengontrol

sinyal panggilan dan garpu
panggilan untuk sejumlah
perangkat secara bersamaan.

PSTN Interworking

H.323 meminjam dari

protokol PSTN tradisional,
misalnya, Q.931, dan karena
itu cocok untuk integrasi
PSTN. Namun, H.323 tidak
menggunakan teknologi
circuit-switched PSTN ini seperti SIP, H.323 benarbenar packet-switched.
Bagaimana Media Gateway
Controller cocok dengan
arsitektur H.323
keseluruhan baikdidefinisikan dalam standar.

SIP tidak memiliki kesamaan

dengan PSTN dan sinyal
tersebut harus "sepatubertanduk" ke SIP. SIP tidak
memiliki arsitektur yang
menggambarkan dekomposisi
gateway ke Media Gateway
Controller dan Media Gateway.
Ini telah menjadi penelitian
terbaru dari 3GPP dan lain-lain
dalam bentuk IMS . Saat ini, ada
sekitar 4 "IMS" varian: 3GPP,
ITU NGN, 3GPP2, dan
PacketCable.

Services

Layanan dapat diberikan

kepada endpoint melalui
antarmuka web-browser
menggunakan HTTP atau
server fitur menggunakan
Megaco / H.248. Selain itu,
layanan dapat diberikan ke
titik akhir karena
menempatkan panggilan,
sebagai panggilan tiba, atau
saat tengah panggilan oleh
gatekeeper atau badan lain
yang rute yang sinyal
panggilan. Akibatnya,
H.323 sangat cocok untuk
menyediakan layanan baru.

Perangkat SIP dapat menerima

layanan dari proxy SIP sebagai
titik akhir menempatkan
panggilan, sebagai panggilan
tiba, atau saat tengah panggilan.
Tidak ada cara didefinisikan
dalam SIP menyediakan layanan
melalui web browser atau server
fitur, karena semuanya
dilakukan dalam konteks "sesi".

Video and Data

Conferencing

H.323 sepenuhnya
mendukung video dan data
conferencing. Prosedur
berada di tempat untuk
memberikan kontrol untuk
konferensi serta sinkronisasi
bibir stream audio dan
video.

SIP memiliki dukungan terbatas

untuk video dan tidak ada
dukungan untuk protokol data
conferencing seperti T.120. SIP
tidak memiliki protokol untuk
mengendalikan konferensi dan
tidak ada mekanisme dalam SIP
untuk sinkronisasi bibir. Tidak
ada cara standar pulih dari
packet loss dalam aliran video
(untuk "update fast video"
perintah paralel H.323 's).

Administrative
Requirements

H.323 tidak membutuhkan

gatekeeper. Panggilan dapat
dilakukan secara langsung
antara dua titik akhir.

SIP tidak memerlukan proxy.

Panggilan dapat dilakukan
secara langsung antara dua agen
pengguna.

Namun, sebagian besar

perangkat lakukan
memanfaatkan gatekeeper
untuk tujuan registrasi dan
resolusi alamat.

Namun, sebagian besar

perangkat lakukan
menggunakan proxy SIP untuk
tujuan pendaftaran, resolusi
alamat, dan routing panggilan.

H.323 mendukung codec

apapun, standar atau
eksklusif. Tidak ada otoritas
pendaftaran diperlukan

SIP mendukung codec IANA

terdaftar (sebagai fitur warisan)
atau codec lain yang namanya
disepakati bersama.

Codecs

Satu mungkin memberikan

layanan ad-hoc melalui cara
lain, seperti XML, SOAP, atau
CPL. Namun, tidak ada standar
untuk ini.

untuk menggunakan codec

apapun dalam H.323.
Firewall/NAT support

Disediakan oleh H.323

"proxy" atau titik akhir, baik
dalam hubungannya dengan
gatekeeper yang berada di
jaringan publik. H.323 juga
mendukung langsung media
yang point-to-point
mengalir di antara perangkat
yang terletak di belakang
NAT / FW. Lihat ke
H.460.17, H.460.18,
H.460.19, H.460.23, dan
H.460.24.

SIP tidak mendefinisikan

mekanisme NAT traversal / FW,
karena hal ini diserahkan kepada
standar lainnya. Beberapa
standar yang sudah ditetapkan
atau sedang didefinisikan yang
STUN , MENGHIDUPKAN ,
Anat , dan ICE . Anat populer
sebagai sarana menangani IPv4 /
IPv6 interworking dan
tampaknya banyak diterapkan.
Pada Januari 2011, ICE masih
belum begitu banyak diadopsi.

Transport protocol

Handal atau tidak dapat

diandalkan, misalnya, TCP
atau UDP. Kebanyakan
entitas H.323 menggunakan
transportasi yang dapat
diandalkan untuk sinyal.

Handal atau tidak dapat

diandalkan, misalnya, TCP atau
UDP. Kebanyakan entitas SIP
menggunakan transportasi tidak
dapat diandalkan untuk sinyal.

Loop Detection

Gatekeeper Routing dapat

mendeteksi loop dengan
melihat bidang
CallIdentifier dan
destinationAddress dalam
pesan panggilanpengolahan. Jika kombinasi
ini cocok panggilan yang
ada, itu adalah lingkaran.
Loop tak terbatas dapat
dicegah dengan
memanfaatkan lapangan
hopCount dalam pesan
SETUP.

Via Header memfasilitasi ini.

Namun, telah ada pembicaraan
tentang mencela Via sebagai
sarana deteksi lingkaran karena
kompleksitas. Sebaliknya,
header Max-Ke depan
tampaknya menjadi metode
yang disukai membatasi hop dan
karena loop.

Multicast Signaling

Ya, permintaan lokasi

(LRQ) dan penemuan auto
gatekeeper (GRQ).

Ya, misalnya, melalui undangan

kelompok.

Third-party Call Control

Ya, melalui jeda pihak

ketiga dan re-routing yang
didefinisikan dalam H.323.

Ya, melalui SIP seperti yang

dijelaskan dalam RFC 3725 .

Lebih kendali canggih

didefinisikan oleh seri
H.450.x terkait standar.
Minimum Ports for VoIP
Call

3 (Call sinyal, RTP, dan

RTCP.)

3 (SIP, RTP, dan RTCP.)

Conferencing Entity

Ya, seorang MC diperlukan

untuk ini, tapi itu bisa coterletak di titik akhir yang
berpartisipasi, atau semua
endpoint bisa mengandung
MC. Sebuah pengantin
konferensi berdiri sendiri
dapat menyediakan fungsi
ini dan H.323 memiliki
prosedur yang ditetapkan
untuk entitas tersebut.

Tak Ada; Namun, agen

pengguna SIP dapat melakukan
konferensi sendiri. Sebuah
jembatan konferensi berdiri
sendiri juga dapat memberikan
fungsi ini.

Yang membedakan H.323

tidak bahwa ia memerlukan
lagi entitas fisik berat untuk
konferensi (tidak) tetapi itu
hanya memiliki nama untuk
fungsi ini, "MC," dan bahwa
ia menyediakan sarana yang
fleksibel menerapkan fungsi
itu.
Lineage

H.323 didasarkan pada

H.324, H.320 tidak. Namun,
H.324 dirancang untuk
menjadi lebih baik H.320.

SIP sering bersekutu dengan

Internet dan World Wide Web
dengan cara HTTP.

1990 - WWW dan HTTP

dijelaskan dan dilaksanakan.

1990 - H.320 disetujui.

1995 - H.324 disetujui.

1995 - H.323 rancangan

kerja beredar.

1996 - SIP Draft internet

beredar.

1999 - SIP ( RFC 2543 )

disetujui.

2002 - SIP ( RFC 3261 )

disetujui.

1996 - H.323 disetujui.

1998 - H.323v2
disetujui.

1999 - H.323v3

Sementara kompatibilitas tidak

dipertahankan antara tahun 1999

disetujui.

2000 - H.323v4
disetujui.

2003 - H.323v5
disetujui.

2006 - H.323v6
disetujui.

dan 2002 dokumen, nomor versi

tetap sama "versi 2.0".

Seperti yang Anda lihat,

H.323 tidak lebih
merupakan "warisan" dari
protokol SIP. Kedua
protokol adalah usia yang
sama!
Open-source projects

Ya, misalnya, H.323

Ditambah .

Ya, misalnya, Opal .

Media Topology

Unicast, multicast, bintang,

dan terpusat.

Unicast, multicast, bintang, dan

terpusat.

Authentication

Ya, melalui H.235.

Ya, melalui HTTP (Digest dan

Basic), SSL, PGP, S / MIME,
atau berbagai cara lainnya.

Encryption

Ya, melalui H.235

(termasuk penggunaan
SRTP, TLS, IPSec, dll).

Ya, melalui SSL, PGP, S /

MIME, atau berbagai cara
lainnya.

DTMF Carriage

H.245 User Input Indikasi,

RFC 4733 , atau melalui
audio streaming. Pilihan
alfanumerik pesan H.245
UserInputIndication adalah
kereta dasar umum untuk
semua endpoint H.323,
sehingga interoperabilitas
terjamin.

Tidak ada kereta dasar, yang

menyajikan isu-isu
interoperabilitas. Transportasi
DTMF melalui metode INFO,
RFC 4733 , KPML, atau stream
audio semua pilihan.