SIP – Mobility

Personal mobility, birçok cihazda sabit bir tanımlayıcıya sahip olma yeteneğidir. SIP, bir mobil cihazın IP adresini ve İnternete bağlantı noktasını değiştirmesine ve yine de gelen çağrıları alabilmesine olanak tanıyan REGISTER yöntemini kullanarak temel kişisel hareketliliği destekler.

SIP aynı zamanda servis hareketliliğini de destekleyebilir – bir kullanıcının mobil cihazdayken aynı servisleri tutma yeteneği

Aktarım Sırasında SIP Hareketliliği (Precall)
Bir cihaz, İletişim URI’sini basit bir yudum kaydı ile kayıt adresine bağlar. Cihazın IP adresine göre kayıt, bu bilgilerin yudum ağında otomatik olarak güncellenmesine izin verir.

Aktarım sırasında, Kullanıcı aracısı farklı operatörler arasında geçiş yapar ve burada başka bir servis sağlayıcı ile bir AOR olarak bir Kontakta tekrar kayıt yapmalıdır.

Örneğin, aşağıdaki çağrı akışı örneğini ele alalım. Geçici olarak yeni bir servis sağlayıcı ile yeni bir SIP URI’si alan UA. UA daha sonra çift kayıt yapar –

İlk kayıt, cihazın Servis URI’sini yeni servis sağlayıcının AOR URI’sine bağlayan yeni servis operatörü ile yapılır.

İkinci KAYIT isteği orijinal servis sağlayıcısına yönlendirilir ve yeni servis sağlayıcının AOR’sunu Kişi URI’sı olarak sağlar.

Çağrı akışında daha sonra gösterildiği gibi, orijinal servis sağlayıcının ağına bir istek geldiğinde, INVITE çağrıyı kullanıcıya yönlendiren yeni servis sağlayıcıya yönlendirilir.

İlk kayıt için, cihaz URI’sini içeren mesaj –

REGISTER sip:visited.registrar1.com SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK97a7ea349ce0fca 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 72d65a24 
Call-ID: [email protected] 
CSeq: 1 REGISTER 
Contact: <sip:[email protected]:5060> 
Expires: 600000 
Content-Length: 0 

Dolaşım URI’sı ile ikinci kayıt mesajı –

REGISTER sip:home.registrar2.in SIP/2.0 
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bKah4vn2u 
Max-Forwards: 70 
To: Tom <sip:[email protected]> 
From: Tom <sip:[email protected]>;tag = 45375 
Call-ID:[email protected] 
CSeq: 6421 REGISTER 
Contact: <sip:[email protected]> 
Content-Length: 0

Yukarıdaki şekilde temsil edilen ilk DAVET sip’e gönderilecektir: registerrar2.in; ikinci DAVET yudum: sip: [email protected]’e, yuduma iletilecek: [email protected]. Tom’a ulaşır ve oturumun kurulmasına izin verir. Periyodik olarak her iki kaydın da yenilenmesi gerekir.


Görüşme Sırasında Hareketlilik (Re-invite)
Kullanıcı Aracısı oturum sırasında IP adresini bir ağdan diğerine değiştirdiği için değiştirebilir. İletişim URI’sını güncellemek ve SDP’deki medya bilgilerini değiştirmek için bir iletişim kutusundaki yeniden INVITE kullanılabileceğinden, temel SIP bu senaryoyu destekler.

Aşağıdaki şekilde belirtilen çağrı akışına bir göz atın.

Tom burada yeni bir ağ tespit etti,

Yeni bir IP adresi almak için DHCP’yi kullanır ve

Sinyalizasyonun ve ortamın yeni IP adresine akışını sağlamak için bir yeniden INVITE gerçekleştirir.

UA her iki ağdan da medya alabiliyorsa, kesinti göz ardı edilebilir. Aksi takdirde, birkaç medya paketi kaybolabilir ve aramada hafif bir kesinti meydana gelebilir.


Yeniden DAVET aşağıdaki gibi görünecektir –

INVITE sip:[email protected] SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:[email protected]> 

From: sip:[email protected];tag = 70133df4 
Call-ID: 76d4861c19c 
CSeq: 1 INVITE 
Accept: application/sdp 
Accept-Language: en 

Allow: INVITE,ACK,CANCEL,BYE,INFO,OPTIONS,REFER,NOTIFY,SUBSCRIBE 
Contact: <sip:172.22.1.102:5060>; 
Content-Type: application/sdp 
Content-Length: 168 

v = 0
o = PPT 40467 40468 IN IP4 192.168.2.1 
s = - 
c = IN IP4 192.168.2.1 
b = AS:49 
t = 0 0 
b = RR:0 
b = RS:0 
a = rtpmap:97 AMR/8000/1 
m = audio 6000 RTP/AVP 96 
a = fmtp:102 0-15 
a = ptime:20 
a = maxptime:240

Yeniden INVITE, Via ve Contact üstbilgisi alanlarında ve SDP medya bilgilerinde Bowditch’in yeni IP adresini içerir.

Ara Çağrıda Hareketlilik (Header değiştirerek)
Orta çağrı hareketliliğinde, gerçek yol kümesi (SIP mesajlarının geçmesi gereken SIP proxy seti) değişmelidir. Ara çağrı hareketliliğinde yeniden INVITE kullanamayız

Örneğin, NAT geçişi için bir proxy gerekiyorsa, Kişi URI’sinin değiştirilmesi gerekir – yeni bir iletişim kutusu oluşturulmalıdır. Bu nedenle, varolan oturumu tanımlayan Replace üstbilgisiyle yeni bir INVITE göndermelidir.

Not – A & B’nin her ikisinin de bir çağrıda olduğunu ve A’nın yeni bir üstbilgiyle başka bir INVITE (diyelim C’den) aldığını varsayalım (mevcut iletişim kutusuyla eşleşmelidir), A’nın INVITE’i kabul etmesi ve oturumu B ile sonlandırması ve tüm kaynağı aktarması gerekir yeni kurulan diyaloğa.

Çağrı akışı aşağıdaki şekilde gösterilmiştir. Re-INVITE kullanan önceki çağrı akışına benzer, ancak Replace ile INVITE kabul edildiğinde mevcut iletişim kutusunu otomatik olarak sonlandırmak için otomatik olarak bir BYE oluşturulur.

Bu senaryoda dikkat edilmesi gereken hususlar aşağıda verilmiştir –

Tom ve Jerry arasındaki mevcut iletişim kutusu, ziyaret edilen eski proxy sunucuyu içerir.

Yeni kablosuz ağı kullanan yeni iletişim kutusu, ziyaret edilen yeni proxy sunucusunun dahil edilmesini gerektirir.

Sonuç olarak, Tom tarafından Değiştirilen bir INVITE gönderilir; bu, yeni ziyaret edilen proxy sunucusunu içeren, ancak eski ziyaret edilen proxy sunucusunu içermeyen yeni bir iletişim kutusu oluşturur.

Jerry DAVET’i kabul ettiğinde, artık oturumda yer almayan eski ziyaret edilen proxy sunucusu üzerinden geçen eski iletişim kutusunu sonlandırmak için otomatik olarak bir BYE gönderilir.

Ortaya çıkan medya oturumu, Tom’un INVITE içindeki SDP’nin yeni IP adresi kullanılarak oluşturulur.

Service Mobility
SIP’deki hizmetler proxy veya ABD’de sağlanabilir. Kişisel mobilite ile birlikte servis hareketliliği sağlamak, kullanıcının cihazları aynı servislerle aynı şekilde yapılandırılmadığı sürece zor olabilir.

SIP, İnternet üzerinden servis hareketliliğini kolayca destekleyebilir. İnternete bağlandığında, Hindistan’da bir dizi proxy kullanmak üzere yapılandırılmış bir UA, Avrupa’da dolaşırken bu proxy’leri kullanmaya devam edebilir. Medya her zaman doğrudan iki UA arasında aktığı ve SIP proxy sunucularını geçmediği için medya oturumunun kalitesi üzerinde herhangi bir etkisi yoktur.

Bitiş noktası yerleşik hizmetleri yalnızca bitiş noktası İnternet’e bağlı olduğunda kullanılabilir. Uç nokta Internet bağlantısını geçici olarak kaybederse, bir uç noktada uygulanan çağrı yönlendirme servisi gibi bir sonlandırma hizmeti başarısız olur. Bu nedenle bazı hizmetler ağda SIP proxy sunucuları kullanılarak uygulanır.

Leave A Comment