Daha ileri gitmeden önce, SIP’in transactional(işlemsel) bir protokol olduğunu anlamamız gerekir, yani, bileşenler arasındaki etkileşimler bir dizi mesaj alışverişinde gerçekleşir.
Transcation, SIP mesajlarının nasıl gönderildiği değil, bileşenlerin (SIP UA, Proxy) bir dizi mesaj alışverişini nasıl anladığı ve ilişkilendirdiği ile ilgilidir.
Özellikle, bir SIP transaction tek bir talepten ve bu talebe verilen yanıtlardan oluşur. İsteğin bir DAVET olması durumunda, transcation yalnızca son yanıt bir 2xx yanıtı değilse ACK’yi de içerir.
Biraz kafa karışıtırıcı gelebilir örnekle daha iyi anlayacaksınız. Şimdi lütfen resme bakın;
Bu yukarıdaki sip çağrısında 4 tane SIP transactions var.
T1: 1. DAVET ve bu DAVET’e verilen tüm yanıtlardan (100, 180, 200) oluşur, son yanıt 200 OK olduğundan, ACK T1 işleminin bir parçası olarak kabul edilmez.
T2: Sadece ACK
T3: 2. DAVET, bu DAVET’e (100, 405) diğer yanıtlar ve ACK’den oluşur. Bu yeniden INVITE arayan tarafından oluşturulur, T1 ve T2 tarafından kurulan oturumu değiştirmek ister, ancak arayan oturum değişikliğini kabul etmez.
T4: BYE işlemi, BYE isteğini ve yanıtını 200 Tamam içerir.
Şimdi herşey çok daha anlaşılır, ancak bileşenler bir iletinin belirli bir işleme ait olup olmadığını nasıl belirler? Benzersiz bir kimlik veya herhangi bir identifier var mıdır?
Çok iyi bir soru! Ve kısaca, Via header alanınındaki branch parameter işlemin tanımlayıcısıdr. Branch parametresindeki değer aynı ise aynı transaction’a ait bir işlemdir.
PEKİ SİP DİALOG NEDİR?
Dialog ise, bir süre devam eden iki UA arasındaki eşler arası SIP ilişkisidir. Dialog bir Call-ID, a local tag(from) and a remote tag(to) ile tanımlanır. Ayrıca ‘call leg ‘ olarakta adlandırılır.
SIP etiketleri hakkında tartışma, bu yayının kapsamı dışındadır. Gelecekte bunlar hakkında yazacağım. Ancak bu gönderiyi anlamak için dialog ID ile ilgili 3 önemli anahtarı not edin:
-İlk INVITE bir dialog oluşturur, From header’ daki “tag param” etiketini doldurur.
-180/200 , INVITE isteğine cevap vererek bir dialog oluşturur, To header’ daki “tag param” etiketini doldurur.
-Call-ID istekten yanıtlara kopyalanır.
Dialog ID ayrıca tüm yanıtlarla ve “to” field alanında tag içeren herhangi bir request ile ilişkilendirilir.
Şimdi ise bir örnekle SIP dialog ve transaction’ı bir örnekle gösterelim.
Aşağıda örnek SIP Paketleri gidiyor, sadece bu yazı için gerekli bilgileri ekliyorum. Via header ve dialog ID ((From Tag, To Tag, Call-ID) dikkat edin.
192.168.X.X: Caller and 192.168.X.Y: Called
192.168.X.X -> 192.168.X.Y
INVITE sip:[email protected] SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.r4rF5rlj~.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: sip:[email protected].
Call-ID: Iw0DFX6m8G.
192.168.X.Y -> 192.168.X.X
SIP/2.0 100 Trying.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.r4rF5rlj~.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: sip:[email protected].
Call-ID: Iw0DFX6m8G.
192.168.X.Y -> 192.168.X.X
SIP/2.0 180 Ringing.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.r4rF5rlj~.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
192.168.X.Y -> 192.168.X.X
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.r4rF5rlj~.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
192.168.X.X -> 192.168.X.Y
ACK sip:[email protected];transport=udp SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.arpMKt0Rt.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
Gördüğünüz gibi, INVITE, 100, 180, 200 aynı T1 işlemine aittir, çünkü Via header alanında aynı branch parametre değerine sahiptirler ve ACK T2 işlemine aittir. Ayrıca, 180 Zil sesinin aynı dialog ID’ye (Etiketten, Etikete, Arama Kimliğine) sahip olduğu için iletilerinin aynı iletişim kutusuna ait olduğu kabul edilir.
92.168.X.X -> 192.168.X.Y
INVITE sip:[email protected] SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.G-Vn8mI~f.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
192.168.X.Y -> 192.168.X.X
SIP/2.0 405 Method Not Allowed.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.G-Vn8mI~f.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
192.168.X.X -> 192.168.X.Y
ACK sip:[email protected];transport=udp SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.G-Vn8mI~f.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
Bu, bir oturum oluşturmak için kullanılan INVITE değil, oturumu değiştirmek içindir, çünkü önceden kurulmuş bir iletişim kutusunun içinde gönderilir ve tahmin edin ne oldu? Yukarıda açıkladığım gibi, callee oturum değişikliğini kabul etmez, bu nedenle mesajı 405 ile yok sayar. Onay mesajı iletişim kutusunun içinde de gönderilir.
Şimdi soruyorsunuz, INVITE, 405 ve bu ACK aynı transaction , çünkü Via headerdaki da branch paramater değeri aynı? Evet kesinlikle doğru!
Son olarak T4 transaction:
192.168.X.X -> 192.168.X.Y
BYE sip:[email protected] SIP/2.0.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.3s25Bh4OJ.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
192.168.X.Y -> 192.168.X.X
SIP/2.0 200 OK.
Via: SIP/2.0/UDP 192.168.X.X;branch=z9hG4bK.3s25Bh4OJ.
From: <sip:[email protected]>;tag=2qYQa0Dsb.
To: <sip:[email protected]>;tag=4m5692mHZNZpr.
Call-ID: Iw0DFX6m8G.
Bu, beklediğiniz gibi, her ikisi de aynı transcation olduğu gibi aynı zaman da aynı Dialog’dur.
SIP transcation and SIP dialog 5 SIP oluşturan 5 elementinden 2 tanesidir.