SIP - Mobilite
Personal mobilitybir dizi cihazda sabit bir tanımlayıcıya sahip olma yeteneğidir. SIP, bir mobil cihazın IP adresini ve İnternet bağlantı noktasını değiştirmesine ve yine de gelen aramaları alabilmesine olanak tanıyan REGISTER yöntemini kullanarak temel kişisel hareketliliği destekler.
SIP ayrıca şunları da destekleyebilir: service mobility - bir kullanıcının mobil haldeyken aynı hizmetleri sürdürme yeteneği
Devir Teslim Sırasında SIP Hareketliliği (Çağrı Öncesi)
Bir cihaz, Kontak URI'sini basit bir yudum kaydı ile kaydın adresi ile bağlar. Cihaz IP adresine göre, kayıt, bu bilgilerin sip ağında otomatik olarak güncellenmesine izin verir.
Devir sırasında, Kullanıcı aracısı, başka bir hizmet sağlayıcıya AOR olarak bir İrtibat Kişisine yeniden kaydolması gereken farklı operatörler arasında yol alır.
Örneğin, aşağıdaki çağrı akışının örneğini ele alalım. Yeni bir hizmet sağlayıcıyla birlikte geçici olarak yeni bir SIP URI almış olan UA. UA daha sonra çift kayıt gerçekleştirir -
İlk kayıt, cihazın İletişim URI'sini yeni hizmet sağlayıcısının AOR URI'sı ile bağlayan yeni hizmet operatörü ile yapılır.
İkinci REGISTER isteği orijinal hizmet sağlayıcıya geri yönlendirilir ve yeni hizmet sağlayıcının AOR'sini Contact URI olarak sağlar.
Çağrı akışında daha sonra gösterildiği gibi, orijinal servis sağlayıcının ağına bir talep geldiğinde, DAVET, aramayı kullanıcıya yönlendiren yeni servis sağlayıcıya yeniden yönlendirilir.
İlk kayıt için, cihaz URI'sini içeren mesaj şu olacaktır:
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: 0Gezici URI ile ikinci kayıt mesajı şöyle olacaktır -
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: 0Yukarıdaki şekilde gösterilen ilk DAVET, sip'e gönderilecektir: registrar2.in; ikinci DAVET, sip: sip: [email protected] adresine gönderilecek vesip:[email protected]. Tom'a ulaşır ve oturumun başlamasına izin verir. Her iki kaydın da düzenli aralıklarla yenilenmesi gerekir.
Çağrı Sırasında Hareketlilik (yeniden Davet)
Kullanıcı Aracısı, oturum sırasında bir ağdan diğerine geçerken IP adresini değiştirebilir. İletişim URI'sını güncellemek ve SDP'deki ortam bilgilerini değiştirmek için bir iletişim kutusundaki bir yeniden DAVET kullanılabileceğinden, Temel SIP bu senaryoyu destekler.
Aşağıdaki şekilde belirtilen çağrı akışına bir göz atın.
Burada Tom yeni bir ağ tespit ediyor,
Yeni bir IP adresi almak için DHCP kullanır ve
Yeni IP adresine sinyal ve ortam akışına izin vermek için bir yeniden DAVET gerçekleştirir.
UA, her iki ağdan da medya alabiliyorsa, kesinti ihmal edilebilir düzeydedir. Aksi takdirde, birkaç ortam paketi kaybedilebilir ve bu da aramada hafif bir kesintiye neden olabilir.
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:240Yeniden DAVET, Bowditch'in Via ve Contact başlık alanlarında ve SDP ortam bilgilerinde yeni IP adresini içerir.
Midcall'da Mobilite (Üstbilgi Değiştirme ile)
Çağrı ortası mobilitesinde, gerçek rota seti (SIP mesajlarının geçmesi gereken SIP vekilleri seti) değişmelidir. Çağrı ortası hareketliliğinde yeniden DAVET kullanamayız
Örneğin, NAT geçişi için bir proxy gerekliyse Contact URI değiştirilmelidir - yeni bir iletişim kutusu oluşturulmalıdır. Bu nedenle, mevcut oturumu tanımlayan bir Replaces başlığına sahip yeni bir INVITE göndermelidir.
Note - A & B'nin her ikisinin de bir çağrıda olduğunu ve A'nın başka bir INVITE aldığını (C'den diyelim) bir değiştirme başlığı (mevcut iletişim kutusu ile eşleşmelidir) aldığında, A'nın INVITE'ı kabul etmesi ve B ile oturumu sonlandırması ve tüm kaynağı yeni oluşturulan diyalog.
Çağrı akışı aşağıdaki Şekilde gösterilmektedir. Bu, Değiştirmelerle DAVET ET kabul edildiğinde mevcut diyaloğu sonlandırmak için otomatik olarak bir BYE oluşturulması dışında, yeniden DAVET kullanan önceki çağrı akışına benzer.
Aşağıda, bu senaryoda dikkat edilmesi gereken noktalar verilmiştir -
Tom ve Jerry arasındaki mevcut iletişim kutusu, ziyaret edilen eski proxy sunucusunu 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 DAVET gönderilir ve bu, ziyaret edilen yeni proxy sunucusunu içeren ancak ziyaret edilen eski proxy sunucusunu içermeyen yeni bir iletişim kutusu oluşturur.
Jerry, DAVETİ kabul ettiğinde, artık oturumda yer almayan eski ziyaret edilen proxy sunucusu üzerinden yönlendiren eski diyaloğu sonlandırmak için otomatik olarak bir BYE gönderilir.
Ortaya çıkan medya oturumu, Tom'un DAVET'teki SDP'den aldığı yeni IP adresi kullanılarak oluşturulur.
Servis Hareketliliği
SIP'deki hizmetler, proxy veya UA'larda sağlanabilir. Kişisel hareketliliğin yanı sıra hizmet hareketliliği sağlamak, kullanıcının cihazları aynı hizmetlerle aynı şekilde yapılandırılmadıkça 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şım sırasında bu proxy'leri kullanmaya devam edebilir. Medya her zaman doğrudan iki UA arasında aktığından ve SIP proxy sunucularından geçmediğinden, medya oturumunun kalitesi üzerinde herhangi bir etkisi yoktur.
Uç nokta yerleşik hizmetleri yalnızca uç nokta İnternet'e bağlı olduğunda kullanılabilir. Bir uç noktada uygulanan çağrı yönlendirme hizmeti gibi bir sonlandırma hizmeti, uç noktanın İnternet bağlantısını geçici olarak kaybetmesi durumunda başarısız olacaktır. Bu nedenle, bazı hizmetler SIP proxy sunucuları kullanılarak ağda uygulanır.