Bazen bir proxy sunucusu tek bir SIP çağrısını birden çok SIP uç noktasına iletir. Bu işlem forking olarak bilinir. Burada tek bir çağrı aynı anda birçok uç noktayı çalabilir.
SIP forking ile, masa telefonunuzun yazılım telefonunuzla veya cep telefonunuzdaki bir SIP telefonuyla aynı anda çalmasını sağlayarak aramayı her iki cihazdan da kolayca almanızı sağlar.
Genel olarak, bir ofiste, patronun çağrıyı seçemediğini veya uzatamadığını varsayalım, SIP çatallama, sekreterin uzantısını aramasına cevap vermesine izin verir.
Aldığı birçok vekilin gerçekleştirilmesi ve yanıt vermesi gerektiğinden durum bilgisi olan bir proxy varsa çatallama mümkün olacaktır.
İki çeşit forking vardır –
- Parallel Forking
- Sequential Forking
Paralel Forking
Bu senaryoda, proxy sunucusu INVITE’i bir seferde iki cihaza (UA2, UA3) çatacaktır. Her iki cihaz da 180 Zil sesi üretecek ve çağrıyı alan kişi 200 OK üretecektir. İlk önce Oluşturan’a ulaşan yanıt (varsayalım UA2) UA2 ile bir oturum oluşturacaktır. Diğer yanıt için bir İPTAL tetiklenir.
Sequential Forking
Bu senaryoda, proxy sunucusu INVITE’i bir aygıta (UA2) yerleştirir. UA2 o anda kullanılamıyorsa veya meşgulse, proxy onu başka bir cihaza (UA3) çatallar.
Branch – ID and Tag
Branch IDs, proxy’lerin forking isteklere verilen yanıtlarla eşleşmesine yardımcı olur. Branch IDs olmadan, bir proxy sunucusu forking yanıtı anlayamaz. Branch IDs Via üstbilgisinde bulunur.
Etiketler, UAC tarafından birden fazla nihai yanıtı farklı UAS’tan ayırmak için kullanılır. Bir UAS, isteğin forking olup olmadığını çözemez. Bu nedenle, bir etiket eklemesi gerekir.
Proxy’ler ayrıca son bir yanıt oluşturuyorsa etiket ekleyebilir, hiçbir zaman ilettikleri isteklere veya yanıtlara etiket eklemezler.
Tek bir isteğin birden çok proxy sunucusu tarafından da forking edilmesi de mümkündür. Böylece forking vekil kendi yarattığı şubelere kendi benzersiz kimliklerini ekleyecektir.
Call leg and Call ID
Call leg, iki kullanıcı aracısı arasında bire bir sinyal ilişkisine karşılık gelir. Çağrı kimliği, çağrıya gönderme yapan SIP mesajında taşınan benzersiz bir tanımlayıcıdır. Çağrı, Call leg yani çağrı bacaklardan oluşur.
Bir UAC, bir INVITE göndererek başlar. Forking nedeniyle, farklı ABD’lerden birden fazla 200 OK alabilir. Her biri aynı çağrı içindeki farklı bir çağrı ayağına karşılık gelir.
Bu nedenle bir çağrı, bir grup çağrı ayağıdır. Bir çağrı ayağı, UA’lar arasında uçtan uca bağlantı anlamına gelir.
Bir çağrı ayağının iki yönündeki CSeq boşlukları bağımsızdır. Tek bir yönde, sıra numarası her işlem için artırılır.
Sesli mesaj
Sesli mesaj, kurumsal kullanıcılar için günümüzde çok yaygındır. Bu bir telefon uygulaması. Aranan taraf müsait olmadığında veya çağrıyı alamadığında resme gelir, PBX sesli tarafı bırakmak üzere arayan tarafa duyurur.
Aranan tarafın numarasına erişilemiyorsa kullanıcı aracısı 3xx yanıtı alır veya sesli posta sunucusuna yönlendirir. Ancak, sesli posta sistemine hangi posta kutusunun kullanılacağını, yani hangi selamlamanın oynatılacağını ve kaydedilen mesajın nerede saklanacağını belirtmek için bir çeşit SIP uzantısı gereklidir. Bunu başarmanın iki yolu vardır –
-SIP başlık alanı uzantısı kullanarak
-Bu bilgiyi işaretlemek için Request-URI kullanarak
Kullanıcı yudumu için düşünün: [email protected], sip: voicemail.tutorialspoint.com adresinde sesli posta sağlayan bir sesli posta sistemine sahiptir, sesli posta sunucusuna yönlendirildiğinde INVITE’ın Request-URI’si şöyle görünebilir –
sip:voicemail.tutorialspoint.com;target =sip:[email protected];cause = 486
Aşağıdaki şekilde, İstek URI’sının posta kutusu tanımlayıcısını ve nedenini nasıl taşıdığı gösterilmektedir (burada 486).
