Yorum Talepleri (Request for Comments): 8829

Kategori: Standartlar Yolu

ISSN: 2070-1721

J. Uberti (Google) C. Jennings (Cisco) E. Rescorla, Ed. (Mozilla)

Ocak 2021

JavaScript Oturum Kurulum Protokolü (JSEP)

#Özet

Bu belge, bir JavaScript uygulamasının W3C RTCPeerConnection API’sinde belirtilen arayüz aracılığıyla bir multimedya oturumunun sinyalleşme düzlemini denetlemesine olanak tanıyan mekanizmaları açıklar ve bunun mevcut sinyalleşme protokolleriyle nasıl ilişkili olduğunu ele alır.

#1. Giriş

Bu belge, W3C Web Gerçek Zamanlı İletişim (WebRTC) RTCPeerConnection arayüzünün [W3C.webrtc] bir multimedya oturumunun kurulumu, yönetimi ve sonlandırılmasının denetlenmesi için nasıl kullanıldığını açıklar.

1.1. JSEP’in Genel Tasarımı

WebRTC çağrı kurulumu, medya düzleminin denetlenmesine odaklanacak şekilde tasarlanmıştır ve sinyalleşme düzlemi davranışını mümkün olduğunca uygulamaya bırakır. Bunun gerekçesi, farklı uygulamaların mevcut SIP çağrı sinyalleşme protokolü gibi farklı protokolleri ya da belirli bir uygulamaya özgü, belki de yeni bir kullanım durumu için tasarlanmış bir çözümü tercih edebilmesidir. Bu yaklaşımda, değiş tokuş edilmesi gereken temel bilgi, medya düzlemini kurmak için gerekli olan taşıma ve medya yapılandırma bilgilerini belirten multimedya oturum tanımıdır.

Bu hususlar göz önünde bulundurularak, bu belge JavaScript Oturum Kurulum Protokolü’nü (JSEP) tanımlar; JSEP, sinyalleşme durum makinesinin JavaScript üzerinden tam olarak denetlenmesine olanak tanır. Yukarıda açıklandığı gibi, JSEP, bir JavaScript uygulamasının WebRTC API’lerini içeren bir çalışma ortamı içinde çalıştığı bir modeli varsayar ("JSEP uygulaması"). JSEP uygulaması, çekirdek sinyalleşme akışından neredeyse tamamen ayrılmıştır; bu akış bunun yerine JavaScript tarafından iki arayüz kullanılarak ele alınır: (1) yerel ve uzak oturum tanımlarının iletilmesi ve (2) Interactive Connectivity Establishment (ICE) durum makinesiyle [RFC8445] etkileşim. JSEP uygulaması ile JavaScript uygulamasının birleşimine bu belge boyunca "JSEP uç noktası" adı verilir.

Bu belgede, JSEP kullanımı her zaman iki JSEP uç noktası arasında gerçekleşiyormuş gibi açıklanmıştır. Ancak, birçok durumda bunun gerçekte bir JSEP uç noktası ile bir ağ geçidi veya Çok Noktalı Kontrol Birimi (MCU) gibi bir tür sunucu arasında olacağına dikkat edilmelidir. Bu ayrım JSEP uç noktası için görünmezdir; uç nokta yalnızca API aracılığıyla kendisine verilen talimatları izler.

JSEP’in oturum tanımlarını ele alış biçimi basit ve doğrudandır. Bir teklif/yanıt değişimi gerektiğinde, başlatan taraf createOffer API’sini çağırarak bir teklif oluşturur. Uygulama daha sonra bu teklifi kullanarak setLocalDescription API’si aracılığıyla yerel yapılandırmasını ayarlar. Son olarak teklif, tercih edilen sinyalleşme mekanizması (örneğin WebSockets) üzerinden uzak tarafa gönderilir; uzak taraf bu teklifi aldığında, setRemoteDescription API’sini kullanarak uygular.

Teklif/yanıt değişimini tamamlamak için uzak taraf createAnswer API’sini kullanarak uygun bir yanıt üretir, bunu setLocalDescription API’siyle uygular ve yanıtı sinyalleşme kanalı üzerinden başlatıcıya geri gönderir. Başlatıcı bu yanıtı aldığında, setRemoteDescription API’sini kullanarak uygular ve ilk kurulum tamamlanmış olur. Bu süreç ek teklif/yanıt değişimleri için tekrarlanabilir.

ICE [RFC8445] ile ilgili olarak JSEP, ICE durum makinesini genel sinyalleşme durum makinesinden ayırır. ICE durum makinesi JSEP uygulamasında kalmak zorundadır; çünkü adaylar ve diğer taşıma bilgileri hakkında gerekli bilgiye yalnızca uygulama sahiptir. Bu ayrımı yapmak, oturum tanımlarını taşımadan ayıran protokollerde ek esneklik sağlar. Örneğin, geleneksel SIP’te her teklif veya yanıt, hem oturum tanımlarını hem de taşıma bilgilerini içerecek şekilde kendi içinde bütünlüdür. Ancak [RFC8840], SIP’in Trickle ICE [RFC8838] ile birlikte kullanılmasına izin verir; bu durumda oturum tanımı hemen gönderilebilir ve taşıma bilgileri hazır olduğunda iletilebilir. Taşıma bilgilerinin ayrı gönderilmesi, ICE denetimlerinin tüm bilgiler beklenmeden, herhangi bir taşıma bilgisi mevcut olur olmaz başlatılabilmesi sayesinde daha hızlı ICE ve DTLS başlatımına olanak tanıyabilir. JSEP’in ICE ve sinyalleşme durum makinelerini ayırması, her iki modeli de desteklemesini sağlar.

Her ne kadar sinyalleşmeyi soyutlasa da, JSEP yaklaşımı uygulamanın sinyalleşme sürecinin farkında olmasını gerektirir. Uygulamanın bir çağrı kurmak için oturum tanımlarının içeriğini anlaması gerekmez; ancak doğru API’leri doğru zamanlarda çağırmalı, oturum tanımlarını ve ICE bilgilerini seçtiği sinyalleşme protokolünün tanımlı iletilerine dönüştürmeli ve karşı taraftan aldığı iletiler üzerinde ters dönüşümü gerçekleştirmelidir.

Uygulama için işleri kolaylaştırmanın bir yolu, bu karmaşıklığı geliştiriciden gizleyen bir JavaScript kütüphanesi sağlamaktır; söz konusu kütüphane, belirli bir sinyalleşme protokolünü, buna ait durum makinesi ve serileştirme koduyla birlikte uygular ve uygulama geliştiricisine daha üst düzey, çağrı odaklı bir arayüz sunar. Örneğin, SIP [RFC3261] ve Extensible Messaging and Presence Protocol (XMPP) [RFC6120] sinyalleşme protokollerinin JSEP API üzerinde gerçekleştirilmiş uygulamalarını sağlayan kütüphaneler mevcuttur. Bu sayede JSEP, deneyimli geliştirici için daha fazla denetim sunarken, yeni başlayan geliştiriciye ek bir karmaşıklık dayatmaz.

1.2. Değerlendirilen Diğer Yaklaşımlar

JSEP yerine değerlendirilen yaklaşımlardan biri, hafif bir sinyalleşme protokolünün dahil edilmesiydi. Bu yaklaşımda API’ye oturum tanımları sağlamak yerine, API bu protokolün iletilerini üretir ve tüketirdi. Daha üst düzey bir API sunmasına rağmen, bu durum sinyalleşme üzerinde daha fazla denetimi JSEP uygulamasına veriyor ve sinyalleşme çakışması (bkz. [RFC3264], Bölüm 4) gibi kavramları anlamasını ve ele almasını zorunlu kılıyordu.

Değerlendirilmiş ancak seçilmemiş ikinci bir yaklaşım, medya denetim nesnelerinin yönetimini oturum tanımlarından ayırmak ve bunun yerine her bileşeni doğrudan denetleyen API’ler sunmaktı. Bu yaklaşım, bu düzeyde bir karmaşıklığın uygulama programcısına açılmasının faydalı olmayacağı gerekçesiyle reddedildi; çünkü (1) basit bir örneğin bile gerekli tüm etkileşimleri düzenlemek için önemli miktarda kod gerektirdiği bir API ortaya çıkaracaktı ve (2) üzerinde uzlaşılması ve belgelenmesi gereken geniş bir API yüzeyi meydana getirecekti. Ayrıca, bu API noktaları herhangi bir sırayla çağrılabileceğinden, JSEP yaklaşımına kıyasla medya alt sistemiyle daha karmaşık bir etkileşimler kümesine yol açacaktı; JSEP ise oturum tanımlarının nasıl değerlendirileceğini ve uygulanacağını açıkça belirtir.

JSEP üzerinde değerlendirilen bir başka varyasyon, temel oturum tanımı odaklı API’yi koruyup, teklif ve yanıtların üretilmesine yönelik mekanizmayı JSEP uygulamasının dışına taşımaktı. Bu yaklaşımda, uygulama içinde createOffer/createAnswer yöntemleri sağlamak yerine, uygulamaya kendi oturum tanımlarını üretmesi için ihtiyaç duyduğu bilgileri sunan bir getCapabilities API’si sağlanacaktı. Bu durum, uygulamanın yapması gereken işi artırır; uygulamanın yeteneklerden oturum tanımları üretmeyi ve özellikle keyfi bir teklif ile desteklenen yeteneklerden doğru yanıtı üretmeyi bilmesi gerekir. Bunun, yukarıda bahsedilen türden bir kütüphane kullanılarak ele alınması mümkün olsa da, temelde basit bir örnek için bile söz konusu kütüphanenin kullanımını zorunlu kılar. createOffer/createAnswer sağlanması bu sorunu ortadan kaldırır.

1.3. Yalnızca bundle için olan "m=" bölümleriyle ilgili çelişki

WebRTC belirtim belgelerinin onaylanmasından bu yana, IETF, JSEP’i tanımlayan belge ile BUNDLE’ı tanımlayan belge (sırasıyla bu RFC ve [RFC8843]) arasında bir tutarsızlığın farkına varmıştır. Daha fazla gecikmeye yol açmamak adına, belgeler ilk onaylandıkları hâliyle yayımlanmaktadır. IETF, bu teknolojiler üzerinde çalışmayı yeniden başlatmayı ve bir çözüme ulaşıldığında bu belgelerin gözden geçirilmiş sürümlerini yayımlamayı amaçlamaktadır.

Özel sorun, bu RFC’nin Bölüm 4.1.1’inde ele alındığı üzere, yalnızca bundle olarak işaretlenen "m=" bölümlerinin ele alınmasıyla ilgilidir. Hâlihazırda JSEP ile BUNDLE arasında ve ayrıca bu belirtimler ile mevcut tarayıcı uygulamaları arasında ayrışma bulunmaktadır:

JSEP, söz konusu "m=" bölümlerinin ilk tekliflerde port sıfır kullanması ve bir "a=bundle-only" özniteliği eklemesi gerektiğini, ancak yanıtlar veya sonraki teklifler için bunun yapılmamasını öngörür.
BUNDLE, bu "m=" bölümlerinin önceki maddede açıklandığı şekilde işaretlenmesini, ancak tüm teklifler ve yanıtlar için yapılmasını öngörür.
Güncel tarayıcıların çoğu, herhangi bir "m=" bölümünü port sıfır ile işaretlemez ve bunun yerine tüm bundle edilmiş "m=" bölümleri için aynı portu kullanır; bazıları ise JSEP davranışını izler.

#2. Terimler

Bu belgede yer alan "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY" ve "OPTIONAL" anahtar sözcükleri, yalnızca ve ancak burada gösterildiği gibi tamamı büyük harflerle yazıldıklarında, BCP 14 [RFC2119] [RFC8174]’te açıklandığı şekilde yorumlanacaktır.

#3. Anlamsal Yapı ve Sözdizimi

3.1. Sinyalleşme Modeli

JSEP, oturumun her iki tarafının da oturumu nasıl yürüteceğini bilmesi için [RFC3264]’te (teklif/yanıt) tanımlanan biçimde oturum tanımlarının değiş tokuş edilmesine yönelik genel gereksinim dışında, belirli bir sinyalleşme modeli veya durum makinesi tanımlamaz. JSEP, teklif ve yanıtların üretilmesi ile bunların bir oturuma uygulanması için mekanizmalar sağlar. Ancak JSEP uygulaması, bu teklif ve yanıtların adresleme, yeniden iletim, çatallanma ve çakışma ele alma dâhil olmak üzere uzak tarafa nasıl iletildiği mekanizmasından tamamen ayrıdır. Bu konular bütünüyle uygulamaya bırakılmıştır; uygulama, hangi teklif ve yanıtların ne zaman uygulamaya iletileceği konusunda tam denetime sahiptir.

     +-----------+                               +-----------+
     | Web Uygul.|<-- Uygulamaya Özgü Sinyalleşme -->| Web Uygul.|
     +-----------+                               +-----------+
           ^                                            ^
           |  SDP                                       |  SDP
           V                                            V
     +-----------+                                +-----------+
     |   JSEP    |<----------- Medya ------------>|   JSEP    |
     |   Uyg.    |                                |   Uyg.    |
     +-----------+                                +-----------+

Şekil 1: JSEP Sinyalleşme Modeli

3.2. Oturum Tanımları ve Durum Makinesi

Medya düzlemini kurabilmek için JSEP uygulamasının, uzak tarafa neyin iletileceğini ve alınan medyanın nasıl ele alınacağını belirtmek üzere belirli parametrelere ihtiyacı vardır. Bu parametreler, tekliflerde ve yanıtlarda oturum tanımlarının değişimiyle belirlenir ve bu sürece ilişkin ele alınması gereken bazı ayrıntılar JSEP API’lerinde yer alır.

Bir oturum tanımının yerel tarafa mı yoksa uzak tarafa mı uygulandığı, bu tanımın anlamını etkiler. Örneğin, uzak bir tarafa gönderilen kodekler listesi, yerel tarafın neyi almaya istekli olduğunu gösterir; bu liste, uzak tarafın desteklediği kodekler kümesiyle kesiştirildiğinde, uzak tarafın ne göndermesi gerektiğini belirler. Ancak tüm parametreler bu kurala uymaz; bazı parametreler bildirimseldir ve uzak tarafın bunları ya bütünüyle kabul etmesi ya da reddetmesi gerekir. Bu tür bir parametreye örnek olarak, DTLS [RFC6347] bağlamında kullanılan TLS parmak izleri [RFC8122] verilebilir; bu parmak izleri, sunulan yerel sertifika(lar)a dayanarak hesaplanır ve müzakereye tabi değildir.

Buna ek olarak, çeşitli RFC’ler tekliflerin ve yanıtların biçimi için farklı koşullar ortaya koyar. Örneğin, bir teklif keyfi sayıda "m=" bölümü (yani [RFC4566], Bölüm 5.14’te tanımlandığı üzere medya tanımları) önerebilir, ancak bir yanıt teklif ile tam olarak aynı sayıda bölüm içermek zorundadır.

Son olarak, kesin medya parametreleri ancak bir teklif ve bir yanıt değiş tokuş edildikten sonra bilinse de, teklifi yapan taraf yanıtı almadan önce ICE denetimleri ve muhtemelen medya (örneğin, bir bağlantı kurulduktan sonra yapılan yeniden teklif durumunda) alabilir. Bu durumda gelen medyayı doğru şekilde işleyebilmek için, teklifi yapan tarafın medya işleyicisinin, yanıt gelmeden önce teklifin ayrıntılarından haberdar olması gerekir.

Dolayısıyla, oturum tanımlarını doğru şekilde ele alabilmek için JSEP uygulamasının şunları bilmesi gerekir:

Bir oturum tanımının yerel tarafa mı yoksa uzak tarafa mı ait olduğunu.
Bir oturum tanımının teklif mi yoksa yanıt mı olduğunu.
Teklifin, yanıttan bağımsız olarak belirtilebilmesini.

JSEP, bunu hem setLocalDescription hem de setRemoteDescription yöntemlerini ekleyerek ve oturum tanımı nesnelerinin, sağlanan oturum tanımının türünü belirten bir tür alanı içermesini sağlayarak ele alır. Bu, yukarıda listelenen gereksinimleri hem önce setLocalDescription(sdp [offer]) çağrısını yapıp daha sonra setRemoteDescription(sdp [answer]) çağrısını yapan teklifi sunan taraf için hem de önce setRemoteDescription(sdp [offer]) çağrısını yapıp daha sonra setLocalDescription(sdp [answer]) çağrısını yapan yanıtlayıcı taraf için karşılar.

Teklif/yanıt değişimi sırasında, bekleyen teklif, kabul edilebileceği veya reddedilebileceği için hem teklifi sunan tarafta hem de yanıtlayıcı tarafta "beklemede" olarak kabul edilir. Eğer bu bir yeniden teklif ise, her iki tarafın da, son teklif/yanıt değişiminin sonucunu yansıtan "geçerli" yerel ve uzak tanımları olacaktır. Bölümler 4.1.14, 4.1.16, 4.1.13 ve 4.1.15, bekleyen ve geçerli tanımlar hakkında daha fazla ayrıntı sağlar.

JSEP ayrıca, bir yanıtın uygulama tarafından geçici olarak ele alınmasına da olanak tanır. Geçici yanıtlar, yanıtlayıcının ilk oturum parametrelerini teklifi sunan tarafa iletmesi için bir yol sağlar; böylece oturumun başlamasına izin verilirken, nihai bir yanıtın daha sonra belirtilmesine olanak tanınır. Nihai yanıt kavramı teklif/yanıt modeli için önemlidir; böyle bir yanıt alındığında, tam oturum yapılandırması artık bilindiği için çağıran tarafından tahsis edilmiş ek kaynaklar serbest bırakılabilir. Bu "kaynaklar"; ek ICE bileşenleri, NAT etrafında Röleler Kullanarak Geçiş (TURN) adayları veya video kod çözücüleri gibi unsurları içerebilir. Buna karşılık, geçici yanıtlar böyle bir serbest bırakma yapmaz; sonuç olarak, kendi kodek seçimleri, taşıma parametreleri vb. olan birden fazla, birbirinden farklı geçici yanıt çağrı kurulumu sırasında alınabilir ve uygulanabilir. Nihai yanıtın kendisinin, alınmış geçici yanıtların herhangi birinden farklı olabileceğini unutmayın.

[RFC3264]’te, sinyalleşme düzeyindeki kısıt, belirli bir oturum için yalnızca bir teklifin beklemede olabilmesidir; ancak JSEP düzeyinde, herhangi bir noktada yeni bir teklif üretilebilir. Örneğin, sinyalleşme için SIP kullanılırken, bir teklif gönderilip daha sonra bir SIP CANCEL kullanılarak iptal edilirse, ilk teklif için hiç yanıt alınmamış olsa bile başka bir teklif üretilebilir. Bunu desteklemek için JSEP medya katmanı, JavaScript uygulamasının sinyalleşme için ihtiyaç duyduğu her durumda createOffer yöntemi aracılığıyla bir teklif sağlayabilir. Yanıtlayıcı, sıfır veya daha fazla geçici yanıt gönderebilir ve ardından nihai bir yanıt göndererek teklif/yanıt değişimini sonlandırabilir. Bunun durum makinesi aşağıdaki gibidir:

                   setRemote(OFFER)               setLocal(PRANSWER)
                       /-----\                               /-----\
                       |     |                               |     |
                       v     |                               v     |
        +---------------+    |                +---------------+    |
        |               |----/                |               |----/
        |  have-        | setLocal(PRANSWER)  | have-         |
        |  remote-offer |------------------- >| local-pranswer|
        |               |                     |               |
        |               |                     |               |
        +---------------+                     +---------------+
             ^   |                                   |
             |   | setLocal(ANSWER)                  |
setRemote(OFFER)  |                                   |
             |   V                  setLocal(ANSWER) |
        +---------------+                            |
        |               |                            |
        |               |<---------------------------+
        |    stable     |
        |               |<---------------------------+
        |               |                            |
        +---------------+          setRemote(ANSWER) |
             ^   |                                   |
             |   | setLocal(OFFER)                   |
setRemote(ANSWER) |                                   |
             |   V                                   |
        +---------------+                     +---------------+
        |               |                     |               |
        |  have-        | setRemote(PRANSWER) | have-         |
        |  local-offer  |------------------- >| remote-pranswer|
        |               |                     |               |
        |               |----\                |               |----\
        +---------------+    |                +---------------+    |
                       ^     |                               ^     |
                       |     |                               |     |
                       \-----/                               \-----/
                   setLocal(OFFER)               setRemote(PRANSWER)

Şekil 2: JSEP Durum Makinesi

Bu durum geçişlerinin dışında, geçici ("pranswer") ve nihai ("answer") yanıtların ele alınması arasında başka bir fark yoktur.

3.3. Oturum Tanımı Biçimi

JSEP’in oturum tanımları, dahili gösterimleri için Oturum Tanımı Protokolü (SDP) sözdizimini kullanır. Bu biçim JavaScript’ten işleme açısından en uygun olmasa da, yaygın olarak kabul görmüştür ve sık sık yeni özelliklerle güncellenir; oturum tanımlarının herhangi bir alternatif kodlamasının, en azından bu yeni kodlama SDP’yi popülerlik açısından geride bırakana kadar, SDP’deki değişimlere ayak uydurması gerekirdi.

Bununla birlikte, gelecekte esneklik sağlamak amacıyla SDP sözdizimi bir SessionDescription nesnesi içinde kapsüllenmiştir; bu nesne SDP’den oluşturulabilir ve SDP’ye serileştirilebilir. Gelecekteki belirtimler oturum tanımları için bir JSON biçimi üzerinde uzlaşırsa, bu nesnenin söz konusu JSON’u üretmesini ve tüketmesini kolayca sağlayabiliriz.

Aşağıda ayrıntılandırıldığı üzere, çoğu uygulama, bu çeşitli API çağrıları tarafından üretilen ve tüketilen SessionDescription’ları opak veri blokları olarak ele alabilmelidir; yani uygulamanın bunları okuması veya değiştirmesi gerekmeyecektir.

3.4. Oturum Tanımı Denetimi

Uygulamaya çeşitli yaygın oturum parametreleri üzerinde denetim sağlamak için JSEP, JSEP uygulamasına oturum tanımlarını nasıl üretmesi gerektiğini söyleyen denetim yüzeyleri sunar. Bu, çoğu durumda JavaScript’in oturum tanımlarını değiştirme gereksinimini ortadan kaldırır.

Bu nesnelerde yapılan değişiklikler, sonraki createOffer/createAnswer çağrıları tarafından üretilen oturum tanımlarında değişikliklere yol açar.

3.4.1. RtpTransceivers

RtpTransceivers, uygulamanın bir "m=" bölümüyle ilişkili RTP medyasını denetlemesine olanak tanır. Her RtpTransceiver’ın bir RtpSender’ı ve bir RtpReceiver’ı vardır; uygulama bunları RTP medyasının gönderimini ve alımını denetlemek için kullanabilir. Uygulama ayrıca, örneğin durdurarak, RtpTransceiver’ı doğrudan da değiştirebilir.

RtpTransceivers genellikle "m=" bölümleriyle 1:1 eşleşmeye sahiptir; ancak RtpTransceiver’lar oluşturulmuş fakat henüz bir "m=" bölümüyle ilişkilendirilmemişse ya da RtpTransceiver’lar durdurulmuş ve "m=" bölümlerinden ayrıştırılmışsa, "m=" bölümlerinden daha fazla RtpTransceiver olabilir. Bir RtpTransceiver’ın, medya kimliği (mid) özelliği null değilse bir "m=" bölümüyle ilişkili olduğu söylenir; aksi halde ayrıştırılmış olduğu kabul edilir. İlişkili "m=" bölümü, bir teklif oluşturulurken veya uzak bir teklif uygulanırken oluşturulan, transceiver’lar ile "m=" bölümü indeksleri arasındaki bir eşleme kullanılarak belirlenir.

Bir RtpTransceiver hiçbir zaman birden fazla "m=" bölümüyle ilişkili değildir ve bir oturum tanımı uygulandıktan sonra bir "m=" bölümü her zaman tam olarak bir RtpTransceiver ile ilişkilidir. Bununla birlikte, aşağıda Bölüm 5.2.2’de tartışıldığı üzere, bir "m=" bölümünün reddedildiği bazı durumlarda, bu "m=" bölümü "geri dönüştürülür" ve yeni bir MID değeriyle yeni bir RtpTransceiver ile ilişkilendirilir.

RtpTransceivers, uygulama tarafından açıkça oluşturulabilir ya da yeni "m=" bölümleri ekleyen bir teklif ile setRemoteDescription çağrısı yapılarak örtük biçimde oluşturulabilir.

3.4.2. RtpSenders

RtpSenders, uygulamanın RTP medyasının nasıl gönderileceğini denetlemesine olanak tanır. Bir RtpSender, kavramsal olarak bir "m=" bölümünde tanımlanan giden RTP akış(lar)ından sorumludur. Buna, ekli MediaStreamTrack’in kodlanması, RTP medya paketlerinin gönderilmesi ve giden RTP akış(lar)ı için RTP Denetim Protokolü’nün (RTCP) üretilmesi/işlenmesi dahildir.

3.4.3. RtpReceivers

RtpReceivers, uygulamanın RTP medyasının nasıl alındığını incelemesine olanak tanır. Bir RtpReceiver, kavramsal olarak bir "m=" bölümünde tanımlanan gelen RTP akış(lar)ından sorumludur. Buna, alınan RTP medya paketlerinin işlenmesi, gelen akış(lar)ın kodu çözülerek uzak bir MediaStreamTrack üretilmesi ve gelen RTP akış(lar)ı için RTCP’nin üretilmesi/işlenmesi dahildir.

3.5. ICE

3.5.1. ICE Toplama Genel Bakış

JSEP, uygulamanın ihtiyaç duyduğu ölçüde ICE adaylarını toplar. ICE adaylarının toplanmasına bir toplama aşaması denir ve bu aşama, yerel oturum tanımına yeni veya geri dönüştürülmüş bir "m=" bölümünün eklenmesiyle ya da bir ICE yeniden başlatmasını gösteren yeni ICE kimlik bilgileriyle tetiklenir. Yeni ICE kimlik bilgilerinin kullanımı, uygulama tarafından açıkça tetiklenebileceği gibi, ICE yapılandırmasındaki değişikliklere yanıt olarak JSEP uygulaması tarafından örtük biçimde de tetiklenebilir.

ICE yapılandırması, yeni bir toplama aşaması gerektirecek şekilde değiştiğinde, needs-ice-restart biti ayarlanır. Bu bit ayarlandığında, createOffer API’sine yapılan çağrılar yeni ICE kimlik bilgileri üretecektir. Bu bit, bir tekliften veya bir yanıttan gelen yeni ICE kimlik bilgileriyle setLocalDescription API’sine yapılan bir çağrı ile, yani yerel veya uzak tarafından başlatılan bir ICE yeniden başlatmasıyla temizlenir.

Yeni bir toplama aşaması başladığında, ICE aracısı bir durum değişikliği olayı aracılığıyla uygulamayı toplamanın gerçekleştiği konusunda bilgilendirir. Ardından, her yeni ICE adayı kullanılabilir hale geldiğinde, ICE aracısı bunu onicecandidate olayı üzerinden uygulamaya iletir; bu adaylar ayrıca otomatik olarak geçerli ve/veya bekleyen yerel oturum tanımına eklenir. Son olarak, tüm adaylar toplandığında, toplama sürecinin tamamlandığını bildirmek üzere son bir onicecandidate olayı gönderilir.

Toplama aşamalarının yalnızca yeni/geri dönüştürülmüş/yeniden başlatılan "m=" bölümlerinin ihtiyaç duyduğu adayları topladığını unutmayın; diğer "m=" bölümleri mevcut adaylarını kullanmaya devam eder. Ayrıca, bir "m=" bölümü paketlenmişse (başarılı bir paketleme müzakeresiyle ya da bundle-only olarak işaretlenmesiyle), [RFC8843]’te açıklandığı üzere, adaylar yalnızca ve yalnızca MID öğesi bir BUNDLE etiketi ise bu "m=" bölümü için toplanır ve değiş tokuş edilir.

3.5.2. ICE Adayı Damlatma

Aday damlatma, çağıranın ilk teklif gönderildikten sonra adayları kademeli olarak aranan tarafa sağlayabildiği bir tekniktir; "Trickle ICE"’in anlamsal tanımı [RFC8838]’de yapılmıştır. Bu süreç, aranan tarafın çağrı üzerinde işlem yapmaya ve ICE (ve muhtemelen DTLS) bağlantılarını hemen kurmaya başlamasına olanak tanır; böylece çağrıyı başlatmadan önce toplamanın yapılmadığı durumlarda tüm olası adayların toplanmasını bekleme gereksinimi ortadan kalkar. Bunun sonucu, daha hızlı medya kurulumu elde edilmesidir.

JSEP, yukarıda açıklandığı üzere, ICE adayı toplama süreci üzerinde denetim ve geri bildirim sağlayan API’ler sunarak isteğe bağlı aday damlatmayı destekler. Aday damlatmayı destekleyen uygulamalar, ilk teklifi hemen gönderebilir ve yeni bir aday bildirimi aldıklarında tek tek adayları gönderebilir; bu özelliği desteklemeyen uygulamalar ise, toplamanın tamamlandığını belirten işareti bekleyip, tüm adaylarla birlikte teklifi o zaman oluşturup gönderebilir.

Damlatılan adaylar alındığında, alıcı uygulama bunları kendi ICE aracısına sağlar. Bu, ICE aracısının bağlantı denetimleri için yeni uzak adayları kullanmaya başlamasını tetikler.

3.5.2.1. ICE Adayı Biçimi

JSEP’te ICE adayları bir IceCandidate nesnesiyle soyutlanır ve oturum tanımlarında olduğu gibi, dahili gösterim için SDP sözdizimi kullanılır.

Aday ayrıntıları, [RFC8839], Bölüm 5.1’de tanımlanan "candidate-attribute" alanıyla aynı SDP sözdizimi kullanılarak bir IceCandidate alanında belirtilir. Aşağıdaki örnekte gösterildiği gibi, bu alan bir "a=" öneki içermez:

candidate:1 1 UDP 1694498815 192.0.2.33 10000 typ host

IceCandidate nesnesi, [RFC8839], Bölüm 5.4’te tanımlandığı üzere, hangi ICE kullanıcı adı parçası (ufrag) ile ilişkili olduğunu belirtmek için bir alan içerir. Bu değer, bu IceCandidate’in hangi oturum tanımına (dolayısıyla hangi toplama aşamasına) ait olduğunu belirlemek için kullanılır; bu da ICE yeniden başlatmaları sırasında belirsizliklerin giderilmesine yardımcı olur. Alınan bir IceCandidate içinde bu alan yoksa (örneğin MID özniteliğini desteklemeyen JSEP olmayan bir uç noktayla iletişim kurarken), en son alınan oturum tanımının geçerli olduğu varsayılır.

IceCandidate nesnesi ayrıca hangi "m=" bölümüne bağlı olduğunu belirtmek için alanlar içerir; bu ilişki iki yoldan biriyle tanımlanabilir: ya bir "m=" bölüm indeksiyle ya da bir MID ile. "m=" bölüm indeksi, sıfır tabanlı bir indekstir; N indeksi, bu IceCandidate tarafından referans verilen oturum tanımındaki N+1’inci "m=" bölümünü ifade eder. MID ise, [RFC5888], Bölüm 4’te tanımlanan bir "medya akışı tanımlama" değeridir ve ilgili RtpTransceiver nesnesinin MID’ini kullanarak (Bölüm 5.10’da tartışıldığı üzere, MID özniteliğini desteklemeyen JSEP olmayan bir uç noktayla etkileşim sırasında yanıtlayıcı tarafından yerel olarak üretilmiş olabilir) oturum tanımındaki "m=" bölümünü tanımlamak için daha sağlam bir yol sağlar. Alınan bir IceCandidate içinde MID alanı mevcutsa, tanımlama için KESİNLİKLE kullanılmalıdır; aksi halde bunun yerine "m=" bölüm indeksi kullanılır.

Uygulamalar, yukarıda belirtildiği gibi, bazı alanları eksik olan nesneleri almaya hazır OLMALIDIR.

3.5.3. ICE Aday Politikası

Tipik olarak, ICE adayları toplanırken JSEP uygulaması başlangıç adaylarının tüm olası biçimlerini toplar: ana makine (host), sunucu-yansıtmalı (server-reflexive) ve aktarım (relay). Ancak bazı durumlarda, gizlilik veya ilgili endişeler nedeniyle uygulamalar toplama süreci üzerinde daha ayrıntılı denetim isteyebilir. Örneğin, konum bilgisinin mümkün olduğunca az sızdırılması için (bu seçimin karşılık gelen işletimsel maliyetler getirdiği akılda tutularak) yalnızca aktarım adaylarının kullanılmasını isteyebilir. Bunu sağlamak için JSEP, uygulamanın bir oturumda hangi ICE adaylarının kullanılacağını kısıtlamasına olanak tanır. Bu filtrelemenin, [RFC8828]’de tartışıldığı üzere, uygulama için hangi IP adreslerine izin verildiğine ilişkin olarak uygulamanın seçebileceği kısıtlamaların üzerine uygulandığını unutmayın.

Oturum etkin durumdayken hangi tür adayların kullanılacağını değiştirmek istediği durumlar da olabilir. Buna önemli bir örnek, çağrıyı alan tarafın başlangıçta yalnızca aktarım adaylarını kullanmak isteyebilmesi; böylece rastgele bir arayana konum bilgisinin sızmasını önlemesi, ancak kullanıcı çağrıyı almak istediğini belirttikten sonra (daha düşük işletimsel maliyet için) tüm adayları kullanmaya geçmesidir. Bu senaryo için JSEP uygulaması, yukarıda belirtilen yerel politika etkileşimlerine tabi olmak üzere, oturum ortasında aday politikasının değiştirilmesine İZİN vermelidir.

ICE aday politikasını yönetmek için JSEP uygulaması, her toplama aşamasının başlangıcında geçerli ayarı belirler. Ardından, toplama aşaması sırasında uygulama, geçerli politika tarafından izin verilmeyen adayları uygulamaya AÇIĞA ÇIKARMAMALI, bunları bağlantı denetimlerinin kaynağı olarak KULLANMAMALI veya diğer ICE adayları için raddr/rport öznitelikleri gibi başka alanlar aracılığıyla dolaylı olarak da olsa AÇIĞA ÇIKARMAMALIDIR. Daha sonra uygulama tarafından farklı bir politika belirtilirse, uygulama bunu bir ICE yeniden başlatması yoluyla yeni bir toplama aşaması başlatarak uygulayabilir.

3.5.4. ICE Aday Havuzu

JSEP uygulamaları genellikle setLocalDescription’a sağlanan bilgiler aracılığıyla JSEP uygulamasını ICE toplamaya başlatması için bilgilendirir; çünkü yerel tanım, kaç ICE bileşenine ihtiyaç duyulacağını ve hangileri için adayların toplanması gerektiğini belirtir. Ancak, uygulamanın kullanılacak ICE bileşenlerinin sayısını önceden bildiği durumları hızlandırmak için, uygulama hızlı medya kurulumu sağlamaya yardımcı olmak üzere uygulamadan potansiyel ICE adaylarından oluşan bir havuz toplamasını isteyebilir.

setLocalDescription nihayet çağrıldığında ve JSEP uygulaması gerekli ICE adaylarını toplamaya hazırlandığında, mevcutsa havuzda herhangi bir aday olup olmadığını kontrol ederek BAŞLAMALIDIR. Havuzda adaylar varsa, bunlar ICE aday olayı aracılığıyla derhal uygulamaya iletilmelidir. Havuz, beklenenden daha fazla sayıda ICE bileşeni kullanılması veya havuzun aday toplamak için yeterli zamana sahip olmaması nedeniyle tükenirse, kalan adaylar her zamanki gibi toplanır. Bu durum yalnızca ilk teklif/yanıt değişimi için geçerlidir; sonrasında aday havuzu boşaltılır ve artık kullanılmaz.

Bu kavramın yararlı olduğu bir örnek, gelecekte bir noktada gelen bir çağrı bekleyen ve bağlantı kurulmasının aldığı süreyi en aza indirerek başlangıç medyasının kesilmesini önlemek isteyen bir uygulamadır. Adayları önceden havuza toplayarak, bir çağrı alındığında neredeyse anında bu adaylardan değişim yapabilir ve bağlantı denetimleri göndermeye başlayabilir. Ancak, bu önceden toplanmış adayların, ihtiyaç duyulabilecekleri süre boyunca canlı tutulacağını ve uygulamanın kullandığı STUN/TURN sunucularında kaynak tüketeceğini unutmayın. ("STUN", "Session Traversal Utilities for NAT" anlamına gelir.)

3.5.5. ICE Sürümleri

Bu belirtim biçimsel olarak [RFC8445]’e dayanmakla birlikte, yayımlandığı tarihte WebRTC uygulamalarının büyük çoğunluğu [RFC5245]’te tanımlanan ICE sürümünü desteklemektedir. [RFC8445]’te tanımlanan "ice2" özniteliği, uzak bir uç nokta tarafından kullanılan sürümü tespit etmek ve eski belirtimden yenisine sorunsuz bir geçiş sağlamak için kullanılabilir. Uygulamalar, "ice2" özniteliği içermeyen uzak tanımları kabul edebilmelidir.

3.6. Video Boyutu Müzakeresi

Video boyutu müzakeresi, bir alıcının alabileceği video kare boyutlarını belirtmek için "a=imageattr" SDP özniteliğini [RFC6236] kullanabildiği süreçtir. Bir alıcının video çözücüsünün işleyebileceği boyutlar üzerinde katı sınırları olabilir veya politika tarafından belirlenmiş bir azami değeri bulunabilir. Bu sınırlar bir "a=imageattr" özniteliğinde belirtilerek, JSEP uç noktaları uzak göndericinin kabul edilebilir bir çözünürlükte video iletmesini sağlamaya çalışabilir. Ancak, bu özniteliği anlamayan JSEP olmayan bir uç noktayla iletişim kurulduğunda, işaretlenen sınırlar aşılabilir ve JSEP uygulaması bunu zarif bir şekilde ele ALMALIDIR; örneğin videoyu atarak.

Bazı codec’lerin, 1.0’dan farklı en-boy oranlarına (yani kare olmayan piksellere) sahip örneklerin iletimini desteklediğini unutmayın. JSEP uygulamaları kare olmayan pikselleri iletmez, ancak bu tür videoyu doğru en-boy oranıyla almalı ve görüntülemelidir. Ancak örnek en-boy oranının, aşağıda açıklanan boyut müzakeresi üzerinde bir etkisi yoktur; tüm boyutlar, kare olsun ya da olmasın, piksel cinsinden ölçülür.

3.6.1. imageattr Özniteliğinin Oluşturulması

Alıcı, alabileceği mutlak asgari ve azami boyutları belirlemek için bilinen tüm yerel sınırları (örneğin donanım çözücü yetenekleri veya yerel politika) önce birleştirir. Bilinen yerel sınırlar yoksa, "a=imageattr" özniteliği ATLANMALIDIR. Bu yerel sınırlar herhangi bir videonun alınmasını engelliyorsa, yani izin verilen çözünürlüklerin olmadığı yozlaşmış durumda, "a=imageattr" özniteliği ATLANMALIDIR ve "m=" bölümü uygun şekilde sendonly/inactive olarak işaretlenmelidir.

Aksi halde, "recv" yönüne sahip bir "a=imageattr" özniteliği oluşturulur ve yukarıda belirtilen kesişimden oluşan çözünürlük alanı, asgari ve azami "x=" ve "y=" değerlerini belirtmek için kullanılır.

Buradaki kurallar tek bir tercih kümesini ifade eder; bu nedenle "a=imageattr" içindeki "q=" değeri önemli değildir. "1.0" olarak ayarlanmalıdır.

"a=imageattr" alanı yük türüne özeldir. Desteklenen tüm video codec’leri aynı yeteneklere sahipse, joker yük türü (*) ile tek bir öznitelik kullanılması ÖNERİLİR. Ancak, desteklenen video codec’lerinin farklı sınırlamaları varsa, her yük türü için ayrı "a=imageattr" öznitelikleri EKLENMELİDİR.

Örnek olarak, 48x48’den 720p’ye kadar herhangi bir çözünürlüğü çözebilen çok biçimli bir video çözücüsüne sahip bir sistemi ele alalım. Bu durumda uygulama şu özniteliği üretir:

a=imageattr:* recv [x=[48:1280],y=[48:720],q=1.0]

Bu bildirim, alıcının 48x48’den 1280x720 piksele kadar herhangi bir görüntü çözünürlüğünü çözebildiğini belirtir.

3.6.2. imageattr Özniteliklerinin Yorumlanması

[RFC6236], "a=imageattr" özniteliğini tavsiye niteliğinde bir alan olarak tanımlar. Bu, göndericinin kullanabileceği video biçimlerini mutlak olarak kısıtlamadığı, ancak tercih edilen değerler hakkında bir gösterge sağladığı anlamına gelir.

Bu belirtim daha özel bir davranış tanımlar. Belirli bir çözünürlükte video üreten bir MediaStreamTrack ("iz çözünürlüğü"), bu iz videosunu aynı veya daha düşük çözünürlük(ler)de kodlayan bir RtpSender’a ("kodlayıcı çözünürlükleri") bağlandığında ve göndericiye referans veren ve geçerli "a=imageattr recv" öznitelikleri içeren bir uzak tanım uygulandığında, göndericinin özniteliklerde belirtilen boyut ölçütlerini aşan bir çözünürlük iletmemesini sağlamak için aşağıdaki kurallara UYULMALIDIR. Bu kurallara, iz çözünürlüğünün değiştiği veya farklı bir iz ile değiştirildiği durumlar da dahil olmak üzere, öznitelikler uzak tanımda var olduğu sürece uyulmalıdır.

RtpSender’ın nasıl yapılandırıldığına bağlı olarak, belirli bir çözünürlükte tek bir kodlama üretiyor olabilir ya da simulcast (Bölüm 3.7) müzakere edilmişse, her biri kendi özgül çözünürlüğüne sahip birden fazla kodlama üretebilir. Ayrıca yapılandırmaya bağlı olarak, her kodlama gerektiğinde çözünürlüğü azaltma esnekliğine sahip olabilir veya belirli bir çıkış çözünürlüğüne kilitlenmiş olabilir.

RtpSender tarafından üretilen her kodlama için, uzak tanımın ilgili "m=" bölümündeki "a=imageattr recv" özniteliklerinin kümesi, neyin iletileceğini belirlemek üzere işlenir. Yalnızca kodlama için seçilen medya biçimine referans veren öznitelikler dikkate alınır; bu özniteliklerin her biri, en yüksek "q=" değerine sahip olandan başlanarak ayrı ayrı değerlendirilir. Birden fazla öznitelik aynı "q=" değerine sahipse, içerdikleri "m=" bölümünde göründükleri sırayla değerlendirilirler. JSEP uç noktalarının medya biçimi başına en fazla bir "a=imageattr recv" özniteliği içereceğini, ancak JSEP olmayan uç noktalardan gelen ve "m=" bölümlerinde birden fazla böyle öznitelik içeren oturum tanımlarının alınabileceğini unutmayın.

Her "a=imageattr recv" özniteliği için aşağıdaki kurallar uygulanır. Bu işlem başarılı olursa, kodlama buna göre iletilir ve bu kodlama için başka öznitelikler değerlendirilmez. Aksi halde, yukarıda belirtilen sırayla bir sonraki öznitelik değerlendirilir. Sağlanan özniteliklerin hiçbiri başarıyla işlenemezse, kodlama İLETİLMEMELİ ve uygulamaya bir hata BİLDİRİLMELİDİR.

Öznitelikten gelen sınırlar, kodlayıcı çözünürlüğü ile karşılaştırılır. Yalnızca aşağıda belirtilen özgül sınırlar dikkate alınır; resim en-boy oranı gibi diğer tüm değerler GÖZ ARDI EDİLMELİDİR. Döndürülmüş video üreten bir MediaStreamTrack söz konusu olduğunda, denetimler için döndürülmemiş çözünürlük KULLANILMALIDIR. Bu, alıcının alma tarafında döndürme yapmayı destekleyip desteklemediğine bakılmaksızın (örneğin Video Yönelimi Koordinasyonu (CVO) [TS26.114] aracılığıyla) gereklidir; çünkü eşleştirme mantığını önemli ölçüde basitleştirir.
Öznitelik, alıcının kare olmayan pikseller almak istediğini gösteren ve "1.0" dışında bir değere ayarlanmış bir "sar=" (örnek en-boy oranı) değeri içeriyorsa, bu karşılanamaz ve öznitelik KULLANILMAMALIDIR.
Kodlayıcı çözünürlüğü, öznitelik tarafından izin verilen azami boyutu aşıyorsa ve kodlayıcının çözünürlüğünü ayarlamasına izin veriliyorsa, kodlayıcı sınırları karşılamak için küçültme (downscaling) uygulamalıdır. Küçültme, yuvarlamadan kaynaklanan önemsiz farklar göz ardı edilerek, kodlamanın resim en-boy oranını DEĞİŞTİRMEMELİDİR. Örneğin, kodlayıcı çözünürlüğü 1280x720 ise ve öznitelik azami 640x480 belirtmişse, beklenen çıkış çözünürlüğü 640x360 olur. Küçültme uygulanamıyorsa, öznitelik KULLANILMAMALIDIR.
Kodlayıcı çözünürlüğü, öznitelik tarafından izin verilen asgari boyuttan küçükse, öznitelik KULLANILMAMALIDIR; kodlayıcı büyütme (upscaling) UYGULAMAMALIDIR. JSEP uygulamaları, belki bir yazılım çözücüsüne geri dönüş yoluyla, keyfi derecede küçük çözünürlüklerin alınmasına izin vererek bu durumdan KAÇINMALIDIR.
Kodlayıcı çözünürlüğü azami ve asgari boyutlar içindeyse, herhangi bir işlem gerekmez.

3.7. Simulcast

JSEP, tek bir "m=" bölümü bağlamında kaynak medyanın birden fazla kodlamasının iletilebildiği bir MediaStreamTrack’in simulcast iletimini destekler. Mevcut JSEP API’si, uygulamaların simulcast edilmiş medya göndermesine olanak tanıyacak şekilde tasarlanmıştır, ancak yalnızca tek bir kodlamayı almayı destekler. Bu, her gönderici istemcinin bir sunucuya birden fazla kodlama gönderdiği ve sunucunun da her alıcı istemci için iletilecek uygun kodlamayı seçtiği çok kullanıcılı senaryolara olanak tanır.

Uygulamalar, bir RtpSender üzerinde birden fazla kodlama yapılandırarak simulcast desteği talep eder. Bir teklif veya yanıt üretildiğinde, bu kodlamalar aşağıda açıklandığı üzere ilgili "m=" bölümünde SDP işaretlemeleri aracılığıyla belirtilir. Simulcast’i anlayan ve almaya istekli olan alıcılar da desteklerini belirtmek için SDP işaretlemeleri ekler ve JSEP uç noktaları bu işaretlemeleri kullanarak belirli bir RtpSender için simulcast’e izin verilip verilmediğini belirler. Simulcast desteği müzakere edilmezse, RtpSender yalnızca yapılandırılmış ilk kodlamayı kullanır.

Simulcast parametrelerinin tam olarak ne olacağı gönderen uygulamaya bağlıdır. Yukarıda belirtilen SDP işaretlemeleri, uzak tarafın birden fazla simulcast kodlamasını alabilmesini ve ayırabilmesini sağlamak için sunulsa da, her kodlama için kullanılacak özgül çözünürlükler ve bit hızları JSEP’te tamamen gönderim tarafına ait bir karardır.

JSEP şu anda simulcast alımını yapılandırmak için bir mekanizma sağlamamaktadır. Bu, uzak uç nokta tarafından simulcast teklif edilirse, bir JSEP uç noktası tarafından üretilen yanıtın simulcast alım desteğini belirtmeyeceği ve bu nedenle uzak uç noktanın "m=" bölümü başına yalnızca tek bir kodlama göndereceği anlamına gelir.

Ayrıca, JSEP, JSEP uç noktasından simulcast talep eden gelen bir teklifi ele almak için bir mekanizma sağlamaz. Bu, JSEP uç noktasının ilk teklifi aldığı durumda simulcast kurulmasının bant dışı sinyalleşme veya SDP incelemesi gerektirdiği anlamına gelir. Ancak, JSEP uç noktasının kendi ilk teklifinde simulcast kurduğu durumda, oluşturulmuş olan tüm simulcast akışları gelen bir yeniden teklif alındığında çalışmaya devam eder. Bu belirtimin gelecekteki sürümleri, gelen ilk teklif senaryosunu ele almak için ek API’ler ekleyebilir.

JSEP kullanılarak bir RtpSender’dan birden fazla kodlama iletiminde, [RFC8853] ve [RFC8851]’deki teknikler kullanılır. Özellikle, bir RtpSender için birden fazla kodlama yapılandırıldığında, RtpSender’a ait "m=" bölümü, [RFC8853], Bölüm 5.1’de tanımlandığı üzere, her bir istenen kodlamayı listeleyen bir "send" simulcast akış tanımı içeren ve hiçbir "recv" simulcast akış tanımı içermeyen bir "a=simulcast" özniteliği içerir. "m=" bölümü ayrıca, [RFC8851], Bölüm 4’te belirtildiği gibi, her bir kodlama için bir "a=rid" özniteliği de içerir; Kısıtlama Tanımlayıcılarının (RID’ler, ayrıca rid-id’ler veya RtpStreamId’ler olarak da adlandırılır) kullanımı, tümü aynı "m=" bölümünün parçası olsa bile, tek tek kodlamaların ayırt edilmesini sağlar.

3.8. Forking ile Etkileşimler

Bazı çağrı sinyalleşme sistemleri, bir SDP Teklifinin birden fazla cihaza sağlanabildiği çeşitli forking türlerine izin verir. Örneğin, SIP [RFC3261] hem "paralel arama" hem de "ardışık arama" tanımlar. Bunlar öncelikle JSEP’in kapsamı dışında kalan sinyalleşme düzeyi konular olsa da, ilgili medya düzlemi yapılandırması üzerinde bazı etkileri vardır. Forking sinyalleşme katmanında gerçekleştiğinde, sinyalleşmeden sorumlu JavaScript uygulamasının, herhangi bir zamanda hangi medyanın gönderileceği veya alınacağına ve hangi uzak uç nokta ile iletişim kurulacağına karar vermesi gerekir; JSEP, medya motorunun uygulamanın gerektirdiği şekilde RTP ve medyayı gerçekleştirebilmesini sağlamak için kullanılır. Uygulamaların medya motoruna yaptırabileceği temel işlemler aşağıdaki gibidir:

Belirli bir uzak eş ile medya alışverişine başlamak, ancak teklifteki tüm kaynakları ayrılmış olarak tutmak.
Belirli bir uzak eş ile medya alışverişine başlamak ve teklifte kullanılmayan tüm kaynakları serbest bırakmak.

3.8.1. Ardışık Forking

Ardışık forking, bir çağrının birden fazla uzak alıcıya yönlendirilmesini içerir; her bir alıcı çağrıyı kabul edebilir, ancak herhangi bir anda yalnızca tek bir etkin oturum bulunur; alınan medyanın karıştırılması yapılmaz.

JSEP, ardışık forking’i iyi bir şekilde ele alır ve uygulamanın istenen uzak uç noktayı seçme politikasını kolayca denetlemesine olanak tanır. Alıcılardan birinden bir yanıt geldiğinde, uygulama bunu ya (1) gelecekte farklı bir yanıtı kullanma olasılığını açık bırakarak geçici bir yanıt olarak ya da (2) kurulum akışını sonlandıran nihai bir yanıt olarak uygulamayı seçebilir.

"İlk gelen kazanır" durumunda, ilk yanıt nihai yanıt olarak uygulanır ve uygulama sonraki tüm yanıtları reddeder. SIP terminolojisinde bu, ACK + BYE olur.

"Son gelen kazanır" durumunda, tüm yanıtlar geçici yanıt olarak uygulanır ve önceki tüm çağrı bacakları sonlandırılır. Bir noktada, uygulama kurulum sürecini, örneğin bir zamanlayıcı ile, sonlandırır; bu noktada uygulama, bekleyen uzak tanımı nihai yanıt olarak yeniden uygulayabilir.

3.8.2. Paralel Forking

Paralel forking, bir çağrının birden fazla uzak alıcıya yönlendirilmesini içerir; her bir alıcı çağrıyı kabul edebilir ve bunun sonucunda birden fazla eşzamanlı etkin sinyalleşme oturumu kurulabilir. Birden fazla alıcı aynı anda medya gönderirse, bunun nasıl ele alınabileceğine ilişkin olasılıklar [RFC3960], Bölüm 3.1’de açıklanmıştır. Günümüzde çoğu SIP cihazı, aynı anda yalnızca tek bir cihazla medya alışverişini destekler ve birden fazla erken medya ses kaynağını karıştırmaya çalışmaz; çünkü bu kafa karıştırıcı bir duruma yol açabilir. Örneğin, Avrupa zil sesi ile Kuzey Amerika zil sesinin birlikte karıştırıldığını düşünün — ortaya çıkan ses, bu tonların hiçbirine benzemez ve kullanıcıyı şaşırtır. Sinyalleşme uygulaması aynı anda yalnızca uzak uç noktalardan biriyle medya alışverişi yapmak istiyorsa, medya motoru açısından bu durum ardışık forking vakasıyla tamamen aynıdır.

JavaScript uygulamasının birden fazla eş ile aynı anda medya alışverişi yapmak istediği paralel forking durumunda, akış biraz daha karmaşıktır; ancak JavaScript uygulaması, UPDATE kullanarak [RFC3960]’da açıklanan stratejiyi izleyebilir. UPDATE yaklaşımı, sinyalleşmenin medya alışverişi yapılmak istenen her bir eş için ayrı bir medya akışı kurmasına olanak tanır. JSEP’te, UPDATE’te kullanılan bu teklif, basitçe yeni bir PeerConnection oluşturarak (Bkz. Bölüm 4.1) ve aynı yerel medya akışlarının bu yeni PeerConnection’a eklenmiş olduğundan emin olarak biçimlendirilir. Ardından yeni PeerConnection nesnesi, [RFC3960]’da ele alınan UPDATE stratejisini gerçekleştirmek için sinyalleşme tarafından kullanılabilecek bir SDP teklifi üretir.

Medya akışlarının paylaşılması sonucunda, uygulama N adet paralel PeerConnection oturumuna sahip olur; her birinin kendi yerel ve uzak tanımı ile kendi yerel ve uzak adresleri vardır. Bu oturumlardan gelen medya akışı setDirection kullanılarak (Bkz. Bölüm 4.2.3) yönetilebilir veya uygulama tüm oturumlardan gelen medyayı karıştırarak oynatmayı seçebilir. Elbette, uygulama yalnızca tek bir oturumu tutmak isterse, artık ihtiyaç duymadığı oturumları basitçe sonlandırabilir.

#4. Arayüz

Bu bölüm, JSEP işlevselliğini uygulamak için bulunması gereken temel işlemleri ayrıntılandırır. W3C API’sinde sunulan gerçek API, sözdizimi açısından bir miktar farklı olabilir ancak bu kavramlara kolayca eşlenebilmelidir.

4.1. PeerConnection

4.1.1. Yapıcı

PeerConnection yapıcısı, uygulamanın medya oturumu için küresel parametreleri belirtmesine olanak tanır; bunlar, adayları toplarken kullanılacak STUN/TURN sunucuları ve kimlik bilgileri, başlangıç ICE aday politikası ve havuz boyutu ile kullanılacak bundle politikası gibi unsurları içerir.

Bir ICE aday politikası belirtilmişse, Bölüm 3.5.3’te açıklandığı şekilde çalışır ve JSEP uygulamasının yalnızca izin verilen adayları (uygulama içi filtreleme dâhil) uygulamaya sunmasına ve bağlantı denetimleri için yalnızca bu adayları kullanmasına neden olur. Kullanılabilir politika kümesi aşağıdaki gibidir:

all: Uygulama politikasının izin verdiği tüm adaylar toplanır ve kullanılır.
relay: Relay adayları dışındaki tüm adaylar elenir. Bu, uzak eşin alınan adaylardan çıkarım yapabileceği konum bilgisini gizler. Uygulamanın relay sunucularını nasıl dağıttığına ve seçtiğine bağlı olarak, bu gizleme metro düzeyinde ya da hatta küresel düzeyde olabilir.

Varsayılan ICE aday politikası MUST "all" olarak ayarlanmalıdır; çünkü bu genellikle istenen politikadır ve ayrıca tipik olarak uygulamanın TURN sunucusu kaynaklarının kullanımını önemli ölçüde azaltır.

ICE aday havuzu için bir boyut belirtilirse, bu, adayların önceden toplanacağı ICE bileşenlerinin sayısını gösterir. Önceden toplama, potansiyel olarak uzun süreler boyunca STUN/TURN sunucusu kaynaklarının kullanılmasına yol açtığından, bu işlem MUST yalnızca uygulama talebi üzerine gerçekleşmelidir; bu nedenle varsayılan aday havuzu boyutu MUST sıfır olmalıdır.

Uygulama, [RFC8843]’te tanımlanan çoklama mekanizması olan bundle kullanımına ilişkin tercih ettiği politikayı belirtebilir. Politika ne olursa olsun, uygulama her zaman tek bir taşıma üzerinde bundle müzakere etmeye çalışır ve tüm "m=" bölümleri boyunca tek bir bundle grubu teklif eder; bu tek taşımanın kullanımı, yanıtlayanın bundle’ı kabul etmesine bağlıdır. Ancak, aşağıdaki listeden bir politika belirtilerek, uygulama medya akışlarını bir araya getirme konusunda ne kadar agresif davranacağını tam olarak denetleyebilir; bu da bundle farkında olmayan bir uç nokta ile nasıl birlikte çalışacağını etkiler. Bundle farkında olmayan bir uç nokta ile müzakere edilirken, yalnızca bundle-only olarak işaretlenmemiş akışlar kurulacaktır.

Kullanılabilir politika kümesi aşağıdaki gibidir:

balanced: Her türün (ses, video veya uygulama) ilk "m=" bölümü taşıma parametrelerini içerir; bu, yanıtlayanın o bölümü bundle’dan ayırabilmesini sağlar. Her türün ikinci ve sonraki tüm "m=" bölümleri bundle-only olarak işaretlenir. Sonuç olarak, N adet farklı medya türü varsa, N medya akışı için adaylar toplanır. Bu politika, çoklama isteği ile temel ses ve videonun eski durumlarda hâlâ müzakere edilebilmesini sağlama ihtiyacı arasında bir denge kurar. Yanıtlayıcı olarak davranıldığında, teklifte bir bundle grubu yoksa, uygulama her türün ilk "m=" bölümü dışındaki tüm bölümleri reddeder.
max-compat: Tüm "m=" bölümleri taşıma parametrelerini içerir; hiçbiri bundle-only olarak işaretlenmez. Bu politika, bundle farkında olmayan uç noktalar tarafından tüm akışların alınmasına izin verir, ancak her bir medya akışı için ayrı adayların toplanmasını gerektirir.
max-bundle: Yalnızca ilk "m=" bölümü taşıma parametrelerini içerir; ilk dışındaki tüm akışlar bundle-only olarak işaretlenir. Bu politika, aday toplamayı en aza indirmeyi ve çoklamayı en üst düzeye çıkarmayı amaçlar, ancak eski uç noktalarla daha az uyumluluk pahasına. Yanıtlayıcı olarak davranıldığında, uygulama, ilk "m=" bölümü ile aynı bundle grubunda olmadıkları sürece, ilk "m=" bölümü dışındaki tüm "m=" bölümlerini reddeder.

Performans ile eski uç noktalarla uyumluluk arasında en iyi dengeyi sağladığından, varsayılan bundle politikası MUST "balanced" olarak ayarlanmalıdır.

Uygulama, RTP/RTCP çoklama [RFC5761] kullanımına ilişkin tercih ettiği politikayı aşağıdaki politikalardan birini kullanarak belirtebilir:

negotiate: JSEP uygulaması hem RTP hem de RTCP adaylarını toplar, ancak aynı zamanda "a=rtcp-mux" teklif eder; böylece hem çoklamalı hem de çoklamasız uç noktalarla uyumluluk sağlanır.
require: JSEP uygulaması yalnızca RTP adaylarını toplar ve ürettiği tekliflerdeki yeni "m=" bölümlerine bir "a=rtcp-mux-only" göstergesi ekler. Bu, teklif verenin toplaması gereken aday sayısını yarıya indirir. "a=rtcp-mux" özniteliği içermeyen bir "m=" bölümüne sahip bir tanımın uygulanması bir hatanın döndürülmesine neden olur.

Varsayılan çoklama politikası MUST "require" olarak ayarlanmalıdır. Uygulamalar, uygulamanın çoklama politikasını "negotiate" olarak ayarlama girişimlerini reddetmeyi MAY seçebilir.

4.1.2. addTrack

addTrack yöntemi, bir MediaStreamTrack’i PeerConnection’a ekler ve MediaStream bağımsız değişkenini kullanarak izi aynı MediaStream içindeki diğer izlerle ilişkilendirir; böylece bir teklif veya yanıt oluşturulurken aynı "LS" (Dudak Senkronizasyonu) grubuna eklenebilirler. İzlerin aynı "LS" grubuna eklenmesi, [RFC5888], Bölüm 7’de açıklandığı üzere, düzgün dudak senkronizasyonu için bu izlerin oynatımının eşzamanlı olması gerektiğini belirtir. addTrack, alıcı-verici sayısını en aza indirmeye çalışır: PeerConnection "have-remote-offer" durumundaysa, iz, setRemoteDescription’ın en son çağrısı tarafından oluşturulmuş ve yerel izi olmayan ilk uyumlu alıcı-vericiye bağlanır. Aksi takdirde, Bölüm 4.1.4’te açıklandığı üzere yeni bir alıcı-verici oluşturulur.

4.1.3. removeTrack

removeTrack yöntemi, hangi göndericinin izinin kaldırılacağını belirtmek için RtpSender bağımsız değişkenini kullanarak bir MediaStreamTrack’i PeerConnection’dan kaldırır. Göndericinin izi temizlenir ve gönderici iletimi durdurur. createOffer’a yapılacak gelecekteki çağrılar, göndericiyle ilişkili "m=" bölümünü recvonly (transceiver.direction sendrecv ise) ya da inactive (transceiver.direction sendonly ise) olarak işaretler.

4.1.4. addTransceiver

addTransceiver yöntemi, PeerConnection’a yeni bir RtpTransceiver ekler. Bir MediaStreamTrack bağımsız değişkeni sağlanırsa, alıcı-verici bu medya türüyle yapılandırılır ve iz alıcı-vericiye bağlanır. Aksi takdirde, uygulama türü açıkça belirtmek MUST zorundadır; bu kip, recvonly alıcı-vericiler oluşturmak ve daha sonraki bir noktada iz bağlanabilecek alıcı-vericiler oluşturmak için kullanışlıdır.

Oluşturma anında, uygulama ayrıca bir alıcı-verici yön özniteliği, alıcı-vericinin ilişkilendirildiği bir MediaStreams kümesi ("LS" grup atamalarına izin verir) ve medya için bir kodlama kümesi (Bölüm 3.7’de açıklandığı üzere simulcast için kullanılır) belirtebilir.

4.1.5. onaddtrack Olayı

onaddtrack olayı, bir setRemoteDescription çağrısı sonucunda yeni bir uzak izin sinyallenmesi durumunda uygulamaya gönderilir. Yeni iz, olay içinde bir MediaStreamTrack nesnesi olarak, izin parçası olduğu MediaStream(ler) ile birlikte sağlanır.

4.1.6. createDataChannel

createDataChannel yöntemi, yeni bir veri kanalı oluşturur ve bunu PeerConnection’a bağlar. Bu PeerConnection için hâlihazırda bir veri kanalı yoksa, yeni bir teklif/yanıt değişimi gereklidir. Belirli bir PeerConnection üzerindeki tüm veri kanalları aynı SCTP/DTLS ilişkilendirmesini paylaşır ("SCTP", "Stream Control Transmission Protocol" anlamına gelir) ve dolayısıyla aynı "m=" bölümünü kullanır; bu nedenle veri kanallarının sonraki oluşturulmaları JSEP durumu üzerinde herhangi bir etkiye sahip değildir.

createDataChannel yöntemi ayrıca, PeerConnection tarafından kullanılan (örneğin maxPacketLifetime) ancak SDP’ye yansıtılmayan ve JSEP durumunu etkilemeyen bir dizi bağımsız değişken de içerir.

4.1.7. ondatachannel Olayı

ondatachannel olayı, uzak tarafça yeni bir veri kanalının müzakere edilmesi durumunda uygulamaya gönderilir; bu, altta yatan SCTP/DTLS ilişkilendirmesi kurulduktan sonra herhangi bir zamanda gerçekleşebilir. Yeni veri kanalı nesnesi olay içinde sağlanır.

4.1.8. createOffer

createOffer yöntemi, [RFC3264] uyarınca bir teklif içeren ve bu PeerConnection’a eklenmiş medyanın tanımlarını, bu uygulamanın desteklediği codec, RTP ve RTCP seçeneklerini ve ICE aracısı tarafından toplanmış tüm adayları içeren bir SDP bloğu üretir. Üretilen teklif üzerinde ek denetim sağlamak için bir seçenekler parametresi verilebilir. Bu seçenekler parametresi, bağlantının yeniden kurulması amacıyla bir ICE yeniden başlatmasını tetiklemeye olanak tanır.

İlk teklifte, üretilen SDP oturum için istenen tüm işlevselliği içerir (desteklenen ancak varsayılan olarak istenmeyen işlevsellik dışarıda bırakılabilir); her bir SDP satırı için, SDP’nin üretilmesi, ilgili SDP satırını tanımlayan belirtimde tanımlanan ilk teklif üretim sürecini izler. İlk teklif üretiminin tam olarak nasıl ele alındığı aşağıda Bölüm 5.2.1’de ayrıntılandırılmıştır.

4.1.9. createAnswer

createAnswer yöntemi, [RFC3264] uyarınca bir yanıt içeren bir SDP bloğu üretir; bu yanıt, en son setRemoteDescription çağrısında sağlanan parametrelerle uyumlu, oturum için desteklenen yapılandırmayı içerir. createAnswer çağrılmadan önce setRemoteDescription çağrılmış OLMALIDIR. createOffer gibi, döndürülen blok bu PeerConnection’a eklenmiş medyanın tanımlarını, bu oturum için müzakere edilen codec/RTP/RTCP seçeneklerini ve ICE aracısı tarafından toplanmış tüm adayları içerir. Üretilen yanıt üzerinde ek denetim sağlamak için bir seçenekler parametresi verilebilir.

Bir yanıt olarak, üretilen SDP medya düzleminin nasıl kurulması gerektiğini belirten somut bir yapılandırma içerir; her SDP satırı için, SDP üretimi, ilgili SDP satırını tanımlayan belirtimde tanımlanan yanıt üretim sürecini İZLEMELİDİR. Yanıt üretiminin tam olarak nasıl ele alındığı aşağıda Bölüm 5.3’te ayrıntılandırılmıştır.

createAnswer tarafından üretilen oturum tanımları, setLocalDescription tarafından doğrudan kullanılabilir OLMALIDIR; createOffer gibi, döndürülen tanım sistemin mevcut durumunu yansıtmalıdır (SHOULD).

Bu yöntemin çağrılması, yeni ICE kimlik bilgilerinin üretilmesi gibi şeylere yol açabilir; ancak PeerConnection durumunu değiştirmez, aday toplamayı tetiklemez veya bir medya durumu değişikliğine neden olmaz. Özellikle, yanıt setLocalDescription çağrılana kadar uygulanmaz ve mevcut yerel tanım haline gelmez.

4.1.10. SessionDescriptionType

Oturum tanımı nesneleri (RTCSessionDescription) "offer", "pranswer", "answer" veya "rollback" türünde olabilir. Bu türler, description parametresinin nasıl ayrıştırılacağı ve medya durumunun nasıl değiştirilmesi gerektiği hakkında bilgi sağlar.

offer

"offer", bir tanımın bir teklif olarak ayrıştırılması gerektiğini belirtir (MUST); böyle bir tanım birçok olası medya yapılandırmasını içerebilir. "offer" olarak kullanılan bir tanım, PeerConnection "stable" durumda olduğunda ya da daha önce sağlanmış ancak yanıtlanmamış bir "offer" üzerinde güncelleme olarak uygulanabilir.

pranswer

"pranswer", bir tanımın bir yanıt olarak ayrıştırılması gerektiğini belirtir (MUST), ancak bu nihai bir yanıt değildir ve bu nedenle ayrılan kaynakların serbest bırakılmasıyla sonuçlanmamalıdır (MUST NOT). Yanıt etkin olmayan bir medya yönü belirtmiyorsa, medya iletiminin başlamasına yol açabilir. "pranswer" olarak kullanılan bir tanım, bir "offer"’a yanıt olarak veya daha önce gönderilmiş bir "pranswer" üzerinde güncelleme olarak uygulanabilir.

answer

"answer", bir tanımın bir yanıt olarak ayrıştırılması gerektiğini belirtir (MUST); teklif/yanıt değişimi tamamlanmış sayılır (MUST) ve artık ihtiyaç duyulmayan tüm kaynaklar (decoder’lar, candidate’ler) serbest bırakılmalıdır (SHOULD). "answer" olarak kullanılan bir tanım, bir "offer"’a yanıt olarak veya daha önce gönderilmiş bir "pranswer" üzerinde güncelleme olarak uygulanabilir.

Geçici (provisional) ve nihai yanıt arasındaki tek fark, nihai yanıtın teklif sonucunda ayrılmış kullanılmayan kaynakları serbest bırakmasıdır. Bu nedenle uygulama, bir yanıtın geçici mi yoksa nihai mi olarak uygulanacağı konusunda takdir yetkisini kullanabilir ve oturum tanımının türünü gerektikçe değiştirebilir. Örneğin, sıralı (serial) bir forking senaryosunda bir uygulama, her uzak uç noktadan birer tane olmak üzere birden fazla "final" yanıt alabilir. Uygulama, ilk yanıtları geçici yanıt olarak kabul edip yalnızca kendi kriterlerini karşılayan bir yanıt aldığında (örn. sesli mesaj yerine canlı bir kullanıcı) yanıtı nihai olarak uygulamayı seçebilir.

rollback

"rollback", durum makinesinin önceki "stable" duruma geri alınması gerektiğini belirten özel bir oturum tanımı türüdür (MUST); ayrıntılar Bölüm 4.1.10.2’de açıklanmıştır. İçerik boş OLMALIDIR.

4.1.10.1. Geçici Yanıtların Kullanımı

Çoğu uygulamanın "pranswer" türünü kullanarak yanıt üretmeye ihtiyacı olmayacaktır. Oturum taşımasını "ısıtmak" ve medya kırpılmasını (clipping) önlemek için bir teklife hızlı yanıt göndermek iyi bir pratik olsa da, JSEP uygulamalarının tercih edilen yaklaşımı, teklif alındıktan hemen sonra null bir MediaStreamTrack ile "sendonly" türünde nihai bir yanıt oluşturup göndermektir. Bu, arayan tarafın medya göndermesini engeller ve callee yanıt verir vermez medya gönderebilmesini sağlar. Daha sonra, çağrı gerçekten kabul edildiğinde uygulama gerçek MediaStreamTrack’i takabilir ve önceki teklif/yanıt çiftini güncellemek ve çift yönlü medya akışını başlatmak için yeni bir "sendrecv" teklifi oluşturabilir. Bu, bir "sendonly" pranswer ardından bir "sendrecv" answer ile de yapılabilirdi; ancak ilk pranswer teklif/yanıt değişimini açık bırakır, bu da arayan tarafın bu süre boyunca güncellenmiş bir teklif gönderememesi anlamına gelir.

Örnek olarak, ses ve videoyu mümkün olduğunca hızlı kurmak isteyen tipik bir JSEP uygulamasını düşünün. Callee, ses ve video MediaStreamTrack’leri içeren bir teklif aldığında, bu izleri sendonly olarak kabul eden anlık bir yanıt gönderir (bu, arayanın henüz callee’ye herhangi bir medya göndermeyeceği ve callee’nin de henüz kendi MediaStreamTrack’lerini eklemediği için herhangi bir medya göndermeyeceği anlamına gelir). Ardından kullanıcıdan çağrıyı kabul etmesini ve gerekli yerel izleri edinmesini ister. Kullanıcı tarafından kabul edildiğinde, uygulama edindiği izleri takar; ICE el sıkışması ve DTLS el sıkışması bu noktada büyük olasılıkla tamamlandığından, iletim hemen başlayabilir. Uygulama ayrıca uzak tarafa çağrının kabul edildiğini bildirmek ve ses/video’yu çift yönlü medyaya taşımak için yeni bir teklif gönderir. Bu doğrultuda ayrıntılı bir akış örneği Bölüm 7.3’te gösterilmiştir.

Elbette bazı uygulamalar bu çift teklif/yanıt değişimini gerçekleştiremeyebilir; özellikle eski sinyalleşme protokollerine ağ geçidi yapmaya çalışanlar. Bu durumlarda pranswer, uygulamaya taşımayı ısıtmak için yine de bir mekanizma sağlayabilir.

4.1.10.2. Geri Alma (Rollback)

Bazı durumlarda, setLocalDescription veya setRemoteDescription’a yapılan bir değişikliği "geri almak" istenebilir. Devam eden bir çağrı olduğunu ve taraflardan birinin bazı oturum parametrelerini değiştirmek istediğini düşünün; bu taraf güncellenmiş bir teklif üretir ve ardından setLocalDescription çağırır. Ancak uzak taraf, setRemoteDescription’dan önce ya da sonra, yeni parametreleri kabul etmemeye karar verir ve teklif gönderene bir red mesajı gönderir. Şimdi teklif gönderen — ve muhtemelen yanıt veren de — "stable" duruma ve önceki yerel/uzak tanıma geri dönmek zorundadır. Bunu desteklemek için, oturum üzerinde önerilen değişiklikleri atan ve durum makinesini "stable" durumuna döndüren "rollback" kavramını sunuyoruz. Geri alma, setLocalDescription veya setRemoteDescription’a boş içerikli, türü "rollback" olan bir oturum tanımı sağlanarak yapılır.

4.1.11. setLocalDescription

setLocalDescription yöntemi, PeerConnection’a sağlanan oturum tanımını yerel yapılandırması olarak uygulamasını söyler. type alanı, tanımın bir teklif, geçici yanıt, nihai yanıt veya geri alma olarak işlenip işlenmeyeceğini belirtir; teklifler ve yanıtlar her bir SDP satırı için var olan çeşitli kurallar kullanılarak farklı şekilde denetlenir.

Bu API yerel medya durumunu değiştirir; diğer şeylerin yanı sıra, medya almak ve kodunu çözmek için yerel kaynakları kurar. Uygulamanın, bir medya formatından farklı, uyumsuz başka bir formata geçişi teklif etmek istediği senaryoları başarıyla ele almak için, PeerConnection mevcut ve bekleyen yerel tanımların ikisinin de kullanımını eş zamanlı olarak desteklemek ZORUNDADIR (örneğin her iki tanımda da bulunan codec’leri desteklemek). Bu çift işleme, PeerConnection "have-local-offer" durumuna girdiğinde başlar ve setRemoteDescription (1) nihai bir yanıtla çağrılana kadar — bu noktada PeerConnection bekleyen yerel tanımı tamamen benimseyebilir — ya da (2) bir geri alma ile çağrılana kadar — bu da mevcut yerel tanıma geri dönüşle sonuçlanır — devam eder.

Bu API, candidate toplama sürecini dolaylı olarak kontrol eder. Bir yerel tanım sağlandığında ve şu anda kullanılan transport sayısı yerel tanımın gerektirdiği transport sayısıyla eşleşmediğinde, PeerConnection ihtiyaç duyulan transport’ları oluşturur ve mevcutsa candidate havuzundaki adayları kullanarak her transport için aday toplamaya başlar.

Eğer (1) setRemoteDescription daha önce bir teklif ile çağrılmışsa, (2) setLocalDescription bir yanıt (geçici veya nihai) ile çağrılırsa, (3) medya yönleri uyumluysa ve (4) gönderilebilecek medya mevcutsa, bu durum medya iletiminin başlamasıyla sonuçlanır.

4.1.12. setRemoteDescription

setRemoteDescription yöntemi, PeerConnection’a sağlanan oturum tanımını istenen uzak yapılandırma olarak uygulamasını söyler. setLocalDescription’da olduğu gibi, tanımın type alanı nasıl işleneceğini belirtir.

Bu API yerel medya durumunu değiştirir; diğer şeylerin yanı sıra, medya göndermek ve kodlamak için yerel kaynakları kurar.

Eğer (1) setLocalDescription daha önce bir teklif ile çağrılmışsa, (2) setRemoteDescription bir yanıt (geçici veya nihai) ile çağrılırsa, (3) medya yönleri uyumluysa ve (4) gönderilebilecek medya mevcutsa, bu durum medya iletiminin başlamasıyla sonuçlanır.

4.1.13. currentLocalDescription

currentLocalDescription yöntemi, mevcut müzakere edilmiş yerel tanımı — yani son başarılı teklif/yanıt değişimindeki yerel tanımı — ve bu yerel tanım ayarlandığından beri ICE aracısı tarafından üretilen tüm yerel adayları döndürür.

Henüz bir teklif/yanıt değişimi tamamlanmamışsa null bir nesne döndürülür.

4.1.14. pendingLocalDescription

pendingLocalDescription yöntemi, şu anda müzakere edilmekte olan yerel tanımın bir kopyasını — yani karşılık gelen bir uzak yanıt olmadan ayarlanmış bir yerel teklifi — ve bu yerel tanım ayarlandığından beri ICE aracısı tarafından üretilen tüm yerel adayları döndürür.

PeerConnection’ın durumu "stable" veya "have-remote-offer" ise null bir nesne döndürülür.

4.1.15. currentRemoteDescription

currentRemoteDescription yöntemi, mevcut müzakere edilmiş uzak tanımın — yani son başarılı teklif/yanıt değişimindeki uzak tanımın — bir kopyasını ve bu uzak tanım ayarlandığından beri processIceMessage aracılığıyla sağlanan tüm uzak adayları döndürür.

Henüz bir teklif/yanıt değişimi tamamlanmamışsa null bir nesne döndürülür.

4.1.16. pendingRemoteDescription

pendingRemoteDescription yöntemi, şu anda müzakere edilmekte olan uzak tanımın bir kopyasını — yani karşılık gelen bir yerel yanıt olmadan ayarlanmış bir uzak teklifi — ve bu uzak tanım ayarlandığından beri processIceMessage aracılığıyla sağlanan tüm uzak adayları döndürür.

PeerConnection’ın durumu "stable" veya "have-local-offer" ise null bir nesne döndürülür.

4.1.17. canTrickleIceCandidates

canTrickleIceCandidates özelliği, uzak tarafın trickle adayları almayı destekleyip desteklemediğini belirtir. Üç olası değer vardır:

null: Diğer taraftan henüz SDP alınmamıştır, bu yüzden trickle’ı işleyebilip işleyemeyeceği bilinmiyor. setRemoteDescription çağrılmadan önceki başlangıç değeridir.
true: Diğer taraftan, trickle’ı destekleyebileceğini gösteren SDP alınmıştır.
false: Diğer taraftan, trickle’ı destekleyemediğini gösteren SDP alınmıştır.

Bölüm 3.5.2’de açıklandığı gibi, JSEP uygulamaları her zaman adayları uygulamaya tek tek sağlar; bu Trickle ICE için gereken davranışla tutarlıdır. Ancak uygulamalar, eşlerinin gerçekten Trickle ICE yapıp yapamayacağını — yani gönderildikten sonra adayları toplandıkça eklemenin güvenli olup olmadığını — belirlemek için canTrickleIceCandidates özelliğini kullanabilir. Uzak Trickle ICE desteğini kesin olarak belirten tek değer "true" olduğu için, canTrickleIceCandidates’ı "true" ile karşılaştıran bir uygulama, ilk tekliflerde varsayılan olarak Half Trickle deneyecek ve Trickle ICE uyumlu bir aracıyla sonraki etkileşimlerde Full Trickle uygulayacaktır.

4.1.18. setConfiguration

setConfiguration yöntemi, başlangıçta yapıcı (constructor) parametreleriyle ayarlanan PeerConnection’ın küresel yapılandırmasının oturum sırasında değiştirilmesine olanak tanır. Bu yöntemin çağrılmasının etkileri ne zaman çağrıldığına bağlıdır ve hangi belirli parametrelerin değiştirildiğine göre farklılık gösterir:

Kullanılacak STUN/TURN sunucularındaki herhangi bir değişiklik bir sonraki toplama aşamasını etkiler. Bir ICE toplama aşaması zaten başlamışsa veya tamamlanmışsa, Bölüm 3.5.1’de bahsedilen needs-ice-restart biti ayarlanır. Bu, bir sonraki createOffer çağrısının, ICE yeniden başlatmasını zorlamak ve yeni sunucuların kullanılacağı yeni bir toplama aşamasını başlatmak amacıyla yeni ICE kimlik bilgileri üretmesine neden olur. ICE candidate havuzunun boyutu sıfır değilse ve henüz bir yerel tanım uygulanmamışsa, mevcut adaylar atılır ve yeni sunuculardan yeni adaylar toplanır.
ICE aday ilkesindeki herhangi bir değişiklik, bir sonraki toplama aşamasını etkiler. Bir ICE toplama aşaması zaten başlamışsa veya tamamlanmışsa, needs-ice-restart biti ayarlanır. Her iki durumda da, ilke değişikliklerinin aday havuzu üzerinde hiçbir etkisi yoktur; çünkü havuzda toplanan adaylar, bir toplama aşaması gerçekleşene kadar uygulamaya sunulmaz ve bu nedenle gerekli tüm filtreleme, havuzlanmış adaylar üzerinde hâlâ yapılabilir.
Yerel bir açıklama uygulandıktan sonra ICE aday havuzu boyutu DEĞİŞTİRİLMEMELİDİR. Henüz bir yerel açıklama uygulanmamışsa, ICE aday havuzu boyutundaki tüm değişiklikler derhal etkili olur; artırılırsa ek adaylar önceden toplanır; azaltılırsa artık gereksiz olan adaylar atılır.
Paketleme (bundle) ve RTCP-çoklama (RTCP-multiplexing) ilkeleri, PeerConnection oluşturulduktan sonra DEĞİŞTİRİLMEMELİDİR.

Bu yöntemin çağrılması, ICE aracısının durumunda bir değişikliğe yol açabilir.

4.1.19. addIceCandidate

addIceCandidate yöntemi, bir IceCandidate nesnesi (Bölüm 3.5.2.1) aracılığıyla ICE aracısına bir güncelleme sağlar. IceCandidate nesnesinin candidate alanı null değilse, IceCandidate yeni bir uzak ICE adayı olarak ele alınır ve Trickle ICE için tanımlanan kurallara göre mevcut ve/veya bekleyen uzak açıklamaya eklenir. Aksi takdirde, IceCandidate, [RFC8838], Bölüm 14’te tanımlandığı üzere bir aday-sonu (end-of-candidates) göstergesi olarak değerlendirilir.

Her iki durumda da, sağlanan IceCandidate içindeki "m=" bölüm dizini, MID ve ufrag alanları, IceCandidate’ın hangi "m=" bölümüne ve hangi ICE aday üretimine ait olduğunu belirlemek için, yukarıdaki Bölüm 3.5.2.1’de açıklandığı şekilde kullanılır. Aday-sonu göstergesi durumunda, "m=" bölüm dizini ve MID alanları için null değerler, göstergenin belirtilen ICE aday üretimindeki tüm "m=" bölümleri için geçerli olduğu şeklinde yorumlanır. Ancak, yeni bir uzak aday için her iki alan da null ise, aşağıda belirtildiği üzere bu GEÇERSİZ bir durum olarak ele ALINMALIDIR.

Herhangi bir IceCandidate alanı geçersiz değerler içeriyorsa veya IceCandidate nesnesinin işlenmesi sırasında bir hata oluşursa, sağlanan IceCandidate YOK SAYILMALIDIR ve bir hata DÖNDÜRÜLMELİDİR.

Aksi takdirde, yeni uzak aday veya aday-sonu göstergesi ICE aracısına iletilir. Yeni bir uzak aday durumunda, ICE toplama sürecini başlatmak için setLocalDescription zaten çağrılmış olduğu varsayılarak, yeni adaya bağlantı denetimleri gönderilir.

4.1.20. onicecandidate Olayı

onicecandidate olayı, iki durumda uygulamaya gönderilir: (1) ICE aracısı, Bölüm 3.5.1’de özetlendiği ve Bölüm 3.5.3’te tartışılan kısıtlamalara tabi olarak, ICE toplama sırasında izin verilen yeni bir yerel ICE adayı keşfettiğinde veya (2) bir ICE toplama aşaması tamamlandığında. Olay, Bölüm 3.5.2.1’de tanımlandığı üzere tek bir IceCandidate nesnesi içerir.

Birinci durumda, yeni keşfedilen aday IceCandidate nesnesine yansıtılır ve tüm alanları null OLMAMALIDIR. Bu aday ayrıca, Trickle ICE için tanımlanan kurallara göre mevcut ve/veya bekleyen yerel açıklamaya eklenir.

İkinci durumda, olayın IceCandidate nesnesinin candidate alanı, mevcut toplama aşamasının tamamlandığını, yani bu aşamada artık başka onicecandidate olayları olmayacağını belirtmek için null olarak AYARLANMALIDIR. Ancak, hangi ICE aday üretiminin sona erdiğini belirtmek için IceCandidate’ın ufrag alanı BELİRTİLMELİDİR. IceCandidate’ın "m=" bölüm dizini ve MID alanları, olayın belirli bir "m=" bölümü için geçerli olduğunu belirtmek üzere BELİRTİLEBİLİR ya da mevcut ICE aday üretimindeki tüm "m=" bölümleri için geçerli olduğunu belirtmek üzere null olarak AYARLANABİLİR. Bu olay, [RFC8838], Bölüm 13’te tanımlandığı üzere, uygulama tarafından bir aday-sonu göstergesi üretmek için kullanılabilir.

4.2. RtpTransceiver

4.2.1. stop

stop yöntemi bir RtpTransceiver’ı durdurur. Bu, createOffer için yapılacak gelecekteki çağrıların, ilişkili "m=" bölümü için sıfır port üretmesine neden olur. Daha fazla ayrıntı için aşağıya bakınız.

4.2.2. stopped

stopped özelliği, transceiver’ın stop çağrısıyla veya ilişkili "m=" bölümünü reddeden bir yanıtın uygulanmasıyla durdurulup durdurulmadığını belirtir. Bu durumların her ikisinde de "true" olarak ayarlanır; aksi takdirde "false" olarak ayarlanır.

Durdurulmuş bir RtpTransceiver, herhangi bir giden RTP veya RTCP göndermez ve gelen RTP veya RTCP’yi işlemez. Yeniden başlatılamaz.

4.2.3. setDirection

setDirection yöntemi, bir transceiver’ın yönünü ayarlar; bu da gelecekteki createOffer ve createAnswer çağrılarında ilişkili "m=" bölümünün direction özelliğini etkiler. Yön için izin verilen değerler, [RFC4566], Bölüm 6’da tanımlanan aynı adlı yön özniteliklerini yansıtacak şekilde "recvonly", "sendrecv", "sendonly" ve "inactive" değerleridir.

Teklifler oluşturulurken, transceiver yönü yeniden teklifler için bile doğrudan çıktıya yansıtılır. Yanıtlar oluşturulurken ise, transceiver yönü, aşağıdaki Bölüm 5.3’te açıklandığı üzere, teklif edilen yönle kesiştirilir.

setDirection her ne kadar transceiver’ın direction özelliğini derhal ayarlasa da (Bölüm 4.2.4), bu özellik transceiver’ın RtpSender’ının gönderip göndermediğini veya RtpReceiver’ının alıp almadığını hemen etkilemez. Etkili olan yön, yalnızca bir yanıt uygulandığında güncellenen currentDirection özelliği ile temsil edilir.

4.2.4. direction

direction özelliği, setDirection içine geçirilen son değeri belirtir. setDirection hiç çağrılmamışsa, transceiver’ın başlatıldığı yön değerine ayarlanır.

4.2.5. currentDirection

currentDirection özelliği, transceiver’ın ilişkili "m=" bölümü için en son müzakere edilen yönü belirtir. Daha açık bir ifadeyle, son uygulanan yanıttaki (geçici yanıtlar dâhil) ilişkili "m=" bölümünün [RFC3264] yön özniteliğini gösterir; eğer bu bir uzak yanıt ise "send" ve "recv" yönleri tersine çevrilir. Örneğin, uzak bir yanıttaki ilişkili "m=" bölümünün yön özniteliği "recvonly" ise, currentDirection "sendonly" olarak ayarlanır.

Bu transceiver’a atıfta bulunan bir yanıt henüz uygulanmamışsa veya transceiver durdurulmuşsa, currentDirection null olarak ayarlanır.

4.2.6. setCodecPreferences

setCodecPreferences yöntemi, bir transceiver’ın codec tercihlerini ayarlar; bu tercihler de gelecekteki createOffer ve createAnswer çağrılarında ilişkili "m=" bölümündeki codec’lerin varlığını ve sırasını etkiler. setCodecPreferences’ın, uygulamanın hangi codec’i göndermeye karar verdiğini doğrudan etkilemediğine dikkat edilmelidir. Bu yöntem yalnızca, teklif veya yanıt aracılığıyla, uygulamanın almayı tercih ettiğini belirttiği codec’leri etkiler. Bir codec, setCodecPreferences tarafından hariç tutulsa bile, bir sonraki teklif/yanıt değişimi onu devre dışı bırakana kadar gönderim için yine de kullanılabilir.

Bir RtpTransceiver’ın codec tercihleri, createOffer ve createAnswer için yapılan sonraki çağrılarda codec’lerin hariç tutulmasına neden olabilir; bu durumda ilişkili "m=" bölümündeki karşılık gelen medya biçimleri de hariç tutulur. Codec tercihleri, aksi takdirde mevcut olmayacak medya biçimlerini ekleyemez.

Bir RtpTransceiver’ın codec tercihleri, createOffer ve createAnswer için yapılan sonraki çağrılarda codec’lerin sırasını da belirleyebilir; bu durumda ilişkili "m=" bölümündeki medya biçimlerinin sırası, belirtilen tercihlere uyar.

#5. SDP Etkileşim Prosedürleri

Bu bölüm, SDP nesneleri oluşturulurken ve ayrıştırılırken izlenecek özel prosedürleri açıklar.

5.1. Gereksinimlere Genel Bakış

JSEP uygulamaları, tekliflerin ve yanıtların oluşturulmasını ve işlenmesini yöneten aşağıda listelenen özelliklere UYMAK ZORUNDADIR.

5.1.1. Kullanım Gereksinimleri

JSEP uygulamaları tarafından işlenen tüm oturum açıklamaları, hem yerel hem de uzak olanlar, aşağıdaki özelliklere destek belirtmek ZORUNDADIR. Bunlardan herhangi biri yoksa, bu eksiklik bir hata olarak ELE ALINMALIDIR.

[RFC8445]’te belirtildiği üzere ICE KULLANILMALIDIR. Uzak uç noktanın lite bir uygulama kullanabileceğine dikkat edilmelidir; uygulamalar, ICE-lite kullanan uzak uç noktaları doğru şekilde ele ALMAK ZORUNDADIR. Uzak uç nokta ayrıca ICE’in daha eski bir sürümünü de kullanabilir; uygulamalar, [RFC5245]’te belirtildiği şekilde ICE kullanan uzak uç noktaları doğru şekilde ele ALMAK ZORUNDADIR.
Medya türüne uygun olarak, [RFC8827]’de belirtildiği üzere DTLS [RFC6347] veya DTLS-SRTP [RFC5763] KULLANILMALIDIR.

[ RFC8827 ]’de tartışıldığı üzere, SRTP anahtarlandırması için SDP güvenlik açıklamaları mekanizması [RFC4568] KULLANILMAMALIDIR.

5.1.2. Profil Adları ve Birlikte Çalışabilirlik

Medya "m=" bölümleri için JSEP uygulamaları, [RFC5764]’te belirtilen "UDP/TLS/RTP/SAVPF" profilini ve [RFC7850]’de belirtilen "TCP/DTLS/RTP/SAVPF" profilini DESTEKLEMEK ZORUNDADIR ve ürettikleri her medya "m=" satırı için bu profillerden birini belirtmek ZORUNDADIR. Veri "m=" bölümleri için uygulamalar, "UDP/DTLS/SCTP" profilini ve "TCP/DTLS/SCTP" profilini DESTEKLEMEK ZORUNDADIR ve ürettikleri her veri "m=" satırı için bu profillerden birini belirtmek ZORUNDADIR. Kullanılacak kesin profil, [RFC8839], Bölüm 4.2.1.2’de açıklandığı üzere, geçerli varsayılan veya seçili ICE adayıyla ilişkili protokol tarafından belirlenir.

Ne yazık ki, uyumluluk sağlama amacıyla bazı uç noktalar, bu profillerden birini desteklemek isteseler bile başka profil dizgeleri üretir. Örneğin, bir uç nokta "RTP/AVP" üretebilir ancak "a=fingerprint" ve "a=rtcp-fb" özniteliklerini sağlayarak "UDP/TLS/RTP/SAVPF" veya "TCP/DTLS/RTP/SAVPF" desteğini ifade edebilir. Bu tür uç noktalarla uyumluluğu basitleştirmek için, JSEP uygulamaları alınan bir teklifteki medya "m=" bölümlerini işlerken aşağıdaki kurallara UYMAK ZORUNDADIR:

Teklifte aşağıdakilerden biriyle eşleşen herhangi bir profil KABUL EDİLMELİDİR:
"RTP/AVP" ([RFC4566], Bölüm 8.2.2’de tanımlanmıştır)
"RTP/AVPF" ([RFC4585], Bölüm 9’da tanımlanmıştır)
"RTP/SAVP" ([RFC3711], Bölüm 12’de tanımlanmıştır)
"RTP/SAVPF" ([RFC5124], Bölüm 6’da tanımlanmıştır)
"TCP/DTLS/RTP/SAVP" ([RFC7850], Bölüm 3.4’te tanımlanmıştır)
"TCP/DTLS/RTP/SAVPF" ([RFC7850], Bölüm 3.5’te tanımlanmıştır)
"UDP/TLS/RTP/SAVP" ([RFC5764], Bölüm 9’da tanımlanmıştır)
"UDP/TLS/RTP/SAVPF" ([RFC5764], Bölüm 9’da tanımlanmıştır)
Üretilen herhangi bir yanıttaki herhangi bir "m=" satırındaki profil, teklifte sağlanan profille TAM OLARAK eşleşmek ZORUNDADIR.
DTLS-SRTP ZORUNLU olduğundan, SAVP veya AVP seçiminin bir etkisi yoktur; DTLS-SRTP desteği, bir veya daha fazla "a=fingerprint" özniteliğinin varlığıyla belirlenir. "a=fingerprint" özniteliğinin bulunmamasının müzakere başarısızlığına yol açacağına dikkat edilmelidir.
AVPF veya AVP kullanımı yalnızca RTCP geri bildirimi için kullanılan zamanlama kurallarını kontrol eder. AVPF sağlanmışsa veya bir a=rtcp-fb özniteliği mevcutsa, AVPF zamanlaması varsayılır; yani varsayılan trr-int=0 değeri kullanılır. Aksi takdirde, AVPF’nin AVP ile uyumlu bir kipte kullanıldığı varsayılır ve trr-int=4000 değeri kullanılır.
Veri m= bölümleri için uygulamalar, UDP/DTLS/SCTP, TCP/DTLS/SCTP veya (geriye dönük uyumluluk için) DTLS/SCTP profillerini almayı DESTEKLEMEK ZORUNDADIR.

JSEP uygulamaları tarafından yapılan yeniden teklifler, ilk teklif/yanıt değişimi (yanlış) eski bir profil dizgesi kullanmış olsa bile, DOĞRU profil dizgelerini kullanmak ZORUNDADIR. Bu durum, JSEP davranışını basitleştirir ve asgari bir olumsuzlukla sonuçlanır; çünkü böyle bir yeniden teklifi ele alamayan herhangi bir uzak uç nokta, bir JSEP uç noktasının ilk teklifini de ele alamayacaktır.

5.2. Bir Teklifin Oluşturulması

createOffer çağrıldığında, [RFC8834]’te belirtilen işlevselliği içeren yeni bir SDP açıklaması OLUŞTURULMALIDIR. Bu sürecin kesin ayrıntıları aşağıda açıklanmaktadır.

5.2.1. İlk Teklifler

createOffer ilk kez çağrıldığında, elde edilen sonuç ilk teklif olarak adlandırılır.

İlk bir teklifin üretilmesindeki ilk adım, [RFC4566], Bölüm 5’te belirtildiği üzere oturum düzeyi özniteliklerin üretilmesidir. Özellikle:

İlk SDP satırı, [RFC4566], Bölüm 5.1’de tanımlandığı üzere v=0 OLMALIDIR.
İkinci SDP satırı, [RFC4566], Bölüm 5.2’de tanımlandığı üzere bir o= satırı OLMALIDIR. <username> alanının değeri - OLMALIDIR. <sess-id>, 64 bitlik işaretli bir tamsayıyla temsil edilebilir OLMALIDIR ve değeri 2^(63)-1’den küçük OLMALIDIR. <sess-id>’nin, en yüksek biti sıfıra ayarlanmış ve kalan 63 bitin kriptografik olarak rastgele olduğu 64 bitlik bir nicelik üretilerek meydana getirilmesi ÖNERİLİR. <nettype> <addrtype> <unicast-address> üçlüsünün değeri, bu alanda yerel bir IP adresinin sızmasını önlemek için IN IP4 0.0.0.0 gibi anlamsız bir adres olarak AYARLANMALIDIR; bu sorun [RFC8828]’de tartışılmaktadır. [RFC4566]’da belirtildiği üzere, o= satırının tamamının benzersiz olması gerekir, ancak <sess-id> için rastgele bir sayı seçmek bunu sağlamak için yeterlidir.
Üçüncü SDP satırı, [RFC4566], Bölüm 5.3’te tanımlandığı üzere bir s= satırı OLMALIDIR; o= satırıyla uyumlu olacak şekilde, oturum adı olarak tek bir tire KULLANILMASI ÖNERİLİR, örneğin s=-. Bunun, tek bir boşluk öneren [RFC4566]’daki tavsiyeden farklı olduğuna dikkat edilmelidir; ancak JSEP’te hem o= hem de s= anlamsız olduğundan, aynı anlamsız değere sahip olmaları daha açık görünmektedir.
Oturum Bilgisi (i=), URI (u=), E-posta Adresi (e=), Telefon Numarası (p=), Tekrar Zamanları (r=) ve Saat Dilimleri (z=) satırları bu bağlamda kullanışlı değildir ve DAHİL EDİLMEMELİDİR.
Şifreleme Anahtarları (k=) satırları yeterli güvenlik sağlamaz ve DAHİL EDİLMEMELİDİR.
[RFC4566], Bölüm 5.9’da belirtildiği üzere bir t= satırı EKLENMELİDİR; hem <start-time> hem de <stop-time> sıfır olarak AYARLANMALIDIR, örneğin t=0 0.
[RFC8840], Bölüm 4.1.1 ve [RFC8445], Bölüm 10’da belirtildiği üzere, trickle ve ice2 seçeneklerini içeren bir a=ice-options satırı EKLENMELİDİR.
WebRTC kimliği kullanılıyorsa, [RFC8827], Bölüm 5’te açıklandığı üzere bir a=identity satırı EKLENMELİDİR.

Bir sonraki adım, [RFC4566], Bölüm 5.14’te belirtildiği üzere m= bölümlerinin üretilmesidir. PeerConnection’a eklenmiş ve durdurulmuş olmayan her RtpTransceiver için bir m= bölümü üretilir; bu işlem, RtpTransceiver’ların PeerConnection’a eklenme sırasına göre yapılır. Böyle RtpTransceiver yoksa, hiçbir m= bölümü üretilmez; daha sonra [RFC3264], Bölüm 5’te tartışıldığı üzere yenileri eklenebilir.

Bir RtpTransceiver için üretilen her m= bölümü için, transceiver ile üretilen m= bölümünün dizini arasında bir eşleme oluşturulur.

Her m= bölümü, bundle-only olarak işaretlenmediği sürece, benzersiz bir ICE kimlik bilgileri kümesi ve benzersiz bir ICE adayları kümesi İÇERMELİDİR. Bundle-only m= bölümleri, herhangi bir ICE kimlik bilgisi İÇERMEMELİ ve hiçbir aday TOPLAMAMALIDIR.

DTLS için, tüm m= bölümleri PeerConnection için belirtilmiş olan tüm sertifikaları KULLANMAK ZORUNDADIR; bunun sonucunda hepsi aynı parmak izi değerine veya değerlerine [RFC8122] sahip OLMALIDIR ya da bu değerler oturum düzeyi öznitelikler OLMALIDIR.

Her m= bölümü, [RFC4566], Bölüm 5.14’te belirtildiği şekilde belirtilen biçimde OLUŞTURULMALIDIR. m= satırının kendisi için aşağıdaki kurallara UYULMALIDIR:

Eğer m= bölümü bundle-only olarak işaretlenmişse, <port> değeri sıfıra ayarlanmalıdır. Aksi halde <port> değeri, bu m= bölümü için varsayılan ICE adayının portu olarak ayarlanır; ancak henüz hiçbir aday mevcut olmadığından, [RFC8840], Bölüm 4.1.1’de belirtildiği üzere varsayılan port değeri olan 9 (Discard) KULLANILMALIDIR.
DTLS kullanımını doğru şekilde belirtmek için <proto> alanı, [RFC5764], Bölüm 8’de belirtildiği üzere UDP/TLS/RTP/SAVPF olarak AYARLANMALIDIR.
İlgili transceiver için codec tercihleri ayarlanmışsa, medya formatları karşılık gelen sırada OLUŞTURULMALI ve codec tercihlerinde yer almayan hiçbir codec’i İÇERMEMELİDİR.
Yukarıdaki kısıtlamalar tarafından hariç tutulmadıkça, medya formatları [RFC7874], Bölüm 3 ve [RFC7742], Bölüm 5’te belirtildiği üzere zorunlu ses/video codec’lerini İÇERMELİDİR.

m= satırını, [RFC4566], Bölüm 5.7’de belirtildiği şekilde, derhal bir c= satırı İZLEMELİDİR. Yine, henüz aday bulunmadığından, c= satırı [RFC8840], Bölüm 4.1.1’de tanımlanan varsayılan değer olan IN IP4 0.0.0.0 değerini İÇERMELİDİR.

[RFC8859], SDP özniteliklerini farklı kategorilere ayırır. Bundle kullanımı sırasında gereksiz tekrarları önlemek için, [RFC8843], Bölüm 7.1.3’teki yönlendirme tekrar edilerek, IDENTICAL veya TRANSPORT kategorisindeki öznitelikler bundle edilmiş m= bölümlerinde TEKRARLANMAMALIDIR. Buna, bundle üzerinde uzlaşılmış ve hâlen istenen m= bölümleri ile bundle-only olarak işaretlenmiş m= bölümleri de DAHİLDİR.

Aşağıdaki öznitelikler, IDENTICAL veya TRANSPORT dışındaki bir kategoriye ait olduklarından, her m= bölümünde BULUNMALIDIR:

[RFC5888], Bölüm 4’te belirtildiği üzere bir a=mid satırı. Tüm MID değerleri, kullanıcı bilgisini sızdırmayacak bir şekilde (örneğin rastgele veya her PeerConnection için bir sayaç kullanılarak) OLUŞTURULMALI ve [RFC8843], Bölüm 15.2’de tanımlanan RTP başlık uzantısına verimli biçimde sığabilmeleri için 3 bayt veya daha az OLMALIDIR. Bunun RtpTransceiver mid özelliğini ayarlamadığı unutulmamalıdır; bu yalnızca açıklama uygulandığında gerçekleşir. Bu noktada oluşturulan MID değeri “önerilen” bir MID olarak kabul edilebilir.
İlgili transceiver’ın yönü ile aynı olan bir yön (direction) özniteliği.
m= satırındaki her medya formatı için, [RFC4566], Bölüm 6 ve [RFC3264], Bölüm 5.1’de belirtildiği üzere a=rtpmap ve a=fmtp satırları.
RTP yeniden iletiminin (retransmission) kullanılması gereken her bir birincil codec için, birincil codec’in saat hızıyla rtx belirten karşılık gelen bir a=rtpmap satırı ve birincil codec’in payload türüne referans veren bir a=fmtp satırı; [RFC4588], Bölüm 8.1’de belirtildiği üzere.
Desteklenen her Forward Error Correction (FEC) mekanizması için, [RFC4566], Bölüm 6’da belirtildiği üzere a=rtpmap ve a=fmtp satırları. Desteklenmesi ZORUNLU olan FEC mekanizmaları [RFC8854], Bölüm 7’de belirtilmiştir ve her medya türü için özel kullanım Bölüm 4 ve 5’te açıklanmıştır.
Eğer bu m= bölümü, paket başına medya süresi yapılandırılabilir olan bir medya (örneğin ses) içinse, [RFC4566], Bölüm 6’da belirtildiği üzere, her pakete kapsüllenebilecek maksimum medya miktarını milisaniye cinsinden belirten bir a=maxptime satırı. Bu değer, m= bölümüne dahil edilen tüm codec’ler arasındaki maksimum süre değerlerinin EN KÜÇÜĞÜNE ayarlanır.
Eğer bu m= bölümü video medyası içiniyse ve çözülebilecek görüntü boyutlarıyla ilgili bilinen sınırlamalar varsa, Bölüm 3.6’da belirtildiği üzere bir a=imageattr satırı.
Desteklenen her RTP başlık uzantısı için, [RFC5285], Bölüm 5’te belirtildiği üzere bir a=extmap satırı. Desteklenmesi GEREKEN/ZORUNLU olan başlık uzantılarının listesi [RFC8834], Bölüm 5.2’de belirtilmiştir. Şifreleme gerektiren tüm başlık uzantıları, [RFC6904], Bölüm 4’te belirtildiği şekilde TANIMLANMALIDIR.
Desteklenen her RTCP geri bildirim mekanizması için, [RFC4585], Bölüm 4.2’de belirtildiği üzere bir a=rtcp-fb satırı. Desteklenmesi GEREKEN/ZORUNLU olan RTCP geri bildirim mekanizmalarının listesi [RFC8834], Bölüm 5.1’de belirtilmiştir.
Eğer RtpTransceiver sendrecv veya sendonly yönüne sahipse:
addTrack veya addTransceiver yoluyla oluşturulurken transceiver ile ilişkilendirilmiş olan her MediaStream için, [RFC8830], Bölüm 2’de belirtildiği üzere, ancak appdata alanı çıkarılmış bir a=msid satırı.
Eğer RtpTransceiver sendrecv veya sendonly yönüne sahipse ve uygulama bir kodlama (encoding) için bir rid-id belirtmişse ya da RtpSender’ın parametrelerinde birden fazla kodlama belirtmişse, belirtilen her kodlama için bir a=rid satırı. a=rid satırı [RFC8851]’de tanımlanmıştır ve yönü send OLMALIDIR. Uygulama bir rid-id seçmişse bu KULLANILMALIDIR; aksi halde rid-id uygulama tarafından OLUŞTURULMALIDIR. Rid-id’ler, kullanıcı bilgisini sızdırmayacak bir şekilde (örneğin rastgele veya her PeerConnection için bir sayaç kullanılarak; [RFC8852], Bölüm 3.3 sonundaki yönlendirmeye bakınız) OLUŞTURULMALIDIR ve [RFC8852], Bölüm 3.3’te tanımlanan RTP başlık uzantılarına verimli biçimde sığabilmeleri için 3 bayt veya daha az OLMALIDIR. Hiç kodlama belirtilmemişse ya da yalnızca bir kodlama belirtilmiş ve rid-id yoksa, hiçbir a=rid satırı OLUŞTURULMAZ.
Eğer RtpTransceiver sendrecv veya sendonly yönüne sahipse ve birden fazla a=rid satırı oluşturulmuşsa, [RFC8853], Bölüm 5.1’de tanımlandığı üzere, yönü send olan bir a=simulcast satırı. İlişkili rid-id kümesi, bu m= bölümü için a=rid satırlarında kullanılan tüm rid-id’leri İÇERMELİDİR.
Eğer (1) bu PeerConnection için bundle politikası max-bundle olarak ayarlanmışsa ve bu ilk m= bölümü değilse veya (2) bundle politikası balanced olarak ayarlanmışsa ve bu medya türü için ilk m= bölümü değilse, bir a=bundle-only satırı.

Aşağıdaki öznitelikler, IDENTICAL veya TRANSPORT kategorisine ait olduklarından, yalnızca benzersiz bir adrese sahip olan ya da BUNDLE-tag ile ilişkilendirilmiş m= bölümlerinde YER ALMALIDIR. (İlk tekliflerde bu, a=bundle-only özniteliğini içermeyen m= bölümleri anlamına gelir.)

[RFC8839], Bölüm 5.4’te belirtildiği üzere a=ice-ufrag ve a=ice-pwd satırları.
İstenen her özet (digest) algoritması için, uç noktanın her sertifikası adına bir veya daha fazla a=fingerprint satırı; [RFC8122], Bölüm 5’te belirtildiği üzere.
[RFC4145], Bölüm 4’te belirtildiği ve DTLS-SRTP senaryolarında kullanım için [RFC5763], Bölüm 5’te netleştirilen bir a=setup satırı. Teklifteki rol değeri actpass OLMALIDIR.
[RFC8842], Bölüm 5.2’de belirtildiği üzere bir a=tls-id satırı.
[RFC3605], Bölüm 2.1’de belirtildiği üzere, henüz adaylar toplanmadığından, varsayılan değer olan 9 IN IP4 0.0.0.0 içeren bir a=rtcp satırı.
[RFC5761], Bölüm 5.1.3’te belirtildiği üzere bir a=rtcp-mux satırı.
RTP/RTCP çoklama politikası require ise, [RFC8858], Bölüm 4’te belirtildiği üzere bir a=rtcp-mux-only satırı.
[RFC5506], Bölüm 5’te belirtildiği üzere bir a=rtcp-rsize satırı.

Son olarak, bir veri kanalı oluşturulmuşsa, veri için bir m= bölümü OLUŞTURULMALIDIR. <media> alanı application olarak, <proto> alanı ise UDP/DTLS/SCTP [RFC8841] olarak AYARLANMALIDIR. <fmt> değeri, [RFC8841], Bölüm 4.2.2’de belirtildiği üzere webrtc-datachannel OLMALIDIR.

Veri m= bölümü içinde, yukarıda açıklandığı şekilde bir a=mid satırı OLUŞTURULMALI ve dahil edilmelidir; ayrıca [RFC8841], Bölüm 5.1’de tanımlandığı üzere SCTP port numarasına referans veren bir a=sctp-port satırı ve uygun durumlarda [RFC8841], Bölüm 6.1’de tanımlandığı üzere bir a=max-message-size satırı BULUNMALIDIR.

Yukarıda tartışıldığı üzere, IDENTICAL veya TRANSPORT kategorisindeki aşağıdaki öznitelikler, yalnızca veri m= bölümü benzersiz bir adrese sahipse ya da BUNDLE-tag ile ilişkilendirilmişse (örneğin tek m= bölümü ise) DAHİL EDİLİR:

a=ice-ufrag
a=ice-pwd
a=fingerprint
a=setup
a=tls-id

Tüm m= bölümleri oluşturulduktan sonra, [RFC5888]’de belirtildiği üzere oturum düzeyinde bir a=group özniteliği EKLENMELİDİR. Bu öznitelik BUNDLE semantiğine sahip OLMALI ve her m= bölümünün mid tanımlayıcılarını İÇERMELİDİR. Bunun etkisi, JSEP uygulamasının tüm m= bölümlerini tek bir bundle grubu olarak teklif etmesidir. Ancak m= bölümlerinin bundle-only olup olmaması bundle politikasına bağlıdır.

Bir sonraki adım, [RFC5888], Bölüm 7’de tanımlandığı üzere oturum düzeyinde dudak senkronizasyonu (lip sync) gruplarının oluşturulmasıdır. Birden fazla RtpTransceiver tarafından referans verilen her MediaStream için (addTrack ve addTransceiver yöntemlerine bu MediaStream’lerin argüman olarak geçirilmesi yoluyla), her RtpTransceiver için MID değerlerini içeren LS türünde bir grup EKLENMELİDİR.

SDP’nin hem oturum düzeyinde hem de medya düzeyinde yer almasına izin verdiği öznitelikler, genellikle aynı olsalar bile medya düzeyinde OLMALIDIR. Bu, özellikle başlangıçta aynı olan bir dizi öznitelikten biri daha sonra değiştirildiğinde, bireysel medya bölümlerini anlamayı kolaylaştırarak geliştirme ve hata ayıklamaya yardımcı olur. Bununla birlikte, uygulamalar öznitelikleri oturum düzeyinde toplulaştırmayı SEÇEBİLİR ve JSEP uygulamaları öznitelikleri her iki konumda da alabilmeye HAZIR OLMALIDIR.

Yukarıda belirtilenler dışındaki öznitelikler DAHİL EDİLEBİLİR; ancak aşağıdaki öznitelikler [RFC8834]’ün gereksinimleriyle özel olarak uyumsuz olduklarından DAHİL EDİLMEMELİDİR:

a=crypto
a=key-mgmt
a=ice-lite

Bundle kullanıldığında, eklenen tüm ilave özniteliklerin bundle ile nasıl etkileştiğine dair [RFC8859]’daki tavsiyelere UYULMASI GEREKTİĞİ unutulmamalıdır.

Bu gereksinimlerin bazı durumlarda SDP’ninkilerden daha katı olduğu unutulmamalıdır. Uygulamalar, bu belirtimde SDP oluşturma gereksinimlerine uymasa bile, uyumlu SDP’yi kabul etmeye HAZIR OLMALIDIR.

5.2.2. Sonraki Teklifler

createOffer ikinci (veya daha sonraki) bir kez çağrıldığında ya da yerel bir açıklama zaten kurulmuşken çağrıldığında, işlem ilk teklife kıyasla bir miktar farklıdır.

Önceki teklif setLocalDescription kullanılarak uygulanmamışsa, yani PeerConnection hâlen "stable" durumundaysa, aşağıdaki kısıtlamaya tabi olmak üzere ilk teklifin oluşturulması için kullanılan adımlar İZLENMELİDİR:

"o=" satırının alanları, her createOffer çağrısında teklifin önceki createOffer çağrısının çıktısından farklı olma ihtimali varsa <session-version> alanının bir artırılması dışında AYNI KALMALIDIR; uygulamalar her çağrıda <session-version> değerini artırmayı SEÇEBİLİR. Oluşturulan <session-version> değeri, mevcut yerel açıklamanın <session-version> değerinden BAĞIMSIZDIR; özellikle mevcut sürüm N iken, N+1 sürümüyle bir teklif oluşturulup uygulanır ve ardından bu teklif geri alınarak mevcut sürüm tekrar N olursa, bir sonraki oluşturulan teklif yine N+2 sürümüne sahip olacaktır.

Uygulama createOffer çağırmak yerine currentLocalDescription okuyarak bir teklif oluşturursa, döndürülen SDP, toplanmış ICE adaylarının eklenmesi nedeniyle setLocalDescription ilk çağrıldığındaki durumdan farklı olabilir; ancak <session-version> değişmemiş olacaktır. Bunun sorunlara yol açtığı bilinen bir senaryo yoktur, ancak bu bir endişe ise çözüm basittir: benzersiz bir <session-version> sağlamak için createOffer kullanmak.

Önceki teklif setLocalDescription kullanılarak uygulanmış, ancak uzak taraftan gelen karşılık (answer) henüz uygulanmamışsa, yani PeerConnection hâlen "have-local-offer" durumundaysa, bir teklif yukarıdaki "stable" durumu adımları izlenerek ve aşağıdaki istisnalarla birlikte OLUŞTURULUR:

"s=" ve "t=" satırları AYNI KALMALIDIR.
Eğer herhangi bir RtpTransceiver eklenmişse ve mevcut yerel açıklamada veya mevcut uzak açıklamada portu sıfır olan bir "m=" bölümü varsa, bu "m=" bölümü, eklenen RtpTransceiver için, "m=" bölümünün oturum açıklamasına ekleniyormuş gibi (yeni bir MID değeri dâhil olmak üzere) bir "m=" bölümü OLUŞTURULARAK ve portu sıfır olan "m=" bölümü ile AYNI indeks konumuna yerleştirilerek YENİDEN KULLANILMALIDIR.
Eğer bir RtpTransceiver durdurulmuşsa ve bir "m=" bölümü ile ilişkilendirilmemişse, onun için bir "m=" bölümü OLUŞTURULMAMALIDIR. Bu, yukarıda açıklandığı üzere önceki bir teklif/yanıt değişiminde geri dönüştürülüp yeni bir RtpTransceiver için kullanılan "m=" bölümlerine sahip RtpTransceiver’ların yeniden eklenmesini önler.
Eğer bir RtpTransceiver durdurulmuşsa ve bir "m=" bölümü ile ilişkilendirilmişse ve bu "m=" bölümü yukarıda açıklandığı şekilde geri dönüştürülmüyorsa, portu sıfıra ayarlanmış ve tüm "a=msid" satırları kaldırılmış bir "m=" bölümü OLUŞTURULMALIDIR.
Durdurulmamış RtpTransceiver’lar için, mevcut açıklamada yer alıyorsa, transceiver’ın yönü veya parçasındaki (track) değişikliklerden bağımsız olarak "a=msid" satırı veya satırları AYNI KALMALIDIR. Mevcut açıklamada hiçbir "a=msid" satırı yoksa, "a=msid" satırı veya satırları ilk teklif için geçerli olan kurallarla AYNI şekilde OLUŞTURULMALIDIR.
Her "m=" ve "c=" satırı, [RFC8839], Bölüm 4.2.1.2’de açıklandığı ve Bölüm 5.1.2’de netleştirildiği üzere, ilgili "m=" bölümü için varsayılan adayın portu, ilgili RTP profili ve adresi ile DOLDURULMALIDIR. Henüz RTP adayları toplanmamışsa, yukarıda açıklandığı üzere varsayılan değerler yine KULLANILMALIDIR.
Her "a=mid" satırı AYNI KALMALIDIR.
Her "a=ice-ufrag" ve "a=ice-pwd" satırı, ICE yapılandırması değişmedikçe (örneğin desteklenen STUN/TURN sunucularında veya ICE aday politikasında değişiklikler) ya da IceRestart seçeneği (Bölüm 5.2.3.1) belirtilmedikçe AYNI KALMALIDIR. "m=" bölümü başka bir "m=" bölümüne bundle edilmişse, yine de hiçbir ICE kimlik bilgisi İÇERMEMELİDİR.
Eğer "m=" bölümü başka bir "m=" bölümüne bundle edilmemişse, onun "a=rtcp" öznitelik satırı, [RFC5761], Bölüm 5.1.3’te belirtildiği üzere, varsayılan RTCP adayının portu ve adresi ile DOLDURULMALIDIR. Henüz RTCP adayları toplanmamışsa, Bölüm 5.2.1’de açıklandığı üzere varsayılan değerler KULLANILMALIDIR.
Eğer "m=" bölümü başka bir "m=" bölümüne bundle edilmemişse, en son toplama aşaması sırasında (Bkz. Bölüm 3.5.1) toplanan her aday için, [RFC8839], Bölüm 5.1’de tanımlandığı üzere bir "a=candidate" satırı EKLENMELİDİR. Bölüm için aday toplama tamamlanmışsa, [RFC8840], Bölüm 8.2’de açıklandığı üzere bir "a=end-of-candidates" özniteliği EKLENMELİDİR. "m=" bölümü başka bir "m=" bölümüne bundle edilmişse, hem "a=candidate" hem de "a=end-of-candidates" ATLANMALIDIR.
Hâlen mevcut olan RtpTransceiver’lar için, "a=rid" satırları AYNI KALMALIDIR.
Hâlen mevcut olan RtpTransceiver’lar için, herhangi bir "a=simulcast" satırı AYNI KALMALIDIR.

Önceki teklif setLocalDescription kullanılarak uygulanmışsa ve uzak taraftan gelen karşılık gelen bir cevap setRemoteDescription kullanılarak uygulanmışsa; yani PeerConnection "have-remote-pranswer" durumunda veya "stable" durumundaysa, yukarıda "have-local-offer" durumu için belirtilen adımlar izlenerek, müzakere edilen oturum tanımlarına dayalı bir teklif üretilir.

Ayrıca, yeni teklifte mevcut olan, geri dönüştürülmemiş ve reddedilmemiş her bir "m=" bölümü için, uygun olduğu şekilde geçerli yerel veya uzak tanımdaki karşılık gelen "m=" bölümünün içeriğine dayanarak aşağıdaki ayarlamalar yapılır:

"m=" satırı ile buna karşılık gelen "a=rtpmap" ve "a=fmtp" satırları YALNIZCA ilişkili transceiver’ın codec tercihleri tarafından hariç tutulmamış medya formatlarını içermeli ve ayrıca şu anda mevcut olan tüm formatları içermelidir. Daha önce teklif edilmiş ancak artık mevcut olmayan medya formatları (örneğin, paylaşılan bir donanım codec’i) HARİÇ tutulabilir.
İlişkili transceiver için codec tercihleri ayarlanmamışsa, "m=" satırındaki medya formatları en son cevaptakiyle aynı sırada üretilmelidir. En son cevapta bulunmayan tüm medya formatları, mevcut tüm formatlardan sonra eklenmelidir.
RTP başlık uzantıları YALNIZCA en son cevapta mevcut olanları içermelidir.
RTCP geri bildirim mekanizmaları YALNIZCA en son cevapta mevcut olanları içermelidir; ancak yeni eklenen bir medya formatına referans veren formata özgü mekanizmalar bu kuralın istisnasıdır.
En son cevap bir "a=rtcp-mux" satırı içeriyorsa, "a=rtcp" satırı EKLENMEMELİDİR.
"a=rtcp-mux" satırı, en son cevapta yer alanla AYNI OLMALIDIR.
"a=rtcp-mux-only" satırı EKLENMEMELİDİR.
"a=rtcp-rsize" satırı, en son cevapta mevcut olmadıkça EKLENMEMELİDİR.
[RFC8843], Bölüm 6’da tanımlandığı üzere bir "a=bundle-only" satırı EKLENMEMELİDİR. Bunun yerine, JSEP uygulamaları [RFC8843], Bölüm 7.1.3’te açıklandığı gibi, paketlenmiş "m=" bölümleri için IDENTICAL ve TRANSPORT kategorilerindeki parametreleri basitçe atlamalıdır.
Medya "m=" bölümleri bir veri "m=" bölümüne paketlenmişse, belirli TRANSPORT ve IDENTICAL öznitelikleri, normalde yalnızca bir medya "m=" bölümü için uygun olsalar bile (örneğin, "a=rtcp-mux"), veri "m=" bölümünde görünebilir. Bu durum ilk teklifler için gerçekleşemez; çünkü ilk teklifte JSEP uygulamaları her zaman medya "m=" bölümlerini (varsa) veri "m=" bölümünden (varsa) önce listeler ve bu medya "m=" bölümlerinden en az biri "a=bundle-only" özniteliğine sahip olmaz. Dolayısıyla, ilk tekliflerde, herhangi bir "a=bundle-only" "m=" bölümü, kendisinden önce gelen bundle-only olmayan bir medya "m=" bölümüne paketlenir.

"a=group:BUNDLE" özniteliği, en son cevapta paket grubunda belirtilen MID tanımlayıcılarını içermelidir; ancak reddedilmiş olarak işaretlenen tüm "m=" bölümleri çıkarılmalı ve yeni eklenen veya yeniden etkinleştirilen tüm "m=" bölümleri eklenmelidir. Başka bir deyişle, bundle özniteliği, hâlâ etkin oldukları sürece daha önce paketlenmiş olan tüm "m=" bölümlerini ve ayrıca tüm yeni "m=" bölümlerini içermelidir.

"a=group:LS" öznitelikleri, ilk teklifler için olduğu şekilde üretilir; ancak ek olarak, en son cevapta mevcut olan tüm dudak senkronizasyonu grupları varlığını sürdürmeli ve tanımlanan "m=" bölümleri hâlâ mevcut olduğu ve reddedilmediği sürece, daha önce var olan tüm MID tanımlayıcılarını içermelidir ve grup en az iki MID tanımlayıcısı içermeye devam etmelidir. Bu, senkronize edilmiş tüm "recvonly" "m=" bölümlerinin yeni teklifte de senkronize kalmasını sağlar.

5.2.3. Seçeneklerin Ele Alınması

createOffer yöntemi, parametre olarak bir RTCOfferOptions nesnesi alır. Aşağıdaki seçenekler mevcut olduğunda bir SDP tanımı üretilirken özel işlemler uygulanır.

5.2.3.1. IceRestart

IceRestart seçeneği "true" değerinde belirtilmişse, teklif [RFC8839], Bölüm 4.4.3.1.1’de belirtildiği üzere yeni ICE ufrag ve pwd öznitelikleri üreterek bir ICE yeniden başlatmasını belirtmelidir. Bu seçenek ilk bir teklifte belirtilmişse hiçbir etkisi yoktur (çünkü yeni bir ICE ufrag ve pwd zaten üretilir). Benzer şekilde, ICE yapılandırması değişmişse bu seçeneğin de bir etkisi yoktur; çünkü yeni ufrag ve pwd öznitelikleri otomatik olarak üretilecektir. Bu seçenek esas olarak, uygulama tarafından arızaların tespit edildiği durumlarda bağlantının yeniden kurulması için kullanışlıdır.

5.2.3.2. VoiceActivityDetection

Kesintili iletim ("DTX") olarak da bilinen sessizlik bastırma, ses etkinliği algılanmadığında özel bir kodlamaya geçerek ses için kullanılan bant genişliğini azaltabilir; ancak bunun karşılığında bir miktar doğruluk kaybı olur.

"VoiceActivityDetection" seçeneği "true" değerinde belirtilmişse, teklif, [RFC3389], Bölüm 5.1’de belirtildiği üzere, sunulan her bir ses codec’i için rahatlatıcı gürültü ("CN") codec’lerini dahil ederek aldığı ses için sessizlik bastırma desteğini belirtmelidir; ancak kendi dahili sessizlik bastırma desteğine sahip codec’ler bu kuralın dışındadır. Kendi dahili sessizlik bastırma desteğine sahip codec’ler için, alınan ses için sessizlik bastırmanın istendiğini belirtmek amacıyla ilgili codec için uygun fmtp parametreleri belirtilmelidir. Örneğin, Opus codec’i [RFC6716] kullanıldığında, [RFC7587]’de belirtilen "usedtx=1" parametresi teklifte kullanılır.

"VoiceActivityDetection" seçeneği "false" değerinde belirtilmişse, JSEP uygulaması "CN" codec’lerini YAYIMLAMAMALIDIR. Kendi dahili sessizlik bastırma desteğine sahip codec’ler için, alınan ses için sessizlik bastırmanın istenmediğini belirtmek amacıyla ilgili codec için uygun fmtp parametreleri belirtilmelidir. Örneğin, Opus codec’i kullanıldığında, teklifte "usedtx=0" parametresi belirtilir. Buna ek olarak, uygulama, eşin tanımında "CN" codec’leri veya ilgili fmtp parametreleri yer alsa bile, ürettiği medya için sessizlik bastırma KULLANMAMALIDIR. Bu kuralların sonucu olarak, JSEP’te sessizlik bastırma her iki tarafın karşılıklı mutabakatına bağlıdır ve bu da hangi codec’in kullanıldığından bağımsız olarak tutarlı bir işleme sağlar.

"VoiceActivityDetection" seçeneğinin, [RFC6464], Bölüm 4’te tanımlanan istemciden miksere ses seviyesi başlık uzantısının sinyallemesindeki "vad" değerinin ayarlanması üzerinde herhangi bir etkisi yoktur.

5.3. Bir Cevap Üretme

createAnswer çağrıldığında, sağlanan uzak tanımla ve [RFC8834]’te belirtilen gereksinimlerle uyumlu yeni bir SDP tanımı OLUŞTURULMALIDIR. Bu sürecin ayrıntıları aşağıda açıklanmaktadır.

5.3.1. İlk Cevaplar

Bir uzak tanım sağlandıktan sonra createAnswer ilk kez çağrıldığında elde edilen sonuç ilk cevap olarak adlandırılır. Herhangi bir uzak tanım kurulmamışsa, bir cevap üretilemez ve bir hata DÖNDÜRÜLMELİDİR.

Uzak tanım SDP’sinin bir JSEP uç noktası tarafından üretilmemiş olabileceğini ve Bölüm 5.2’de listelenen tüm gereksinimlere uymayabileceğini unutmayın. Çoğu durumda bu bir sorun değildir. Ancak, zorunlu SDP özniteliklerinden herhangi biri eksikse veya yukarıda kullanımı zorunlu olarak listelenen işlevsellik mevcut değilse, bu bir hata olarak ele alınmalı ve etkilenen "m=" bölümlerinin reddedilmiş olarak işaretlenmesine neden olmalıdır.

Bir ilk cevap üretmenin ilk adımı, oturum düzeyindeki öznitelikleri üretmektir. Buradaki süreç, yukarıdaki Bölüm 5.2.1’de belirtilenle aynıdır; ancak "trickle" seçeneği [RFC8840], Bölüm 4.1.3’te ve "ice2" seçeneği [RFC8445], Bölüm 10’da belirtildiği şekilde, yalnızca teklifte böyle bir seçenek mevcutsa "a=ice-options" satırı dahil edilir.

Bir sonraki adım, [RFC5888], Bölüm 7’de tanımlandığı üzere, oturum düzeyinde dudak senkronizasyonu gruplarını üretmektir. Teklifte mevcut olan her bir "LS" türündeki grup için, belirtilen gruptaki MID değerleri tarafından referans verilen yerel RtpTransceiver’lar seçilir ve bunlardan hangilerinin ortak bir yerel MediaStream’e referans verdiği (bunları oluşturmak için kullanılan addTrack/addTransceiver çağrılarında belirtilen) ya da addTrack/addTransceiver ile oluşturulmadıkları için referans verecek bir MediaStream’e sahip olmadığı belirlenir. En az iki böyle RtpTransceiver mevcutsa, bu RtpTransceiver’ların MID değerlerini içeren bir "LS" türünde grup EKLENMELİDİR. Aksi takdirde, sunulan "LS" grubu YOK SAYILMALI ve cevapta karşılık gelen bir grup üretilmemelidir.

Basit bir örnek olarak, aynı MediaStream içinde bulunan tek bir ses ve tek bir video izinin yer aldığı aşağıdaki teklifi düşünün. Bu örnekle ilgili olmayan SDP satırları açıklık için çıkarılmıştır. Bölüm 5.2’de açıklandığı gibi, her bir izin RtpTransceiver’ına referans veren bir "LS" türünde grup eklenmiştir.

a=group:LS a1 v1
m=audio 10000 UDP/TLS/RTP/SAVPF 0
a=mid:a1
a=msid:ms1
m=video 10001 UDP/TLS/RTP/SAVPF 96
a=mid:v1
a=msid:ms1

Cevaplayıcı, izlerini eklerken tek bir MediaStream kullanırsa, her iki transceiver’ı da bu akışa referans verecek ve dolayısıyla sonraki cevap, aşağıda gösterildiği gibi, tekliftekiyle aynı olan bir "LS" grubu içerecektir:

a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1
a=msid:ms2
m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1
a=msid:ms2

Ancak, cevaplayıcı izlerini ayrı MediaStream’ler halinde gruplarsa, transceiver’ları farklı akışlara referans verecek ve dolayısıyla sonraki cevap bir "LS" grubu içermeyecektir.

m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1
a=msid:ms2a
m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1
a=msid:ms2b

Son olarak, cevaplayıcı hiç iz eklemezse, transceiver’ları herhangi bir MediaStream’e referans vermeyecek, bu da teklif edenin tercihlerinin korunmasına neden olacak ve dolayısıyla sonraki cevap aynı "LS" grubunu içerecektir.

a=group:LS a1 v1
m=audio 20000 UDP/TLS/RTP/SAVPF 0
a=mid:a1
a=recvonly
m=video 20001 UDP/TLS/RTP/SAVPF 96
a=mid:v1
a=recvonly

Bölüm 7.2’deki örnek, "LS" grubu üretiminin daha karmaşık bir durumunu göstermektedir.

Bir sonraki adım, [RFC3264], Bölüm 6’da belirtildiği üzere, uzak teklifte mevcut olan her bir "m=" bölümü için bir "m=" bölümü üretmektir. Bu tartışmanın amaçları doğrultusunda, teklifte yer alan ve medya düzeyi öznitelikleri olarak da geçerli olan tüm oturum düzeyi özniteliklerinin her bir "m=" bölümünde mevcut olduğu kabul edilir. Sunulan her bir "m=" bölümünün, Bölüm 5.10’da açıklandığı üzere ilişkili bir RtpTransceiver’ı olacaktır. "m=" bölümlerinden daha fazla RtpTransceiver varsa, eşleşmeyen RtpTransceiver’ların sonraki bir teklifte ilişkilendirilmesi gerekecektir.

Sunulan her bir "m=" bölümü için, aşağıdaki koşullardan herhangi biri doğruysa, cevapta karşılık gelen "m=" bölümü, [RFC3264], Bölüm 6’da belirtildiği gibi, "m=" satırındaki <port> değeri sıfıra ayarlanarak reddedilmiş olarak işaretlenmelidir ve bu "m=" bölümü için sonraki işlemler atlanabilir:

İlişkili RtpTransceiver durdurulmuşsa.
Desteklenen ve varsa codec tercihleri tarafından izin verilen herhangi bir sunulmuş medya formatı yoksa.
Paketleme politikası "max-bundle" ise ve bu, ilk "m=" bölümü değilse veya ilk "m=" bölümüyle aynı paket grubunda değilse.
Paketleme politikası "balanced" ise ve bu, bu medya türü için ilk "m=" bölümü değilse veya bu medya türü için ilk "m=" bölümüyle aynı paket grubunda değilse.
Bu "m=" bölümü bir paket grubundaysa ve grubun teklif eden tarafından etiketlenmiş "m=" bölümü yukarıdaki nedenlerden biri nedeniyle reddediliyorsa. Bu durum, [RFC8843], Bölüm 7.3.3’te belirtildiği üzere, paket grubundaki tüm "m=" bölümlerinin reddedilmesini gerektirir.

Aksi halde, cevapta yer alan her bir "m=" bölümü [RFC3264], Bölüm 6.1’de belirtildiği şekilde üretilmelidir. "m=" satırının kendisi için aşağıdaki kurallar izlenmelidir:

<port> değeri normalde bu "m=" bölümü için varsayılan ICE adayının portuna ayarlanırdı; ancak henüz adaylar mevcut olmadığından, [RFC8840], Bölüm 4.1.1’de belirtildiği üzere varsayılan <port> değeri olan 9 (Discard) KULLANILMALIDIR.
<proto> alanı, teklifteki karşılık gelen "m=" satırının <proto> alanıyla birebir EŞLEŞMELİDİR.
İlişkili transceiver için codec tercihleri ayarlanmışsa, medya formatları, neyin sunulduğuna bakılmaksızın, karşılık gelen sırada üretilmeli ve codec tercihlerinde yer almayan tüm codec’ler hariç tutulmalıdır.
Aksi halde, "m=" satırındaki medya formatları, şu anki uzak tanımda sunulanlarla aynı sırada üretilmeli ve şu anda desteklenmeyen tüm formatlar hariç tutulmalıdır. Şu anki uzak tanımda yer almayan ancak şu anda mevcut olan tüm medya formatları, mevcut tüm formatlardan sonra eklenmelidir.
Her iki durumda da, cevapta yer alan medya formatları, teklifte mevcut olan en az bir formatı içermelidir; ancak [RFC3264], Bölüm 6.1’de belirtildiği gibi, yerel olarak desteklenen ancak teklifte yer almayan formatları da içerebilir. Ortak bir format yoksa, "m=" bölümü yukarıda açıklandığı şekilde reddedilir.

"m=" satırını, [RFC4566], Bölüm 5.7’de belirtildiği üzere, hemen bir "c=" satırı izlemelidir. Yine, henüz adaylar mevcut olmadığından, "c=" satırı [RFC8840], Bölüm 4.1.3’te tanımlandığı üzere varsayılan IN IP4 0.0.0.0 değerini içermelidir.

Teklif paketlemeyi destekliyorsa, paketlenecek tüm "m=" bölümleri aynı ICE kimlik bilgilerini ve adaylarını kullanmalıdır; paketlenmeyen tüm "m=" bölümleri benzersiz ICE kimlik bilgileri ve adayları kullanmalıdır. Her bir "m=" bölümü aşağıdaki öznitelikleri içermelidir (bunlar IDENTICAL veya TRANSPORT türleri dışındaki öznitelik türleridir):

Yalnızca ve ancak teklifte mevcutsa, [RFC5888], Bölüm 9.1’de belirtildiği şekilde bir a=mid satırı. MID değeri, teklifte belirtilen değerle EŞLEŞMELİDİR.
[RFC3264], Bölüm 6.1’de belirtilen sunulan yönle ilgili kurallar uygulanarak belirlenen ve ardından ilişkili RtpTransceiver’ın yönüyle kesiştirilen bir yön özniteliği. Örneğin, bir "m=" bölümü "sendonly" olarak sunulmuşsa ve yerel transceiver "sendrecv" olarak ayarlanmışsa, yanıttaki sonuç "recvonly" yönü olur.
"m=" satırındaki her bir medya biçimi için, [RFC4566], Bölüm 6 ve [RFC3264], Bölüm 6.1’de belirtildiği şekilde a=rtpmap ve a=fmtp satırları.
Teklifte "rtx" mevcutsa, RTP yeniden iletiminin kullanılması gereken her bir birincil codec için, birincil codec’in saat hızını içeren ve "rtx" belirten karşılık gelen bir a=rtpmap satırı ile birincil codec’in yük türüne başvuran bir a=fmtp satırı; [RFC4588], Bölüm 8.1’de belirtildiği şekilde.
Desteklenen her bir FEC mekanizması için, [RFC4566], Bölüm 6’da belirtildiği şekilde a=rtpmap ve a=fmtp satırları. Desteklenmesi ZORUNLU olan FEC mekanizmaları [RFC8854], Bölüm 7’de belirtilmiştir ve her bir medya türü için özel kullanım Bölüm 4 ve 5’te açıklanmıştır.
Bu "m=" bölümü paket başına medya süreleri yapılandırılabilir olan medyalar (ör. ses) içinse, Bölüm 5.2’de açıklandığı şekilde bir a=maxptime satırı.
Bu "m=" bölümü video medyası içinse ve çözülebilecek görüntü boyutları üzerinde bilinen sınırlamalar varsa, Bölüm 3.6’da belirtildiği şekilde bir a=imageattr satırı.
Teklifte mevcut olan ve desteklenen her bir RTP başlık uzantısı için, [RFC5285], Bölüm 5’te belirtildiği şekilde bir a=extmap satırı. Desteklenmesi GEREKEN/ZORUNLU olan başlık uzantılarının listesi [RFC8834], Bölüm 5.2’de belirtilmiştir. Şifreleme gerektiren herhangi bir başlık uzantısı [RFC6904], Bölüm 4’te belirtildiği şekilde tanımlanmalıdır.
Teklifte mevcut olan ve desteklenen her bir RTCP geri bildirim mekanizması için, [RFC4585], Bölüm 4.2’de belirtildiği şekilde bir a=rtcp-fb satırı. Desteklenmesi GEREKEN/ZORUNLU olan RTCP geri bildirim mekanizmalarının listesi [RFC8834], Bölüm 5.1’de belirtilmiştir.
RtpTransceiver sendrecv veya sendonly yönüne sahipse:
Transceiver addTrack veya addTransceiver yoluyla oluşturulduğunda onunla ilişkilendirilmiş her bir MediaStream için, [RFC8830], Bölüm 2’de belirtildiği şekilde, ancak appdata alanı atlanarak bir a=msid satırı.

Başka bir "m=" bölümüne bundle edilmemiş olan her bir "m=" bölümü, aşağıdaki öznitelikleri (IDENTICAL veya TRANSPORT kategorisinde olan) İÇERMEK ZORUNDADIR:

[RFC8839], Bölüm 5.4’te belirtildiği şekilde a=ice-ufrag ve a=ice-pwd satırları.
İstenen her bir özet algoritması için, uç noktanın her bir sertifikası adına bir veya daha fazla a=fingerprint satırı; [RFC8122], Bölüm 5’te belirtildiği şekilde.
[RFC4145], Bölüm 4’te belirtildiği ve DTLS-SRTP senaryolarında kullanım için [RFC5763], Bölüm 5’te netleştirildiği şekilde bir a=setup satırı. Yanıttaki rol değeri "active" veya "passive" OLMALIDIR. Teklif "actpass" değerini içerdiğinde (JSEP uç noktalarında her zaman böyle olacaktır), yanıtlayıcı "active" rolünü KULLANMALIDIR. JSEP olmayan uç noktalardan gelen teklifler a=setup için başka değerler GÖNDEREBİLİR; bu durumda yanıt, teklifteki değerle tutarlı bir değer KULLANMALIDIR.
[RFC8842], Bölüm 5.3’te belirtildiği şekilde bir a=tls-id satırı.
Teklifte mevcutsa, [RFC5761], Bölüm 5.1.3’te belirtildiği şekilde bir a=rtcp-mux satırı. Aksi halde, [RFC3605], Bölüm 2.1’de belirtildiği şekilde, varsayılan 9 IN IP4 0.0.0.0 değerini içeren bir a=rtcp satırı (çünkü henüz adaylar toplanmamıştır).
Teklifte mevcutsa, [RFC5506], Bölüm 5’te belirtildiği şekilde bir a=rtcp-rsize satırı.

Bir veri kanalı "m=" bölümü teklif edildiyse, veri için de bir "m=" bölümü OLUŞTURULMALIDIR. <media> alanı application olarak AYARLANMALIDIR ve <proto> ile <fmt> alanları teklifteki alanlarla birebir eşleşecek şekilde AYARLANMALIDIR.

Veri "m=" bölümü içinde, yukarıda açıklandığı şekilde bir a=mid satırı OLUŞTURULMALI ve dahil edilmelidir; ayrıca [RFC8841], Bölüm 5.1’de tanımlandığı üzere SCTP port numarasına başvuran bir a=sctp-port satırı ve uygun olduğunda [RFC8841], Bölüm 6.1’de tanımlandığı üzere bir a=max-message-size satırı yer almalıdır.

Yukarıda tartışıldığı üzere, IDENTICAL veya TRANSPORT kategorisindeki aşağıdaki öznitelikler yalnızca veri "m=" bölümü başka bir "m=" bölümüne bundle edilmemişse dahil edilir:

a=ice-ufrag
a=ice-pwd
a=fingerprint
a=setup
a=tls-id

Medya "m=" bölümleri bir veri "m=" bölümüne bundle edilmişse, bazı TRANSPORT ve IDENTICAL öznitelikler normalde yalnızca bir medya "m=" bölümü için uygun olsa bile veri "m=" bölümünde de yer alabilir (ör. a=rtcp-mux).

BUNDLE anlamlı a=group öznitelikleri teklif edildiyse, [RFC5888]’de belirtildiği şekilde karşılık gelen oturum düzeyi a=group öznitelikleri EKLENMELİDİR. Bu öznitelikler BUNDLE anlamına sahip OLMALIDIR ve reddedilmemiş olan sunulan bundle gruplarındaki tüm MID tanımlayıcılarını İÇERMELİDİR. Teklifte a=bundle-only bulunup bulunmamasına bakılmaksızın, yanıttaki tüm "m=" bölümlerinde a=bundle-only satırı BULUNMAMALIDIR.

Tüm "m=" bölümleri arasında ortak olan öznitelikler, oturum düzeyinde geçerli olduğu açıkça tanımlanmışsa oturum düzeyine TAŞINABİLİR.

Tekliflerin oluşturulmasında yasaklanan öznitelikler, yanıtların oluşturulmasında da yasaktır.

5.3.2. Sonraki Yanıtlar

createAnswer ikinci (veya daha sonraki) bir kez çağrıldığında ya da yerel bir tanım zaten yüklenmişken çağrıldığında, işleme ilk yanıta kıyasla bir miktar farklıdır.

Önceki yanıt setLocalDescription kullanılarak uygulanmadıysa, yani PeerConnection hâlâ "have-remote-offer" durumundaysa, aşağıdaki kısıtlamaya tabi olmak üzere ilk yanıtın oluşturulmasına yönelik adımlar IZLENMELİDİR:

o= satırının alanları, <session-version> alanı dışında aynı KALMALIDIR; oturum tanımı önceki oluşturulan yanıttan herhangi bir şekilde değişirse <session-version> alanı ARTIRILMALIDIR.

Herhangi bir oturum tanımı daha önce setLocalDescription’a sağlanmışsa, yanıt yukarıdaki "have-remote-offer" durumundaki adımlar izlenerek ve aşağıdaki istisnalarla birlikte oluşturulur:

s= ve t= satırları aynı KALMALIDIR.
Her bir m= ve c= satırı, [RFC8839], Bölüm 4.2.1.2’de açıklandığı şekilde, ilgili "m=" bölümü için varsayılan adayın portu ve adresiyle DOLDURULMALIDIR. Belirli durumlarda m= satırı protokolü varsayılan adayın protokolüyle eşleşmeyebilir; çünkü m= satırı protokol değeri, yukarıda açıklandığı üzere, teklifte sağlanan değerle eşleşmek ZORUNDADIR.
Her bir a=ice-ufrag ve a=ice-pwd satırı aynı KALMALIDIR; ancak "m=" bölümü yeniden başlatılıyorsa, [RFC8839], Bölüm 4.4.1.1.1’de belirtildiği şekilde yeni ICE kimlik bilgileri OLUŞTURULMALIDIR. "m=" bölümü başka bir "m=" bölümüne bundle edilmişse, yine de hiçbir ICE kimlik bilgisi İÇERMEMELİDİR.
Her bir a=tls-id satırı aynı KALMALIDIR; ancak teklif sahibinin a=tls-id satırı değiştiyse, [RFC8842], Bölüm 5.2’de açıklandığı şekilde yeni bir tls-id değeri OLUŞTURULMALIDIR.
Her bir a=setup satırı, ilişki teklif sahibi tarafından sürdürülüyorsa, mevcut DTLS ilişkilendirmesiyle tutarlı bir "active" veya "passive" rol değeri KULLANMALIDIR.
RTCP çoklama KULLANILMALIDIR ve yalnızca ve ancak "m=" bölümü daha önce RTCP çoklama kullandıysa bir a=rtcp-mux satırı EKLENMELİDİR.
"m=" bölümü başka bir "m=" bölümüne bundle edilmemişse ve RTCP çoklama etkin değilse, bir a=rtcp öznitelik satırı varsayılan RTCP adayının portu ve adresiyle DOLDURULMALIDIR. Henüz RTCP adayları toplanmadıysa, yukarıdaki Bölüm 5.3.1’de açıklandığı şekilde varsayılan değerler KULLANILMALIDIR.
"m=" bölümü başka bir "m=" bölümüne bundle edilmemişse, en son toplama aşamasında toplanmış her bir aday için (Bkz. Bölüm 3.5.1), [RFC8839], Bölüm 5.1’de tanımlandığı şekilde bir a=candidate satırı EKLENMELİDİR. Bölüm için aday toplama tamamlandıysa, [RFC8840], Bölüm 8.2’de açıklandığı şekilde bir a=end-of-candidates özniteliği EKLENMELİDİR. "m=" bölümü başka bir "m=" bölümüne bundle edilmişse, hem a=candidate hem de a=end-of-candidates ATLANMALIDIR.
Durdurulmamış RtpTransceiver’lar için, transceiver’ın yönünde veya parçasında yapılan değişikliklerden bağımsız olarak a=msid satırı/satırları aynı KALMALIDIR. Mevcut tanımda hiçbir a=msid satırı yoksa, a=msid satırı/satırları ilk yanıt için geçerli olan kurallarla aynı şekilde OLUŞTURULMALIDIR.

5.3.3. Seçeneklerin Ele Alınması

createAnswer yöntemi, parametre olarak bir RTCAnswerOptions nesnesi alır. RTCAnswerOptions için parametre kümesi, RTCOfferOptions’ta desteklenenlerden farklıdır; IceRestart seçeneği gereksizdir, çünkü teklif sahibinin ICE yeniden başlatmayı seçtiği tüm "m=" bölümleri için ICE kimlik bilgileri otomatik olarak değiştirilecektir.

Aşağıdaki seçenekler RTCAnswerOptions içinde desteklenmektedir.

5.3.3.1. VoiceActivityDetection

Yanıtta sessizlik bastırma, Bölüm 5.2.3.2’de açıklandığı şekilde ele alınır; tek bir istisna ile: sessizlik bastırma desteği teklifte belirtilmemişse, VoiceActivityDetection parametresinin hiçbir etkisi yoktur ve yanıt, VoiceActivityDetection "false" olarak ayarlanmış gibi OLUŞTURULMALIDIR. Bu işlem codec bazında yapılır (ör. teklif sahibi bir şekilde CN desteği sunduysa ancak Opus için "usedtx=0" ayarladıysa, VoiceActivityDetection’ın "true" olarak ayarlanması CN codec’leri ve "usedtx=0" içeren bir yanıtla sonuçlanır). Bu kuralın etkisi, bir yanıtlayıcının, bunu sunmayan herhangi bir uç nokta ile sessizlik bastırmayı kullanmaya çalışmamasıdır; böylece sessizlik bastırma desteği, JSEP olmayan uç noktalarla bile iki taraflı hâle gelir.

5.4. Bir Teklifin veya Yanıtın Değiştirilmesi

createOffer veya createAnswer tarafından döndürülen SDP, setLocalDescription’a iletilmeden önce DEĞİŞTİRİLMEMELİDİR. SDP üzerinde hassas denetim gerekiyorsa, yukarıda bahsedilen createOffer/createAnswer seçenekleri veya RtpTransceiver API’leri KULLANILMALIDIR.

Bir teklif veya yanıt ile setLocalDescription çağrıldıktan sonra, uygulama, geçerli bir JSEP teklifi veya yanıtını tanımlayan yukarıdaki kurallara uyduğu sürece, uzak tarafa göndermeden önce yeteneklerini azaltmak amacıyla SDP’yi DEĞİŞTİREBİLİR. Benzer şekilde, bir eşten bir teklif veya yanıt almış olan bir uygulama, setRemoteDescription’ı çağırmadan önce aynı kısıtlamalara tabi olarak alınan SDP’yi DEĞİŞTİREBİLİR.

Her zaman olduğu gibi, uygulama karşı tarafa ne gönderdiğinden tamamen sorumludur ve gelen tüm SDP, JSEP uygulaması tarafından kendi yetenekleri ölçüsünde işlenecektir. Tüm SDP’nin iyi biçimlendirilmiş olduğunu varsaymak bir hatadır; ancak bu belirtimin herhangi bir uygulamasının, bu belirtimin başka herhangi bir uygulamasından gelen ve değiştirilmemiş SDP’yi uzak teklif veya yanıt olarak işleyebileceği varsayılabilir.

5.5. Yerel Bir Tanımın İşlenmesi

Bir SessionDescription setLocalDescription’a sağlandığında, aşağıdaki adımlar UYGULANMALIDIR:

Tanımın türü "rollback" ise, Bölüm 5.7’de tanımlanan işleme uyun ve bu bölümün geri kalanında açıklanan işlemleri ATLAYIN.
Aksi halde, SessionDescription’ın türü, PeerConnection’ın mevcut durumuna göre kontrol edilir:
Tür "offer" ise, PeerConnection durumu "stable" veya "have-local-offer" OLMALIDIR.
Tür "pranswer" veya "answer" ise, PeerConnection durumu "have-remote-offer" veya "have-local-pranswer" OLMALIDIR.
Tür mevcut durum için doğru değilse, işlem DURDURULMALI ve bir hata DÖNDÜRÜLMELİDİR.
Ardından, SessionDescription, Bölüm 5.4’te tartışıldığı üzere, son createOffer/createAnswer çağrısında üretilenlerle özdeş olduğundan ve dolayısıyla değiştirilmediğinden emin olmak için KONTROL EDİLİR; aksi halde işlem DURDURULMALI ve bir hata DÖNDÜRÜLMELİDİR.
Sonraki adımda, SessionDescription, aşağıdaki Bölüm 5.8’de açıklandığı şekilde bir veri yapısına ayrıştırılır.
Son olarak, ayrıştırılmış SessionDescription, aşağıdaki Bölüm 5.9’da açıklandığı şekilde UYGULANIR.

5.6. Uzak Bir Tanımın İşlenmesi

Bir SessionDescription setRemoteDescription’a sağlandığında, aşağıdaki adımlar UYGULANMALIDIR:

Tanımın türü "rollback" ise, Bölüm 5.7’de tanımlanan işleme uyun ve bu bölümün geri kalanında açıklanan işlemleri ATLAYIN.
Aksi halde, SessionDescription’ın türü, PeerConnection’ın mevcut durumuna göre kontrol edilir:
Tür "offer" ise, PeerConnection durumu "stable" veya "have-remote-offer" OLMALIDIR.
Tür "pranswer" veya "answer" ise, PeerConnection durumu "have-local-offer" veya "have-remote-pranswer" OLMALIDIR.
Tür mevcut durum için doğru değilse, işlem DURDURULMALI ve bir hata DÖNDÜRÜLMELİDİR.
Sonraki adımda, SessionDescription, aşağıdaki Bölüm 5.8’de açıklandığı şekilde bir veri yapısına ayrıştırılır. Herhangi bir nedenle ayrıştırma başarısız olursa, işlem DURDURULMALI ve bir hata DÖNDÜRÜLMELİDİR.
Son olarak, ayrıştırılmış SessionDescription, aşağıdaki Bölüm 5.10’da açıklandığı şekilde UYGULANIR.

5.7. Rollback İşlenmesi

Bir rollback, PeerConnection "stable" durumu dışında herhangi bir durumda ise gerçekleştirilebilir. Bu, hem tekliflerin hem de geçici yanıtların geri alınabileceği anlamına gelir. Rollback yalnızca önerilen değişiklikleri iptal etmek için kullanılabilir; "stable" durumdan önceki bir "stable" duruma geri dönüş desteği yoktur. "stable" durumdayken bir rollback denenirse, işlem DURDURULMALI ve bir hata DÖNDÜRÜLMELİDİR. Bunun anlamı, yanıtlayıcı kendi yanıtı ile setLocalDescription’ı bir kez gerçekleştirdikten sonra bunun geri alınamayacağıdır.

Rollback’in etkisi, setLocalDescription veya setRemoteDescription çağrılıp çağrılmadığına bakılmaksızın AYNI OLMALIDIR.

Rollback’i işlemek için, bir JSEP uygulaması mevcut teklif/yanıt işlemini terk eder, sinyalleşme durumunu "stable" olarak ayarlar ve bekleyen yerel ve/veya uzak tanımı (Bkz. Bölüm 4.1.14 ve 4.1.16) null olarak ayarlar. Terk edilen yerel tanım tarafından tahsis edilmiş olan tüm kaynaklar veya adaylar atılır; alınan tüm medya ise önceki yerel ve uzak tanımlara göre işlenir.

Bir geri alma işlemi, geri alınan oturum açıklamasının uygulanmasıyla uygulama tarafından "m=" bölümleriyle ilişkilendirilmiş olan tüm RtpTransceiver nesnelerinin ilişkisini kaldırır (bkz. Bölüm 5.10 ve 5.9). Bu, daha önce ilişkilendirilmiş olan bazı RtpTransceiver nesnelerinin artık herhangi bir "m=" bölümüyle ilişkilendirilmemiş olacağı anlamına gelir; bu gibi durumlarda, RtpTransceiver nesnesinin mid özelliğinin değeri null olarak ayarlanmalı ve transceiver ile onun "m=" bölüm indeksini eşleyen ilişki atılmalıdır. Daha sonra geri alınan bir uzak teklifin uygulanmasıyla meydana getirilmiş olan RtpTransceiver nesneleri durdurulmalı ve PeerConnection içinden kaldırılmalıdır. Ancak, addTrack yöntemi aracılığıyla RtpTransceiver nesnesine bir track eklenmişse, bu durumda bir RtpTransceiver KALDIRILMAMALIDIR. Bunun amacı, bir uygulamanın addTrack çağrısını yapabilmesi, ardından bir teklif ile setRemoteDescription çağırabilmesi, sonra bu teklifi geri alabilmesi ve ardından createOffer çağırdığında, eklenen track için bir "m=" bölümünün oluşturulan teklifte görünmesini sağlayabilmesidir.

5.8. Bir Oturum Açıklamasının Ayrıştırılması

Oturum açıklaması nesnesinde yer alan SDP, [RFC4566], Bölüm 5’te açıklandığı üzere, her biri bir anahtar-değer ifadesi içeren metin satırlarından oluşan bir diziden meydana gelir. SDP satır satır okunur ve seri hâlinden çıkarılmış bilgileri içeren bir veri yapısına dönüştürülür. Ancak SDP, çok sayıda satır türüne izin verir ve bunların tamamı JSEP uygulamaları açısından ilgili değildir. Her satır için, uygulama öncelikle tanımlayıcı ABNF’ye göre sözdizimsel olarak doğru olduğunu doğrular, [RFC4566] ve [RFC3264]’te kullanılan anlamsal kurallara uyduğunu denetler ve ardından aşağıda açıklandığı şekilde verilen değeri ya ayrıştırıp saklar ya da yok sayar.

Herhangi bir satır düzgün biçimlendirilmemişse veya açıklanan şekilde ayrıştırılamıyorsa, ayrıştırıcı MUTLAKA bir hata ile durmalı ve oturum açıklamasını reddetmelidir; değer atılacak olsa bile bu geçerlidir. Bu, uygulamaların belirsiz SDP’yi yanlışlıkla hatalı yorumlamasını önler.

5.8.1. Oturum Düzeyi Ayrıştırma

İlk olarak, oturum düzeyindeki satırlar denetlenir ve ayrıştırılır. Bu satırlar, [RFC4566], Bölüm 5’te tanımlandığı üzere, belirli bir sırada ve belirli bir sözdizimiyle yer almalıdır. Belirli satır türlerinin (ör. "v=", "c=") tanımlı sırada yer alması GEREKTİĞİNİ, ancak aynı türdeki satırların (genellikle "a=") herhangi bir sırada bulunabileceğini unutmayın.

Aşağıdaki öznitelik olmayan satırlar JSEP bağlamında anlamlı değildir ve denetlendikten sonra ATILABİLİR:

"c=" satırı sözdizimi açısından denetlenmelidir, ancak değeri yalnızca [RFC8445], Bölüm 5.4’te tanımlandığı üzere ICE uyumsuzluk tespiti için kullanılır. JSEP uygulamalarının bu durumla karşılaşmaması gerekir, çünkü WebRTC için ICE zorunludur.
"i=", "u=", "e=", "p=", "t=", "r=", "z=" ve "k=" satırları sözdizimi açısından denetlenmelidir, ancak değerleri başka bir amaçla kullanılmaz.

Kalan öznitelik olmayan satırlar aşağıdaki şekilde işlenir:

"v=" satırı, [RFC4566], Bölüm 5.1’de belirtildiği gibi 0 sürümüne sahip OLMALIDIR.
"o=" satırı, [RFC4566], Bölüm 5.2’de belirtildiği şekilde ayrıştırılmalıdır.
"b=" satırı varsa, [RFC4566], Bölüm 5.8’de belirtildiği şekilde ayrıştırılmalı ve bwtype ile bandwidth değerleri saklanmalıdır.

Son olarak, öznitelik satırları işlenir. Aşağıdaki oturum düzeyi öznitelik ("a=") satırları için özel işlem uygulanmalıdır:

Herhangi bir "a=group" satırı, [RFC5888], Bölüm 5’te belirtildiği şekilde ayrıştırılır ve grubun semantiği ile MID değerleri saklanır.
Varsa, tek bir "a=ice-lite" satırı, [RFC8839], Bölüm 5.3’e göre ayrıştırılır ve ice-lite varlığını gösteren bir değer saklanır.
Varsa, tek bir "a=ice-ufrag" satırı, [RFC8839], Bölüm 5.4’e göre ayrıştırılır ve ufrag değeri saklanır.
Varsa, tek bir "a=ice-pwd" satırı, [RFC8839], Bölüm 5.4’e göre ayrıştırılır ve parola değeri saklanır.
Varsa, tek bir "a=ice-options" satırı, [RFC8839], Bölüm 5.6’ya göre ayrıştırılır ve belirtilen seçenekler kümesi saklanır.
Herhangi bir "a=fingerprint" satırı, [RFC8122], Bölüm 5’e göre ayrıştırılır ve parmak izi ile algoritma değerleri kümesi saklanır.
Varsa, tek bir "a=setup" satırı, [RFC4145], Bölüm 4’e göre ayrıştırılır ve setup değeri saklanır.
Varsa, tek bir "a=tls-id" satırı, [RFC8842], Bölüm 5’e göre ayrıştırılır ve öznitelik değeri saklanır.
Herhangi bir "a=identity" satırı, [RFC8827], Bölüm 5’te belirtildiği üzere ayrıştırılır ve daha sonra doğrulama için kimlik değerleri saklanır.
Herhangi bir "a=extmap" satırı, [RFC5285], Bölüm 5’e göre ayrıştırılır ve değerleri saklanır.

JSEP ile ilgili olmayan başka öznitelikler de bulunabilir ve uygulamalar tanıdıkları öznitelikleri İŞLEMELİDİR. [RFC4566], Bölüm 5.13’te gerektirildiği üzere, bilinmeyen öznitelik satırları yok sayılmalıdır.

Tüm oturum düzeyi satırlar ayrıştırıldıktan sonra, işlem "m=" bölümlerindeki satırlarla devam eder.

5.8.2. Medya Bölümü Ayrıştırma

Oturum düzeyi satırlarda olduğu gibi, medya bölümü satırları da [RFC4566], Bölüm 5’te tanımlanan belirli sırada ve belirli sözdizimiyle yer almalıdır.

"m=" satırının kendisi, [RFC4566], Bölüm 5.14’te açıklandığı şekilde ayrıştırılmalı ve <media>, <port>, <proto> ve <fmt> değerleri saklanmalıdır.

"m=" satırını takiben, aşağıdaki öznitelik olmayan satırlar için özel işlem uygulanmalıdır:

Oturum düzeyindeki "c=" satırında olduğu gibi, "c=" satırı [RFC4566], Bölüm 5.7’ye göre ayrıştırılmalıdır, ancak değeri kullanılmaz.
"b=" satırı varsa, [RFC4566], Bölüm 5.8’de belirtildiği şekilde ayrıştırılmalı ve bwtype ile bandwidth değerleri saklanmalıdır.

Aşağıdaki öznitelik satırları için de özel işlem uygulanmalıdır:

Varsa, tek bir "a=ice-ufrag" satırı, [RFC8839], Bölüm 5.4’e göre ayrıştırılır ve ufrag değeri saklanır.
Varsa, tek bir "a=ice-pwd" satırı, [RFC8839], Bölüm 5.4’e göre ayrıştırılır ve parola değeri saklanır.
Varsa, tek bir "a=ice-options" satırı, [RFC8839], Bölüm 5.6’ya göre ayrıştırılır ve belirtilen seçenekler kümesi saklanır.
Herhangi bir "a=candidate" özniteliği, [RFC8839], Bölüm 5.1’e göre ayrıştırılmalı ve değerleri saklanmalıdır.
Herhangi bir "a=remote-candidates" özniteliği, [RFC8839], Bölüm 5.2’ye göre ayrıştırılmalıdır, ancak değerleri yok sayılır.
Varsa, tek bir "a=end-of-candidates" özniteliği, [RFC8840], Bölüm 8.1’e göre ayrıştırılmalı ve varlığı ya da yokluğu işaretlenerek saklanmalıdır.
Herhangi bir "a=fingerprint" satırı, [RFC8122], Bölüm 5’e göre ayrıştırılır ve parmak izi ile algoritma değerleri kümesi saklanır.

Eğer "m=" <proto> değeri, yukarıdaki Bölüm 5.1.2’de açıklandığı üzere RTP kullanımını gösteriyorsa, aşağıdaki öznitelik satırları işlenmelidir:

"m=" <fmt> değeri, [RFC4566], Bölüm 5.14’e göre ayrıştırılmalı ve tekil değerler saklanmalıdır.
Herhangi bir "a=rtpmap" veya "a=fmtp" satırı, [RFC4566], Bölüm 6’ya göre ayrıştırılmalı ve değerleri saklanmalıdır.
Varsa, tek bir "a=ptime" satırı, [RFC4566], Bölüm 6’da açıklandığı şekilde ayrıştırılmalı ve değeri saklanmalıdır.
Varsa, tek bir "a=maxptime" satırı, [RFC4566], Bölüm 6’da açıklandığı şekilde ayrıştırılmalı ve değeri saklanmalıdır.
Varsa, tek bir yön özniteliği satırı (ör. "a=sendrecv"), [RFC4566], Bölüm 6’da açıklandığı şekilde ayrıştırılmalı ve değeri saklanmalıdır.
Herhangi bir "a=ssrc" özniteliği, [RFC5576], Bölüm 4.1’e göre ayrıştırılmalı ve değerleri saklanmalıdır.
Herhangi bir "a=extmap" özniteliği, [RFC5285], Bölüm 5’e göre ayrıştırılmalı ve değerleri saklanmalıdır.
Herhangi bir "a=rtcp-fb" özniteliği, [RFC4585], Bölüm 4.2’ye göre ayrıştırılmalı ve değerleri saklanmalıdır.
Varsa, tek bir "a=rtcp-mux" özniteliği, [RFC5761], Bölüm 5.1.3’e göre ayrıştırılmalı ve varlığı ya da yokluğu işaretlenerek saklanmalıdır.
Varsa, tek bir "a=rtcp-mux-only" özniteliği, [RFC8858], Bölüm 3’e göre ayrıştırılmalı ve varlığı ya da yokluğu işaretlenerek saklanmalıdır.
Varsa, tek bir "a=rtcp-rsize" özniteliği, [RFC5506], Bölüm 5’e göre ayrıştırılmalı ve varlığı ya da yokluğu işaretlenerek saklanmalıdır.
Varsa, tek bir "a=rtcp" özniteliği, [RFC3605], Bölüm 2.1’e göre ayrıştırılmalıdır, ancak ICE kullanıldığında bu bilgi gereksiz olduğundan değeri yok sayılır.
Varsa, "a=msid" öznitelikleri, [RFC8830], Bölüm 3.2’ye göre ayrıştırılmalı ve "appdata" alanı yok sayılarak değerleri saklanmalıdır. Hiç "a=msid" özniteliği yoksa, oturum için henüz mevcut değilse "varsayılan" bir MediaStream için rastgele bir msid-id değeri üretilir ve bu değer saklanır.
Herhangi bir "a=imageattr" özniteliği, [RFC6236], Bölüm 3’e göre ayrıştırılmalı ve değerleri saklanmalıdır.
Herhangi bir "a=rid" satırı, [RFC8851], Bölüm 10’a göre ayrıştırılmalı ve değerleri saklanmalıdır.
Varsa, tek bir "a=simulcast" satırı, [RFC8853]’e göre ayrıştırılmalı ve değerleri saklanmalıdır.

Aksi takdirde, "m=" <proto> değeri SCTP kullanımını gösteriyorsa, aşağıdaki öznitelik satırları işlenmelidir:

"m=" <fmt> değeri, [RFC8841], Bölüm 4.3’e göre ayrıştırılmalı ve uygulama protokolü değeri saklanmalıdır.
Bir "a=sctp-port" özniteliği bulunmalıdır ve [RFC8841], Bölüm 5.2’ye göre ayrıştırılarak değeri saklanmalıdır.
Varsa, tek bir "a=max-message-size" özniteliği, [RFC8841], Bölüm 6’ya göre ayrıştırılmalı ve değeri saklanmalıdır. Aksi takdirde, belirtilen varsayılan değer kullanılmalıdır.

5.8.3. Anlamsal Doğrulama

Ayrıştırmanın başarıyla tamamlandığı varsayıldığında, ayrıştırılmış açıklama dahili tutarlılığı ve zorunlu özellikler için uygun desteği sağladığından emin olmak amacıyla değerlendirilir. Özellikle, aşağıdaki denetimler yapılır:

Her bir "m=" bölümü için, Bölüm 5.1.1’de listelenen kullanımı zorunlu özelliklerin her biri için geçerli değerler bulunmalıdır. Bu değerler medya düzeyinde mevcut olabilir veya oturum düzeyinden devralınabilir.
[RFC8839], Bölüm 5.4’te belirtilen boyut sınırlarına uyması GEREKEN ICE ufrag ve parola değerleri.
[RFC8842], Bölüm 5’e göre ayarlanması GEREKEN bir tls-id değeri. Bu bir yeniden teklif veya yeniden teklife yanıt ise ve tls-id değeri hâlihazırda kullanılan değerden farklıysa, DTLS bağlantısı devam ettirilmiyordur ve uzak açıklama, yeni ufrag ve parola değerleriyle birlikte bir ICE yeniden başlatmasının parçası OLMALIDIR.
[RFC5763], Bölüm 5’te belirtilen kurallara göre ayarlanması GEREKEN ve mevcutsa ve devam ettiriliyorsa, mevcut DTLS bağlantısının seçilmiş rolüyle tutarlı olması GEREKEN bir DTLS setup değeri.
En az bir parmak izinin bulunması GEREKEN DTLS parmak izi değerleri.
Bir "a=simulcast" satırında referans verilen tüm rid-id’ler, "a=rid" satırları olarak mevcut OLMALIDIR.
Her bir "m=" bölümü, yasaklanmış özelliklerin kullanılmadığından emin olmak için de denetlenir.
RTP/RTCP çoklama ilkesi "require" ise, her bir "m=" bölümü bir "a=rtcp-mux" özniteliği içermelidir. Bir "m=" bölümü bir "a=rtcp-mux-only" özniteliği içeriyorsa, bu bölüm ayrıca bir "a=rtcp-mux" özniteliği de içermelidir.
Bir "m=" bölümü önceki yanıtta mevcutsa, RTP/RTCP çoklama durumu daha önce müzakere edilmiş olanla eşleşmelidir.

Bu oturum açıklaması "pranswer" veya "answer" türündeyse, aşağıdaki ek denetimler uygulanır:

Oturum açıklaması, [RFC3264], Bölüm 6’da tanımlanan kurallara uymalıdır; buna, "m=" bölümlerinin sayısının, ilişkili teklifteki "m=" bölümlerinin sayısıyla tam olarak eşleşmesi gerekliliği de dahildir.
Her bir "m=" bölümü için, medya türü ve protokol değerleri, ilişkili teklifteki karşılık gelen "m=" bölümündeki medya türü ve protokol değerleriyle birebir aynı OLMALIDIR.

Yukarıdaki denetimlerden herhangi biri başarısız olursa, işlem MUTLAKA durdurulmalı ve bir hata döndürülmelidir.

5.9. Yerel Bir Açıklamanın Uygulanması

Bir yerel açıklamayı uygulamak için medya motoru düzeyinde aşağıdaki adımlar gerçekleştirilir. Bir hata döndürülürse, oturum bu adımlar gerçekleştirilmeden önceki durumuna geri döndürülmelidir.

Öncelikle "m=" bölümleri işlenir. Her bir "m=" bölümü için aşağıdaki adımlar MUTLAKA gerçekleştirilmelidir; herhangi bir parametre sınırların dışındaysa veya uygulanamıyorsa, işlem durdurulmalı ve bir hata döndürülmelidir.

Bu "m=" bölümü yeniyse, [RFC8445], Bölüm 5.1.1’de tanımlandığı üzere, bu bölüm için aday toplamaya başlanır; ancak kesin olarak paketleniyorsa (ya (1) bu bir tekliftir ve "m=" bölümü bundle-only olarak işaretlenmiştir ya da (2) bu bir yanıttır ve "m=" bölümü başka bir "m=" bölümüne paketlenmiştir) bu işlem yapılmaz.
Ya da, ICE ufrag ve parola değerleri değişmişse, ICE aracısının [RFC8445], Bölüm 9’da açıklandığı şekilde bir ICE yeniden başlatması başlatması tetiklenir ve "m=" bölümü için yeni adayların toplanmasına başlanır. Bu açıklama bir yanıt ise, bu medya bölümü üzerinde kontroller de başlatılır.
Eğer "m=" bölümü <proto> değeri RTP kullanımını gösteriyorsa:
Bu "m=" bölümüyle ilişkili bir RtpTransceiver yoksa, aşağıdaki adımlara göre bir tane bulunur ve bu "m=" bölümüyle ilişkilendirilir. Bu durumun yalnızca bir teklif uygulanırken ortaya çıkacağını unutmayın.
Teklif oluşturulurken tesis edilen transceiver’lar ile "m=" bölüm indeksleri arasındaki eşlemeyi kullanarak, bu "m=" bölümüne karşılık gelen RtpTransceiver bulunur.
Bu RtpTransceiver’ın mid özelliğinin değeri, "m=" bölümünün MID değeri olarak ayarlanır.
RTCP çoklama belirtilmişse, [RFC5761], Bölüm 5.1.3’te belirtildiği üzere, RTP ICE bileşeninden RTP ve RTCP’yi ayırmaya hazırlık yapılır.
Belirtilen her bir RTP başlık uzantısı için, [RFC5285], Bölüm 6’da açıklandığı şekilde, uzantı kimliği ile URI arasında bir eşleme kurulur.
MID başlık uzantısı destekleniyorsa, [RFC8843], Bölüm 15’te açıklandığı üzere, MID başlık uzantısına dayanarak bu "m=" bölümü için hedeflenen RTP akışlarını ayırmaya hazırlık yapılır.
Belirtilen her bir medya biçimi için, [RFC3264], Bölüm 6.1’de açıklandığı şekilde, yük türü ile gerçek medya biçimi arasında bir eşleme kurulur. Buna ek olarak, [RFC8843], Bölüm 9.2’de açıklandığı üzere, bu "m=" bölümünün desteklediği medya biçimlerine dayanarak bu "m=" bölümü için hedeflenen RTP akışlarını ayırmaya hazırlık yapılır.
Belirtilen her bir "rtx" medya biçimi için, [RFC4588]’in Bölüm 8.6 ve 8.7’sinde açıklandığı şekilde, RTX yük türü ile ilişkili birincil yük türü arasında bir eşleme kurulur.
Yön özniteliği "sendrecv" veya "recvonly" türündeyse, medyanın alınması ve çözümlenmesi etkinleştirilir.

Son olarak, bu açıklama "pranswer" veya "answer" türündeyse, aşağıdaki Bölüm 5.11’de tanımlanan işlem izlenir.

5.10. Uzak Bir Açıklamanın Uygulanması

Bir uzak açıklamayı uygulamak için aşağıdaki adımlar gerçekleştirilir. Bir hata döndürülürse, oturum bu adımlar gerçekleştirilmeden önceki durumuna geri döndürülmelidir.

Yanıt herhangi bir "a=ice-options" özniteliği içeriyor ve burada "trickle" bir öznitelik olarak listelenmişse, PeerConnection canTrickleIceCandidates özelliğini "true" olarak ayarlayın. Aksi takdirde bu özelliği "false" olarak ayarlayın.

Aşağıdaki adımlar oturum düzeyindeki öznitelikler için MUTLAKA uygulanmalıdır; herhangi bir parametre sınırların dışındaysa veya uygulanamıyorsa, işlem MUTLAKA durdurulmalı ve bir hata döndürülmelidir.

Belirtilmiş herhangi bir "CT" bant genişliği değeri için, bu değeri [RFC4566], Bölüm 5.8’de belirtildiği üzere tüm "m=" bölümleri için maksimum toplam bit hızı sınırı olarak ayarlayın. Bu genel sınır dahilinde, uygulama, bireysel "m=" bölümleri için belirtilmiş özel sınırları dikkate alarak, mevcut bant genişliğinin "m=" bölümleri arasında en iyi şekilde nasıl dağıtılacağına dinamik olarak karar verebilir.
Belirtilmiş herhangi bir "RR" veya "RS" bant genişliği değeri için, [RFC3556], Bölüm 2’de belirtildiği şekilde işlem yapın.
Herhangi bir "AS" bant genişliği değeri ([RFC4566], Bölüm 5.8) MUTLAKA yok sayılmalıdır; çünkü bu yapının oturum düzeyindeki anlamı iyi tanımlanmamıştır.

Her bir "m=" bölümü için aşağıdaki adımlar MUTLAKA uygulanmalıdır; herhangi bir parametre sınırların dışındaysa veya uygulanamıyorsa, işlem MUTLAKA durdurulmalı ve bir hata döndürülmelidir.

ICE ufrag veya parola önceki uzak tanımdan farklıysa:
Tanımın türü "offer" ise, uygulama [RFC8839], Bölüm 4.4.1.1.1’de açıklandığı gibi bir ICE yeniden başlatmasının gerekli olduğunu MUTLAKA not etmelidir.
Tanımın türü "answer" veya "pranswer" ise, mevcut yerel tanımın bir ICE yeniden başlatması olup olmadığını kontrol edin; değilse bir hata üretin. PeerConnection durumu "have-remote-pranswer" ise ve ICE ufrag veya parola önceki geçici yanıttan farklıysa, ICE aracısına "m=" bölümü için önceki herhangi bir ICE kontrol listesi durumunu atmasını bildirin. Son olarak, ICE aracısına kontrolleri başlatması için sinyal verin.
Mevcut yerel tanım bir ICE yeniden başlatmasını gösteriyor ancak ne ICE ufrag ne de parola önceki uzak tanımdan değişmişse ([RFC8445], Bölüm 9’da belirtildiği üzere), bir hata üretin.
Bu medya bölümüyle ilişkili ICE bileşenlerini, bağlantı kontrolleri için sağlanan uzak ICE ufrag ve parolayı kullanacak şekilde yapılandırın.
Sağlanan herhangi bir ICE adayını, [RFC8445], Bölüm 6.1.2’de açıklandığı gibi toplanmış yerel adaylarla eşleştirin ve uygun kimlik bilgileriyle bağlantı kontrollerini başlatın.
Bir "a=end-of-candidates" özniteliği mevcutsa, [RFC8838], Bölüm 14’te açıklandığı şekilde adayların sonu göstergesini işleyin.
"m=" bölümünün <proto> değeri RTP kullanımını gösteriyorsa:
"m=" bölümü yeniden kullanılıyorsa (Bkz. Bölüm 5.2.2), şu anda ilişkilendirilmiş olan RtpTransceiver’ı, mid özelliğini "null" olarak ayarlayarak ayırın ve alıcı-verici ile onun "m=" bölüm indeksini arasındaki eşlemeyi atın.
"m=" bölümü herhangi bir RtpTransceiver ile ilişkilendirilmemişse (önceki adımda ayrılmış olması mümkün), aşağıdaki adımlara göre ya bir RtpTransceiver bulun ya da bir tane oluşturun:
"m=" bölümü sendrecv veya recvonly ise ve PeerConnection’a addTrack ile eklenmiş, herhangi bir "m=" bölümüyle ilişkilendirilmemiş ve durdurulmamış aynı türde RtpTransceiver’lar varsa, bu türden ilkini (Bölüm 5.2.1’de açıklanan kanonik sıraya göre) bulun.
Önceki adımda bir RtpTransceiver bulunamadıysa, recvonly yönüne sahip bir tane oluşturun.
Bulunan veya oluşturulan RtpTransceiver’ı, RtpTransceiver’ın mid özelliğinin değerini "m=" bölümünün MID değerine ayarlayarak "m=" bölümüyle ilişkilendirin ve alıcı-verici ile "m=" bölümünün indeksi arasında bir eşleme kurun. Eğer "m=" bölümü bir MID içermiyorsa (yani uzak uç MID uzantısını desteklemiyorsa), Bölüm 5.2.1’de belirtilen "a=mid" rehberliğini izleyerek RtpTransceiver mid özelliği için bir değer üretin.
Yerel uygulama tarafından da desteklenen her bir belirtilmiş medya biçimi için, [RFC3264], Bölüm 6.1’de açıklandığı üzere, belirtilen yük türü ile medya biçimi arasında bir eşleme kurun. Özellikle bu, uygulamanın, her bir belirtilmiş medya biçimini gönderirken çıkış RTP paketlerinde kullanılacak yük türünü ve sıralamalarında belirtilen her bir biçim için göreli tercihi kaydetmesi anlamına gelir. Belirtilen herhangi bir medya biçimi yerel uygulama tarafından desteklenmiyorsa, MUTLAKA yok sayılmalıdır.
Belirtilmiş her bir "rtx" medya biçimi için, [RFC4588], Bölüm 4’te açıklandığı üzere, RTX yük türü ile ilişkili birincil yük türü arasında bir eşleme kurun. Referans verilen birincil yük türlerinden herhangi biri mevcut değilse, bu MUTLAKA bir hatayla sonuçlanmalıdır. RTX yük türlerinin, yerel medya uygulaması tarafından desteklenmeyen birincil yük türlerine başvurabileceğini unutmayın; bu durumda RTX yük türü de MUTLAKA yok sayılmalıdır.
Yerel uygulama tarafından desteklenen her bir belirtilmiş fmtp parametresi için, bunları ilişkili medya biçimleri üzerinde etkinleştirin.
"m=" bölümünde sinyallenen her bir belirtilmiş Eşzamanlama Kaynağı (SSRC) için, [RFC8843], Bölüm 9.2’de açıklandığı üzere, bu SSRC’yi kullanarak bu "m=" bölümü için amaçlanan RTP akışlarının demultiplekslenmesine hazırlanın.
Yerel uygulama tarafından da desteklenen her bir belirtilmiş RTP başlık uzantısı için, [RFC5285], Bölüm 5’te açıklandığı üzere, uzantı kimliği ile URI arasında bir eşleme kurun. Özellikle bu, uygulamanın her bir belirtilmiş başlık uzantısını gönderirken çıkış RTP paketlerinde kullanılacak uzantı kimliğini kaydetmesi anlamına gelir. Belirtilen herhangi bir RTP başlık uzantısı yerel uygulama tarafından desteklenmiyorsa, MUTLAKA yok sayılmalıdır.
Yerel uygulama tarafından desteklenen her bir belirtilmiş RTCP geri bildirim mekanizması için, bunları ilişkili medya biçimleri üzerinde etkinleştirin.
Belirtilmiş herhangi bir "TIAS" ("Transport Independent Application Specific Maximum") bant genişliği değeri için, [RFC3890]’da belirtildiği üzere, bu değeri medya gönderirken kullanılacak maksimum RTP bit hızı üzerinde bir kısıt olarak ayarlayın. Bir "TIAS" değeri mevcut değilse ancak bir "AS" değeri belirtilmişse, aşağıdaki formülü kullanarak bir "TIAS" değeri üretin:
TIAS = AS 1000 0.95 - (50 40 8)
Buradaki 1000, birimi kbps’ten bps’e dönüştürür (TIAS için gerektiği üzere) ve 0.95, RTCP için %5 ayırmak içindir. Daha sonra başlık ek yükü için bir tahmin çıkarılır; burada 50, saniyede 50 paket varsayımına, 40 tipik başlık boyutuna (bayt cinsinden) ve 8 bayttan bite dönüşüme dayanır. "TIAS"’ın, bant genişliği üzerinde daha doğru kontrol sağladığı için "AS"’ye tercih edildiğini unutmayın.
Herhangi bir "RR" veya "RS" bant genişliği değeri için, [RFC3556], Bölüm 2’de belirtildiği şekilde işlem yapın.
Belirtilmiş herhangi bir "CT" bant genişliği değeri MUTLAKA yok sayılmalıdır; çünkü bu yapının medya düzeyindeki anlamı iyi tanımlanmamıştır.
"m=" bölümü "audio" türündeyse:
Belirtilmiş her bir "CN" medya biçimi için, [RFC3389], Bölüm 5’te açıklandığı üzere, kendi dahili sessizlik bastırma mekanizmalarına sahip biçimler hariç olmak üzere, aynı saat hızına sahip tüm desteklenen medya biçimleri için sessizlik bastırmayı yapılandırın. Bu tür biçimler (ör. Opus) için sessizlik bastırma, Bölüm 5.2.3.2’de tartışıldığı gibi fmtp parametreleri aracılığıyla denetlenir.
Belirtilmiş her bir "telephone-event" medya biçimi için, [RFC4733], Bölüm 2.5.1.2’de açıklandığı üzere, aynı saat hızına sahip tüm desteklenen medya biçimleri için çift tonlu çoklu frekans (DTMF) iletimini etkinleştirin. Karşılık gelen bir telephone-event biçimine sahip olmayan desteklenen medya biçimleri varsa, bu biçimler için DTMF iletimini devre dışı bırakın.
Belirtilmiş herhangi bir "ptime" değeri için, gönderim sırasında belirtilen paket boyutunu kullanacak şekilde mevcut medya biçimlerini yapılandırın. Belirtilen boyut bir medya biçimi için desteklenmiyorsa, bunun yerine en yakın değeri kullanın.

Son olarak, bu tanımın türü "pranswer" veya "answer" ise, aşağıdaki Bölüm 5.11’de tanımlanan işlemeyi izleyin.

5.11. Bir Yanıtın Uygulanması

Yerel veya uzak bir tanımın işlenmesi için yukarıda belirtilen adımlara ek olarak, "pranswer" veya "answer" türünde bir tanım işlenirken aşağıdaki adımlar uygulanır.

Her bir "m=" bölümü için aşağıdaki adımlar MUTLAKA uygulanmalıdır:

"m=" bölümü reddedilmişse (yani yanıtta <port> değeri sıfıra ayarlanmışsa), bu bölüm için herhangi bir medya alımını veya gönderimini durdurun ve bu "m=" bölümü reddedilmemiş bir "m=" bölümüyle demetlenmedikçe, [RFC8839], Bölüm 4.4.3.1’de açıklandığı üzere, ilişkili tüm ICE bileşenlerini atın.
Uzak DTLS parmak izi değişmişse veya "a=tls-id" özniteliğinin değeri değişmişse, DTLS bağlantısını sonlandırın. Bu, PeerConnection durumunun "have-remote-pranswer" olduğu durumu da kapsar. Bir DTLS bağlantısının sonlandırılması gerekiyorsa ancak yanıt bir ICE yeniden başlatmasını veya "have-remote-pranswer" durumunda yeni ICE kimlik bilgilerini göstermiyorsa, MUTLAKA bir hata üretilmelidir. Bir ICE yeniden başlatması, tls-id değeri veya parmak izi değişmeden gerçekleştirilirse, aynı DTLS bağlantısı yeni ICE kanalı üzerinden sürdürülür. JSEP’in, yanıtlayıcıların tls-id değerini yalnızca ve yalnızca teklif sahibi değiştirdiğinde değiştirmesini gerektirdiğini; ancak JSEP olmayan yanıtlayıcıların, teklif bir ICE yeniden başlatması içerdiği sürece tls-id değerini değiştirmesine izin verildiğini unutmayın. Bu nedenle, yanıt alınmadan önce DTLS verilerini işleyen JSEP uygulamaları, bir ClientHello veya önceki DTLS bağlantısından veri alabilecek şekilde hazırlıklı olmalıdır.
Geçerli bir DTLS bağlantısı yoksa, etkin hale geldiklerinde, belirtilen roller ve parmak izleri kullanılarak, alttaki herhangi bir ICE bileşeni üzerinde bir DTLS bağlantısı başlatmaya hazırlanın.
"m=" bölümünün <proto> değeri RTP kullanımını gösteriyorsa:
"m=" bölümü, teklifteki karşılık gelen "m=" bölümünde bulunmayan RTCP geri bildirim mekanizmalarına başvuruyorsa, bu bir müzakere sorununu gösterir ve MUTLAKA bir hatayla sonuçlanmalıdır. Ancak, [RFC3264], Bölüm 7 ve [RFC5285], Bölüm 6’da açıklandığı üzere, yanıtta yeni medya biçimlerine ve yeni RTP başlık uzantısı değerlerine izin verilir.
"m=" bölümünde RTCP mux etkinse, mevcutsa RTCP ICE bileşenini atın ve [RFC5761], Bölüm 5.1.3’te belirtildiği üzere, RTCP’yi RTP ICE bileşeni üzerinden çoklamaya başlayın veya buna devam edin. Aksi takdirde, RTCP’yi RTCP ICE bileşeni üzerinden iletmeye hazırlanın; RTCP mux daha önce etkin olduğu için bir RTCP ICE bileşeni yoksa, bu MUTLAKA bir hatayla sonuçlanmalıdır.
"m=" bölümünde Reduced-Size RTCP etkinse, bu "m=" bölümü için RTCP iletimini [RFC5506]’da belirtildiği üzere Reduced-Size RTCP kullanacak şekilde yapılandırın.
Yanıttaki yön özniteliği JSEP uygulamasının medya göndermesi gerektiğini gösteriyorsa (yerel yanıtlar için "sendonly", uzak yanıtlar için "recvonly" veya her iki yanıt türü için "sendrecv"), [RFC3264], Bölüm 6.1 ve 7’de tartışıldığı üzere, uzak tanımdaki ve yerel olarak da desteklenen en tercih edilen medya biçimini gönderilecek medya biçimi olarak seçin ve alttaki taşıma katmanları kurulduğunda bu biçimi kullanarak RTP medyasını göndermeye başlayın. Bu çıkış RTP akışı için henüz bir SSRC seçilmemişse, benzersiz rastgele bir tane seçin. Medya zaten gönderiliyorsa, yeni codec’in saat hızı farklı olmadıkça aynı SSRC KULLANILMALIDIR; saat hızı farklıysa, [RFC7160], Bölüm 4.1’de belirtildiği üzere yeni bir SSRC MUTLAKA seçilmelidir.
Uzak tanımdaki yük türü eşlemesi, yukarıda seçilen gönderim medya biçimi için yük türü de dahil olmak üzere, çıkış RTP akışları için yük türlerini belirlemek amacıyla kullanılır. Müzakere edilmiş olan herhangi bir RTP başlık uzantısı, uzak tanımdaki uzantı eşlemesi kullanılarak çıkış RTP akışlarına dahil edilmelidir. MID başlık uzantısı müzakere edilmişse, [RFC8843], Bölüm 15’te belirtildiği üzere, çıkış RTP akışlarına dahil edin. RtpStreamId veya RepairedRtpStreamId başlık uzantıları müzakere edilmişse ve rid-id’ler kurulmuşsa, [RFC8851], Bölüm 4’te belirtildiği üzere bu başlık uzantılarını çıkış RTP akışlarına dahil edin.
"m=" bölümü "audio" türündeyse ve sessizlik bastırma (1) uzak tanımın işlenmesi sonucunda gönderim medya biçimi için yapılandırılmışsa ve (2) yerel tanımda da bu biçim için etkinleştirilmişse, Bölüm 5.2.3.2’deki rehberliğe uygun olarak çıkış medyası için sessizlik bastırma kullanın. Bu koşullar sağlanmıyorsa, çıkış medyası için sessizlik bastırma MUTLAKA kullanılmamalıdır.
Simulcast müzakere edilmişse, [RFC8853], Bölüm 5.3.3’te belirtildiği üzere uygun sayıda Kaynak RTP Akışı gönderin.
Yukarıda seçilen gönderim medya biçiminin karşılık gelen bir "rtx" medya biçimi varsa veya bir FEC mekanizması müzakere edilmişse, her bir Kaynak RTP Akışı için benzersiz rastgele bir SSRC’ye sahip bir yedeklilik RTP akışı kurun ve gerektiğinde RTX/FEC paketlerini göndermeye başlayın veya devam edin.
Yukarıda seçilen gönderim medya biçiminin aynı saat hızına sahip karşılık gelen bir "red" medya biçimi varsa, [RFC8854], Bölüm 3.2’de tartışıldığı üzere, dayanıklılık amacıyla belirtilen biçimi kullanarak yedekli kodlamaya izin verin. RTX veya FEC medya biçimlerinden farklı olarak, "red" biçiminin yedeklilik RTP akışı üzerinde değil, Kaynak RTP Akışı üzerinde iletildiğini unutmayın.
Medya bölümünde başvurulan RTCP geri bildirim mekanizmalarını, belirtilen medya biçimlerini kullanan tüm Kaynak RTP Akışları için etkinleştirin. Özellikle, [RFC4585], Bölüm 4.2’de belirtildiği üzere, istenen geri bildirim türlerini göndermeye başlayın veya buna devam edin ve alınan geri bildirimlere tepki verin. RTCP geri bildirimi gönderirken, hangi SSRC’nin kullanılacağını seçmek için [RFC8108], Bölüm 5.4.1’deki kuralları ve önerileri izleyin.
Yanıttaki yön özniteliği JSEP uygulamasının medya göndermemesi gerektiğini gösteriyorsa (yerel yanıtlar için "recvonly", uzak yanıtlar için "sendonly" veya her iki yanıt türü için "inactive"), [RFC3264], Bölüm 5.1’de açıklandığı üzere, tüm RTP medya iletimini durdurun ancak RTCP göndermeye devam edin.
"m=" bölümünün <proto> değeri SCTP kullanımını gösteriyorsa:
Bir SCTP ilişkilendirmesi mevcutsa ve uzak SCTP portu değişmişse, mevcut SCTP ilişkilendirmesini atın. Bu, PeerConnection durumunun "have-remote-pranswer" olduğu durumu da kapsar.
Geçerli bir SCTP ilişkilendirmesi yoksa, [RFC8841], Bölüm 10.2’de açıklandığı üzere, yerel tanımdaki yerel SCTP port değeri ve uzak tanımdaki uzak SCTP port değeri kullanılarak, ilişkili ICE bileşeni ve DTLS bağlantısı üzerinden bir SCTP ilişkilendirmesi başlatmaya hazırlanın.

Yanıt geçerli demet (bundle) grupları içeriyorsa, her bir demette birincil ICE bileşenleri üzerine demetlenecek "m=" bölümleri için tüm ICE bileşenlerini atın ve [RFC8843], Bölüm 7.4’te açıklandığı üzere bu "m=" bölümlerini buna göre çoklamaya başlayın.

Tanımın türü "answer" ise ve ICE aday havuzunda hâlâ kalan adaylar varsa, bunları atın.

#6. RTP/RTCP’nin İşlenmesi

Paketleme (bundling) kullanıldığında, gelen RTP/RTCP’nin uygun "m=" bölümüne ilişkilendirilmesi [RFC8843], Bölüm 9.2’de tanımlanmıştır. Paketleme kullanılmadığında ise, RTP/RTCP’nin alındığı ICE bileşeninden uygun "m=" bölümü açıkça anlaşılır.

Uygun "m=" bölümü ya da bölümleri belirlendikten sonra, RTP/RTCP, "m=" bölümü/bölümleri ile ilişkili RtpTransceiver(lar)a iletilir ve RTP/RTCP’nin sonraki işlenmesi RtpTransceiver düzeyinde yapılır. Buna, birden fazla kodlanmış akış arasında ayrım yapmak ve belirli bir yedeklilik RTP akışının hangi Kaynak RTP akışını onarması gerektiğini belirlemek için RID mekanizmasının [RFC8851] ve buna bağlı RtpStreamId ile RepairedRtpStreamId tanımlayıcılarının kullanılması dahildir.

#7. Örnekler

Bu örnekler bölümünün birden fazla SDP parçası gösterdiğini unutmayın. RFC satır uzunluğu kısıtlamalarına uyum sağlamak için, bazı SDP satırları birden fazla satıra bölünmüştür; baştaki boşluk, bir satırın önceki satırın devamı olduğunu belirtir. Ayrıca, okunabilirliği artırmak için bazı boş satırlar eklenmiştir; ancak bunlar SDP’de geçerli değildir.

IPv6 adresleri içeren örnekler de dahil olmak üzere, WebRTC çağrı akışları için daha fazla SDP örneği [SDP4WebRTC] belgesinde bulunabilir.

7.1. Basit Örnek

Bu bölüm, Trickle ICE kullanmadan iki JSEP uç noktası arasında asgari düzeyde bir ses/video çağrısı kuran çok basit bir örnek göstermektedir. Bir sonraki bölümdeki örnek, bir JSEP oturumunda nelerin gerçekleşebileceğine dair daha ayrıntılı bir örnek sunmaktadır.

Aşağıdaki kod akışı, Alice’in uç noktasının Bob’un uç noktasına oturumu başlatmasını göstermektedir. Alice’in tarayıcısındaki JavaScript uygulamasından Bob’un tarayıcısındaki JavaScript’e giden mesajların, sırasıyla "AliceJS" ve "BobJS" olarak kısaltıldığı ve bir web sunucusu aracılığıyla bir sinyalleşme protokolü üzerinden aktığı varsayılmaktadır. Hem Alice tarafındaki hem de Bob tarafındaki JavaScript, teklifi veya yanıtı göndermeden önce tüm adayları bekler; bu nedenle teklifler ve yanıtlar eksiksizdir ve Trickle ICE kullanılmaz. Alice’in ve Bob’un tarayıcılarındaki kullanıcı ajanları (JSEP uygulamaları), sırasıyla "AliceUA" ve "BobUA" olarak kısaltılmıştır; her ikisi de varsayılan "balanced" paketleme politikasını ve varsayılan "require" RTCP mux politikasını kullanmaktadır.

//                  yerel medya durumunu ayarla
AliceJS->AliceUA:   create new PeerConnection
AliceJS->AliceUA:   addTrack with two tracks: audio and video
AliceJS->AliceUA:   createOffer to get offer
AliceJS->AliceUA:   setLocalDescription with offer
AliceUA->AliceJS:   multiple onicecandidate events with candidates

//                  ICE toplamanın tamamlanmasını bekle
AliceUA->AliceJS:   onicecandidate event with null candidate
AliceJS->AliceUA:   get |offer-A1| from pendingLocalDescription

//                  |offer-A1| sinyalleşme protokolü üzerinden Bob’a gönderilir
AliceJS->WebServer: signaling with |offer-A1|
WebServer->BobJS:   signaling with |offer-A1|

//                  |offer-A1| Bob’a ulaşır
BobJS->BobUA:       create a PeerConnection
BobJS->BobUA:       setRemoteDescription with |offer-A1|
BobUA->BobJS:       ontrack events for audio and video tracks

//                  Bob çağrıyı kabul eder
BobJS->BobUA:       addTrack with local tracks
BobJS->BobUA:       createAnswer
BobJS->BobUA:       setLocalDescription with answer
BobUA->BobJS:       multiple onicecandidate events with candidates

//                  ICE toplamanın tamamlanmasını bekle
BobUA->BobJS:       onicecandidate event with null candidate
BobJS->BobUA:       get |answer-A1| from currentLocalDescription

//                  |answer-A1| sinyalleşme protokolü üzerinden
//                  Alice’e gönderilir
BobJS->WebServer:   signaling with |answer-A1|
WebServer->AliceJS: signaling with |answer-A1|

//                  |answer-A1| Alice’e ulaşır
AliceJS->AliceUA:   setRemoteDescription with |answer-A1|
AliceUA->AliceJS:   ontrack events for audio and video tracks

//                  medya akışı
BobUA->AliceUA:     media sent from Bob to Alice
AliceUA->BobUA:     media sent from Alice to Bob

|offer-A1| için SDP aşağıdaki gibidir:

v=0
o=- 4962303333179871722 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle ice2
a=group:BUNDLE a1 v1
a=group:LS a1 v1

m=audio 10100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.100
a=mid:a1
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=fmtp:97 0-15
a=fmtp:98 0-15
a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:47017fee-b6c1-4162-929c-a25110252400
a=ice-ufrag:ETEn
a=ice-pwd:OtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256
              19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:
              BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=tls-id:91bbf309c0990a6bec11e38ba2933cee
a=rtcp:10101 IN IP4 203.0.113.100
a=rtcp-mux
a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host
a=candidate:1 2 udp 2113929470 203.0.113.100 10101 typ host
a=end-of-candidates

m=video 10102 UDP/TLS/RTP/SAVPF 100 101 102 103
c=IN IP4 203.0.113.100
a=mid:v1
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=msid:47017fee-b6c1-4162-929c-a25110252400
a=ice-ufrag:BGKk
a=ice-pwd:mqyWsAjvtKwTGnvhPztQ9mIf
a=fingerprint:sha-256 19:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=tls-id:91bbf309c0990a6bec11e38ba2933cee
a=rtcp:10103 IN IP4 203.0.113.100
a=rtcp-mux
a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.100 10102 typ host
a=candidate:1 2 udp 2113929470 203.0.113.100 10103 typ host
a=end-of-candidates

#|answer-A1| için SDP

v=0
o=- 6729291447651054566 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle ice2
a=group:BUNDLE a1 v1
a=group:LS a1 v1

m=audio 10200 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 203.0.113.200
a=mid:a1
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=fmtp:97 0-15
a=fmtp:98 0-15
a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae
a=ice-ufrag:6sFv
a=ice-pwd:cOTZKZNVlO9RSGsEGM63JXT2
a=fingerprint:sha-256 6B:8B:F0:65:5F:78:E2:51:3B:AC:6F:F3:3F:46:1B:35:DC:B8:5F:64:1A:24:C2:43:F0:A1:58:D0:A1:2C:19:08
a=setup:active
a=tls-id:eec3392ab83e11ceb6a0990c903fbb19
a=rtcp-mux
a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.200 10200 typ host
a=end-of-candidates

m=video 10200 UDP/TLS/RTP/SAVPF 100 101 102 103
c=IN IP4 203.0.113.200
a=mid:v1
a=sendrecv
a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=101
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli
a=msid:61317484-2ed4-49d7-9eb7-1414322a7aae

7.2. Ayrıntılı Örnek

Bu bölüm, iki JSEP uç noktası arasındaki daha kapsamlı bir oturum örneğini göstermektedir. Trickle ICE, "max-bundle" paketleme politikası, "require" RTCP mux politikası ve tek bir TURN sunucusu ile tam trickle modunda kullanılır. Başlangıçta hem Alice hem de Bob bir ses kanalı ve bir veri kanalı kurar. Daha sonra Bob, ikisi de FEC destekleyen iki video akışı ekler—biri kendi video akışı, diğeri ekran paylaşımı içindir—ve video akışı simulcast için yapılandırılmıştır. Alice bu video akışlarını kabul eder ancak kendisi video akışı eklemez; bu nedenle bunlar recvonly olarak ele alınır. Alice ayrıca azami video kod çözücü çözünürlüğünü belirtir.

Çağrı Akışı

AliceJS->AliceUA:   create new PeerConnection
AliceJS->AliceUA:   addTrack with an audio track
AliceJS->AliceUA:   createDataChannel to get data channel
AliceJS->AliceUA:   createOffer to get |offer-B1|
AliceJS->AliceUA:   setLocalDescription with |offer-B1|

AliceJS->WebServer: signaling with |offer-B1|
WebServer->BobJS:   signaling with |offer-B1|

BobJS->BobUA:       create a PeerConnection
BobJS->BobUA:       setRemoteDescription with |offer-B1|
BobUA->BobJS:       ontrack event with audio track from Alice

(Kalan çağrı akışı özgün metindeki gibi korunmuştur)

#|offer-B1| için SDP

v=0
o=- 4962303333179871723 1 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle ice2
a=group:BUNDLE a1 d1

m=audio 9 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 0.0.0.0
a=mid:a1
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=fmtp:97 0-15
a=fmtp:98 0-15
a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:57017fee-b6c1-4162-929c-a25110252400
a=ice-ufrag:ATEn
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256 29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:actpass
a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7
a=rtcp-mux
a=rtcp-mux-only
a=rtcp-rsize

m=application 0 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 0.0.0.0
a=mid:d1
a=sctp-port:5000
a=max-message-size:65536
a=bundle-only

#|answer-B2| için SDP

v=0
o=- 4962303333179871723 2 IN IP4 0.0.0.0
s=-
t=0 0
a=ice-options:trickle ice2
a=group:BUNDLE a1 d1 v1 v2
a=group:LS a1 v1

m=audio 12100 UDP/TLS/RTP/SAVPF 96 0 8 97 98
c=IN IP4 192.0.2.100
a=mid:a1
a=sendrecv
a=rtpmap:96 opus/48000/2
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:97 telephone-event/8000
a=rtpmap:98 telephone-event/48000
a=fmtp:97 0-15
a=fmtp:98 0-15
a=maxptime:120
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:2 urn:ietf:params:rtp-hdrext:ssrc-audio-level
a=msid:57017fee-b6c1-4162-929c-a25110252400
a=ice-ufrag:ATEn
a=ice-pwd:AtSK0WpNtpUjkY4+86js7ZQl
a=fingerprint:sha-256
29:E2:1C:3B:4B:9F:81:E6:B8:5C:F4:A5:A8:D8:73:04:
BB:05:2F:70:9F:04:A9:0E:05:E9:26:33:E8:70:88:A2
a=setup:passive
a=tls-id:17f0f4ba8a5f1213faca591b58ba52a7
a=rtcp-mux
a=rtcp-mux-only
a=rtcp-rsize
a=candidate:1 1 udp 2113929471 203.0.113.100 10100 typ host
a=candidate:1 1 udp 1845494015 198.51.100.100 11100 typ srflx raddr 203.0.113.100 rport 10100
a=candidate:1 1 udp 255 192.0.2.100 12100 typ relay raddr 198.51.100.100 rport 11100
a=end-of-candidates

m=application 12100 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.100
a=mid:d1
a=sctp-port:5000
a=max-message-size:65536

m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103
c=IN IP4 192.0.2.100
a=mid:v1
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=101
a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0]
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli

m=video 12100 UDP/TLS/RTP/SAVPF 100 101 102 103
c=IN IP4 192.0.2.100
a=mid:v2
a=recvonly
a=rtpmap:100 VP8/90000
a=rtpmap:101 H264/90000
a=fmtp:101 packetization-mode=1;profile-level-id=42e01f
a=rtpmap:102 rtx/90000
a=fmtp:102 apt=100
a=rtpmap:103 rtx/90000
a=fmtp:103 apt=101
a=imageattr:100 recv [x=[48:1920],y=[48:1080],q=1.0]
a=extmap:1 urn:ietf:params:rtp-hdrext:sdes:mid
a=extmap:3 urn:ietf:params:rtp-hdrext:sdes:rtp-stream-id
a=rtcp-fb:100 ccm fir
a=rtcp-fb:100 nack
a=rtcp-fb:100 nack pli

7.3. Erken Taşıma Isınması Örneği

Bu örnek, Bölüm 4.1.10.1’de açıklanan erken ısınma tekniğini göstermektedir. Burada Alice’in uç noktası, bir ses/video çağrısı başlatmak için Bob’un uç noktasına bir teklif gönderir. Bob, ses/video "m=" bölümlerini kabul eden ancak bunları kendi bakış açısından sendonly olarak işaretleyen bir yanıtla hemen karşılık verir; bu da Alice’in henüz medya göndermeyeceği anlamına gelir. Bu durum, JSEP uygulamasının ICE ve DTLS müzakerelerini derhal başlatmasına olanak tanır. Ardından Bob’un uç noktası, çağrıyı yanıtlaması için onu yönlendirir ve Bob yanıtladığında, uç noktası ses ve video "m=" bölümlerini etkinleştiren ikinci bir teklif gönderir; böylece çift yönlü medya iletimi sağlanır.

Bu tür bir akışın avantajı, ilk yanıt alınır alınmaz uygulamanın ICE ve DTLS müzakerelerine devam edebilmesi ve oturum taşımasını kurabilmesidir. Taşıma kurulumu ikinci teklif gönderilmeden önce tamamlanırsa, çağrıyı alan taraf çağrıyı yanıtladığı anda medyayı derhal iletebilir; bu da algılanan arama sonrası gecikmeyi en aza indirir. İkinci teklif/yanıt değişimi, tercih edilen kodekleri veya diğer oturum parametrelerini de değiştirebilir.

Bu örnek ayrıca, gerekli ICE toplama ve denetim miktarını en aza indirmek için Bölüm 3.5.3’te açıklanan "relay" ICE aday politikasını kullanır.

Çağrı Akışı

AliceJS → AliceUA: "relay" ICE politikasıyla yeni bir PeerConnection oluştur
AliceJS → AliceUA: iki parça içeren addTrack: ses ve video
AliceJS → AliceUA: |offer-C1| elde etmek için createOffer
AliceJS → AliceUA: |offer-C1| ile setLocalDescription
AliceJS → WebServer: |offer-C1| ile sinyalleşme
WebServer → BobJS: |offer-C1| ile sinyalleşme
BobJS → BobUA: "relay" ICE politikasıyla yeni bir PeerConnection oluştur
BobJS → BobUA: |offer-C1| ile setRemoteDescription
BobUA → BobJS: ses ve video için ontrack olayları
AliceUA → AliceJS: onicecandidate (relay) |offer-C1-candidate-1|
AliceJS → WebServer: |offer-C1-candidate-1| ile sinyalleşme
WebServer → BobJS: |offer-C1-candidate-1| ile sinyalleşme
BobJS → BobUA: |offer-C1-candidate-1| ile addIceCandidate
BobJS → BobUA: null ses ve video parçalarıyla addTransceiver
BobJS → BobUA: her ikisi için transceiver.setDirection(sendonly)
BobJS → BobUA: createAnswer
BobJS → BobUA: yanıt ile setLocalDescription
BobJS → WebServer: |answer-C1| ile sinyalleşme
WebServer → AliceJS: |answer-C1| ile sinyalleşme
AliceJS → AliceUA: |answer-C1| ile setRemoteDescription
AliceUA → AliceJS: ses ve video için ontrack olayları
BobUA → BobJS: onicecandidate (relay) |answer-B1-candidate-1|
BobJS → WebServer: |answer-B1-candidate-1| ile sinyalleşme
WebServer → AliceJS: |answer-B1-candidate-1| ile sinyalleşme
AliceJS → AliceUA: |answer-B1-candidate-1| ile addIceCandidate
Çağrı çalarken ICE ve DTLS kurulur
BobJS → BobUA: ses ve video parçalarıyla transceiver.setTrack
BobUA → AliceUA: Bob’dan Alice’e medya gönderilir
BobJS → BobUA: her iki transceiver için transceiver.setDirection(sendrecv)
BobJS → BobUA: createOffer
BobJS → BobUA: teklif ile setLocalDescription
BobJS → WebServer: |offer-C2| ile sinyalleşme
WebServer → AliceJS: |offer-C2| ile sinyalleşme
AliceJS → AliceUA: |offer-C2| ile setRemoteDescription
AliceJS → AliceUA: createAnswer
AliceJS → AliceUA: |answer-C2| ile setLocalDescription
AliceUA → BobUA: Alice’ten Bob’a medya gönderilir
AliceJS → WebServer: |answer-C2| ile sinyalleşme
WebServer → BobJS: |answer-C2| ile sinyalleşme
BobJS → BobUA: |answer-C2| ile setRemoteDescription

#8. Güvenlik Hususları

IETF, WebRTC’nin tamamı için güvenlik mimarisini tanımlayan ayrı belgeler olan [RFC8827] ve [RFC8826]’yı yayımlamıştır. Bu bölümün geri kalanı, bu belgeye özgü güvenlik hususlarını açıklamaktadır.

Biçimsel olarak JSEP arayüzü bir API olsa da, uygulama JavaScript’inin JSEP uygulamasının bakış açısından güvenilmez olması nedeniyle, onu bir İnternet protokolü olarak düşünmek daha uygundur. Bu nedenle [RFC3552]’nin tehdit modeli geçerlidir. Özellikle JavaScript, API’yi herhangi bir sırayla ve kötü niyetli olanlar dâhil olmak üzere herhangi girdilerle çağırabilir. Bu durum, setLocalDescription’a aktarılan SDP’yi ele aldığımızda özellikle önemlidir. Doğru API kullanımı, uygulamanın createOffer veya createAnswer’dan türetilmiş SDP’yi iletmesini gerektirse de, uygulamaların bunu yapacağına dair bir garanti yoktur. JSEP uygulaması, JavaScript’in bunun yerine sahte veriler iletebileceğine karşı hazırlıklı OLMALIDIR.

Buna karşılık, uygulama geliştiricisinin JavaScript’in uç nokta davranışı üzerinde tam denetime sahip olmadığının farkında olması gerekir. Özellikle belirtilmesi gereken bir durum, ICE adaylarını SDP’den çıkarmanın veya damlatmalı (trickle) adayları bastırmanın beklenen davranışı vermemesidir: uygulamalar, bu adaylar karşı tarafa gönderilmese bile, yine de bu adaylardan denetimler gerçekleştirecektir. Dolayısıyla, örneğin sunucu-yansıtmalı (server-reflexive) adayları kaldırarak uzak eşin genel IP adresinizi öğrenmesini engellemek mümkün değildir. Genel IP adreslerini gizlemek isteyen uygulamalar, bunun yerine ICE aracısını yalnızca aktarıcı (relay) adayları kullanacak şekilde yapılandırmak ZORUNDADIR.

#9. IANA Hususları

Bu belgenin IANA açısından herhangi bir işlemi yoktur.

#10. Kaynaklar

10.1. Normatif Kaynaklar

[RFC2119] Bradner, S., "Gereksinim Düzeylerini Belirtmek İçin RFC’lerde Kullanılacak Anahtar Sözcükler", BCP 14, RFC 2119, DOI 10.17487/RFC2119, Mart 1997, https://www.rfc-editor.org/info/rfc2119.
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. ve E. Schooler, "SIP: Oturum Başlatma Protokolü", RFC 3261, DOI 10.17487/RFC3261, Haziran 2002, https://www.rfc-editor.org/info/rfc3261.
[RFC3264] Rosenberg, J. ve H. Schulzrinne, "Oturum Tanımlama Protokolü (SDP) ile Bir Teklif/Cevap Modeli", RFC 3264, DOI 10.17487/RFC3264, Haziran 2002, https://www.rfc-editor.org/info/rfc3264.
[RFC3552] Rescorla, E. ve B. Korver, "Güvenlik Hususları Üzerine RFC Metni Yazımı İçin Kılavuzlar", BCP 72, RFC 3552, DOI 10.17487/RFC3552, Temmuz 2003, https://www.rfc-editor.org/info/rfc3552.
[RFC3605] Huitema, C., "Oturum Tanımlama Protokolü (SDP) İçinde Gerçek Zamanlı Kontrol Protokolü (RTCP) Özniteliği", RFC 3605, DOI 10.17487/RFC3605, Ekim 2003, https://www.rfc-editor.org/info/rfc3605.
[RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E. ve K. Norrman, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP)", RFC 3711, DOI 10.17487/RFC3711, Mart 2004, https://www.rfc-editor.org/info/rfc3711.
[RFC3890] Westerlund, M., "Oturum Tanımlama Protokolü (SDP) için Taşıma Bağımsız Bir Bant Genişliği Değiştiricisi", RFC 3890, DOI 10.17487/RFC3890, Eylül 2004, https://www.rfc-editor.org/info/rfc3890.
[RFC4145] Yon, D. ve G. Camarillo, "Oturum Tanımlama Protokolü (SDP) İçinde TCP Tabanlı Medya Taşımacılığı", RFC 4145, DOI 10.17487/RFC4145, Eylül 2005, https://www.rfc-editor.org/info/rfc4145.
[RFC4566] Handley, M., Jacobson, V. ve C. Perkins, "SDP: Oturum Tanımlama Protokolü", RFC 4566, DOI 10.17487/RFC4566, Temmuz 2006, https://www.rfc-editor.org/info/rfc4566.
[RFC4585] Ott, J., Wenger, S., Sato, N., Burmeister, C. ve J. Rey, "Gerçek Zamanlı Taşıma Kontrol Protokolü (RTCP) Tabanlı Geri Bildirim için Genişletilmiş RTP Profili (RTP/AVPF)", RFC 4585, DOI 10.17487/RFC4585, Temmuz 2006, https://www.rfc-editor.org/info/rfc4585.
[RFC5124] Ott, J. ve E. Carrara, "Gerçek Zamanlı Taşıma Kontrol Protokolü (RTCP) Tabanlı Geri Bildirim için Genişletilmiş Güvenli RTP Profili (RTP/SAVPF)", RFC 5124, DOI 10.17487/RFC5124, Şubat 2008, https://www.rfc-editor.org/info/rfc5124.
[RFC5285] Singer, D. ve H. Desineni, "RTP Başlık Uzantıları için Genel Bir Mekanizma", RFC 5285, DOI 10.17487/RFC5285, Temmuz 2008, https://www.rfc-editor.org/info/rfc5285.
[RFC5761] Perkins, C. ve M. Westerlund, "RTP Veri ve Kontrol Paketlerinin Tek Bir Port Üzerinde Çoklanması", RFC 5761, DOI 10.17487/RFC5761, Nisan 2010, https://www.rfc-editor.org/info/rfc5761.
[RFC5888] Camarillo, G. ve H. Schulzrinne, "Oturum Tanımlama Protokolü (SDP) Gruplama Çerçevesi", RFC 5888, DOI 10.17487/RFC5888, Haziran 2010, https://www.rfc-editor.org/info/rfc5888.
[RFC6236] Johansson, I. ve K. Jung, "Oturum Tanımlama Protokolü (SDP) İçinde Genel Görüntü Özniteliklerinin Müzakeresi", RFC 6236, DOI 10.17487/RFC6236, Mayıs 2011, https://www.rfc-editor.org/info/rfc6236.
[RFC6347] Rescorla, E. ve N. Modadugu, "Datagram Taşıma Katmanı Güvenliği Sürüm 1.2", RFC 6347, DOI 10.17487/RFC6347, Ocak 2012, https://www.rfc-editor.org/info/rfc6347.
[RFC6716] Valin, J.-M., Vos, K. ve T. Terriberry, "Opus Ses Kodlayıcısının Tanımı", RFC 6716, DOI 10.17487/RFC6716, Eylül 2012, https://www.rfc-editor.org/info/rfc6716.
[RFC6904] Lennox, J., "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) İçinde Başlık Uzantılarının Şifrelenmesi", RFC 6904, DOI 10.17487/RFC6904, Nisan 2013, https://www.rfc-editor.org/info/rfc6904.
[RFC7160] Petit-Huguenin, M. ve G. Zorn (Ed.), "Bir RTP Oturumunda Birden Çok Saat Hızının Desteklenmesi", RFC 7160, DOI 10.17487/RFC7160, Nisan 2014, https://www.rfc-editor.org/info/rfc7160.
[RFC7587] Spittka, J., Vos, K. ve J.-M. Valin, "Opus Konuşma ve Ses Kodlayıcısı için RTP Yük Biçimi", RFC 7587, DOI 10.17487/RFC7587, Haziran 2015, https://www.rfc-editor.org/info/rfc7587.
[RFC7742] Roach, A. B., "WebRTC Video İşleme ve Kodlayıcı Gereksinimleri", RFC 7742, DOI 10.17487/RFC7742, Mart 2016, https://www.rfc-editor.org/info/rfc7742.
[RFC7850] Nandakumar, S., "Çeşitli RTP Profilleri Altında TCP Üzerinden RTP Medyası Taşımak için SDP 'proto' Alanı Değerlerinin Kaydı", RFC 7850, DOI 10.17487/RFC7850, Nisan 2016, https://www.rfc-editor.org/info/rfc7850.
[RFC7874] Valin, J.-M. ve C. Bran, "WebRTC Ses Kodlayıcısı ve İşleme Gereksinimleri", RFC 7874, DOI 10.17487/RFC7874, Mayıs 2016, https://www.rfc-editor.org/info/rfc7874.
[RFC8108] Lennox, J., Westerlund, M., Wu, Q. ve C. Perkins, "Tek Bir RTP Oturumunda Birden Çok RTP Akışının Gönderilmesi", RFC 8108, DOI 10.17487/RFC8108, Mart 2017, https://www.rfc-editor.org/info/rfc8108.
[RFC8122] Lennox, J. ve C. Holmberg, "Oturum Tanımlama Protokolü (SDP) İçinde Taşıma Katmanı Güvenliği (TLS) Protokolü Üzerinden Bağlantı Odaklı Medya Taşımacılığı", RFC 8122, DOI 10.17487/RFC8122, Mart 2017, https://www.rfc-editor.org/info/rfc8122.
[RFC8174] Leiba, B., "RFC 2119 Anahtar Sözcüklerinde Büyük Harf ile Küçük Harf Kullanımındaki Belirsizlik", BCP 14, RFC 8174, DOI 10.17487/RFC8174, Mayıs 2017, https://www.rfc-editor.org/info/rfc8174.
[RFC8445] Keränen, A., Holmberg, C. ve J. Rosenberg, "Etkileşimli Bağlanabilirlik Kurulumu (ICE): Ağ Adresi Çeviricisi (NAT) Geçişi için Bir Protokol", RFC 8445, DOI 10.17487/RFC8445, Temmuz 2018, https://www.rfc-editor.org/info/rfc8445.
[RFC8826] Rescorla, E., "WebRTC için Güvenlik Hususları", RFC 8826, DOI 10.17487/RFC8826, Ocak 2021, https://www.rfc-editor.org/info/rfc8826.
[RFC8827] Rescorla, E., "WebRTC Güvenlik Mimarisi", RFC 8827, DOI 10.17487/RFC8827, Ocak 2021, https://www.rfc-editor.org/info/rfc8827.
[RFC8830] Alvestrand, H., "Oturum Tanımlama Protokolü İçinde WebRTC MediaStream Kimliklendirmesi", RFC 8830, DOI 10.17487/RFC8830, Ocak 2021, https://www.rfc-editor.org/info/rfc8830.
[RFC8834] Perkins, C., Westerlund, M. ve J. Ott, "WebRTC’de Medya Taşımacılığı ve RTP Kullanımı", RFC 8834, DOI 10.17487/RFC8834, Ocak 2021, https://www.rfc-editor.org/info/rfc8834.
[RFC8838] Ivov, E., Uberti, J. ve P. Saint-Andre, "Trickle ICE: Etkileşimli Bağlanabilirlik Kurulumu (ICE) Protokolü için Artımlı Aday Sağlama", RFC 8838, DOI 10.17487/RFC8838, Ocak 2021, https://www.rfc-editor.org/info/rfc8838.
[RFC8839] Petit-Huguenin, M., Nandakumar, S., Holmberg, C., Keränen, A. ve R. Shpount, "Etkileşimli Bağlanabilirlik Kurulumu (ICE) için Oturum Tanımlama Protokolü (SDP) Teklif/Cevap Usulleri", RFC 8839, DOI 10.17487/RFC8839, Ocak 2021, https://www.rfc-editor.org/info/rfc8839.
[RFC8840] Ivov, E., Stach, T., Marocco, E. ve C. Holmberg, "Etkileşimli Bağlanabilirlik Kurulumu (Trickle ICE) için Artımlı Aday Sağlamaya Yönelik Bir Oturum Başlatma Protokolü (SIP) Kullanımı", RFC 8840, DOI 10.17487/RFC8840, Ocak 2021, https://www.rfc-editor.org/info/rfc8840.
[RFC8841] Holmberg, C., Shpount, R., Loreto, S. ve G. Camarillo, "Datagram Taşıma Katmanı Güvenliği (DTLS) Taşıması Üzerinden Akış Denetim Taşıma Protokolü (SCTP) için Oturum Tanımlama Protokolü (SDP) Teklif/Cevap Usulleri", RFC 8841, DOI 10.17487/RFC8841, Ocak 2021, https://www.rfc-editor.org/info/rfc8841.
[RFC8842] Holmberg, C. ve R. Shpount, "Datagram Taşıma Katmanı Güvenliği (DTLS) ve Taşıma Katmanı Güvenliği (TLS) için Oturum Tanımlama Protokolü (SDP) Teklif/Cevap Hususları", RFC 8842, DOI 10.17487/RFC8842, Ocak 2021, https://www.rfc-editor.org/info/rfc8842.
[RFC8843] Holmberg, C., Alvestrand, H. ve C. Jennings, "Oturum Tanımlama Protokolü (SDP) Kullanılarak Medya Çoklamasının Müzakere Edilmesi", RFC 8843, DOI 10.17487/RFC8843, Ocak 2021, https://www.rfc-editor.org/info/rfc8843.
[RFC8851] Roach, A. B. (Ed.), "RTP Yük Biçimi Kısıtlamaları", RFC 8851, DOI 10.17487/RFC8851, Ocak 2021, https://www.rfc-editor.org/info/rfc8851.
[RFC8852] Roach, A. B., Nandakumar, S. ve P. Thatcher, "RTP Akış Tanımlayıcı Kaynak Tanımı (SDES)", RFC 8852, DOI 10.17487/RFC8852, Ocak 2021, https://www.rfc-editor.org/info/rfc8852.
[RFC8853] Burman, B., Westerlund, M., Nandakumar, S. ve M. Zanaty, "Oturum Tanımlama Protokolü (SDP) ve RTP Oturumlarında Simulcast Kullanımı", RFC 8853, DOI 10.17487/RFC8853, Ocak 2021, https://www.rfc-editor.org/info/rfc8853.
[RFC8854] Uberti, J., "WebRTC İleri Hata Düzeltme Gereksinimleri", RFC 8854, DOI 10.17487/RFC8854, Ocak 2021, https://www.rfc-editor.org/info/rfc8854.
[RFC8858] Holmberg, C., "Oturum Tanımlama Protokolü (SDP) Kullanılarak RTP ve RTP Kontrol Protokolü (RTCP) Çoklamasına Münhasır Desteğin Belirtilmesi", RFC 8858, DOI 10.17487/RFC8858, Ocak 2021, https://www.rfc-editor.org/info/rfc8858.
[RFC8859] Nandakumar, S., "Çoklama Yapılırken Oturum Tanımlama Protokolü (SDP) Öznitelikleri için Bir Çerçeve", RFC 8859, DOI 10.17487/RFC8859, Ocak 2021, https://www.rfc-editor.org/info/rfc8859.

10.2. Bilgilendirici Kaynaklar

[RFC3389] Zopf, R., "Konfor Gürültüsü (CN) için Gerçek Zamanlı Taşıma Protokolü (RTP) Yükü", RFC 3389, DOI 10.17487/RFC3389, Eylül 2002, https://www.rfc-editor.org/info/rfc3389.
[RFC3556] Casner, S., "RTP Kontrol Protokolü (RTCP) Bant Genişliği için Oturum Tanımlama Protokolü (SDP) Bant Genişliği Değiştiricileri", RFC 3556, DOI 10.17487/RFC3556, Temmuz 2003, https://www.rfc-editor.org/info/rfc3556.
[RFC3960] Camarillo, G. ve H. Schulzrinne, "Oturum Başlatma Protokolü (SIP) İçinde Erken Medya ve Çalma Tonu Üretimi", RFC 3960, DOI 10.17487/RFC3960, Aralık 2004, https://www.rfc-editor.org/info/rfc3960.
[RFC4568] Andreasen, F., Baugher, M. ve D. Wing, "Medya Akışları için Oturum Tanımlama Protokolü (SDP) Güvenlik Tanımları", RFC 4568, DOI 10.17487/RFC4568, Temmuz 2006, https://www.rfc-editor.org/info/rfc4568.
[RFC4588] Rey, J., Leon, D., Miyazaki, A., Varsa, V. ve R. Hakenberg, "RTP Yeniden İletim Yük Biçimi", RFC 4588, DOI 10.17487/RFC4588, Temmuz 2006, https://www.rfc-editor.org/info/rfc4588.
[RFC4733] Schulzrinne, H. ve T. Taylor, "DTMF Rakamları, Telefon Tonları ve Telefon Sinyalleri için RTP Yükü", RFC 4733, DOI 10.17487/RFC4733, Aralık 2006, https://www.rfc-editor.org/info/rfc4733.
[RFC5245] Rosenberg, J., "Etkileşimli Bağlanabilirlik Kurulumu (ICE): Teklif/Cevap Protokolleri için Ağ Adresi Çeviricisi (NAT) Geçişi Protokolü", RFC 5245, DOI 10.17487/RFC5245, Nisan 2010, https://www.rfc-editor.org/info/rfc5245.
[RFC5506] Johansson, I. ve M. Westerlund, "Azaltılmış Boyutlu Gerçek Zamanlı Taşıma Kontrol Protokolü (RTCP) Desteği: Fırsatlar ve Sonuçlar", RFC 5506, DOI 10.17487/RFC5506, Nisan 2009, https://www.rfc-editor.org/info/rfc5506.
[RFC5576] Lennox, J., Ott, J. ve T. Schierl, "Oturum Tanımlama Protokolü (SDP) İçinde Kaynağa Özgü Medya Öznitelikleri", RFC 5576, DOI 10.17487/RFC5576, Haziran 2009, https://www.rfc-editor.org/info/rfc5576.
[RFC5763] Fischl, J., Tschofenig, H. ve E. Rescorla, "Datagram Taşıma Katmanı Güvenliği (DTLS) Kullanılarak Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) Güvenlik Bağlamı Kurulması için Çerçeve", RFC 5763, DOI 10.17487/RFC5763, Mayıs 2010, https://www.rfc-editor.org/info/rfc5763.
[RFC5764] McGrew, D. ve E. Rescorla, "Güvenli Gerçek Zamanlı Taşıma Protokolü (SRTP) için Anahtarların Kurulmasına Yönelik Datagram Taşıma Katmanı Güvenliği (DTLS) Uzantısı", RFC 5764, DOI 10.17487/RFC5764, Mayıs 2010, https://www.rfc-editor.org/info/rfc5764.
[RFC6120] Saint-Andre, P., "Genişletilebilir Mesajlaşma ve Durum Protokolü (XMPP): Çekirdek", RFC 6120, DOI 10.17487/RFC6120, Mart 2011, https://www.rfc-editor.org/info/rfc6120.
[RFC6464] Lennox, J., Ed., Ivov, E. ve E. Marocco, "İstemciden Karıştırıcıya Ses Seviyesi Göstergesi için Bir Gerçek Zamanlı Taşıma Protokolü (RTP) Başlık Uzantısı", RFC 6464, DOI 10.17487/RFC6464, Aralık 2011, https://www.rfc-editor.org/info/rfc6464.
[RFC8828] Uberti, J. ve G. Shieh, "WebRTC IP Adresi İşleme Gereksinimleri", RFC 8828, DOI 10.17487/RFC8828, Ocak 2021, https://www.rfc-editor.org/info/rfc8828.
[SDP4WebRTC] Nandakumar, S. ve C. Jennings, "WebRTC için Açıklamalı Örnek SDP", Çalışma Aşamasında, Internet-Draft, draft-ietf-rtcweb-sdp-14, 17 Aralık 2020, https://tools.ietf.org/html/draft-ietf-rtcweb-sdp-14.
[TS26.114] 3GPP, "3. Nesil Ortaklık Projesi; Teknik Şartname Grubu Hizmetler ve Sistem Yönleri; IP Multimedya Alt Sistemi (IMS); Multimedya Telefonisi; Medya işleme ve etkileşim (Sürüm 16)", 3GPP TS 26.114 V16.3.0, Eylül 2019, https://www.3gpp.org/DynaReport/26114.htm.
[W3C.webrtc] Jennings, C., Ed., Boström, H., Ed. ve J. Bruaroey, Ed., "WebRTC 1.0: Tarayıcılar Arası Gerçek Zamanlı İletişim", World Wide Web Consortium PR PR-webrtc-20201215, Aralık 2020, https://www.w3.org/TR/2020/PR-webrtc-20201215/.

#Ek A. SDP ABNF Sözdizimi

Bölüm 5.8'de gerçekleştirilen sözdizimi doğrulaması için aşağıdaki ABNF tanımları listesi kullanılır:

| Öznitelik | Referans | |---------------------------|-----------------------------| | ptime | [RFC4566] Bölüm 6 | | maxptime | [RFC4566] Bölüm 6 | | rtpmap | [RFC4566] Bölüm 6 | | recvonly | [RFC4566] Bölüm 9 | | sendrecv | [RFC4566] Bölüm 9 | | sendonly | [RFC4566] Bölüm 9 | | inactive | [RFC4566] Bölüm 9 | | fmtp | [RFC4566] Bölüm 9 | | rtcp | [RFC3605] Bölüm 2.1 | | setup | [RFC4145] Bölüm 4 | | fingerprint | [RFC8122] Bölüm 5 | | rtcp-fb | [RFC4585] Bölüm 4.2 | | extmap | [RFC5285] Bölüm 7 | | mid | [RFC5888] Bölüm 4 | | group | [RFC5888] Bölüm 5 | | imageattr | [RFC6236] Bölüm 3.1 | | extmap (şifreleme seçeneği)| [RFC6904] Bölüm 4 | | candidate | [RFC8839] Bölüm 5.1 | | remote-candidates | [RFC8839] Bölüm 5.2 | | ice-lite | [RFC8839] Bölüm 5.3 | | ice-ufrag | [RFC8839] Bölüm 5.4 | | ice-pwd | [RFC8839] Bölüm 5.4 | | ice-options | [RFC8839] Bölüm 5.6 | | msid | [RFC8830] Bölüm 3 | | rid | [RFC8851] Bölüm 10 | | simulcast | [RFC8853] Bölüm 5.1 | | tls-id | [RFC8842] Bölüm 4 |

Tablo 1: SDP ABNF Referansları

RFC 8829

JavaScript Oturum Kurulum Protokolü (JSEP)

#Özet

#1. Giriş

1.1. JSEP’in Genel Tasarımı

1.2. Değerlendirilen Diğer Yaklaşımlar

1.3. Yalnızca bundle için olan "m=" bölümleriyle ilgili çelişki

#2. Terimler

#3. Anlamsal Yapı ve Sözdizimi

3.1. Sinyalleşme Modeli

3.2. Oturum Tanımları ve Durum Makinesi

3.3. Oturum Tanımı Biçimi

3.4. Oturum Tanımı Denetimi

3.4.1. RtpTransceivers

3.4.2. RtpSenders

3.4.3. RtpReceivers

3.5. ICE

3.5.1. ICE Toplama Genel Bakış

3.5.2. ICE Adayı Damlatma

3.5.2.1. ICE Adayı Biçimi

3.5.3. ICE Aday Politikası

3.5.4. ICE Aday Havuzu

3.5.5. ICE Sürümleri

3.6. Video Boyutu Müzakeresi

3.6.1. imageattr Özniteliğinin Oluşturulması

3.6.2. imageattr Özniteliklerinin Yorumlanması

3.7. Simulcast

3.8. Forking ile Etkileşimler

3.8.1. Ardışık Forking

3.8.2. Paralel Forking

#4. Arayüz

4.1. PeerConnection

4.1.1. Yapıcı

4.1.2. addTrack

4.1.3. removeTrack

4.1.4. addTransceiver

4.1.5. onaddtrack Olayı

4.1.6. createDataChannel

4.1.7. ondatachannel Olayı

4.1.8. createOffer

4.1.9. createAnswer

4.1.10. SessionDescriptionType

4.1.10.1. Geçici Yanıtların Kullanımı

4.1.10.2. Geri Alma (Rollback)

4.1.11. setLocalDescription

4.1.12. setRemoteDescription

4.1.13. currentLocalDescription

4.1.14. pendingLocalDescription

4.1.15. currentRemoteDescription

4.1.16. pendingRemoteDescription

4.1.17. canTrickleIceCandidates

4.1.18. setConfiguration

4.1.19. addIceCandidate

4.1.20. onicecandidate Olayı

4.2. RtpTransceiver

4.2.1. stop

4.2.2. stopped

4.2.3. setDirection

4.2.4. direction

4.2.5. currentDirection

4.2.6. setCodecPreferences

#5. SDP Etkileşim Prosedürleri

5.1. Gereksinimlere Genel Bakış

5.1.1. Kullanım Gereksinimleri

5.1.2. Profil Adları ve Birlikte Çalışabilirlik

5.2. Bir Teklifin Oluşturulması

5.2.1. İlk Teklifler

5.2.2. Sonraki Teklifler

5.2.3. Seçeneklerin Ele Alınması

5.2.3.1. IceRestart

5.2.3.2. VoiceActivityDetection

5.3. Bir Cevap Üretme

5.3.1. İlk Cevaplar

5.3.2. Sonraki Yanıtlar

5.3.3. Seçeneklerin Ele Alınması

5.3.3.1. VoiceActivityDetection

5.4. Bir Teklifin veya Yanıtın Değiştirilmesi

5.5. Yerel Bir Tanımın İşlenmesi

5.6. Uzak Bir Tanımın İşlenmesi

5.7. Rollback İşlenmesi