Ağ Çalışma Grubu Yorum Talebi: 4566 Yürürlükten Kaldırılanlar: 2327, 3266 Kategori: Standartlar Yolu
M. Handley (UCL) V. Jacobson (Packet Design) C. Perkins (University of Glasgow)
Temmuz 2006
#Özet
Bu belge, Oturum Tanımlama Protokolü’nü (SDP) tanımlar. SDP, oturum duyurusu, oturum daveti ve multimedya oturum başlatmanın diğer biçimleri amacıyla multimedya oturumlarını tanımlamak için tasarlanmıştır.
#1. Giriş
Multimedya telekonferansları, IP üzerinden ses çağrıları, akış video veya diğer oturumlar başlatılırken, medya ayrıntılarının, taşıma adreslerinin ve diğer oturum tanımlama üstverilerinin katılımcılara iletilmesi gereksinimi vardır.
SDP, bu tür bilgiler için, bilginin nasıl taşındığından bağımsız olarak standart bir gösterim sağlar. SDP yalnızca bir oturum tanımlama biçimidir—bir taşıma protokolü içermez ve Oturum Duyuru Protokolü [14], Oturum Başlatma Protokolü [15], Gerçek Zamanlı Akış Protokolü [16], MIME uzantıları kullanılarak elektronik posta ve Hiper Metin Taşıma Protokolü dâhil olmak üzere uygun olan farklı taşıma protokollerinin kullanılmasını hedefler.
SDP, geniş bir ağ ortamı ve uygulama yelpazesinde kullanılabilmesi için genel amaçlı olacak şekilde tasarlanmıştır. Ancak, oturum içeriğinin veya medya kodlamalarının müzakeresini desteklemesi amaçlanmamıştır; bu, oturum tanımlamanın kapsamı dışında olarak değerlendirilir.
Bu belge, RFC 2327 [6] ve RFC 3266 [10] belgelerini yürürlükten kaldırır. Bölüm 10, bu belgede sunulan değişiklikleri özetler.
#2. Terimler Sözlüğü
Aşağıdaki terimler bu belgede kullanılmaktadır ve bu belgenin bağlamı içinde özel anlamlara sahiptir.
Konferans: Bir multimedya konferansı, iletişim kuran iki veya daha fazla kullanıcıdan ve iletişim kurmak için kullandıkları yazılımdan oluşur.
Oturum: Bir multimedya oturumu, multimedya göndericileri ve alıcılarının bir kümesi ile göndericilerden alıcılara akan veri akışlarından oluşur. Bir multimedya konferansı, bir multimedya oturumuna örnektir.
Oturum Tanımı: Bir multimedya oturumunu keşfetmek ve katılmak için yeterli bilgiyi iletmeye yönelik iyi tanımlanmış bir biçim.
Bu belgede yer alan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, RFC 2119 [3]’te açıklandığı şekilde yorumlanacaktır.
#3. SDP Kullanım Örnekleri
3.1. Oturum Başlatma
Oturum Başlatma Protokolü (SIP) [15], İnternet multimedya konferansları, İnternet telefon çağrıları ve multimedya dağıtımı gibi oturumları oluşturmak, değiştirmek ve sonlandırmak için kullanılan bir uygulama katmanı denetim protokolüdür. Oturumları oluşturmak için kullanılan SIP iletileri, katılımcıların uyumlu bir medya türleri kümesi üzerinde anlaşmasına olanak tanıyan oturum tanımlarını taşır. Bu oturum tanımları yaygın olarak SDP kullanılarak biçimlendirilir. SIP ile birlikte kullanıldığında, teklif/yanıt modeli [17], SDP kullanarak müzakere için sınırlı bir çerçeve sağlar.
3.2. Akış Medyası
Gerçek Zamanlı Akış Protokolü (RTSP) [16], gerçek zaman özelliklerine sahip verilerin iletiminin denetlenmesi için bir uygulama düzeyi protokolüdür. RTSP, ses ve video gibi gerçek zamanlı verilerin denetimli ve isteğe bağlı iletimini mümkün kılmak için genişletilebilir bir çerçeve sunar. Bir RTSP istemcisi ve sunucusu, medya iletimi için uygun bir parametre kümesini, bu parametreleri tanımlamak üzere kısmen SDP sözdizimini kullanarak müzakere eder.
3.3. E-posta ve World Wide Web
Oturum tanımlarını iletmenin alternatif yolları arasında elektronik posta ve World Wide Web (WWW) yer alır. Hem e-posta hem de WWW dağıtımı için "application/sdp" medya türü kullanılır. Bu, WWW istemcisi veya e-posta okuyucusundan oturuma katılım için uygulamaların standart bir biçimde otomatik olarak başlatılmasını sağlar.
Yalnızca e-posta veya WWW aracılığıyla yapılan çok noktaya yayın oturum duyurularının, duyuruyu alan kişinin mutlaka oturumu alabileceği özelliğine sahip olmadığına dikkat edilmelidir; çünkü çok noktaya yayın oturumları kapsam bakımından sınırlı olabilir ve WWW sunucusuna erişim veya e-posta alımı bu kapsamın dışında mümkün olabilir.
3.4. Çok Noktaya Yayın Oturum Duyurusu
Çok noktaya yayınlı multimedya konferanslarının ve diğer çok noktaya yayın oturumlarının duyurulmasına yardımcı olmak ve ilgili oturum kurulum bilgilerini potansiyel katılımcılara iletmek amacıyla, dağıtık bir oturum dizini kullanılabilir. Böyle bir oturum dizininin bir örneği, oturumun bir tanımını içeren paketleri iyi bilinen bir çok noktaya yayın grubuna periyodik olarak gönderir. Bu duyurular, diğer oturum dizinleri tarafından alınır; böylece potansiyel uzak katılımcılar, oturuma katılmak için gerekli araçları başlatmak üzere oturum tanımını kullanabilir.
Bu tür dağıtık bir dizini uygulamak için kullanılan protokollerden biri Oturum Duyuru Protokolü’dür (SAP) [14]. SDP, bu tür oturum duyuruları için önerilen oturum tanımlama biçimini sağlar.
#4. Gereksinimler ve Öneriler
SDP’nin amacı, bir oturum tanımını alanların oturuma katılabilmesini sağlamak için multimedya oturumlarındaki medya akışları hakkında bilgi iletmektir. SDP öncelikle ağlar arası bir ortamda kullanılmak üzere tasarlanmıştır, ancak diğer ağ ortamlarındaki konferansları da tanımlayabilecek kadar geneldir. Medya akışları çoktan-çoğa olabilir. Oturumların sürekli olarak etkin olması gerekmez.
Bugüne kadar, İnternet üzerindeki çok noktaya yayın tabanlı oturumlar, trafiği alan herkesin oturuma katılabilmesi (oturum trafiği şifrelenmemişse) açısından birçok başka konferans biçiminden farklılık göstermiştir. Böyle bir ortamda SDP iki temel amaca hizmet eder. Birincisi, bir oturumun varlığını iletmenin bir yoludur; ikincisi ise oturuma katılmayı ve katılımı mümkün kılacak yeterli bilgiyi iletmenin bir yoludur. Tek noktaya yayın ortamında ise genellikle yalnızca ikinci amaç geçerli olacaktır.
Bir SDP oturum tanımı aşağıdakileri içerir:
- Oturum adı ve amacı
- Oturumun etkin olduğu zaman(lar)
- Oturumu oluşturan medya
- Bu medyayı almak için gereken bilgiler (adresler, portlar, biçimler vb.)
Bir oturuma katılmak için gerekli kaynaklar sınırlı olabileceğinden, bazı ek bilgiler de istenebilir:
- Oturum tarafından kullanılacak bant genişliği hakkında bilgiler
- Oturumdan sorumlu kişi için iletişim bilgileri
Genel olarak SDP, uygulamaların bir oturuma katılmasını sağlamak için yeterli bilgiyi (şifreleme anahtarları olası istisnası ile) ve ayrıca bilmesi gerekebilecek katılımcı olmayanlara kullanılacak kaynakları duyurmak için yeterli bilgiyi iletmelidir. (Bu son özellik, esas olarak SDP çok noktaya yayın oturum duyuru protokolü ile birlikte kullanıldığında yararlıdır.)
4.1. Medya ve Taşıma Bilgileri
Bir SDP oturum tanımı aşağıdaki medya bilgilerini içerir:
- Medya türü (video, ses vb.)
- Taşıma protokolü (RTP/UDP/IP, H.320 vb.)
- Medya biçimi (H.261 video, MPEG video vb.)
Medya biçimi ve taşıma protokolüne ek olarak SDP, adres ve port ayrıntılarını da iletir. Bir IP çok noktaya yayın oturumu için bunlar şunları kapsar:
- Medya için çok noktaya yayın grup adresi
- Medya için taşıma portu
Bu adres ve port, gönderiliyor, alınıyor veya her ikisi birden yapılıyor olsun, çok noktaya yayın akışının hedef adresi ve hedef portudur.
Tek noktaya yayın IP oturumları için aşağıdakiler iletilir:
- Medya için uzak adres
- Medya için uzak taşıma portu
Bu adres ve portun anlamsal yorumu, tanımlanan medya ve taşıma protokolüne bağlıdır. Varsayılan olarak, bu, verinin gönderildiği uzak adres ve uzak port OLMALIDIR. Bazı medya türleri bu davranışı yeniden tanımlayabilir, ancak bu, uygulamaları (Ağ Adresi Dönüştürme (NAT) veya güvenlik duvarı açıklıkları açmak için adresleri ayrıştırmak zorunda olan ara kutular dâhil) karmaşıklaştırdığı için ÖNERİLMEZ.
4.2. Zamanlama Bilgileri
Oturumlar zaman açısından sınırlı veya sınırsız olabilir. Sınırlı olsun ya da olmasın, yalnızca belirli zamanlarda etkin olabilirler. SDP şunları iletebilir:
- Oturumu sınırlayan başlama ve bitiş zamanlarının isteğe bağlı bir listesi
- Her bir sınır için, "her Çarşamba saat 10:00’da bir saat boyunca" gibi tekrar zamanları
Bu zamanlama bilgileri, yerel zaman diliminden veya yaz saati uygulamasından bağımsız olarak küresel ölçekte tutarlıdır (Bkz. Bölüm 5.9).
4.3. Özel Oturumlar
Hem genel oturumlar hem de özel oturumlar yapmak mümkündür. SDP’nin kendisi bunlar arasında ayrım yapmaz; özel oturumlar genellikle dağıtım sırasında oturum tanımı şifrelenerek iletilir. Şifrelemenin nasıl yapıldığına ilişkin ayrıntılar, SDP’yi iletmek için kullanılan mekanizmaya bağlıdır; şu anda SAP [14] ve SIP [15] kullanılarak taşınan SDP için mekanizmalar tanımlanmıştır ve gelecekte başkaları da tanımlanabilir.
Bir oturum duyurusu özel ise, bu özel duyuru, konferanstaki her bir medyanın kodunu çözmek için gerekli şifreleme anahtarlarını ve her bir medya için hangi şifreleme şemasının kullanıldığını bilmeye yetecek bilgiyi iletmek üzere kullanılabilir.
4.4. Bir Oturum Hakkında Ek Bilgi Edinme
Bir oturum tanımı, bir oturuma katılıp katılmamaya karar vermek için yeterli bilgiyi iletmelidir. SDP, oturum hakkında daha fazla bilgi için Birörnek Kaynak Tanımlayıcıları (URI’ler) biçiminde ek işaretçiler içerebilir.
4.5. Kategorilendirme
SAP veya başka herhangi bir duyuru mekanizması tarafından çok sayıda oturum tanımı dağıtıldığında, ilgilenilen oturum duyurularını ilgilenilmeyenlerden ayırmak istenebilir. SDP, otomatikleştirilebilen bir oturum kategorilendirme mekanizmasını destekler ("a=cat:" özniteliği; bkz. Bölüm 6).
4.6. Uluslararasılaştırma
SDP spesifikasyonu, birçok farklı dilin temsil edilmesine olanak tanımak için UTF-8 kodlamasında ISO 10646 karakter kümelerinin kullanılmasını önerir [5]. Bununla birlikte, daha kompakt gösterimlere yardımcı olmak için, istendiğinde ISO 8859-1 gibi diğer karakter kümelerinin kullanılmasına da izin verir. Uluslararasılaştırma yalnızca serbest metin alanları (oturum adı ve arka plan bilgileri) için geçerlidir ve SDP’nin tamamı için geçerli değildir.
#5. SDP Spesifikasyonu
Bir SDP oturum tanımı, application/sdp medya türü ile gösterilir (Bkz. Bölüm 8).
Bir SDP oturum tanımı, UTF-8 kodlamasında ISO 10646 karakter kümesi kullanılarak tamamen metinseldir. SDP alan adları ve öznitelik adları, UTF-8’in yalnızca US-ASCII alt kümesini kullanır; ancak metinsel alanlar ve öznitelik değerleri ISO 10646 karakter kümesinin tamamını KULLANABİLİR. Tam UTF-8 karakter kümesini kullanan alan ve öznitelik değerleri hiçbir zaman doğrudan karşılaştırılmaz; dolayısıyla UTF-8 normalizasyonu için bir gereksinim yoktur. ASN.1 veya XDR gibi ikili bir kodlama yerine metinsel biçimin seçilmesi, taşınabilirliği artırmak, çeşitli taşıma yöntemlerinin kullanılmasını mümkün kılmak ve oturum tanımlarını üretmek ve işlemek için esnek, metin tabanlı araç setlerinin kullanılmasına olanak tanımak içindir. Ancak, SDP’nin oturum tanımının izin verilen azami boyutunun sınırlı olduğu ortamlarda kullanılabilmesi nedeniyle, kodlama bilinçli olarak kompakt tutulmuştur. Ayrıca, duyurular çok güvenilmez yollarla taşınabileceğinden veya ara bir önbellekleme sunucusu tarafından bozulabileceğinden, kodlama, çoğu hatanın kolayca tespit edilip atılabilecek bozuk oturum duyurularına yol açması için katı sıra ve biçimlendirme kurallarıyla tasarlanmıştır. Bu durum ayrıca, alıcının doğru anahtara sahip olmadığı şifreli oturum duyurularının hızlıca atılmasına da olanak tanır.
Bir SDP oturum tanımı, aşağıdaki biçimde bir dizi metin satırından oluşur:
<type>=<value>Burada <type> tam olarak bir adet büyük/küçük harfe duyarlı karakter OLMALIDIR ve <value>, biçimi <type>’a bağlı olan yapılandırılmış bir metindir. Genel olarak <value>, tek bir boşluk karakteriyle ayrılmış bir dizi alan ya da serbest biçimli bir dizedir ve belirli bir alan aksini tanımlamadıkça büyük/küçük harfe duyarlıdır. "=" işaretinin her iki tarafında da boşluk KULLANILMAMALIDIR.
Bir SDP oturum tanımı, bir oturum düzeyi bölümünden ve bunu izleyen sıfır veya daha fazla medya düzeyi bölümünden oluşur. Oturum düzeyi bölümü bir v= satırıyla başlar ve ilk medya düzeyi bölümüne kadar devam eder. Her medya düzeyi bölümü bir m= satırıyla başlar ve bir sonraki medya düzeyi bölümüne veya tüm oturum tanımının sonuna kadar sürer. Genel olarak, oturum düzeyi değerleri, eşdeğer bir medya düzeyi değeri tarafından geçersiz kılınmadıkça tüm medyalar için varsayılandır.
Her tanımda bazı satırlar ZORUNLUDUR, bazıları ise İSTEĞE BAĞLIDIR; ancak hepsi burada verilen sırada TAM OLARAK yer almalıdır (sabit sıra, hata tespitini büyük ölçüde geliştirir ve basit bir ayrıştırıcıya olanak tanır). İSTEĞE BAĞLI öğeler * ile işaretlenmiştir.
Oturum tanımı
v=(protokol sürümü)o=(kaynak ve oturum tanımlayıcısı)s=(oturum adı)i=*(oturum bilgisi)u=*(açıklamanın URI’si)e=*(e‑posta adresi)p=*(telefon numarası)c=*(bağlantı bilgisi — tüm medyada yer alıyorsa gerekli değildir)b=*(sıfır veya daha fazla bant genişliği bilgi satırı)- Bir veya daha fazla zaman açıklaması (
t=ver=satırları; aşağıya bakın) z=*(saat dilimi ayarlamaları)k=*(şifreleme anahtarı)a=*(sıfır veya daha fazla oturum öznitelik satırı)- Sıfır veya daha fazla medya açıklaması
Zaman açıklaması
t=(oturumun etkin olduğu zaman)r=*(sıfır veya daha fazla tekrar zamanı)
Medya açıklaması (varsa)
m=(medya adı ve taşıma adresi)i=*(medya başlığı)c=*(bağlantı bilgisi — oturum düzeyinde yer alıyorsa isteğe bağlıdır)b=*(sıfır veya daha fazla bant genişliği bilgi satırı)k=*(şifreleme anahtarı)a=*(sıfır veya daha fazla medya öznitelik satırı)
Tür harflerinin kümesi bilinçli olarak küçüktür ve genişletilebilir olması amaçlanmamıştır — bir SDP ayrıştırıcısı, anlamadığı bir tür harfi içeren herhangi bir oturum açıklamasını MUTLAKA tamamen yok saymalıdır. Öznitelik mekanizması (aşağıda açıklanan a=) SDP’yi genişletmenin ve belirli uygulamalara veya medyaya uyarlamanın birincil yoludur. Bazı özniteliklerin (bu belgenin Bölüm 6’sında listelenenler) tanımlı bir anlamı vardır, ancak diğerleri uygulamaya, medyaya veya oturuma özgü olarak eklenebilir. Bir SDP ayrıştırıcısı, anlamadığı herhangi bir özniteliği MUTLAKA yok saymalıdır.
Bir SDP oturum açıklaması, u=, k= ve a= satırlarında harici içeriğe başvuran URI’ler içerebilir. Bu URI’ler bazı durumlarda çözümlenebilir; bu da oturum açıklamasının kendi kendine yeterli olmamasına yol açar.
Oturum düzeyi bölümündeki bağlantı (c=) ve öznitelik (a=) bilgileri, medya açıklamasında aynı adda bir bağlantı bilgisi veya öznitelik ile geçersiz kılınmadıkça, o oturumun tüm medyaları için geçerlidir. Örneğin, aşağıdaki örnekte her medya, kendisine recvonly özniteliği verilmiş gibi davranır.
Bir örnek SDP açıklaması şöyledir:
v=0
o=jdoe 2890844526 2890842807 IN IP4 10.47.16.5
s=SDP Seminar
i=Oturum açıklama protokolü üzerine bir seminer
u=http://www.example.com/seminars/sdp.pdf
e=j.doe@example.com (Jane Doe)
c=IN IP4 224.2.17.12/127
t=2873397496 2873404696
a=recvonly
m=audio 49170 RTP/AVP 0
m=video 51372 RTP/AVP 99
a=rtpmap:99 h263-1998/90000Oturum adı ve bilgi gibi metin alanları, 0x00 (Nul), 0x0a (ASCII yeni satır) ve 0x0d (ASCII satır başı) istisnaları dışında herhangi bir okteti içerebilen oktet dizgeleridir. Bir kaydı sonlandırmak için CRLF (0x0d0a) dizisi kullanılır; ancak ayrıştırıcılar toleranslı OLMALI ve tek bir yeni satır karakteri ile sonlandırılan kayıtları da kabul etmelidir. a=charset özniteliği mevcut değilse, bu oktet dizgeleri UTF‑8 kodlamasında ISO 10646 karakterleri içeriyor olarak YORUMLANMALIDIR (a=charset özniteliğinin varlığı bazı alanların farklı yorumlanmasını zorunlu kılabilir).
Bir oturum açıklaması o=, u=, e=, c= ve a= satırlarında alan adları içerebilir. SDP’de kullanılan herhangi bir alan adı [1], [2] ile uyumlu OLMALIDIR. Uluslararasılaştırılmış alan adları (IDN’ler), [11]’de tanımlanan ASCII Uyumlu Kodlama (ACE) biçimi kullanılarak gösterilmelidir ve UTF‑8 veya başka herhangi bir kodlama ile doğrudan temsil EDİLMEMELİDİR (bu gereksinim, uluslararasılaştırılmış alan adlarının geliştirilmesinden önceye dayanan RFC 2327 ve diğer SDP ile ilgili standartlarla uyumluluk içindir).
5.1. Protokol Sürümü ("v=")
v=0v= alanı, Oturum Açıklama Protokolünün sürümünü verir. Bu belge sürüm 0’ı tanımlar. Küçük sürüm numarası yoktur.
5.2. Kaynak ("o=")
o=<username> <sess-id> <sess-version> <nettype> <addrtype> <unicast-address>o= alanı, oturumun kaynağını (kullanıcının kullanıcı adı ve kullanıcının ana bilgisayarının adresi) ile birlikte bir oturum tanımlayıcısı ve sürüm numarasını verir:
<username>, kaynağı oluşturan ana bilgisayardaki kullanıcının oturum açma adıdır; eğer kaynak ana bilgisayar kullanıcı kimlikleri kavramını desteklemiyorsa-olur.<username>boşluk İÇERMEMELİDİR.<sess-id>,<username>,<sess-id>,<nettype>,<addrtype>ve<unicast-address>demetinin birlikte oturum için küresel olarak benzersiz bir tanımlayıcı oluşturacağı şekilde sayısal bir dizgedir.<sess-id>tahsis yöntemi aracı geliştiren araca bırakılmıştır; ancak benzersizliği sağlamak için Ağ Zaman Protokolü (NTP) biçiminde bir zaman damgası kullanılması önerilmiştir [13].<sess-version>, bu oturum açıklaması için bir sürüm numarasıdır. Kullanımı, oturum verilerinde bir değişiklik yapıldığında<sess-version>artırıldığı sürece, aracı geliştiren araca bırakılmıştır. Yine, NTP biçiminde bir zaman damgası kullanılması ÖNERİLİR.<nettype>, ağ türünü veren bir metin dizgesidir. BaşlangıçtaIN, “Internet” anlamına gelecek şekilde tanımlanmıştır; ancak gelecekte başka değerler KAYDEDİLEBİLİR (Bkz. Bölüm 8).<addrtype>, ardından gelen adresin türünü veren bir metin dizgesidir. BaşlangıçtaIP4veIP6tanımlanmıştır; ancak gelecekte başka değerler KAYDEDİLEBİLİR (Bkz. Bölüm 8).<unicast-address>, oturumun oluşturulduğu makinenin adresidir. IP4 adres türü için bu, makinenin tam nitelikli alan adı ya da makinenin IP sürüm 4 adresinin noktalı ondalık gösterimidir. IP6 adres türü için bu, makinenin tam nitelikli alan adı ya da makinenin IP sürüm 6 adresinin sıkıştırılmış metinsel gösterimidir. Hem IP4 hem de IP6 için, bu mevcut olduğu sürece tam nitelikli alan adı verilmesi GEREKİR; bu mümkün değilse küresel olarak benzersiz adres YERİNE KONABİLİR. SDP açıklamasının adresin anlamlı olduğu kapsamın dışına çıkabileceği herhangi bir bağlamda yerel bir IP adresi KULLANILMAMALIDIR (örneğin, kapsam dışına çıkabilecek bir uygulama düzeyi yönlendirmede yerel bir adres BULUNMAMALIDIR).
Genel olarak, o= alanı bu oturum açıklamasının bu sürümü için küresel olarak benzersiz bir tanımlayıcı görevi görür ve sürüm hariç alt alanlar birlikte, herhangi bir değişiklikten bağımsız olarak oturumu tanımlar.
Gizlilik nedenleriyle, bazen oturum kaynağının kullanıcı adını ve IP adresini gizlemek istenebilir. Bu bir endişeyse, küresel benzersizliği etkilemeyecek şekilde seçilmesi koşuluyla, o= alanını doldurmak için rastgele bir <username> ve özel bir <unicast-address> SEÇİLEBİLİR.
5.3. Oturum Adı ("s=")
s=<session name>s= alanı metinsel oturum adıdır. Her oturum açıklaması için bir ve yalnızca bir adet s= alanı BULUNMALIDIR. s= alanı boş OLMAMALIDIR ve ISO 10646 karakterleri İÇERMELİDİR (ancak a=charset özniteliğine de bakınız). Bir oturumun anlamlı bir adı yoksa, s= değeri KULLANILMALIDIR (yani oturum adı olarak tek bir boşluk).
5.4. Oturum Bilgisi ("i=")
i=<session description>i= alanı oturum hakkında metinsel bilgi sağlar. Her oturum açıklaması için oturum düzeyinde en fazla bir adet i= alanı ve her medya için en fazla bir adet i= alanı BULUNABİLİR. a=charset özniteliği mevcutsa, i= alanında kullanılan karakter kümesini belirtir. a=charset özniteliği mevcut değilse, i= alanı UTF‑8 kodlamasında ISO 10646 karakterleri İÇERMELİDİR.
Her medya tanımı için tek bir i= alanı da KULLANILABİLİR. Medya tanımlarında i= alanları öncelikle medya akışlarını etiketlemek için tasarlanmıştır. Bu nedenle, tek bir oturumda aynı medya türünden birden fazla farklı medya akışı olduğunda en kullanışlı olmaları beklenir. Örneğin, slaytlar için bir, geri bildirim ve sorular için bir olmak üzere iki farklı beyaz tahta.
i= alanı, bir oturumun veya bir medya akışının amacının serbest biçimli, insan tarafından okunabilir bir açıklamasını sağlamak için tasarlanmıştır. Otomatlar tarafından ayrıştırılmaya uygun değildir.
5.5. URI ("u=")
u=<uri>URI, WWW istemcileri tarafından kullanılan bir Tekdüzen Kaynak Tanımlayıcısıdır [7]. URI, oturum hakkında ek bilgilere işaret etmelidir. Bu alan İSTEĞE BAĞLIDIR; ancak mevcutsa, ilk medya alanından önce belirtilmelidir. Her oturum açıklaması için birden fazla URI alanına izin verilmez.
5.6. E‑posta Adresi ve Telefon Numarası ("e=" ve "p=")
e=<email-address>
p=<phone-number>e= ve p= satırları, konferanstan sorumlu kişi için iletişim bilgilerini belirtir. Bu kişi, konferans duyurusunu hazırlayan kişiyle aynı olmak zorunda değildir.
E‑posta adresi veya telefon numarası eklenmesi İSTEĞE BAĞLIDIR. SDP’nin önceki sürümü, ya bir e‑posta alanının ya da bir telefon alanının MUTLAKA belirtilmesi gerektiğini söylüyordu; ancak bu yaygın olarak göz ardı edilmiştir. Bu değişiklik, belirtimi yaygın kullanım ile uyumlu hale getirir.
Bir e‑posta adresi veya telefon numarası mevcutsa, ilk medya alanından önce belirtilmelidir. Bir oturum açıklaması için birden fazla e‑posta veya telefon alanı verilebilir.
Telefon numaraları, başına + eklenmiş uluslararası genel telekomünikasyon numarası biçiminde VERİLMELİDİR (Bkz. ITU‑T Tavsiyesi E.164). Okunabilirliği artırmak için istenirse boşluklar ve tireler kullanılabilir. Örneğin:
p=+1 617 555-6011Hem e‑posta adresleri hem de telefon numaraları, genellikle iletişime geçilebilecek kişinin adını veren İSTEĞE BAĞLI bir serbest metin dizgesi ile birlikte verilebilir. Mevcutsa bu parantez içinde OLMALIDIR. Örneğin:
e=j.doe@example.com (Jane Doe)Alternatif RFC 2822 [29] ad alıntılama kuralı, hem e‑posta adresleri hem de telefon numaraları için de izinlidir. Örneğin:
e=Jane Doe <j.doe@example.com>Serbest metin dizgesi ISO‑10646 karakter kümesinde UTF‑8 kodlamasıyla OLMALIDIR ya da uygun oturum düzeyi a=charset özniteliği ayarlanmışsa ISO‑8859‑1 veya diğer kodlamalarda OLABİLİR.
5.7. Bağlantı Verisi ("c=")
c=<nettype> <addrtype> <connection-address>"c=" alanı bağlantı verilerini içerir.
Bir oturum açıklaması, her medya açıklamasında en az bir adet "c=" alanı ya da oturum düzeyinde tek bir "c=" alanı MUTLAKA içermelidir. Oturum düzeyinde tek bir "c=" alanı ve ayrıca medya açıklaması başına ek "c=" alan(lar)ı içerebilir; bu durumda medya başına verilen değerler, ilgili medya için oturum düzeyi ayarlarını geçersiz kılar.
Birinci alt alan ("<nettype>") ağ türüdür; ağ türünü veren bir metin dizgesidir. Başlangıçta "IN", “Internet” anlamına gelecek şekilde tanımlanmıştır; ancak gelecekte başka değerler KAYDEDİLEBİLİR (Bkz. Bölüm 8).
İkinci alt alan ("<addrtype>") adres türüdür. Bu, SDP’nin IP tabanlı olmayan oturumlar için de kullanılmasına olanak tanır. Bu belge yalnızca IP4 ve IP6’yı tanımlar; ancak gelecekte başka değerler KAYDEDİLEBİLİR (Bkz. Bölüm 8).
Üçüncü alt alan ("<connection-address>") bağlantı adresidir. <addrtype> alanının değerine bağlı olarak, bağlantı adresinden sonra İSTEĞE BAĞLI alt alanlar EKLENEBİLİR.
<addrtype> IP4 veya IP6 olduğunda, bağlantı adresi aşağıdaki şekilde tanımlanır:
- Oturum çok noktaya yayın (multicast) ise, bağlantı adresi bir IP multicast grup adresi olacaktır. Oturum multicast değilse, bağlantı adresi, ek öznitelik alanlarıyla belirlenen beklenen veri kaynağının, veri aktarım noktasının veya veri alıcısının tekil (unicast) IP adresini içerir. Multicast bir duyuru ile iletilen bir oturum açıklamasında unicast adreslerin verilmesi beklenmez; ancak bu yasaklanmış değildir.
- IPv4 multicast bağlantı adresi kullanan oturumlar, multicast adresine ek olarak MUTLAKA bir yaşam süresi (TTL) değeri de içermelidir. TTL ve adres birlikte, bu konferansta gönderilen multicast paketlerinin gönderileceği kapsamı tanımlar. TTL değerleri 0–255 aralığında OLMALIDIR. TTL belirtilmesi zorunlu olmakla birlikte, multicast trafiğini kapsamlandırmak için kullanımı artık önerilmemektedir; uygulamalar bunun yerine idari olarak kapsamlandırılmış adresler KULLANMALIDIR.
Oturum için TTL, ayırıcı olarak eğik çizgi kullanılarak adrese eklenir. Bir örnek şöyledir:
c=IN IP4 224.2.36.42/127IPv6 multicast TTL kapsamlandırması kullanmaz; bu nedenle IPv6 multicast için TTL değeri BULUNMAMALIDIR. Konferansların kapsamını sınırlamak için IPv6 kapsamlı adreslerin kullanılması beklenir.
Hiyerarşik veya katmanlı kodlama şemaları, tek bir medya kaynağından yapılan kodlamanın birden fazla katmana bölündüğü veri akışlarıdır. Alıcı, bu katmanların yalnızca bir alt kümesine abone olarak istenen kaliteyi (dolayısıyla bant genişliğini) seçebilir. Bu tür katmanlı kodlamalar, multicast budamaya olanak sağlamak için normalde birden fazla multicast grubunda iletilir. Bu teknik, hiyerarşinin yalnızca belirli düzeylerine ihtiyaç duyan sitelere istenmeyen trafiğin gitmesini engeller. Birden fazla multicast grubu gerektiren uygulamalar için, bağlantı adresinde aşağıdaki gösterimin kullanılmasına izin verilir:
<base multicast address>[/<ttl>]/<number of addresses>Adres sayısı verilmezse, bir olduğu varsayılır. Bu şekilde atanan multicast adresleri, taban adresin üzerinde bitişik olarak tahsis edilir; örneğin:
c=IN IP4 224.2.1.1/127/3ifadesi, 224.2.1.1, 224.2.1.2 ve 224.2.1.3 adreslerinin 127 TTL ile kullanılacağını belirtir. Bu, bir medya açıklamasında birden fazla "c=" satırı eklemekle anlamsal olarak aynıdır:
c=IN IP4 224.2.1.1/127
c=IN IP4 224.2.1.2/127
c=IN IP4 224.2.1.3/127Benzer şekilde, bir IPv6 örneği şöyledir:
c=IN IP6 FF15::101/3bu da anlamsal olarak şuna eşdeğerdir:
c=IN IP6 FF15::101
c=IN IP6 FF15::102
c=IN IP6 FF15::103(IPv6 multicast’te TTL alanının bulunmadığı hatırlanmalıdır).
Birden fazla adres veya "c=" satırı, yalnızca hiyerarşik veya katmanlı bir kodlama şemasında farklı katmanlar için multicast adresleri sağlıyorsa, medya başına belirtilmesi UYGUNDUR. Oturum düzeyi bir "c=" alanı için belirtilmemelidir.
Yukarıda açıklanan çoklu adresler için eğik çizgi gösterimi, IP unicast adresleri için KULLANILMAMALIDIR.
5.8. Bant Genişliği ("b=")
b=<bwtype>:<bandwidth>Bu İSTEĞE BAĞLI alan, oturum veya medya tarafından kullanılması önerilen bant genişliğini belirtir. <bwtype>, <bandwidth> değerinin anlamını veren alfasayısal bir değiştiricidir. Bu belirtimde iki değer tanımlanmıştır; ancak gelecekte başka değerler KAYDEDİLEBİLİR (Bkz. Bölüm 8 ve [21], [25]):
- CT: Bir oturumun veya bir oturum içindeki medyanın bant genişliği, kapsamdan örtük olarak anlaşılan bant genişliğinden farklıysa, kullanılan bant genişliği için önerilen üst sınırı veren bir
b=CT:...satırı oturum için VERİLMELİDİR (“konferans toplamı” bant genişliği). Bunun temel amacı, iki veya daha fazla oturumun aynı anda birlikte var olup olamayacağına dair yaklaşık bir fikir vermektir. CT değiştiricisi RTP ile kullanıldığında, konferansın bir parçası olan birden fazla RTP oturumu varsa, konferans toplamı tüm RTP oturumlarının toplam bant genişliğini ifade eder. - AS: Bant genişliğinin uygulamaya özgü olduğu şeklinde yorumlanır (uygulamanın azami bant genişliği kavramı olacaktır). Normalde bu, uygulanabilirse uygulamanın "azami bant genişliği" denetiminde ayarlanan değerle örtüşür. RTP tabanlı uygulamalar için AS, [19]’un 6.2 Bölümünde tanımlandığı üzere RTP "oturum bant genişliğini" verir.
CT’nin, tüm sitelerdeki tüm ortamlar için toplam bir bant genişliği değeri verdiğine dikkat edin. AS ise tek bir sitedeki tek bir ortam için bir bant genişliği değeri verir; ancak aynı anda gönderim yapan birçok site olabilir.
<bwtype> adları için "X-" öneki tanımlanmıştır. Bu yalnızca deneysel amaçlar için tasarlanmıştır. Örneğin:
b=X-YZ:128"X-" önekinin kullanımı ÖNERİLMEZ: bunun yerine yeni değiştiriciler standart ad alanında IANA’ya kaydedilmelidir. SDP ayrıştırıcıları, bilinmeyen değiştiricilere sahip bant genişliği alanlarını YOK SAYMAK ZORUNDADIR. Değiştiriciler alfasayısal OLMALIDIR ve herhangi bir uzunluk sınırı verilmemiş olsa da kısa olmaları önerilir.
<bandwidth> varsayılan olarak saniye başına kilobit olarak yorumlanır. Yeni bir <bwtype> değiştiricisinin tanımı, bant genişliğinin başka bir alternatif birimde yorumlanacağını belirtebilir (bu notta tanımlanan "CT" ve "AS" değiştiricileri varsayılan birimleri kullanır).
5.9. Zamanlama ("t=")
t=<start-time> <stop-time>"t=" satırları bir oturumun başlangıç ve bitiş zamanlarını belirtir. Bir oturum düzensiz aralıklarla birden fazla zamanda etkinse birden çok "t=" satırı KULLANILABİLİR; her ek "t=" satırı, oturumun etkin olacağı ek bir zaman dilimini belirtir. Oturum düzenli zamanlarda etkinse, bir "t=" satırına ek olarak ve onu takiben bir "r=" satırı (aşağıya bakınız) kullanılmalıdır — bu durumda "t=" satırı, tekrar dizisinin başlangıç ve bitiş zamanlarını belirtir.
Birinci ve ikinci alt alanlar sırasıyla oturumun başlangıç ve bitiş zamanlarını verir. Bu değerler, 1900’den bu yana geçen saniyeler cinsinden Network Time Protocol (NTP) zaman değerlerinin ondalık gösterimidir [13]. Bu değerleri UNIX zamanına dönüştürmek için ondalık 2208988800 çıkarın.
NTP zaman damgaları başka yerlerde 64 bitlik değerler olarak temsil edilir ve bu değerler 2036 yılı civarında sarar. SDP keyfi uzunlukta ondalık bir gösterim kullandığından, bunun bir sorun oluşturması beklenmez (SDP zaman damgaları 1900’den itibaren saniyeleri saymaya DEVAM ETMELİDİR; NTP ise değeri 64 bit sınırına göre mod alarak kullanacaktır).
<stop-time> sıfır olarak ayarlanırsa, oturum sınırsızdır; ancak <start-time> sonrasına kadar etkin hale gelmez. <start-time> da sıfırsa, oturum kalıcı olarak kabul edilir.
Kullanıcı arayüzleri, sınırsız ve kalıcı oturumların oluşturulmasını güçlü biçimde caydırmalıdır; çünkü bu tür oturumlar oturumun gerçekte ne zaman sona ereceğine dair bilgi vermez ve bu da zamanlamayı zorlaştırır.
Zaman aşımına uğramamış sınırsız oturumlar kullanıcıya gösterilirken, genel varsayım olarak sınırsız bir oturumun yalnızca mevcut zamandan veya oturum başlangıç zamanından hangisi daha geçse ondan itibaren yarım saat boyunca etkin olacağı kabul edilebilir. Bundan farklı bir davranış gerekiyorsa, bir bitiş zamanı VERİLMELİ ve oturumun gerçekte ne zaman sona ermesi gerektiğine dair yeni bilgiler elde edildikçe uygun şekilde değiştirilmelidir.
Kalıcı oturumlar, oturumun tam olarak ne zaman etkin olacağını açıkça belirten ilişkili tekrar zamanları yoksa, kullanıcıya hiçbir zaman etkin değilmiş gibi gösterilebilir.
5.10. Tekrar Zamanları ("r=")
r=<repeat interval> <active duration> <offsets from start-time>"r=" alanları bir oturum için tekrar zamanlarını belirtir. Örneğin, bir oturum Pazartesi günü saat 10:00’da ve Salı günü saat 11:00’da, her hafta birer saat olmak üzere üç ay boyunca etkinse, karşılık gelen "t=" alanındaki <start-time> ilk Pazartesi günü saat 10:00’un NTP gösterimi olur, <repeat interval> 1 hafta, <active duration> 1 saat olur ve ofsetler sıfır ve 25 saat olur. Karşılık gelen "t=" alanının bitiş zamanı, üç ay sonraki son oturumun bitişinin NTP gösterimi olur. Varsayılan olarak tüm alanlar saniye cinsindendir; dolayısıyla "r=" ve "t=" alanları aşağıdaki gibi olabilir:
t=3034423619 3042462419
r=604800 3600 0 90000Açıklamayı daha derli toplu yapmak için zamanlar gün, saat veya dakika birimleriyle de verilebilir. Bunların sözdizimi, hemen ardından tek bir büyük/küçük harfe duyarlı karakter gelen bir sayıdır. Kesirli birimler izinli değildir — bunun yerine daha küçük bir birim kullanılmalıdır. Aşağıdaki birim belirtim karakterlerine izin verilir:
- d — gün (86400 saniye)
- h — saat (3600 saniye)
- m — dakika (60 saniye)
- s — saniye (tamlık için izinlidir)
Dolayısıyla, yukarıdaki oturum duyurusu aşağıdaki şekilde de yazılabilirdi:
r=7d 1h 0 25hAylık ve yıllık tekrarlar tek bir SDP tekrar zamanı ile doğrudan belirtilemez; bunun yerine, oturum zamanlarını açıkça listelemek için ayrı "t=" alanları kullanılmalıdır.
5.11. Zaman Dilimleri ("z=")
z=<adjustment time> <offset> <adjustment time> <offset> ....Yaz saati uygulamasından standart zamana veya tersine geçişi kapsayan tekrarlı bir oturumu zamanlamak için, temel zamandan ofsetlerin belirtilmesi gerekir. Bunun nedeni, farklı zaman dilimlerinin günün farklı saatlerinde zaman değiştirmesi, farklı ülkelerin yaz saati uygulamasına farklı tarihlerde geçmesi veya çıkması ve bazı ülkelerde yaz saati uygulamasının hiç olmamasıdır.
Dolayısıyla, kış ve yaz boyunca aynı saatte olan bir oturumu zamanlamak için, bir oturumun hangi zaman dilimine göre zamanlandığının açık ve net biçimde belirtilebilmesi gerekir. Alıcılar için bu görevi basitleştirmek amacıyla, göndericinin zaman dilimi ayarlamasının gerçekleştiği NTP zamanını ve oturumun ilk kez zamanlandığı andaki zamandan olan ofseti belirtmesine izin verilir. "z=" alanı, göndericinin bu ayarlama zamanlarının ve temel zamandan olan ofsetlerin bir listesini belirtmesine olanak tanır.
Bir örnek aşağıdaki gibi olabilir:
z=2882844526 -1h 2898848070 0Bu, 2882844526 zamanında oturumun tekrar zamanlarının hesaplandığı zaman tabanının 1 saat geri alındığını ve 2898848070 zamanında oturumun özgün zaman tabanının geri yüklendiğini belirtir. Ayarlamalar her zaman belirtilen başlangıç zamanına göredir — birikimli değildir. Ayarlamalar, bir oturum tanımındaki tüm "t=" ve "r=" satırlarına uygulanır.
Bir oturumun birkaç yıl sürmesi muhtemelse, tek bir oturum duyurusunda birkaç yıllık ayarlamaların iletilmesi yerine, oturum duyurusunun periyodik olarak değiştirilmesi beklenir.
5.12. Şifreleme Anahtarları ("k=")
k=<method>
k=<method>:<encryption key>Güvenli ve güvenilir bir kanal üzerinden taşındığında, Oturum Tanımlama Protokolü şifreleme anahtarlarını iletmek için KULLANILABİLİR. Anahtar değişimi için basit bir mekanizma anahtar alanı ("k=") ile sağlanır; ancak bu, esas olarak eski uygulamalarla uyumluluk için desteklenir ve kullanımı ÖNERİLMEZ. SDP ile kullanılmak üzere yeni anahtar değişim mekanizmalarını tanımlamak için çalışmalar sürmektedir [27] [28] ve yeni uygulamaların bu mekanizmaları kullanması beklenmektedir.
Bir anahtar alanına ilk ortam girdisinden önce izin verilir (bu durumda oturumdaki tüm ortamlar için geçerlidir) veya gerektiğinde her bir ortam girdisi için verilebilir. Anahtarların biçimi ve kullanımı bu belgenin kapsamı dışındadır ve anahtar alanı, kullanılacak şifreleme algoritmasını, anahtar türünü veya anahtarla ilgili diğer bilgileri belirtmenin bir yolunu sağlamaz: bunların SDP’yi kullanan üst düzey protokol tarafından sağlandığı varsayılır. Bu bilgilerin SDP içinde iletilmesine ihtiyaç varsa, daha önce belirtilen uzantılar KULLANILMALIDIR. Birçok güvenlik protokolü iki anahtar gerektirir: biri gizlilik, diğeri bütünlük için. Bu belirtim iki anahtarın aktarımını desteklemez.
Yöntem, kullanılabilir bir anahtarın harici yollarla veya verilen kodlanmış şifreleme anahtarından elde edilmesi için kullanılacak mekanizmayı belirtir. Aşağıdaki yöntemler tanımlanmıştır:
k=clear:<encryption key>Şifreleme anahtarı bu anahtar alanında dönüştürülmeden yer alır. Bu yöntem, SDP’nin güvenli bir kanal üzerinden iletildiği garanti edilemediği sürece KULLANILMAMALIDIR. Şifreleme anahtarı, karakter kümesi özniteliğine göre metin olarak yorumlanır; SDP’de aksi halde yasaklı olan karakterleri iletmek için "k=base64:" yöntemini kullanın.
k=base64:<encoded encryption key>Şifreleme anahtarı bu anahtar alanında yer alır ancak SDP’de yasaklı olan karakterleri içerdiği için base64 ile kodlanmıştır [12]. Bu yöntem, SDP’nin güvenli bir kanal üzerinden iletildiği garanti edilemediği sürece KULLANILMAMALIDIR.
k=uri:<URI to obtain key>Anahtar alanına bir Uniform Resource Identifier eklenir. URI, anahtarı içeren veriye başvurur ve anahtarın döndürülmesinden önce ek kimlik doğrulama gerektirebilir. Verilen URI’ye bir istek yapıldığında, yanıt anahtar için kullanılan kodlamayı belirtmelidir. URI çoğunlukla Secure Socket Layer/Transport Layer Security (SSL/TLS) ile korunan bir HTTP URI’sidir ("https:"), ancak bu zorunlu değildir.
k=promptBu SDP tanımında herhangi bir anahtar yer almaz, ancak bu anahtar alanının işaret ettiği oturum veya ortam akışı şifrelenmiştir. Oturuma katılmaya çalışırken kullanıcıdan anahtar istenmelidir ve kullanıcı tarafından sağlanan bu anahtar daha sonra ortam akışlarının şifresini çözmek için kullanılmalıdır. Kullanıcı tarafından belirlenen anahtarların kullanımı, bu tür anahtarların genellikle zayıf güvenlik özelliklerine sahip olması nedeniyle ÖNERİLMEZ.
Anahtar alanı, SDP’nin güvenli ve güvenilir bir kanal üzerinden iletildiği garanti edilemediği sürece KULLANILMAMALIDIR. Böyle bir kanala örnek olarak S/MIME mesajı içine gömülü SDP veya TLS ile korunan bir HTTP oturumu verilebilir. Güvenli kanalın, aracı bir tarafla değil, oturuma katılmaya yetkili tarafla kurulmuş olduğundan emin olmak önemlidir: bir önbellekleme proxy sunucusu kullanılıyorsa, proxy’nin ya güvenilir olduğundan ya da SDP’ye erişemediğinden emin olmak gerekir.
5.13. Öznitelikler ("a=")
a=<attribute>
a=<attribute>:<value>Öznitelikler SDP’yi genişletmenin birincil yoludur. Öznitelikler "oturum düzeyi" öznitelikler, "ortam düzeyi" öznitelikler veya her ikisi olarak kullanılacak şekilde tanımlanabilir.
Bir ortam tanımı, ortama özgü olan herhangi sayıda öznitelik ("a=" alanları) içerebilir. Bunlara "ortam düzeyi" öznitelikler denir ve ortam akışı hakkında bilgi ekler. Öznitelik alanları ilk ortam alanından önce de eklenebilir; bu "oturum düzeyi" öznitelikler, tek tek ortamlar yerine konferansın tamamına uygulanan ek bilgiler iletir.
Öznitelik alanları iki biçimde olabilir:
- Özellik öznitelikleri basitçe
a=<flag>biçimindedir. Bunlar ikili özniteliklerdir ve özniteliğin varlığı, özniteliğin oturumun bir özelliği olduğunu iletir. Bir örneka=recvonlyolabilir. - Değer öznitelikleri
a=<attribute>:<value>biçimindedir. Örneğin, bir beyaz tahtaa=orient:landscapedeğer özniteliğine sahip olabilir.
Özniteliklerin yorumlanması çağrılan ortam aracına bağlıdır. Bu nedenle, oturum tanımlarını alan alıcılar, genel olarak oturum tanımlarının ve özel olarak özniteliklerin yorumlanmasında yapılandırılabilir olmalıdır.
Öznitelik adları ISO-10646/UTF-8’in US-ASCII alt kümesini KULLANMAK ZORUNDADIR.
Öznitelik değerleri oktet dizgeleridir ve 0x00 (Nul), 0x0A (LF) ve 0x0D (CR) dışında herhangi bir oktet değerini KULLANABİLİR. Varsayılan olarak, öznitelik değerleri UTF-8 kodlamalı ISO-10646 karakter kümesine göre yorumlanır. Diğer metin alanlarının aksine, öznitelik değerleri normalde "charset" özniteliğinden ETKİLENMEZ; çünkü bu, bilinen değerlere karşı karşılaştırmaları sorunlu hale getirir. Ancak bir öznitelik tanımlanırken, karakter kümesine bağlı olacak şekilde tanımlanabilir; bu durumda değeri ISO-10646 yerine oturum karakter kümesine göre yorumlanmalıdır.
Öznitelikler IANA’ya kaydedilmek ZORUNDADIR (Bkz. Bölüm 8). Anlaşılmayan bir öznitelik alınırsa, alıcı tarafından YOK SAYILMAK ZORUNDADIR.
5.14. Ortam Tanımları ("m=")
m=<media> <port> <proto> <fmt> ...Bir oturum tanımı birden fazla ortam tanımı içerebilir. Her ortam tanımı bir m= alanı ile başlar ve ya bir sonraki m= alanı ile ya da oturum tanımının sonuyla biter. Bir ortam alanının birkaç alt alanı vardır:
<media>ortam türüdür. Şu anda tanımlı ortamlar "audio", "video", "text", "application" ve "message"’dır; ancak bu liste gelecekte genişletilebilir (Bkz. Bölüm 8).<port>, ortam akışının gönderildiği taşıma portudur. Taşıma portunun anlamı, ilgilic=alanında belirtildiği üzere kullanılan ağa ve ortam alanının<proto>alt alanında tanımlanan taşıma protokolüne bağlıdır. Ortam uygulaması tarafından kullanılan diğer portlar (örneğin RTP Control Protocol (RTCP) portu [19]) temel ortam portundan algoritmik olarak türetilebilir veya ayrı bir öznitelikte belirtilebilir (örneğin, [22]’de tanımlandığı üzerea=rtcp:).Bitişik olmayan portlar kullanılıyorsa veya çift RTP portları ve tek RTCP portları şeklindeki parite kuralını izlemiyorlarsa,
a=rtcp:özniteliği KULLANILMAK ZORUNDADIR.<port>değeri tek olan vea=rtcp:özniteliğinin mevcut olduğu durumlarda ortama gönderim yapması istenen uygulamalar, RTP portundan 1 ÇIKARMAMALIDIR: yani RTP’yi<port>’ta belirtilen porta, RTCP’yi isea=rtcpözniteliğinde belirtilen porta göndermelidir.Hiyerarşik olarak kodlanmış akışların bir tekil yayın adresine gönderildiği uygulamalarda, birden fazla taşıma portunun belirtilmesi gerekebilir. Bu,
c=alanında IP çok noktaya yayın adresleri için kullanılan gösterime benzer bir gösterim kullanılarak yapılır:``
m=<media> <port>/<number of ports> <proto> <fmt> ...``Böyle bir durumda, kullanılan portlar taşıma protokolüne bağlıdır. RTP için varsayılan olarak, yalnızca çift numaralı portlar veri için kullanılır ve bunlara karşılık gelen bir üstteki tek numaralı portlar RTP oturumuna ait RTCP için kullanılır;
<number of ports>ise RTP oturumlarının sayısını belirtir. Örneğin:``
m=video 49170/2 RTP/AVP 31``bu, 49170 ve 49171 portlarının bir RTP/RTCP çifti, 49172 ve 49173 portlarının ise ikinci RTP/RTCP çiftini oluşturduğunu belirtir. RTP/AVP taşıma protokolüdür ve 31 formattır (aşağıya bakınız). Bitişik olmayan portlar gerekiyorsa, bunlar ayrı bir öznitelik kullanılarak işaretlenmelidir (örneğin, [22]’de tanımlandığı üzere
a=rtcp:).c=alanında birden fazla adres vem=alanında birden fazla port belirtilmişse, porttan karşılık gelen adrese bire bir bir eşleme varsayılır. Örneğin:``
c=IN IP4 224.2.1.1/127/2 m=video 49170/2 RTP/AVP 31``bu, 224.2.1.1 adresinin 49170 ve 49171 portlarıyla, 224.2.1.2 adresinin ise 49172 ve 49173 portlarıyla kullanıldığını ima eder.
Aynı taşıma adresini kullanan birden fazla
m=satırının anlambilimi tanımlı değildir. Bu, geçmişteki sınırlı uygulamaların aksine, bu tür yollarla tanımlanmış örtük bir gruplamanın olmadığı anlamına gelir; bunun yerine amaçlanan anlambilimi ifade etmek için açık bir gruplama çerçevesi (örneğin, [18]) kullanılmalıdır.<proto>aktarım protokolüdür. Aktarım protokolünün anlamı, ilgilic=alanındaki adres türü alanına bağlıdır. Dolayısıyla IP4 olan birc=alanı, aktarım protokolünün IP4 üzerinde çalıştığını belirtir. Aşağıdaki aktarım protokolleri tanımlanmıştır; ancak IANA’ya yeni protokollerin kaydedilmesi yoluyla genişletilebilirler (bkz. Bölüm 8):udp: UDP üzerinde çalışan, belirtilmemiş bir protokolü ifade eder.RTP/AVP: UDP üzerinde çalışan, Asgari Denetimli Ses ve Video Konferansları için RTP Profili altında kullanılan RTP [19]’yi ifade eder [20].RTP/SAVP: UDP üzerinde çalışan Güvenli Gerçek Zamanlı Aktarım Protokolü’nü (Secure Real-time Transport Protocol) [23] ifade eder.
Medya biçimine ek olarak aktarım protokolünü belirtmenin temel nedeni, ağ protokolü aynı olsa bile aynı standart medya biçimlerinin farklı aktarım protokolleri üzerinden taşınabilmesidir. Ayrıca, biçimden bağımsız ancak aktarım protokolüne özgü ara birimler ve izleme araçları da mümkündür.
<fmt>bir medya biçimi açıklamasıdır. Dördüncü ve bundan sonraki tüm alt alanlar medyanın biçimini tanımlar. Medya biçiminin yorumu<proto>alt alanının değerine bağlıdır.<proto>alt alanıRTP/AVPveyaRTP/SAVPise,<fmt>alt alanları RTP yük türü numaralarını içerir. Bir yük türü numaraları listesi verildiğinde, bu tüm yük biçimlerinin oturumda KULLANILABİLECEĞİ anlamına gelir; ancak bu biçimlerin ilki oturum için varsayılan biçim olarak KULLANILMALIDIR. Dinamik yük türü atamaları için, bir RTP yük türü numarasını yük biçimini tanımlayan bir medya kodlama adına eşlemek amacıylaa=rtpmap:özniteliği (bkz. Bölüm 6) KULLANILMALIDIR. Biçim parametrelerini belirtmek içina=fmtp:özniteliği KULLANILABİLİR (bkz. Bölüm 6).<proto>alt alanıudpise,<fmt>alt alanları "audio", "video", "text", "application" veya "message" üst düzey medya türleri altında biçimi tanımlayan bir medya türüne MUTLAKA başvurmalıdır. Medya türü kaydı, UDP aktarımıyla kullanım için paket biçimini TANIMLAMALIDIR.Diğer aktarım protokollerini kullanan medyalar için
<fmt>alanı protokole özgüdür.<fmt>alt alanının yorumlanmasına ilişkin kurallar, yeni protokoller kaydedilirken TANIMLANMALIDIR (bkz. Bölüm 8.2.2).
#6. SDP Öznitelikleri
Aşağıdaki öznitelikler tanımlanmıştır. Uygulama yazarları gerektikçe yeni öznitelikler ekleyebileceğinden, bu liste kapsamlı değildir. Yeni özniteliklerin kayıt prosedürleri Bölüm 8.2.4’te tanımlanmıştır.
a=cat:<category>Bu öznitelik, oturumun nokta ile ayrılmış hiyerarşik kategorisini verir. Bu, alıcının istenmeyen oturumları kategoriye göre filtrelemesini sağlamak içindir. Kategoriler için merkezi bir kayıt yoktur. Bu bir oturum düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
a=keywds:<keywords>Cat özniteliğinde olduğu gibi, bu da alıcı tarafında istenen oturumların belirlenmesine yardımcı olur. Bu, alıcının oturumun amacını tanımlayan anahtar sözcüklere dayanarak ilgi çekici oturumları seçmesine olanak tanır; anahtar sözcükler için merkezi bir kayıt yoktur. Bu bir oturum düzeyi özniteliğidir. Karakter kümesine bağlı bir özniteliktir; yani değeri, belirtilmişse oturum tanımı için belirtilen karakter kümesinde, aksi halde varsayılan olarak ISO 10646/UTF-8’de yorumlanmalıdır.
a=tool:<name and version of tool>Bu, oturum tanımını oluşturmak için kullanılan aracın adını ve sürüm numarasını verir. Bu bir oturum düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
a=ptime:<packet time>Bu, bir pakette temsil edilen medyanın milisaniye cinsinden zaman uzunluğunu verir. Bu muhtemelen yalnızca ses verileri için anlamlıdır, ancak mantıklı olduğu takdirde diğer medya türleriyle de kullanılabilir. RTP veya vat sesini çözmek için ptime bilgisinin bilinmesi gerekli olmamalıdır ve sesin kodlanması/paketlenmesi için bir öneri olarak tasarlanmıştır. Bu bir medya düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
a=maxptime:<maximum packet time>Bu, her bir pakette kapsüllenebilecek azami medya miktarını, milisaniye cinsinden zaman olarak ifade eder. Zaman, pakette bulunan medyanın temsil ettiği zamanların toplamı olarak HESAPLANMALIDIR. Kare tabanlı kodekler için zaman, kare boyutunun tamsayı katı OLMALIDIR. Bu öznitelik muhtemelen yalnızca ses verileri için anlamlıdır, ancak mantıklı olduğu takdirde diğer medya türleriyle de kullanılabilir. Bu bir medya düzeyi özniteliğidir ve karakter kümesine bağlı değildir. Bu özniteliğin RFC 2327’den sonra tanıtıldığı ve güncellenmemiş uygulamaların bu özniteliği yok sayacağı unutulmamalıdır.
a=rtpmap:<payload type> <encoding name>/<clock rate> [/<encoding parameters>]Bu öznitelik, bir RTP yük türü numarasını (m= satırında kullanıldığı şekilde) kullanılacak yük biçimini belirten bir kodlama adına eşler. Ayrıca saat hızı ve kodlama parametreleri hakkında bilgi sağlar. Bu, karakter kümesine bağlı olmayan bir medya düzeyi özniteliğidir.
Bir RTP profili, yük türü numaralarını yük biçimlerine statik olarak atayabilse de, bu atamanın a=rtpmap: öznitelikleri kullanılarak dinamik olarak yapılması daha yaygındır. Statik bir yük türüne örnek olarak, 8 kHz’de örneklenmiş u-law PCM kodlu tek kanallı sesi ele alalım. Bu, RTP Ses/Video profilinde yük türü 0 olarak tamamen tanımlanmıştır; dolayısıyla a=rtpmap: özniteliğine gerek yoktur ve UDP portu 49232’ye gönderilen böyle bir akış için medya şu şekilde belirtilebilir:
m=audio 49232 RTP/AVP 0Dinamik bir yük türüne örnek olarak, 16 kHz’de örneklenmiş 16 bit doğrusal kodlu stereo sesi ele alalım. Bu akış için dinamik RTP/AVP yük türü 98’i kullanmak istersek, onu çözmek için ek bilgi gereklidir:
m=audio 49232 RTP/AVP 98
a=rtpmap:98 L16/16000/2Belirtilen her bir medya biçimi için en fazla bir rtpmap özniteliği tanımlanabilir. Dolayısıyla aşağıdakine sahip olabiliriz:
m=audio 49230 RTP/AVP 96 97 98
a=rtpmap:96 L8/8000
a=rtpmap:97 L16/8000
a=rtpmap:98 L16/11025/2Dinamik yük türlerinin kullanımını belirten RTP profilleri, bu profil SDP ile kullanılacaksa geçerli kodlama adları kümesini ve/veya kodlama adlarını kaydetmek için bir yöntemi TANIMLAMALIDIR. "RTP/AVP" ve "RTP/SAVP" profilleri, "m=" satırında belirtilen üst düzey medya türü altında kodlama adları için medya alt türlerini kullanır. Yukarıdaki örnekte medya türleri "audio/l8" ve "audio/l16"’dır.
Ses akışları için <encoding parameters>, ses kanallarının sayısını belirtir. Bu parametre OPSİYONELDİR ve kanal sayısı bir ise ve ek parametreler gerekmiyorsa atlanabilir.
Video akışları için şu anda herhangi bir kodlama parametresi belirtilmemiştir.
İleride ek kodlama parametreleri TANIMLANABİLİR; ancak kodeğe özgü parametreler EKLENMEMELİDİR. Bir "a=rtpmap:" özniteliğine eklenen parametreler, bir oturum dizininin bir oturuma katılmak için uygun medyayı seçebilmesi adına gerekli olanlarla sınırlı OLMALIDIR. Kodeğe özgü parametreler diğer özniteliklere eklenmelidir (örneğin, "a=fmtp:").
Not: RTP ses biçimleri genellikle paket başına örnek sayısı hakkında bilgi içermez. Varsayılan olmayan (RTP Ses/Video Profilinde tanımlandığı şekilde) bir paketleme gerekiyorsa, yukarıda verildiği gibi "ptime" özniteliği kullanılır.
#a=recvonly
Bu, uygulanabildiği durumlarda araçların yalnızca alma kipinde başlatılması gerektiğini belirtir. Bir oturum veya medya düzeyi özniteliği olabilir ve karakter kümesine bağlı değildir. recvonly’nin yalnızca medyaya uygulandığı, ilişkili herhangi bir denetim protokolüne uygulanmadığı unutulmamalıdır (örneğin, recvonly kipindeki RTP tabanlı bir sistem RTCP paketlerini yine de GÖNDERMELİDİR).
#a=sendrecv
Bu, araçların gönderme ve alma kipinde başlatılması gerektiğini belirtir. Varsayılanı yalnızca alma kipi olan araçlarla etkileşimli konferanslar için bu gereklidir. Bir oturum veya medya düzeyi özniteliği olabilir ve karakter kümesine bağlı değildir.
"sendonly", "recvonly", "inactive" ve "sendrecv" özniteliklerinden hiçbiri yoksa, konferans türü "broadcast" veya "H332" olmayan oturumlar için varsayılan olarak "sendrecv" KABUL EDİLMELİDİR (aşağıya bakınız).
#a=sendonly
Bu, araçların yalnızca gönderme kipinde başlatılması gerektiğini belirtir. Bir örnek, trafik hedefi için trafik kaynağından farklı bir tekil yayın (unicast) adresinin kullanılacağı durum olabilir. Böyle bir durumda, biri sendonly ve diğeri recvonly olmak üzere iki medya tanımı kullanılabilir. Bir oturum veya medya düzeyi özniteliği olabilir, ancak normalde yalnızca bir medya özniteliği olarak kullanılır. Karakter kümesine bağlı değildir. sendonly’nin yalnızca medyaya uygulandığı ve ilişkili herhangi bir denetim protokolünün (örneğin, RTCP) yine de normal şekilde ALINMASI ve İŞLENMESİ GEREKTİĞİ unutulmamalıdır.
#a=inactive
Bu, araçların etkin olmayan kipte başlatılması gerektiğini belirtir. Bu, kullanıcıların diğer kullanıcıları beklemeye alabileceği etkileşimli konferanslar için gereklidir. Etkin olmayan bir medya akışı üzerinden medya gönderilmez. RTP tabanlı bir sistemin, etkin olmayan kipte başlatılsa bile RTCP GÖNDERMESİ GEREKTİĞİ unutulmamalıdır. Bir oturum veya medya düzeyi özniteliği olabilir ve karakter kümesine bağlı değildir.
#a=orient:<orientation>
Normalde bu yalnızca bir beyaz tahta veya sunum aracı için kullanılır. Ekrandaki çalışma alanının yönelimini belirtir. Bu bir medya düzeyi özniteliğidir. İzin verilen değerler "portrait", "landscape" ve "seascape" (baş aşağı yatay) şeklindedir. Karakter kümesine bağlı değildir.
#a=type:<conference type>
Bu, konferansın türünü belirtir. Önerilen değerler "broadcast", "meeting", "moderated", "test" ve "H332"’dir. "type:broadcast" oturumları için varsayılan "recvonly" olmalıdır, "type:meeting" "sendrecv" anlamına gelmelidir ve "type:moderated" bir söz kontrol aracının kullanımını ve konferansa katılan yeni sitelerin sesinin kısılacak şekilde medya araçlarının başlatıldığını göstermelidir.
"type:H332" özniteliğinin belirtilmesi, bu gevşek bağlı oturumun ITU H.332 belirtimi [26] ile tanımlandığı şekilde bir H.332 oturumunun parçası olduğunu gösterir. Medya araçları "recvonly" olarak başlatılmalıdır.
"type:test" özniteliğinin belirtilmesi, açıkça aksi istenmedikçe alıcıların bu oturum tanımını kullanıcılara göstermekten güvenle kaçınabileceğine dair bir ipucu olarak önerilir.
Type özniteliği bir oturum düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
#a=charset:<character set>
Bu, oturum adını ve bilgi verilerini görüntülemek için kullanılacak karakter kümesini belirtir. Varsayılan olarak UTF-8 kodlamasında ISO-10646 karakter kümesi kullanılır. Daha kompakt bir gösterim gerekiyorsa, diğer karakter kümeleri kullanılabilir. Örneğin, ISO 8859-1 aşağıdaki SDP özniteliği ile belirtilir:
a=charset:ISO-8859-1Bu bir oturum düzeyi özniteliğidir ve karakter kümesine bağlı değildir. Belirtilen karakter kümesi, ISO-8859-1 gibi IANA’ya kayıtlı olanlardan biri OLMALIDIR. Karakter kümesi tanımlayıcısı bir US-ASCII dizgesidir ve IANA tanımlayıcılarıyla BÜYÜK/küçük harfe duyarsız bir karşılaştırma kullanılarak karşılaştırılmalıdır. Tanımlayıcı tanınmıyorsa veya desteklenmiyorsa, bundan etkilenen tüm dizgeler sekizli (octet) dizgeler olarak KABUL EDİLMELİDİR.
Belirtilen bir karakter kümesinin yine de 0x00 (Nul), 0x0A (LF) ve 0x0D (CR) baytlarının kullanımını yasaklaması GEREKTİĞİ unutulmamalıdır. Bu karakterlerin kullanımını gerektiren karakter kümeleri, bu baytların metin alanları içinde görünmesini engelleyen bir alıntılama mekanizması TANIMLAMALIDIR.
#a=sdplang:<language tag>
Bu bir oturum düzeyi veya medya düzeyi özniteliği olabilir. Oturum düzeyi özniteliği olarak, oturum tanımı için dili belirtir. Medya düzeyi özniteliği olarak, o medyayla ilişkili herhangi bir medya düzeyi SDP bilgi alanı için dili belirtir. Oturum tanımında veya medyada birden fazla dil kullanılıyorsa, oturum veya medya düzeyinde birden fazla sdplang özniteliği sağlanabilir; bu durumda özniteliklerin sırası, en önemli dilden en az önemli dile doğru önem sırasını gösterir.
Genel olarak, birden fazla dilden oluşan oturum tanımlarının gönderilmesi önerilmez. Bunun yerine, her dil için bir tane olmak üzere oturumu tanımlayan birden fazla tanım GÖNDERİLMELİDİR. Ancak bu tüm aktarım mekanizmalarıyla mümkün değildir; bu nedenle birden fazla sdplang özniteliğine izin verilir, ancak ÖNERİLMEZ.
"sdplang" öznitelik değeri, US-ASCII [9] içinde tek bir RFC 3066 dil etiketi olmalıdır. Karakter kümesi özniteliğine bağlı değildir. Bir oturum, alıcıların dilinin varsayılamayacağı coğrafi sınırları aşacak kadar geniş kapsamlıysa veya oturum yerel olarak varsayılan normdan farklı bir dildeyse, bir "sdplang" özniteliği BELİRTİLMELİDİR.
#a=lang:<language tag>
Bu bir oturum düzeyi veya medya düzeyi özniteliği olabilir. Oturum düzeyi özniteliği olarak, tanımlanan oturum için varsayılan dili belirtir. Medya düzeyi özniteliği olarak, belirtilmiş herhangi bir oturum düzeyi dili geçersiz kılarak o medya için dili belirtir. Oturum tanımı veya medya birden fazla dil kullanıyorsa, oturum veya medya düzeyinde birden fazla lang özniteliği sağlanabilir; bu durumda özniteliklerin sırası, en önemli dilden en az önemli dile doğru önem sırasını gösterir.
"lang" öznitelik değeri, US-ASCII [9] içinde tek bir RFC 3066 dil etiketi olmalıdır. Karakter kümesi özniteliğine bağlı değildir. Bir oturum, alıcıların dilinin varsayılamayacağı coğrafi sınırları aşacak kadar geniş kapsamlıysa veya oturum yerel olarak varsayılan normdan farklı bir dildeyse, bir "lang" özniteliği BELİRTİLMELİDİR.
#a=framerate:<frame rate>
Bu, saniye başına kare cinsinden azami video kare hızını verir. Video verilerinin kodlanması için bir öneri olarak tasarlanmıştır. "<tamsayı>.<kesir>" gösterimini kullanan ondalık kesirli değerlerin gösterimine izin verilir. Bu, yalnızca video medyası için tanımlanmış bir medya düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
#a=quality:<quality>
Bu, kodlamanın kalitesi için tamsayı bir değer olarak bir öneri verir. Video için quality özniteliğinin amacı, kare hızı ile durağan görüntü kalitesi arasında varsayılan olmayan bir ödünleşimi belirtmektir. Video için değer 0 ile 10 aralığındadır ve aşağıdaki önerilen anlama sahiptir:
- 10 – sıkıştırma şemasının sağlayabileceği en iyi durağan görüntü kalitesi.
- 5 – herhangi bir kalite önerisi verilmediğinde varsayılan davranış.
- 0 – kodek tasarımcısının hâlâ kullanılabilir olduğunu düşündüğü en kötü durağan görüntü kalitesi.
Bu bir medya düzeyi özniteliğidir ve karakter kümesine bağlı değildir.
#a=fmtp:<format> <format specific parameters>
Bu öznitelik, belirli bir biçime özgü parametrelerin SDP’nin bunları anlamasına gerek kalmadan iletilmesine olanak tanır. Biçim, medya için belirtilen biçimlerden biri olmalıdır. Biçime özgü parametreler, SDP tarafından iletilmesi gereken ve bu biçimi kullanacak medya aracına değişmeden aktarılacak herhangi bir parametre kümesi olabilir. Her biçim için bu özniteliğin en fazla bir örneğine izin verilir.
Bu, medya düzeyinde bir özniteliktir ve karakter kümesine bağlı değildir.
#7. Güvenlik Hususları
SDP, tekil yayın (unicast) oturumları için parametreler üzerinde anlaşmak amacıyla teklif/yanıt modeli [17] kullanılarak Oturum Başlatma Protokolü (Session Initiation Protocol, SIP) [15] ile birlikte sıklıkla kullanılır. Bu şekilde kullanıldığında, söz konusu protokollerin güvenlik hususları geçerlidir.
SDP, multimedya oturumlarını tanımlayan bir oturum tanımlama biçimidir. Bir SDP mesajını alan ve buna göre işlem yapan varlıklar, bir oturum tanımının, bilinen ve güvenilir bir kaynaktan, kimliği doğrulanmış bir taşıma protokolü aracılığıyla elde edilmediği sürece güvenilir kabul edilemeyeceğinin farkında OLMALIDIR. Oturum tanımlarını dağıtmak için birçok farklı taşıma protokolü kullanılabilir ve kimlik doğrulamanın niteliği taşıma protokolünden taşıma protokolüne farklılık gösterecektir. Bazı taşımalarda güvenlik özellikleri çoğu zaman devreye alınmamıştır. Bir oturum tanımı güvenilir bir şekilde elde edilmediyse, uç nokta dikkatli OLMALIDIR; çünkü diğer saldırıların yanı sıra, alınan medya oturumları amaçlanan oturumlar olmayabilir, medyanın gönderildiği hedef beklenen hedef olmayabilir, oturumun herhangi bir parametresi yanlış olabilir veya medya güvenliği ihlal edilmiş olabilir. Uç noktanın, uygulamanın güvenlik risklerini ve kullanıcı tercihlerini dikkate alarak makul bir karar vermesi gerekir ve oturumu kabul edip etmeme konusunda kullanıcıya sorulmasına karar verebilir.
Oturum tanımlarını dağıtmak için kullanılabilecek taşımalardan biri Oturum Duyuru Protokolü’dür (Session Announcement Protocol, SAP). SAP hem şifreleme hem de kimlik doğrulama mekanizmaları sağlar; ancak oturum duyurularının doğası gereği, duyurunun alıcısı için duyuruyu başlatan taraf önceden bilinmediğinden ve ortak bir açık anahtar altyapısı bulunmadığından, birçok durumda bir oturum duyurusunun kaynağının kimliği doğrulanamayacaktır.
Kimliği doğrulanmamış bir taşıma mekanizması üzerinden veya güvenilmeyen bir taraftan bir oturum tanımı alındığında, oturumu ayrıştıran yazılım bazı önlemler almalıdır. Oturum tanımları, alıcının sisteminde yazılım başlatmak için gerekli bilgileri içerir. Bir oturum tanımını ayrıştıran yazılım, multimedya oturumlarına katılmak üzere uygun yazılım olarak özel olarak yapılandırılmış olanlar dışında başka yazılımları başlatabilme yeteneğine SAHİP OLMAMALIDIR. Bir kullanıcının sisteminde, multimedya oturumlarına katılmak için uygun yazılımları, kullanıcıya önce böyle bir yazılımın başlatılacağı bildirilmeden ve kullanıcının onayı alınmadan başlatmak, genellikle oturum tanımını ayrıştıran yazılımlar için uygunsuz kabul edilir. Bu nedenle, oturum duyurusu, e-posta, oturum daveti veya WWW sayfası yoluyla gelen bir oturum tanımı, kullanıcı bu eylemi açıkça önceden yetkilendirmedikçe kullanıcıyı etkileşimli bir multimedya oturumuna sokmamalıdır. Bir oturumun etkileşimli olup olmadığını belirlemek her zaman kolay olmadığından, emin olmayan uygulamalar oturumların etkileşimli olduğunu varsaymalıdır.
Bu belirtimde, bir oturum tanımının alıcısının multimedya araçlarını varsayılan olarak iletim yapacak bir kipte başlatması gerektiğini bildirmesine olanak tanıyan hiçbir öznitelik yoktur. Bazı koşullar altında bu tür özniteliklerin tanımlanması uygun olabilir. Bu yapılırsa, bu tür öznitelikler içeren bir oturum tanımını ayrıştıran bir uygulama, bunları ya yok saymalı ya da bu oturuma katılmanın multimedya verilerinin otomatik olarak iletilmesiyle sonuçlanacağını kullanıcıya bildirmelidir. Bilinmeyen bir öznitelik için varsayılan davranış, onu yok saymaktır.
Bazı ortamlarda, aracı sistemlerin diğer sinyalleşme protokolleri içinde yer alan oturum tanımlarını yakalaması ve analiz etmesi yaygın hale gelmiştir. Bu, medya akışlarının geçmesine izin vermek için güvenlik duvarlarında delikler açmak ya da trafiği seçici olarak işaretlemek, önceliklendirmek veya engellemek dahil ancak bunlarla sınırlı olmamak üzere çeşitli amaçlarla yapılır. Bazı durumlarda, bu tür aracı sistemler oturum tanımını değiştirebilir; örneğin, oturum tanımının içeriğinin dinamik olarak oluşturulan NAT bağlamalarıyla eşleşmesini sağlamak için. Bu davranışlar, oturum tanımının, aracı sistemin oturum tanımının gerçekliğini ve kaynağının bu tür iletişim oturumlarını kurma yetkisini doğrulayacak uygun kontrolleri yapmasına olanak tanıyan bir şekilde iletilmediği sürece ÖNERİLMEZ. SDP tek başına bu kontrolleri mümkün kılacak yeterli bilgiyi içermez; bunlar kapsülleyici protokole (ör. SIP veya RTSP) bağlıdır.
"k=" alanının kullanımı önemli bir güvenlik riski oluşturur; çünkü oturum şifreleme anahtarlarını açık biçimde iletir. SDP, SDP’nin iletildiği kanalın hem özel hem de kimliği doğrulanmış olduğu garanti edilemediği sürece anahtar materyalini iletmek için KULLANILMAMALIDIR. Ayrıca, "k=" satırı kriptografik anahtar algoritmalarını belirtmek veya müzakere etmek için herhangi bir yol sunmaz. Gizlilik ve bütünlük için ayrı anahtarlar yerine yalnızca tek bir simetrik anahtar sağladığından, kullanışlılığı ciddi şekilde sınırlıdır. Bölüm 5.12’de tartışıldığı üzere, "k=" satırının kullanımı ÖNERİLMEZ.
#8. IANA Hususları
8.1. "application/sdp" Medya Türü
RFC 2327’den gelen bir medya türü kaydı, aşağıda tanımlandığı şekilde güncellenecektir.
- Kime: ietf-types@iana.org
- Konu: "application/sdp" medya türünün kaydı
- Tür adı: application
- Alt tür adı: sdp
- Gerekli parametreler: Yok.
- İsteğe bağlı parametreler: Yok.
Kodlama hususları:
SDP dosyaları esas olarak UTF-8 biçiminde metindir. "a=charset:" özniteliği, bir SDP dosyasının belirli bölümlerinde diğer karakter kümelerinin varlığını belirtmek için kullanılabilir (bkz. RFC 4566 Bölüm 6). Keyfi ikili içerik SDP’de doğrudan temsil edilemez.
Güvenlik hususları:
RFC 4566 Bölüm 7’ye bakınız
Birlikte çalışabilirlik hususları:
RFC 4566’ya bakınız
Yayınlanan belirtim:
RFC 4566’ya bakınız
Bu medya türünü kullanan uygulamalar:
Voice over IP, video telekonferans, akış medyası, anlık mesajlaşma ve diğerleri. Ayrıca RFC 4566 Bölüm 3’e bakınız.
- Ek bilgiler:
- Sihirli numara(lar): Yok.
- Dosya uzantı(lar)ı: ".sdp" uzantısı yaygın olarak kullanılır.
- Macintosh Dosya Türü Kodu(ları): "sdp "
- Daha fazla bilgi için iletişim kurulacak kişi ve e-posta adresi:
- Mark Handley <M.Handley@cs.ucl.ac.uk>
- Colin Perkins <csp@csperkins.org>
- IETF MMUSIC çalışma grubu <mmusic@ietf.org>
- Amaçlanan kullanım: COMMON
- Yazar/Değişiklik denetleyicisi:
- RFC 4566 yazarları
- IESG tarafından yetkilendirilen IETF MMUSIC çalışma grubu
8.2. Parametrelerin Kaydı
IANA’ya kaydedilebilecek yedi alan adı vardır. SDP belirtimindeki Backus-Naur Formu (BNF) terminolojisi kullanılarak bunlar "media", "proto", "fmt", "att-field", "bwtype", "nettype" ve "addrtype" olarak adlandırılır.
8.2.1. Medya Türleri ("media")
Medya türleri kümesinin küçük olması amaçlanmaktadır ve nadir durumlar dışında genişletilmemelidir. Medya adları için, üst düzey medya içerik türleriyle aynı kurallar geçerli olmalı ve mümkün olan yerlerde SDP için MIME ile aynı ad kaydedilmelidir. Mevcut üst düzey medya içerik türleri dışındaki medyalar için, kaydedilecek yeni bir üst düzey içerik türü adına bir Standartlar Yolundaki RFC üretilmeli ve kayıt, neden mevcut hiçbir medya adının uygun olmadığını iyi gerekçelendirmelidir (RFC 2434 [8]’ün "Standards Action" politikası).
Bu not, "audio", "video", "text", "application" ve "message" medya türlerini kaydeder.
Not: "control" ve "data" medya türleri, bu belirtimin önceki sürümünde [6] geçerli olarak listelenmişti; ancak anlamsal tanımları hiçbir zaman tam olarak belirtilmedi ve yaygın olarak kullanılmamaktadır. Bu medya türleri bu belirtimde kaldırılmıştır; ancak RFC 3840 [24]’te tanımlandığı üzere bir SIP kullanıcı aracısı için hâlâ geçerli medya türü yetenekleri olarak kalmaktadır. Bu medya türleri gelecekte faydalı kabul edilirse, kullanımlarını belgelemek için bir Standartlar Yolundaki RFC üretilmelidir. Bu yapılana kadar, uygulamalar bu türleri KULLANMAMALI ve SIP yetenek bildirimlerinde destek beyan ETMEMELİDİR (RFC 3840 tarafından oluşturulan kayıtta mevcut olsalar bile).
8.2.2. Taşıma Protokolleri ("proto")
"proto" alanı kullanılan taşıma protokolünü tanımlar. Bu, Standartlar Yolundaki bir protokol RFC’sine atıfta bulunmalıdır. Bu not üç değeri kaydeder:
- "RTP/AVP", UDP/IP üzerinde çalışan, Asgari Kontrol ile Ses ve Video Konferansları için RTP Profili altında kullanılan RTP [19]’ye bir referanstır [20].
- "RTP/SAVP", Güvenli Gerçek Zamanlı Taşıma Protokolü’ne (Secure Real-time Transport Protocol) [23] bir referanstır.
- "udp", UDP üzerinde belirtilmemiş bir protokolü ifade eder.
Gelecekte başka RTP profilleri tanımlanırsa, bunların "proto" adları aynı şekilde belirtilmelidir. Örneğin, kısa adı "XYZ" olan bir RTP profili, "RTP/XYZ" değerine sahip bir "proto" alanı ile gösterilecektir.
Yeni taşıma protokolleri IANA’ya kaydedilmelidir. Kayıtlar, protokolü tanımlayan bir RFC’ye atıfta bulunmalıdır. Böyle bir RFC Deneysel veya Bilgilendirici OLABİLİR; ancak Standartlar Yolunda olması tercih edilir. Kayıtlar ayrıca, "fmt" ad alanlarının nasıl yönetileceğine ilişkin kuralları da tanımlamalıdır (aşağıya bakınız).
8.2.3. Medya Biçimleri ("fmt")
"proto" alanı ile tanımlanan her taşıma protokolünün, o protokol tarafından iletilebilecek medya biçimlerini tanımlayan ilişkili bir "fmt" ad alanı vardır. Biçimler, bir multimedya oturumunda taşınmak istenebilecek tüm olası kodlamaları kapsar.
"RTP/AVP" ve "RTP/SAVP" profilleri altındaki RTP yük biçimleri, "fmt" değeri olarak yük türü numarasını KULLANMALIDIR. Yük türü numarası bu oturum tanımı tarafından dinamik olarak atanıyorsa, yük biçimi için medya türü kaydında tanımlandığı şekilde biçim adını ve parametrelerini belirtmek üzere ek bir "rtpmap" özniteliği EKLENMELİDİR. SDP taşıma protokolleri olarak (RTP ile birlikte) kaydedilen diğer RTP profillerinin, "fmt" ad alanı için aynı kuralları belirtmesi ÖNERİLİR.
"udp" protokolü için yeni biçimler kaydedilmelidir. Biçim için mevcut bir medya alt türünün kullanılması teşvik edilir. Eğer bir medya alt türü yoksa, uygun bir tanesinin IETF süreci [31] aracılığıyla, biçim için taşıma protokolünü tanımlayan bir Standartlar Yolundaki RFC’nin üretilmesi veya buna atıfta bulunulması yoluyla kaydedilmesi ÖNERİLİR.
Diğer protokoller için, biçimler ilgili "proto" belirtiminin kurallarına göre KAYDEDİLEBİLİR.
Yeni biçim kayıtları, hangi taşıma protokollerine uygulandıklarını BELİRTMELİDİR.
8.2.4. Öznitelik Adları ("att-field")
Öznitelik alan adları ("att-field"), aynı ad altındaki çakışan özniteliklerden kaynaklanan belirgin sorunlar nedeniyle IANA’ya kaydedilmeli ve belgelenmelidir. SDP’de bilinmeyen öznitelikler basitçe yok sayılır; ancak protokolü parçalayan çakışan öznitelikler ciddi bir sorundur.
Yeni öznitelik kayıtları, RFC 2434’ün "Specification Required" politikasına göre kabul edilir; bunun için belirtimin aşağıdaki bilgileri içermesi gerekir:
- iletişim kurulacak kişinin adı, e-posta adresi ve telefon numarası
- öznitelik adı (SDP’de görüneceği şekilde)
- İngilizce uzun biçimli öznitelik adı
- öznitelik türü (oturum düzeyi, medya düzeyi veya her ikisi)
- öznitelik değerinin karakter kümesi özniteliğine tabi olup olmadığı
- özniteliğin amacını açıklayan bir paragraf
- bu öznitelik için uygun öznitelik değerlerinin belirtimi
Yukarıdakiler, IANA’nın kabul edeceği asgari gerekliliklerdir. Yaygın kullanım ve birlikte çalışabilirlik görmesi beklenen öznitelikler, özniteliği daha kesin biçimde tanımlayan bir Standartlar Yolundaki RFC ile belgelenmelidir.
Kayıt gönderenler, belirtimin SDP özniteliklerinin ruhuna uygun olmasını sağlamalıdır; özellikle de özniteliğin, işletim sistemleri hakkında örtük varsayımlarda bulunmayan ve birlikte çalışabilirliği engelleyebilecek şekilde belirli yazılım parçalarını adlandırmayan, platformdan bağımsız olması önemlidir.
IANA, bu notun Bölüm 6’sındaki tanımlarla (bu tanımlar RFC 2327’dekileri günceller) aşağıdaki ilk öznitelik adları kümesini ("att-field" değerleri) kaydetmiştir:
| Ad | Oturum mu Medya düzeyi mi? | Karakter kümesine bağlı mı? | |-----------|----------------------------|-----------------------------| | cat | Oturum | Hayır | | keywds | Oturum | Evet | | tool | Oturum | Hayır | | ptime | Medya | Hayır | | maxptime | Medya | Hayır | | rtpmap | Medya | Hayır | | recvonly | Her ikisi | Hayır | | sendrecv | Her ikisi | Hayır | | sendonly | Her ikisi | Hayır | | inactive | Her ikisi | Hayır | | orient | Medya | Hayır | | type | Oturum | Hayır | | charset | Oturum | Hayır | | sdplang | Her ikisi | Hayır | | lang | Her ikisi | Hayır | | framerate | Medya | Hayır | | quality | Medya | Hayır | | fmtp | Medya | Hayır |
8.2.5. Bant Genişliği Belirteçleri ("bwtype")
Bant genişliği belirteçlerinin çoğalması kesinlikle caydırılmaktadır.
Yeni bant genişliği belirteçleri ("bwtype" alanları) IANA’ya kaydedilmelidir. Başvuru, bant genişliği belirtecinin anlamsal tanımını kesin biçimde belirten, ne zaman kullanılması gerektiğini ve mevcut kayıtlı bant genişliği belirteçlerinin neden yeterli olmadığını açıklayan bir Standartlar Yolundaki RFC’ye atıfta bulunmalıdır.
IANA, bu notun Bölüm 5.8’inde yer alan tanımlarla (bu tanımlar RFC 2327’dekileri günceller) "CT" ve "AS" bant genişliği belirteçlerini kaydetmiştir.
8.2.6. Ağ Türleri ("nettype")
SDP’nin İnternet dışı ortamlar bağlamında kullanılması gerekiyorsa, yeni ağ türleri ("nettype" alanı) IANA’ya kaydedilebilir. Bunlar normalde IANA’nın alanına girmez; ancak bir İnternet uygulamasının, İnternet telefon çağrısının Anahtarlamalı Genel Telefon Ağı’na (Public Switched Telephone Network, PSTN) ağ geçidi üzerinden aktarılması gibi durumlarda İnternet dışı bir uygulama ile birlikte çalışması gerekebilir. Ağ türlerinin sayısı küçük olmalı ve nadiren genişletilmelidir. En az bir adres türü bu ağ türüyle birlikte kullanılmak üzere kaydedilmeden yeni bir ağ türü kaydedilemez. Yeni bir ağ türü kaydı, ağ türü ve adres türü hakkında ayrıntılar veren ve nasıl ve ne zaman kullanılacaklarını belirten bir RFC’ye atıfta bulunmalıdır.
IANA, İnternet’i temsil etmek üzere "IN" ağ türünü, bu notun Bölüm 5.2 ve 5.7’sindeki tanımlarla (bu tanımlar RFC 2327’dekileri günceller) kaydetmiştir.
8.2.7. Adres Türleri ("addrtype")
Yeni adres türleri ("addrtype") IANA nezdinde kaydedilebilir. Bir adres türü yalnızca bir ağ türü bağlamında anlamlıdır ve bir adres türünün herhangi bir kaydı, kayıtlı bir ağ türünü BELİRTMELİDİR ya da bir ağ türü kaydıyla birlikte sunulmalıdır. Yeni bir adres türü kaydı, adres türünün sözdizimiyle ilgili ayrıntıları veren bir RFC’ye atıfta BULUNMAK ZORUNDADIR. Adres türlerinin sık aralıklarla kaydedilmesi beklenmemektedir.
IANA, bu belgenin 5.2 ve 5.7 bölümlerinde tanımlandığı şekilde (bu tanımlar RFC 2327’deki tanımları günceller) "IP4" ve "IP6" adres türlerini kaydetmiştir.
8.2.8. Kayıt Prosedürü
SDP "media", "proto", "fmt", "bwtype", "nettype" ve "addrtype" alanlarını kaydeden RFC belgelerinde, yazarlar IANA’nın ilgili kayıt defterine yerleştirmesi için aşağıdaki bilgileri DAHİL ETMEK ZORUNDADIR:
- irtibat adı, e-posta adresi ve telefon numarası
- kaydedilen ad (SDP’de görüneceği şekliyle)
- İngilizce uzun biçimli ad
- adın türü ("media", "proto", "fmt", "bwtype", "nettype" veya "addrtype")
- kaydedilen adın amacını açıklayan tek paragraflık bir açıklama
- kaydedilen adın belirtimine bir atıf (bu genellikle bir RFC numarası olacaktır)
IANA, herhangi bir kaydı inceleme için IESG’ye yönlendirebilir ve bir kaydın yapılmasından önce düzeltmeler talep edebilir.
8.3. Şifreleme Anahtarı Erişim Yöntemleri
IANA daha önce SDP şifreleme anahtarı erişim yöntemi ("enckey") adlarının bir tablosunu tutuyordu. "k=" satırı genişletilebilir olmadığından bu tablo artık geçersizdir. Yeni kayıtlar KABUL EDİLMEMELİDİR.
#9. SDP Grameri
Bu bölüm SDP için Genişletilmiş BNF gramerini sağlar. ABNF, [4]’te tanımlanmıştır.
; SDP Sözdizimi
session-description = proto-version
origin-field
session-name-field
information-field
uri-field
email-fields
phone-fields
connection-field
bandwidth-fields
time-fields
key-field
attribute-fields
media-descriptions
proto-version = %x76 "=" 1*DIGIT CRLF
; bu belge sürüm 0’ı tanımlar
origin-field = %x6f "=" username SP sess-id SP sess-version SP
nettype SP addrtype SP unicast-address CRLF
session-name-field = %x73 "=" text CRLF
information-field = [%x69 "=" text CRLF]
uri-field = [%x75 "=" uri CRLF]
email-fields = *(%x65 "=" email-address CRLF)
phone-fields = *(%x70 "=" phone-number CRLF)
connection-field = [%x63 "=" nettype SP addrtype SP
connection-address CRLF]
; bir bağlantı alanı her medya tanımında
; ya da oturum düzeyinde bulunmalıdır
bandwidth-fields = *(%x62 "=" bwtype ":" bandwidth CRLF)
time-fields = 1*(%x74 "=" start-time SP stop-time
*(CRLF repeat-fields) CRLF)
[zone-adjustments CRLF]
repeat-fields = %x72 "=" repeat-interval SP typed-time
1*(SP typed-time)
zone-adjustments = %x7a "=" time SP ["-"] typed-time
*(SP time SP ["-"] typed-time)
key-field = [%x6b "=" key-type CRLF]
attribute-fields = *(%x61 "=" attribute CRLF)
media-descriptions = *( media-field
information-field
*connection-field
bandwidth-fields
key-field
attribute-fields )
media-field = %x6d "=" media SP port ["/" integer]
SP proto 1*(SP fmt) CRLF
; 'o=' alt kuralları
username = non-ws-string
; oldukça geniş bir tanım, ancak
; boşluk içermez
sess-id = 1*DIGIT
; bu kullanıcı adı/ana bilgisayar için
; benzersiz olmalıdır
sess-version = 1*DIGIT
nettype = token
; genellikle "IN"
addrtype = token
; genellikle "IP4" veya "IP6"
; 'u=' alt kuralları
uri = URI-reference
; RFC 3986’ya bakınız
; 'e=' alt kuralları, tanımlar için RFC 2822’ye bakınız
email-address = address-and-comment / dispname-and-address
/ addr-spec
address-and-comment = addr-spec 1*SP "(" 1*email-safe ")"
dispname-and-address = 1*email-safe 1*SP "<" addr-spec ">"
; 'p=' alt kuralları
phone-number = phone *SP "(" 1*email-safe ")" /
1*email-safe "<" phone ">" /
phone
phone = ["+"] DIGIT 1*(SP / "-" / DIGIT)
; 'c=' alt kuralları
connection-address = multicast-address / unicast-address
; 'b=' alt kuralları
bwtype = token
bandwidth = 1*DIGIT
; 't=' alt kuralları
start-time = time / "0"
stop-time = time / "0"
time = POS-DIGIT 9*DIGIT
; 1900 yılından bu yana saniye cinsinden
; NTP zamanının ondalık gösterimi.
; NTP zamanının gösterimi, en az 10 basamak
; içeren sınırsız uzunlukta bir alandır.
; Başka yerlerde kullanılan 64 bitlik
; gösterimin aksine, SDP’deki zaman
; 2036 yılında sarma yapmaz.
; 'r=' ve 'z=' alt kuralları
repeat-interval = POS-DIGIT *DIGIT [fixed-len-time-unit]
typed-time = 1*DIGIT [fixed-len-time-unit]
fixed-len-time-unit = %x64 / %x68 / %x6d / %x73
; 'k=' alt kuralları
key-type = %x70 %x72 %x6f %x6d %x70 %x74 / ; "prompt"
%x63 %x6c %x65 %x61 %x72 ":" text / ; "clear:"
%x62 %x61 %x73 %x65 "64:" base64 / ; "base64:"
%x75 %x72 %x69 ":" uri ; "uri:"
base64 = *base64-unit [base64-pad]
base64-unit = 4base64-char
base64-pad = 2base64-char "==" / 3base64-char "="
base64-char = ALPHA / DIGIT / "+" / "/"
; 'a=' alt kuralları
attribute = (att-field ":" att-value) / att-field
att-field = token
att-value = byte-string
; 'm=' alt kuralları
media = token
; genellikle "audio", "video", "text" veya
; "application"
fmt = token
; genellikle ses ve video ortamları için
; bir RTP yük türü
proto = token *("/" token)
; genellikle "RTP/AVP" veya "udp"
port = 1*DIGIT
; genel alt kurallar: adresleme
unicast-address = IP4-address / IP6-address / FQDN / extn-addr
multicast-address = IP4-multicast / IP6-multicast / FQDN
/ extn-addr
IP4-multicast = m1 3("." decimal-uchar)
"/" ttl ["/" integer]
; IPv4 çok noktaya yayın adresleri
; 224.0.0.0 ile 239.255.255.255
; aralığında olabilir
m1 = ("22" ("4"/"5"/"6"/"7"/"8"/"9")) /
("23" DIGIT)
IP6-multicast = hexpart ["/" integer]
; FF ile başlayan IPv6 adresi
ttl = (POS-DIGIT *2DIGIT) / "0"
FQDN = 4*(alpha-numeric / "-" / ".")
; RFC 1035’te belirtilen (ve güncellemeleri)
; tam nitelikli alan adı
IP4-address = b1 3("." decimal-uchar)
b1 = decimal-uchar
; "224"ten küçüktür
; Aşağıdakiler RFC 2373 [30], Ek B ile tutarlıdır.
IP6-address = hexpart [":" IP4-address]
hexpart = hexseq / hexseq "::" [hexseq] /
"::" [hexseq]
hexseq = hex4 *(":" hex4)
hex4 = 1*4HEXDIG
; Diğer adres aileleri için genel
extn-addr = non-ws-string
; genel alt kurallar: veri türleri
text = byte-string
; varsayılan olarak UTF-8 metin olarak
; yorumlanır. ISO 8859-1 için
; oturum düzeyinde
; "a=charset:ISO-8859-1" özniteliği
; kullanılmalıdır
byte-string = 1*(%x01-09/%x0B-0C/%x0E-FF)
; NUL, CR veya LF dışındaki herhangi bir bayt
non-ws-string = 1*(VCHAR/%x80-FF)
; görünür karakterlerden oluşan dize
token-char = %x21 / %x23-27 / %x2A-2B / %x2D-2E / %x30-39
/ %x41-5A / %x5E-7E
token = 1*(token-char)
email-safe = %x01-09/%x0B-0C/%x0E-27/%x2A-3B/%x3D/%x3F-FF
; NUL, CR, LF veya
; tırnaklama karakterleri ()<> dışındaki
; herhangi bir bayt
integer = POS-DIGIT *DIGIT
; genel alt kurallar: ilkel öğeler
alpha-numeric = ALPHA / DIGIT
POS-DIGIT = %x31-39 ; 1 - 9
decimal-uchar = DIGIT
/ POS-DIGIT DIGIT
/ ("1" 2*(DIGIT))
/ ("2" ("0"/"1"/"2"/"3"/"4") DIGIT)
/ ("2" "5" ("0"/"1"/"2"/"3"/"4"/"5"))
; harici başvurular:
; ALPHA, DIGIT, CRLF, SP, VCHAR: RFC 4234’ten
; URI-reference: RFC 3986’dan
; addr-spec: RFC 2822’den#10. RFC 2327’den Bu Yana Yapılan Değişikliklerin Özeti
Bu belge, kullanımdan elde edilen geri bildirimler ışığında belirtime çok sayıda açıklık kazandıracak şekilde önemli ölçüde yeniden yapılandırılmıştır. Aşağıda belirtilen maddeler dışında, belgede yapılan değişikliklerin geriye dönük uyumlu açıklamalar olması amaçlanmıştır. Bununla birlikte, RFC 2327’deki tutarsızlıklar ve belirsiz tanımlar nedeniyle, bazı uygulamaların bu SDP sürümünden farklı yorumlar getirmiş olması muhtemeldir.
- Bölümdeki ABNF grameri kapsamlı biçimde gözden geçirilmiş ve güncellenmiş, çeşitli hatalar düzeltilmiş ve RFC 3266 IPv6 uzantıları dahil edilmiştir. Gramer ile belirtim metni arasındaki bilinen tutarsızlıklar giderilmiştir.
SDP için bir ortam türü kaydı eklenmiştir. Özniteliklerin ve diğer parametrelerin IANA nezdinde kaydedilmesine ilişkin gereksinimler netleştirilmiş ve sıkılaştırılmıştır (Bölüm 8). "text" ve "message"’ın SDP ile kullanım için geçerli ortam türleri olduğu, ancak "control" ve "data"nın yetersiz tanımlandığı ve kullanımdan kaldırıldığı belirtilmiştir.
Gereksinim düzeylerini belirtmek için artık her yerde RFC 2119 terimleri kullanılmaktadır. Bu gereksinimlerin bazıları, özellikle parametre kaydıyla ilgili olanlar, RFC 2327’dekilerden daha katıdır.
"RTP/SAVP" RTP profili ve buna ait "fmt" ad alanı kaydedilmiştir.
"a=inactive" ve "a=maxptime" öznitelikleri eklenmiştir.
RFC 2327, "e=" veya "p=" alanlarından birinin zorunlu olduğunu belirtmekteydi. Gerçek kullanımı yansıtmak amacıyla her ikisi de artık isteğe bağlıdır.
"k=" alanının önemli sınırlamaları belirtilmiş ve kullanımı tavsiye edilmez duruma getirilmiştir.
Deneysel parametreler için kullanılan "x-" önek gösteriminin çoğu kullanımına izin verilmemekte, diğer kullanımlar ise tavsiye edilmez duruma getirilmiştir.
#11. Teşekkürler
IETF Çok Taraflı Multimedya Oturum Kontrolü (MMUSIC) çalışma grubundaki pek çok kişi bu belgeye katkıda bulunan yorumlar ve önerilerde bulunmuştur. Özellikle Eve Schooler, Steve Casner, Bill Fenner, Allison Mankin, Ross Finlayson, Peter Parnes, Joerg Ott, Carsten Bormann, Steve Hanna, Jonathan Lennox, Keith Drage, Sean Olson, Bernie Hoeneisen, Jonathan Rosenberg, John Elwell, Flemming Andreasen, Jon Peterson ve Spencer Dawkins’e teşekkür ederiz.
#12. Kaynaklar
12.1. Normatif Kaynaklar
- Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, Kasım 1987.
- Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, Kasım 1987.
- Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, Mart 1997.
- Crocker, D., Ed. ve P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, Ekim 2005.
- Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, Kasım 2003.
- Handley, M. ve V. Jacobson, "SDP: Session Description Protocol", RFC 2327, Nisan 1998.
- Berners-Lee, T., Fielding, R. ve L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, Ocak 2005.
- Narten, T. ve H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, Ekim 1998.
- Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, Ocak 2001.
- Olson, S., Camarillo, G. ve A. Roach, "Support for IPv6 in Session Description Protocol (SDP)", RFC 3266, Haziran 2002.
- Fältström, P., Hoffman, P. ve A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, Mart 2003.
- Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, Temmuz 2003.
12.2. Bilgilendirici Kaynaklar
- Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, Mart 1992.
- Handley, M., Perkins, C. ve E. Whelan, "Session Announcement Protocol", RFC 2974, Ekim 2000.
- Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. ve E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, Haziran 2002.
- Schulzrinne, H., Rao, A. ve R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, Nisan 1998.
- Rosenberg, J. ve H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, Haziran 2002.
- Camarillo, G., Eriksson, G., Holler, J. ve H. Schulzrinne, "Grouping of Media Lines in the Session Description Protocol (SDP)", RFC 3388, Aralık 2002.
- Schulzrinne, H., Casner, S., Frederick, R. ve V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, Temmuz 2003.
- Schulzrinne, H. ve S. Casner, "RTP Profile for Audio and Video Conferences with Minimal Control", STD 65, RFC 3551, Temmuz 2003.
#Kaynaklar
[21] Casner, S., "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth", RFC 3556, Temmuz 2003.
[22] Huitema, C., "Real Time Control Protocol (RTCP) attribute in Session Description Protocol (SDP)", RFC 3605, Ekim 2003.
[23] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, Mart 2004.
[24] Rosenberg, J., Schulzrinne, H. ve P. Kyzivat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", RFC 3840, Ağustos 2004.
[25] Westerlund, M., "A Transport Independent Bandwidth Modifier for the Session Description Protocol (SDP)", RFC 3890, Eylül 2004.
[26] International Telecommunication Union, "H.323 extended for loosely coupled conferences", ITU Recommendation H.332, Eylül 1998.
[27] Arkko, J., Carrara, E., Lindholm, F., Naslund, M. ve K. Norrman, "Key Management Extensions for Session Description Protocol (SDP) and Real Time Streaming Protocol (RTSP)", RFC 4567, Temmuz 2006.
[28] Andreasen, F., Baugher, M. ve D. Wing, "Ortam Akışları için Oturum Tanımlama Protokolü (SDP) Güvenlik Tanımları", RFC 4568, Temmuz 2006.
[29] Resnick, P., "İnternet İleti Biçimi", RFC 2822, Nisan 2001.
[30] Hinden, R. ve S. Deering, "IP Sürüm 6 Adresleme Mimarisi", RFC 2373, Temmuz 1998.
[31] Freed, N. ve J. Klensin, "Ortam Türü Tanımlamaları ve Kayıt Prosedürleri", BCP 13, RFC 4288, Aralık 2005.
#Tam Telif Hakkı Beyanı
Telif Hakkı (C) The Internet Society (2006).
Bu belge, BCP 78'de yer alan haklara, lisanslara ve kısıtlamalara tabidir ve burada belirtilenler dışında, yazarlar tüm haklarını saklı tutar.
Bu belge ve burada yer alan bilgiler "OLDUĞU GİBİ" esasına göre sağlanmaktadır ve KATKIDA BULUNAN, TEMSİL ETTİĞİ VEYA DESTEKLENDİĞİ KURULUŞ (VARSA), THE INTERNET SOCIETY VE INTERNET ENGINEERING TASK FORCE; BURADA YER ALAN BİLGİLERİN KULLANIMININ HERHANGİ BİR HAKKI İHLAL ETMEYECEĞİNE DAİR HERHANGİ BİR GARANTİ DAHİL OLMAK ÜZERE, TİCARİ ELVERİŞLİLİK VEYA BELİRLİ BİR AMACA UYGUNLUK KONUSUNDAKİ ZIMNİ GARANTİLER DE DAHİL OLMAK ANCAK BUNLARLA SINIRLI OLMAMAK KAYDIYLA, AÇIK VEYA ZIMNİ TÜM GARANTİLERİ REDDEDER.
#Fikri Mülkiyet
IETF, bu belgede açıklanan teknolojinin uygulanması veya kullanımıyla ilgili olduğu iddia edilebilecek herhangi bir Fikri Mülkiyet Hakkının veya diğer hakların geçerliliği ya da kapsamı konusunda ya da bu tür haklar kapsamındaki herhangi bir lisansın mevcut olup olmayacağı konusunda hiçbir görüş belirtmez; ayrıca bu tür hakları belirlemek için bağımsız herhangi bir çaba gösterdiğini de beyan etmez. RFC belgelerindeki haklara ilişkin prosedürler hakkında bilgi BCP 78 ve BCP 79'da bulunabilir.
IETF Sekretaryasına yapılan Fikri Mülkiyet Hakları (IPR) açıklamalarının kopyaları ve kullanıma sunulacak lisanslara ilişkin her türlü güvence ya da bu şartnamenin uygulayıcıları veya kullanıcıları tarafından bu tür mülkiyet haklarının kullanımı için genel bir lisans veya izin elde etmeye yönelik yapılan bir girişimin sonucu, http://www.ietf.org/ipr adresindeki IETF çevrimiçi IPR deposundan temin edilebilir.
IETF, bu standardın uygulanması için gerekli olabilecek teknolojiyi kapsayabilecek her türlü telif hakkı, patent veya patent başvurusu ya da diğer mülkiyet haklarını dikkatine sunmaları için ilgili tüm tarafları davet eder. Lütfen bu bilgileri ietf-ipr@ietf.org adresinden IETF'ye iletin.