SIP - Mobility إمكانية التنقل

التنقل الشخصي هو القدرة على الحصول على معرف ثابت عبر عدد من الأجهزة. يدعم SIP التنقل الشخصي الأساسي باستخدام طريقة التسجيل ، والتي تسمح للجهاز المحمول بتغيير عنوان IP الخاص به ونقطة الاتصال بالإنترنت ويظل قادرًا على استقبال المكالمات الواردة.

يمكن لـ SIP أيضًا دعم تنقل الخدمة - قدرة المستخدم على الاحتفاظ بنفس الخدمات أثناء التنقل

تنقل SIP أثناء التسليم (قبل المكالمة)

يربط الجهاز عنوان URI الخاص بجهة الاتصال بعنوان السجل عن طريق تسجيل رشفة بسيط. وفقًا لعنوان IP الخاص بالجهاز ، يصرح التسجيل بتحديث هذه المعلومات تلقائيًا في شبكة sip.

أثناء التسليم ، يقوم وكيل المستخدم بالتوجيه بين المشغلين المختلفين ، حيث يتعين عليه التسجيل مرة أخرى مع جهة اتصال باعتبارها AOR مع مزود خدمة آخر.

على سبيل المثال ، لنأخذ مثالاً على تدفق المكالمات التالي. UA الذي استلم مؤقتًا SIP URI مع مزود خدمة جديد. ثم يقوم UA بإجراء تسجيل مزدوج -

• التسجيل الأول هو مع مشغل الخدمة الجديد ، الذي يربط جهة الاتصال URI للجهاز بمزود الخدمة الجديد AOR URI.

• يتم توجيه طلب التسجيل الثاني مرة أخرى إلى مزود الخدمة الأصلي ويقدم AOR لمزود الخدمة الجديد باعتباره URI جهة الاتصال.

كما هو موضح لاحقًا في تدفق المكالمات ، عندما يأتي طلب إلى شبكة مزود الخدمة الأصلي ، تتم إعادة توجيه INVITE إلى مزود الخدمة الجديد الذي يقوم بعد ذلك بتوجيه المكالمة إلى المستخدم.

بالنسبة للتسجيل الأول ، ستكون الرسالة التي تحتوي على URI للجهاز -

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:UA1@registrar1.in> 
From: Tom <sip:UA1@registrar1.in>;tag = 72d65a24 
Call-ID: 4e719d1c1fc9000803630373300@172.22.1.102 
CSeq: 1 REGISTER 
Contact: <sip:Tom@172.22.1.102:5060> 
Expires: 600000 
Content-Length: 0

ستكون رسالة التسجيل الثانية مع URI المتجول -

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:UA1@registrar2.in> 
From: Tom <sip:UA1@registrar2.in>;tag = 45375 
Call-ID:87nr43i@172.22.1.102 
CSeq: 6421 REGISTER 
Contact: <sip:UA1@registrar2.in> 
Content-Length: 0

سيتم إرسال أول دعوة تم تمثيلها في الشكل أعلاه إلى sip: registrar2.in؛ سيتم إرسال الدعوة الثانية إلى sip: Tom@registrar2.in ، والتي سيتم إرسالها إلى sip: Tom@172.22.1.102 . يصل إلى توم ويسمح بإنشاء الجلسة. بشكل دوري ، يجب تحديث كلا التسجيلين.

التنقل أثناء المكالمة (إعادة الدعوة)

يجوز لوكيل المستخدم تغيير عنوان IP الخاص به أثناء الجلسة حيث ينتقل من شبكة إلى أخرى. يدعم SIP الأساسي هذا السيناريو ، حيث يمكن استخدام إعادة INVITE في مربع حوار لتحديث جهة الاتصال URI وتغيير معلومات الوسائط في SDP.

ألق نظرة على تدفق المكالمات المذكور في الشكل أدناه.

• هنا ، يكتشف توم شبكة جديدة ،

• يستخدم DHCP للحصول على عنوان IP جديد ، و

• يقوم بإجراء إعادة دعوة للسماح بتدفق الإشارات والوسائط إلى عنوان IP الجديد.

إذا كان بإمكان UA استقبال الوسائط من كلتا الشبكتين ، فإن المقاطعة لا تكاد تذكر. إذا لم يكن الأمر كذلك ، فقد يتم فقد بعض حزم الوسائط ، مما يؤدي إلى مقاطعة طفيفة للمكالمة.

ستظهر إعادة INVITE على النحو التالي -

INVITE sip:Jerry@TTP.com SIP/2.0  
Via: SIP/2.0/UDP 172.22.1.102:5060;branch = z9hG4bK918f5a84fe6bf7a 
Max-Forwards: 70 

To: <sip:Harry@TTP.com> 

From: sip:Tom@PPT.com;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

يحتوي re-INVITE على عنوان IP الجديد الخاص بـ Bowditch في حقلي العنوان Via and Contact ومعلومات وسائط SDP.

التنقل في Midcall (مع استبدال الرأس)

في التنقل أثناء المكالمة ، يجب تغيير مجموعة المسار الفعلي (مجموعة وكلاء SIP التي يجب أن تعبرها رسائل SIP). لا يمكننا استخدام إعادة INVITE في التنقل أثناء المكالمة

على سبيل المثال ، إذا كان الوكيل ضروريًا لاجتياز NAT ، فيجب تغيير جهة الاتصال URI - يجب إنشاء مربع حوار جديد. ومن ثم ، يتعين عليه إرسال دعوة جديدة برأس استبدال ، والذي يحدد الجلسة الحالية.

ملاحظة - افترض أن كلا من A و B في مكالمة وإذا حصل A على دعوة أخرى (دعنا نقول من C) برأس استبدال (يجب أن يتطابق مع مربع الحوار الحالي) ، فيجب على A قبول INVITE وإنهاء الجلسة مع B ونقل جميع الموارد إلى مربع حوار تم تشكيله حديثًا.

يظهر تدفق المكالمات في الشكل التالي. إنه مشابه لتدفق المكالمات السابق باستخدام إعادة الدعوة فيما عدا أنه يتم إنشاء BYE تلقائيًا لإنهاء مربع الحوار الحالي عند قبول دعوة مع البدائل.

فيما يلي النقاط التي يجب ملاحظتها في هذا السيناريو -

• يشتمل مربع الحوار الحالي بين توم وجيري على الخادم الوكيل القديم الذي تمت زيارته.

• يتطلب مربع الحوار الجديد الذي يستخدم الشبكة اللاسلكية الجديدة تضمين خادم الوكيل الجديد الذي تمت زيارته.

• ونتيجة لذلك ، أرسل توم رسالة دعوة مع بدائل ، مما يؤدي إلى إنشاء مربع حوار جديد يتضمن الخادم الوكيل الجديد الذي تمت زيارته وليس الخادم الوكيل القديم الذي تمت زيارته.

• عندما يقبل Jerry INVITE ، يتم إرسال BYE تلقائيًا لإنهاء مربع الحوار القديم الذي يوجه عبر الخادم الوكيل القديم الذي تمت زيارته والذي لم يعد مشاركًا في الجلسة الآن.

• يتم إنشاء جلسة الوسائط الناتجة باستخدام عنوان IP الجديد الخاص بـ Tom من SDP في INVITE.

تنقل الخدمة

يمكن تقديم الخدمات في SIP إما في وكلاء أو في UAs. يمكن أن يكون توفير إمكانية التنقل للخدمة جنبًا إلى جنب مع التنقل الشخصي أمرًا صعبًا ما لم يتم تكوين أجهزة المستخدم بشكل مماثل مع نفس الخدمات.

يمكن لـ SIP بسهولة دعم تنقل الخدمة عبر الإنترنت. عند الاتصال بالإنترنت ، لا يزال بإمكان UA المهيأ لاستخدام مجموعة من الوكلاء في الهند استخدام تلك الوكلاء أثناء التجوال في أوروبا. ليس له أي تأثير على جودة جلسة الوسائط لأن الوسائط تتدفق دائمًا بشكل مباشر بين اثنين من UAs ولا تعبر خوادم بروكسي SIP.

تتوفر الخدمات المقيمة في نقطة النهاية فقط عندما تكون نقطة النهاية متصلة بالإنترنت. ستفشل خدمة إنهاء مثل خدمة إعادة توجيه المكالمات المطبقة في نقطة نهاية إذا فقدت نقطة النهاية اتصالها بالإنترنت مؤقتًا. ومن ثم يتم تنفيذ بعض الخدمات في الشبكة باستخدام خوادم بروكسي SIP.