Evaluation of SIP signaling implementation using QoS parameters
Subject Areas : ICTmojtaba jahanbakhsh 1 , azharivs azharivs 2 , maryam homayooni 3 , Ahmad akbari 4
1 - University of Science and Technology
2 -
3 -
4 -
Keywords: computer network, multi- agent system, buffer, router, traffic shaping.,
Abstract :
Normal 0 false false false EN-US X-NONE AR-SA MicrosoftInternetExplorer4 !mso]> st1:*{behavior:url(#ieooui) } /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal" mso-tstyle-rowband-size:0 mso-tstyle-colband-size:0 mso-style-noshow:yes mso-style-priority:99 mso-style-qformat:yes mso-style-parent:"" mso-padding-alt:0cm 5.4pt 0cm 5.4pt mso-para-margin:0cm mso-para-margin-bottom:.0001pt mso-pagination:widow-orphan font-size:11.0pt font-family:"Calibri","sans-serif" mso-ascii-font-family:Calibri mso-ascii-theme-font:minor-latin mso-fareast-font-family:"Times New Roman" mso-fareast-theme-font:minor-fareast mso-hansi-font-family:Calibri mso-hansi-theme-font:minor-latin mso-bidi-font-family:Arial mso-bidi-theme-font:minor-bidi} Abstract The variety of services on IP networks and the need for network technology convergence have resulted in many access networks to adopt the IP technology. The Session Initiation Protocol (SIP) is an end to end application level protocol for establishing, terminating and modifying sessions and has experienced widespread use in IP networks due to its distinguished features such as being text based, independence from the underlying network, and more importantly supporting various types of mobility. In fact these features have lead SIP to be used as the core signaling protocol in the IP Multimedia Subsystem, which is the control plane proposed for next generation networks by the 3GPP community. Nevertheless, the performance of SIP servers when used by the millions of users of the next generation networks is not well established. In this paper we evaluate the performance of SIP servers using a test bed developed at the Iran University of Science & Technology. We consider eight different configurations for SIP server and also study the effect of using TCP and UDP as the transport protocol for SIP packets. We measure several parameters including call setup delay, call failure rate and SIP server throughput. Our results suggest that using SIP in large networks require using special techniques for balancing the load of SIP servers as well as mitigating temporary overloads.
مجتبی جهانبخش، سید وحید ازهری، مریم همایونی، احمد اکبری فصلنامه فنّاوري اطلاعات وارتباطات ایران، سال اول، شماره‌هاي 1و 2، پاييز و زمستان 1387
فصلنامه علمي-پژوهشي فنّاوري اطلاعات و ارتباطات ایران | سال اول، شماره‌هاي 1و 2، پاييز و زمستان 1387 صص: 41- 54 |
|
ارزیابی پیکربندیهای مختلف شبکه سیگنالینگ SIP با استفاده از اندازهگیری پارامترهای کیفیت برقراری تماس
مجتبی جهانبخش*1 سید وحید ازهری* مریم همایونی* احمد اکبری*
* دانشکده مهندسي کامپیوتر، دانشگاه علم وصنعت ایران
چکيده1
گستردگی و تنوع سرویسهای فراهم شده توسط شبکههای IP2 باعث شده تا انواع مختلف شبکههای دسترسی به سمت استفاده از این پروتکل حرکت کنند که این خود میتواند به مجتمع‌سازی شبکههای دسترسی مختلف کمک نماید. پروتکل SIP3 با توجه به امکاناتی چون متنی بودن، برقراری تماس انتهابهانتها، استقلال از نوع داده انتقالی و مهمتر از همه پشتیبانی از انواع جابجایی4، انتخاب مناسبی برای پروتکل سیگنالینگ جهت برقراری ارتباط بین دو کاربر شبکه IP است. این مزایا موجب شده تا SIP بهعنوان پروتکل سیگنالینگ درIMS 5، که بستر سیگنالینگ پیشنهادی برای شبکههای نسل آینده است، درنظرگرفته شود. با همه این مزایا، عملکرد دقیق این پروتکل در صورتی که توسط کاربران میلیونی شبکه مورد استفاده گسترده قرارگیرد، مشخص نیست. در این مقاله با استفاده از بستر تست توسعه داده شده، کارایی پروتکل SIP مورد ارزیابی دقیق قرار گرفته شده است و پارامترهایی چون تأخیر برقراری تماس، نرخ تماسهای ناموفق و بار پردازشی پروکسی6 در قالب هشت پیکربندی مختلف مورد بررسی قرار گرفته است. همچنین اثر نوع پروتکل لایه انتقال TCP و UDP روی کارایی SIP تحلیل شده است. نتایج بدست آمده از این بررسی نشان میدهد که استفاده از SIP در شبکههای بزرگ مستلزم بکارگیری تکنیکهایی جهت متعادل نمودن بار پروکسیها و همچنین جلوگیری از اضافه بارهای موقت میباشد.
کليد واژگان: SIP، ارزیابی کارایی، پیکره بندی،
مدیریت جابجایی
1- مقدمه
پروتكل SIP به منظور شروع، مدیریت و خاتمه نشست مابین دویا چند برنامه کاربردی مورد استفاده قرار میگیرد [1]. SIP پروتکلی از نوع مشتری- سرویسدهنده است. برنامههای کاربردی تماس گیرنده یا عاملهای کاربر در نقش مشتریها و پروکسیها به عنوان عناصری میانی به منظور مسیریابی پیامها در این پروتکل تعبیه شدهاند.
استفاده از SIP بخصوص برای مکالمات صوتی مبتنی بر VoIP از رشد روزافزونی برخوردار شده، تا آنجا که عملا SIP بهعنوان پروتکل سیگنالینگ درIMS ، که بستر سیگنالینگ پیشنهادی برای شبکههای نسل آینده است، درنظر گرفته شده است. دلایل استفاده روز افزون از SIP، قابلیتهای منحصر به فردی نظیر امکان تفکیک ترافیک سیگنالینگ از ترافیک داده‌ها، مستقل بودن پروتکل از محتوای پیامها و نیز نوع جلسه در حال تشکیل و متنی بودن پیامها میباشد. این مزایا SIP را قادر میسازد تا از انواع ارتباطات چند رسانهای چون مکالمات صوتی، تصویری، و نیز محاوره متنی در یک قالب واحد پشتیانی کند.
با این حال بارزترین مشخصه پروتکل SIP امکان پشتیبانی از جابجایی کاربر7، ترمینال8، سرویس9 و جلسه10 است. جابجایی کاربر به این معنی است که یک کاربر مشخص میتواند از هر نقطه دلخواه به شبکه وصل شده و از سرویسهای SIP از جمله دریافت تماس بهره ببرد، همانگونه که میتوان از هر نقطه به پست الکترونیکی خود دسترسی داشت. همچنین پروتکل SIP دارای مکانیزمهایی است که میتوان از آنها برای دستبهدستدهی11 ارتباط به هنگام جابجا شدن ترمینال بین دو شبکه استفاده نمود. با توجه به رشد چشمگیر استفاده از SIP، تحقیقات گستردهای روی کارایی این پروتکل انجام شده است.
SIPStone [2] مجموعه محکی12 است که درآن معیارهای متنوعی برای ارزیابی توان سرورهای پروکسی13، راهنما14 و ثبتکننده15 در پاسخگویی به درخواستهای SIP، پیشنهاد شده است. در [3] یک محک دیگر برای اندازهگیری اثر سیستمعامل، پیکربندی سختافزاری، پایگاهداده و لایه انتقال انتخابی در کارایی SIP ارائه شده است. در [4] روی چهار نوع پیادهسازی پروکسی که از لحاظ مدیریت رگه16 و روش تخصیص حافظه متفاوتند، آزمایشهای عملی انجام گرفته است. نتایج این آزمایشات نشان میدهد که پارامترهای موثر در کارایی پروکسی را میتوان به دو دسته تقسیم نمود: پارامترهای مرتبط با پروتکل، از قبیل طول پیام، متغیربودن طول و نامرتب بودن سربارها و پارامترهای مرتبط با نوع پیادهسازی سرور، مانند نحوه تخصیص منابع سیستم عامل به تراکنشها. همچنین در [5] نیز تحقیقات مشابهی در مورد اثر سیستم عامل و نوع پیادهسازی پروکسی روی کارایی SIP انجام شده است.
در [6] کارایی سیگنالینگ SIP در برقراری تماسهای VoIP با استفاده از JAIN SIP API و با در نظرگرفتن تاثیر مدت زمان مکالمه و نرخ تماسها روی تأخیر برقراری تماس بین دو عاملکاربر17 انتهابهانتها مطالعه شده است. در این تحقیق از پروکسی SIP استفاده نشده است و برای سیگنالینگ SIP از پروتکل لایه انتقال UDP استفاده شده است. در [7] با معرفی ابزاری تحت عنوان SIPPerfromer، تاثیر تأخیر پاسخ کاربر روی کارایی سرور SIP مورد تحلیل قرارگرفته است. در [8] با قراردادن تنها یک پروکسی بین عاملهای کاربر، مسائلی چون قابل توجه بودن هزینه امنیت در پیکربندی با تصدیقهویت، اثر حالتمند118بودن یا نبودن پروکسی و نوع پروتکل لایه انتقال روی کارایی پروکسی مورد مطالعه قرار گرفته است.
دستهای از پژوهشها بر ارزیابی کاراییSIP تحت تکنولوژیهای دسترسی مختلف متمرکز شدهاند. برای نمونه در [9] با استفاده از یک پروکسی، اثر تأخیر انتقال و گمشدن بستهها روی لینک W-CDMA، بررسی شده است. در [10] تأخیر سیگنالینگ SIP در برقراری جلسات IMS برای کانال های مختلف WiMax با سرعت‌های متفاوت ارزیابی شده است. همچنین برای کاهش حجم بستههای SIP و تأخیر ارسال آنها از تکنیکهای فشردهسازی روی پیامهای SIP استفاده شده است.
انتخاب پروتکل لایه انتقال نیز درکارایی سیگنالینگ SIP تاثیرگذار است. در [11] گزینههای مختلف در انتخاب پروتکل لایه انتقال برایSIP مورد بررسی کیفی قرار گرفته است. در [12] تاثیر بکارگیری پروتکلهای لایه انتقال مختلف، بخصوص تاثیر مکانیزم کنترل پنجره در TCP، روی گذردهی219 و تأخیر برقراری تماس مورد بررسی قرار گرفته است. در [13] نشان داده شده است که برخلاف تصور عام که علت استفاده متداول از UDP در برابر TCP را سربار پردازشی کم آن قلمداد میکنند، ممکن است نامطلوب بودن کارایی در استفاده از TCP ناشی از نحوه پیادهسازی پروکسی باشد.
دراین مقاله درنظرداریم به طور عمیقتری به تحلیل و بررسی تاثیرپذیری پارامترهای کیفیت تماس از پیکربندیهای مختلف پروکسی سرور SIP، پروتکل انتقال بکار رفته و فاصله طرفین تماس از یکدیگر بپردازیم. از اینرو با درنظر گرفتن یک سرور به ازای هر دامنه، هزینه فرایندهای امنیتی چون تصدیقهویت برای تمامی تماسهای برقرارشده و تاثیر حالتمند یا بدون حالت بودن سرور، در شرایطی که تمام تماسها محلی بوده و در داخل یک دامنه صورت می‌گیرند و نیز در حالتی که تماسها بین دامنهای هستند مورد مطالعه قرارگرفته است. به علاوه تاثیر انتخاب پروتکل لایه انتقال روی پارامترهای کیفیت تماس در هریک از سناریوهای فوق بررسی شده است. معیارهای کارایی درنظرگرفته شده دراین مقاله عبارتند از: تأخیر ایجاد تماس، گذردهی سرور، منابع پردازشی سرور و نرخ خطا در ایجاد تماس بهعنوان تابعی از میزان بار اعمال شده روی سرور.
دراین مقاله با آزمایش عملی تماسهای خارج دامنهای، نقش DNS بعنوان یک گلوگاه در اینگونه تماسها بررسی میشود و همچنین نحوه تخصیص حافظه برای پروکسیهای SIP جهت کمرنگ کردن اثر اضافه بار مطالعه شده است.
در ادامه این مقاله ابتدا به معرفی اجمالی پروتکل SIP پرداخته و به الگوهای متداول استفاده از SIP در قالب چند مثال اشاره شده است. در بخش3- بستر تست منطبق با الگوهای مذکور معرفی شده است. بخش 4- شامل نتایج حاصل از انجام آزمایشها به همراه تحلیل آنهاست. در پایان، بخش 5- به جمع بندی و نتیجه گیری مي‌پردازد.
2- مروری بر پروتکل SIP
پروتکل SIP یک پروتکل لایه کاربرد و مبتنی بر متن میباشد که برای مدیریت جلسات توسط IETF استاندارد شده است. معماری این پروتکل متشکل از دو نوع نهاد منطقی تحت عنوان عامل کاربر (UA) وسرور میباشد. عاملهای کاربر که خود به دوگروه عامل کاربر مشتری (UAC) وعامل کاربر سرویسدهنده (UAS) تقسیم میشوند به ترتیب به صدور درخواست و پاسخ می‌پردازند. سرورها نیز خود به چند دسته تقسیم میشوند. سرورهای ثبت کننده که وظیفه ثبت کردن کاربر را برعهده دارند و سرورهای راهنما با ارائه مکان‌های متعددی که ممکن است کاربر در آن جا باشد، به مکان یابی عامل کاربر SIP می‌پردازد و سرورهای پروکسی که بر خلاف سرور راهنما، خود به جستجوی کاربر مورد نظر مي‌پردازند و عملا مسیر یابی برای رساندن درخواستها به محل و کاربر مورد نظر، را بر عهده دارند. پروکسیها ممکن است بسته به شرایط و نیاز شبکه (که در بخش2-1- مفصلا به آن اشاره خواهد شد)، به صورتهای متفاوتی پیکربندی شوند. به عنوان مثال رفتار پروکسی با تراکنشهای SIP میتواند حالتمند یا بدونحالت20 باشد. منظور از تراکنش SIP، یک درخواست و تمامي پاسخهای مرتبط با آن است که بین دو عنصر مجاور SIP ردوبدل مي‌شود. پروکسی حالتمند، لازم است اطلاعات حالت21
شکل1: پیام های مبادله شده به منظور برقراری تماس درSIP
هر تراکنش را برای انجام برخی عملیات مانند ارسال مجدد احتمالی بستههای سیگنالینگ نگهداری کند. پروکسیهای SIP طوری طراحی شدهاند که میتوانند سابقه عملیات تراکنش به ازای هر درخواست را ثبت نمایند (حالتمند) یا سابقه را ثبت نکنند (بدون حالت) [14].
شکل1 روند برقراری تماس بین دو عامل کاربر را در حالتی که پروکسی میانی به صورت حالتمند پیکربندی شده است، نشان میدهد. همانطور که در این شکل مشاهده مي‌شود، اقدام به برقراری تماس با ارسال پیام INVITE از جانب یکی از طرفین تماس صورت میگیرد. با رسیدن این پیام به سرور، پاسخ 100 Trying به سمت عامل کاربر درخواست دهنده صادر شده و پیام INVITE او به طرف دیگر مکالمه باز ارسال122مي‌شود. با رسیدن پیامINVITE به شخص مورد نظر، پاسخ 180 Ringing و با برداشتن تلفن پیام پاسخ 200 OK از جانب وی ارسال میشود. در نهایت پس از ارسال ACK توسط طرف اول مکالمه تماس بین طرفین برقرار مي‌شود و از این پس پیامهای مکالمه بین طرفین، بدون عبور از سرورها مبادله مي‌شود. به همین ترتیب خاتمه دادن به تماس نیز با ارسال پیام BYE از سوی یکی از طرفین مکالمه و صدور پاسخ 200 OK توسط دیگری انجام میگیرد. لازم به ذکر است در صورتی که پروکسی بدون حالت پیکربندی شده باشد، تراکنشی روی پروکسی ساخته نمیشود و پروکسی تایمری را برای پیگیری حسن انجام سیگنالینگ کاربر و ارسالهای مجدد تنظیم نمی‌کند و در نتیجه پیام 100 Trying نیز از جانب پروکسی ارسال نمیشود.
[1] 1. نویسنده عهدهدار مکاتبات(m_jahanbakhsh@comp.iust.ac.ir)
[2] .Internet Protocol (IP)
[3] .Session Initionation Protocol (SIP)
[4] .Mobility
[5] .IP Multimedia Subsystem (IMS)
[6] .Proxy
[7] .Perssonal Mobility
[8] .Terminal Mobility
[9] .Service Mobility
[10] .Session Mobility
[11] .Handoff
[12] .benchmark
[13] .Proxy server
[14] .Redirect server
[15] .Registrar
[16] .Thread management
[17] .User Agent (UA)
[18] 1.stateful
[19] 2.Throughput
[20] .stateless
[21] .state
[22] 1.forward
در شرایطی که لازم باشد کاربر برای دریافت سرویس، احراز هویت شود پروکسی با تصدیق هویت پیکربندی خواهدشد ومطابق شکل3، پروکسی علاوه بر ایجاد تراکنش برای هر مکالمه، در پاسخ به INVITE اولیه پیام
407 Unauthorized را ارسال میکند تا مشتری را وادار به ارائه اعتبارنامه کند. سپس مشتری INVITE مجددی ارسال میکند که در سربارِ Authorization آن اعتبارنامهاش آمده است.
با توجه به استقلال پروتکل SIP از پروتکلهای لایه انتقال، پیامهایSIP میتوانند روی انواع پروتکلهای لایه انتقال اعم از TCP یا UDP منتقل شوند. با توجه به اینکه پروتکل انتقال پیش فرض،UDP است مکانیزم های ارسال مجددی درSIP تعبیه شده است که قادر است در صورت لزوم به جبران گم شدن بستهها بپردازد اما در مواردی که پروتکل انتقال، TCP باشد ارسال مجدد در لایه انتقال انجام میشود.
2-1- الگوهای متداول در استفاده ازSIP
شکل2 نحوه بکارگیری سرورهای SIP و سناریویهای مختلف برقراری تماس برای دو مرکز خدمات اینترنتی1 که سرویس VoIP مبتنی برSIP ارائه میدهند را نمایش میدهد. در این شکل:
· SIP Proxy Server/Registrar: مجموعاً سرور پروکسی SIP و سرور ثبت کننده میباشد که مسئول سرویس دهی به تماسهای درون مرزی12به درون مرزی و درون‌مرزی به برون مرزی23است.
· Proxy Server (Public): پروکسی سرور SIP است که مسئول تماسهای برون مرزی به درون مرزی میباشد و مسئولیت ثبت کردن کاربران را به عهده ندارد.
· Registery DB: پایگاه داده مربوط به کاربران ثبت شده است که با مرکز مربوطه ارتباط برخط34دارند.
· Subscriber Table/ My SQL DB: حاوی اطلاعات مربوط به مشترکین مرکز مربوطه است که لزوما دارای ارتباط برخط نیستند.
همانطور که در این شکل مشاهده مي‌شود وقتی امین میخواهد با اکرم با آدرس akram@iust.ir تماس بگیرد، پروکسی1 با پایگاه داده ثبت خود مشورت کرده و INVITE امین را به تلفن اکرم باز ارسال میکند. بطور کلی اگر دو طرف مکالمه در پایگاه داده یک سرور محلی ثبت شده باشند، سیگنالینگ مربوط به مکالمه آنها تنها از طریق پروکسی مربوط به همان دامنه مسیریابی میشود. مسیر سینگالینگ در این سناریو با خط چین کوتاه45نشانداده شدهاست.
هنگامیکه امین میخواهد با حسن که از مشتریان ISP دیگریست تماس بگیرد باید سیگنالینگ SIP از طریق پروکسی محلی امین (پروکسی شماره1) به پروکسی محلی حسن (پروکسی شماره3) و از آنجا به تلفن حسن ارسال شود. در این حالت دو پروکسی وظیفه برقراری تماس را بعهده دارند و بستههای سیگنالینگ از مسیر نشان داده شده با خط چین طولانی در شکل2 عبور خواهند کرد. از آنجا که در اینگونه تماسهای برون مرزی تعداد بیشتری پروکسی دخالت دارند تأخیر ایجاد تماس و همچنین احتمال ناموفق بودن تماس بیشتر از حالت تماسهای درون مرزی است.
تصدیقهویت عامل درخواست دهنده تماس، مسئله مهم دیگریست که باید مورد توجه قرار گیرد. اهمیت این قضیه از آن جهت است که باید هویت کاربر درخواست دهنده سرویس احراز شده، درصورتیکه مجاز به استفاده از آن سرویس میباشد به او اجازه شرکت در روند سیگنالینگ داده شود. برای مثال فرض کنید ISP1 برای مشتریان خودش اجازه تماس با شبکههای خارجی از جمله PSTN را فراهم کند. از آنجا که اتصال به شبکه خارجی نیازمند خرید پهنای باند است، این ISP میخواهد مطمئن شود تنها مشترکان خود او میتوانند تماسهای خارجی برقرار کنند. برای این کار کافیست پروکسی3 به هنگام گرفتن درخواست تماس از طرف یک مشتری مانند حسن به مقصدی چون سارا یا اکرم، از مشتری خود (حسن) تقاضای تصدیق هویت نماید اما اگر حسن تقاضای برقراری ارتباط با مشتری دیگری ازهمین ISP را داشته باشد دیگر نیازی به تصدیق هویت مجدد نخواهد بود. حتی در شرایطی برخی ISP ها بدلیل جلب مشتری اجازه میدهند که همه کاربران خارجی حتی اگر از مشترکان آنها نباشند، بتوانند با مشترکین ISP مذکور ارتباط برقرار نمایند. در چنین شرایطی تماسهایی که از خارج به داخل انجام میشوند نیازی به تصدیق هویت نخواهند داشت.
گاهی ممکن است تماسهای بین مشترکین یکISP که از طریق یک پروکسی مسیریابی میشوند نیز نیاز به تصدیق هویت داشته باشند. چنین سیاستی هنگامی اتخاذ میشود که شرکت سرویس دهنده تماس تلفنی (مثلا مبتنی بر VoIP) مستقل از ISP فراهم کننده اتصال شبکه است، باشد. از این دسته مثال های متنوعی وجود دارد که یک نمونه از آنها در[15] پیادهسازی شده است. در شکل3 نمونهای از سیگنالینگ مربوط به برقراری تماس با تصدیق هویت نشان داده شده است.
شکل3: سناریوی یک پروکسی همراه با تصدیق هویت
همانطورکه پیش از این اشاره شد، مسأله مهم دیگر در پیکر بندی پروکسی سرور SIP، بدونحالت یا حالتمند بودن آن در رابطه با تراکنشهای SIP است. پردازش پیام ها در پروکسی حالتمند شامل ایجاد، جستجو، به روز رسانی و حذف حالت تراکنش، و ایجاد و تنظیم چندین تایمر به ازای هر تراکنش میباشد. بنابراین هر درخواستی که به صورت حالتمند توسط پروکسی پردازش مي‌شود در مقایسه با بدون حالت، نیازمند حافظه بیشتر، زمان پردازش بیشتر در CPU، رسیدگی به تایمر و به طور خلاصه صرف منابع بیشتری میباشد.
اگرچه در نگاه اول به نظر میرسد استفاده تام از پروکسیهای بدونحالت سبب افزایش گذردهی پروکسی خواهد شد، اما برای مثال وقتیکه نرخ گم شدن بسته روی لینکهای شبکه ناچیز نباشد، استفاده از پروکسیهای بدونحالت که قادر به ارسال مجدد نیستند، سبب به طول انجامیدن زمان برقراری تماس خواهد شد [14]. معمولا پروکسیهایی که مسئولیتهایی چون انشعاب6، پیمایش NAT، رسیدگی به ارسال مجدد پیام، یافتن کاربر، و محاسبه صورت حساب را به عهده دارند حالتمند و پروکسیهایی که تنها مسئول اعمالی چون توزیع بار و ترجمه و باز ارسال کردن پیامها هستند، بدون حالت تنظیم مي‌شوند [16]. یکی از بهینه سازیهای ممکن این است که پروکسی با توجه به نوع درخواست، میزان بار CPU و کیفیت لینک، تنها برای برخی از پیامهای SIP (برای مثال INVITE و BYE) ایجاد تراکنش نموده و حالتمند عمل کند [14] و در مقابل هنگامیکه نرخ گم شدن بستهها ناچیز باشد یا اینکه سیگنالینگ SIP از طریق TCP که یک سرویس انتقال تضمین شده است انجام شود حالت نگهداری نشود.
شکل4: بستر تست برای آزمایش با یک پروکسی
دربخش بعدی بستر تست فراهم شده برای ارزیابی کارایی SIP و بررسی معیارهای ارزیابی این پروتکل از جمله تأخیر برقراری تماس و گذردهی پروکسی معرفی شده و سناریوهایی که تست آن ها به یک ارزیابی فراگیر از پروتکل SIP منجر مي‌شود توضیح داده شده است. در ادامه، در بخش 4- نتایج حاصل از بررسی کارایی SIP تحت پیکربندی های مختلف در حالاتیکه کلیه تماسها داخل دامنه ای و خارج دامنه ای هستند ارائه شده است. همچنین در در بخش 4- اثر بکارگیری هریک از پروتکل های لایه انتقال در کارایی SIP تحلیل شده است.
3- معرفی بستر و سناریوهای آزمایش
ساختار کلی بستر تست بکار رفته برای سناریوهایی که تمامی تماسها درون مرزی (یک پروکسی) و یا برون مرزی
(دو پروکسی) هستند به ترتیب در شکل4 و شکل5 نشان داده شده است. جهت پیادهسازی موجودیتهای سرور از نرم افزار openSER [17] استفاده شده است و هر یک از سرورها بهترتیب روی یک PC با پردازنده INTEL Dual Core 2.8GHz و 2.0GHz و حافظه 1.5GB و 2.0GB نصب شده اند. همچنین برای عاملهای کاربر که وظیفه تولید ترافیک SIP را دارند از نرمافزار SIPp [18] روی PC هایی با پردازنده Intel Pentium4 2.8GHz و حافظه 1.0GB استفاده شده است.
تمامی کامپیوترهای بستر تست از سیستم عامل لینوکس فدورا نسخه 9 استفاده میکنند. برای بررسی زمان و نوع پیامهای ارسالی و دریافتی توسط کاربرها از گزارشاتی که SIPp تولید میکند استفاده شده است. همچنین از گزارشات نرم افزار openSER برای اندازهگیری وضعیت پیشرفت تماسها و تراکنشهای روی پروکسی استفاده شده و نرمافزار oProfile نیز جهت اندازه گیری بار پردازشی پروکسی بکار رفته است.
شکل5: بستر تست برای آزمایش با دو پروکسی
پیکربندیهای مورد مطالعه در این دو ساختار در جدول1 نشان داده شده اند. در هر دو سناریوی شامل یک و دو پروکسی کلیه پیکربندیهای فوق در حالتی که پروتکل لایه انتقال TCP یا UDP باشد تست و مورد مقایسه قرار گرفتهاند.
جدول1: سناریو های آزمون و پیکربندی های مربوطه
پیکربندی نام سناریو | تصدیق هویت | حالتمند |
WA-SF7 | ü | ü |
WA-SL8 | ü | û |
NA-SF9 | û | ü |
NA-SL10 | û | û |
4- تحلیل نتایج ارزیابی کارایی SIP
معیارهای متعددی برای تعیین کارایی SIP وجود دارد [19] که از این میان، ما در این پژوهش روی تأخیر برقراری تماس (زمان بین ارسال INVITE از طرف UAC تا زمان دریافت OK از پروکسی)، نرخ ارسال مجدد و گذردهی پروکسی (تعداد تماسهای موفق در واحد زمان) متمرکز شدهایم. ابتدا در بخش 4-1- به بررسی کارایی پروکسی تحت پیکربندیهای گوناگون در حالتی که کاربرها درون مرزی هستند و برقراری تماس بینشان از طریق یک پروکسی صورت میگیرد پرداخته شده است. در بخش
4-2- با این فرض که دو پروکسی بین طرفین تماس واقع شده است، به بررسی نتایج در تماسهای برون مرزی میپردازیم و در نهایت این بخش را با بررسی اثر بکارگیری پروتکلهای لایه انتقال TCP و UDP و مقایسه مزایا و معایب هریک به پایان میرسانیم.
4-1- ارزیابی کارایی پروکسی درتماسهای درون مرزی
در این بخش به بررسی عوامل تاثیر گذار بر کارایی یک پروکسی SIP مي‌پردازیم. همانطور که قبلا اشاره شد مطابق شکل4 بار سیگنالینگ توسط دو عامل کاربر UAC و UAS تولید میشود. نرخ تولید مکالمه از مقدار کم 100 تماس در ثانیه شروع شده و تا نرخ مکالمه سنگین 2000 تماس در ثانیه ادامه مییابد. در این حالت تنها یک پروکسی به مسیریابی تماسها رسیدگی میکند.
شکل6 میانگین زمان برقراری تماس برای چهار پیکربندی را نشان میدهد. با مقایسه منحنیهای این شکل میتوان نتیجه گرفت که هزینه انجام تصدیق هویت در پروکسی نسبتا زیاد است. برای مثال تحت بار میانهای چون 800 تماس بر ثانیه، تأخیر برقراری تماس در پیکربندیهای بدون تصدیق هویت حدودا 2 میلی ثانیه است که کمتر از نصف تأخیر پیکربندیهای دارای تصدیق هویت با تأخیر بیش از 4 میلی ثانیه میباشد. این تفاوت همانطور که ملاحظه میشود در بارهای بالاتر بسیار قابل ملاحظه است تا جاییکه وقتی نرخ تماس 1200 در ثانیه میشود تأخیر ایجاد تماس برای پیکربندی WA-SF به بالای 4 ثانیه میرسد.
شکل6 همچنین اثر بدون حالت و یا حالتمند بودن پروکسی را در تأخیر برقراری تماس نشان میدهد. با مقایسه نمودارهای مربوط به پیکربندی NA-SF و NA-SL واضح است که پیکربندی حالتمند سبب افزایش تأخیر ایجاد تماس میشود. دلیل این مسئله مصرف حافظه و منابع پردازشی بیشتر توسط پروکسی برای ایجاد تراکنش برای هر مکالمه میباشد. البته همانطور که در منحنیها نیز مشهود است، هزینه حالتمند رفتارکردن پروکسی بسیار کمتر از پشتیبانی از تصدیق هویت میباشد. این مطلب از روی ناچیز بودن تفاوت میان منحنیهای تأخیر WA-SF و WA-SL مشهود است. اثر حالتمند رفتار کردن پروکسی تنها در بارهای زیاد قابل توجه است. برای مثال منحنیهای پیکربندی NA-SF و NA-SL در بارهای میانه و کم تأخیری تقریبا مساوی دارند، در حالیکه برای بارهای بیش از 1000 تماس در ثانیه، تأخیر پیکربندی NA-SF نزدیک به
ده برابر NA-SL میباشد که دلیل این مسئله در تنگنا قرار گرفتن پروکسی از لحاظ بار پردازشی و حافظه برای ذخیره‌سازی حالت یک تراکنش در پیکربندی حالتمند است.
پدیده بارز دیگری که دراین شکل مشاهده میشود جهش تأخیر برقراری تماس برای بارهای بیش از یک حد آستانه مشخص است. در پیکربندیهایی که پروکسی از تصدیق هویت پشتیبانی میکند، مقدار این آستانه کوچکتر و درحدود 1100 تماس برثانیه میباشد و مقدار جهش نیز بسیار بزرگ است
شکل6: میانگین زمان برقراری تماس برای پیکربندی های مختلف
بطوریکه تأخیر برقراری تماس برای بار 1200 تماس بر ثانیه به بیش از 3 ثانیه میرسد. به طور کلی علت این افزایش تأخیر را میتوان ناشی از بالارفتن بار پردازشی CPU، کمبود حافظه جهت ایجاد تراکنش و گم شدن بستهها بدلیل کمبود فضا در بافرهای سیستم عامل و بافر پروتکل SIP و در نتیجه افزایش احتمال ارسال مجدد هر پیام دانست. دلیل جهش بسیار فاحش تأخیر در پیکربندی با تصدیق هویت اینست که به ازای هر تماس یکبار دسترسی به پایگاه داده کاربران انجام میشود، که در بار زیاد این دسترسی به گلوگاه سیستم تبدیل میشود. در ادامه به بررسی موارد مطرح شده خواهیم پرداخت.
شکل7 گذردهی پروکسی را نشان میدهد. در این شکل تعداد تماسهای برقرار شده در واحد زمان برحسب نرخ درخواست تماس برای چهار پیکربندی مختلف ترسیم شده است. همانگونه که ملاحظه میشود در پیکربندیهای مشتمل بر تصدیق هویت بیشترین گذردهی پروکسی در نرخ تماس 1100 بدست میآید که متناظر با پرش قابل ملاحظه تأخیر نشان دادهشده در شکل8 میباشد. از این پس با افزایش بار، گذردهی پروکسی متناسب با بار ورودی افزایش نمییابد که این به معنی عدم موفقیت پروکسی در برقراری برخی تماسهاست. همانطور که در این شکل مشهود است، پیکربندیهای بدون تصدیق هویت از گذردهی بالاتری برخوردار هستند.
شکل7: گذردهی پروکسی درحالت تک پروکسی
شکل8: گذردهی پروکسی برحسب تأخیر برقراری
تماس برای حالت تک پروکسی
نکته قابل ملاحظه دیگر اینست که با عبور بار از آستانه مشخصی، گذردهی پروکسی نه تنها افزایش نمییابد بلکه کاهش نیز مییابد. به عبارت دیگر پروکسی دیگر حتی قادر نیست با همان ظرفیت گذشته خود تماسها را سرویس دهد، بلکه با افزایش بار ظرفیت پروکسی کاهش می یابد.
بررسیهای بعمل آمده روشن ساخت که این پدیده بدلیل انباشتگی بافرهای پروکسی با بستههای SIP میباشد که پس از مدتی باعث سرریز شدن آنها و بالا رفتن نرخ گم شدن بستهها و درنتیجه ناموفق بودن تماسها میشود. شکل8 نیز بر این مطلب صحه می‌گذارد زیرا نشان میدهد با عبور بار ورودی از یک آستانه مشخص، گذردهی شروع به کاهش میکند اما تأخیر همچنان افزایش مییابد. این افزایش تأخیر بدلیل گم شدن بستههای ارسالی از طرف کاربران است که منجر به ارسال مجدد بستهها پس از انقضای تایمر SIP میشود و این خود باعث جهش تأخیر ایجاد تماس است. شاید در وهله اول اینطور به نظر برسد که با افزایش بافر پروکسی میتوان از این مسأله جلوگیری نمود اما واقعیت آنست که با بیشتر شدن بار ورودی از ظرفیت پروکسی، مقدار بافر هر قدر هم که باشد در مدتی محدود پرخواهد شد. بنابراین باید سعی شود تا اساسا باری بیش از ظرفیت پروکسی به آن تحمیل نشود.
ارسال مجدد پیامها نه تنها باعث عدم موفقیت برخی تماسها میشود بلکه حتی اگر تماس هم موفقیت آمیز باشد برقراری آن به اندازه چند دوره انقضای تایمر SIP طول خواهد کشید که سبب افزایش تأخیر ایجاد تماس میشود. از طرف دیگر با افزایش تأخیر ایجاد تماس، تایمرهای عامل های کاربر منقضی شده و نرخ ارسال مجدد افزایش مییابد که این به نوبه خود باعث افزایش تأخیر، سرریز بیشتر بافر پروکسی و درنتیجه احتمال بیشتر گم شدن بستهها میشود. همانطور که ملاحظه میکنید فیدبک مثبت ایجاد شده در سیستم باعث افت ناگهانی گذردهی پروکسی و جهش تأخیر ایجاد تماس میشود.
شکل9: تقاضاها و جوابهای دریافتی در سرور پروکسی
شکل9 تعداد درخواستها و پاسخهای دریافت شده توسط پروکسی را نشان میدهد. دقت در این شکل صحت مطالب فوق در زمینه اثر مخرب ارسالهای مجدد را روشن میکند. با توجه به این شکل، با وجود تصدیق هویت از نرخ 1100 به بعد، منحنی دریافت تقاضاها (که با خط ممتد نشان داده شده است) بدلیل افزایش ناگهانی ارسالهای مجدد دچار یک جهش میشود. این افزایش ناگهانی تعداد تقاضاهای دریافتی، موجب سرریز شدن بافر ورودی پروکسی میشود که باعث گم شدن برخی بستهها و درنتیجه سبب عدم پردازش برخی از تماسها و کاهش تعداد پاسخهای دریافتی در پروکسی میشود (نقطه چین). درحقیقت علت کاهش گذردهی پروکسی در بارهای زیاد (شکل7) نیز همین کاهش تعداد جلسات موفق است.
هنگامی که سرور تصدیق هویت نمی نماید از نرخ 1200 تا 1600 هر دو منحنی دریافت تقاضا و پاسخ با اندکی افزایش مواجه میشوند. در حقیقت در این نرخها سرور در مرحله پیگیری تماسها دچار مشکل میشود (و نه در مرحله تجزیه کردن پیام) و پاسخهای (OK) نیز مجددا ارسال مي‌شوند. در نرخ 1700و 1800 بالاترین نرخ ارسال مجدد تقاضا را داریم اما با توجه به درصد بالای ناموفقیت تماسها، پروکسی اغلب اوقات درگیر تجزیه تماسها و اختصاص تراکنش برای پیگیری تماسهاست. بنابراین تماسهای موفق میانگین زمان برقراری تماس بالایی دارند و همچنین تماسهای زیادی ناموفق تمام میشوند. شایان ذکر است که در آزمایشات مربوط به تصدیق هویت، مقدار حافظه اختصاصی بقدر کافی درنظر گرفته شده تا قبل از اینکه پردازنده به اشباع برسد، کمبود حافظه برای ایجاد تراکنش هر تماس رخ ندهد.
در موارد بدون تصدیق هویت، تعداد پیامها به ازای هر تماس کمتر است. از طرف دیگر فرایند MySQL نیز اجرا نشده و بنابراین تماسهای بیشتری توسط OpenSER پردازش 
شکل10: درصد استفاده از پردازنده در پروکسی
برای پیکربندی WA_SF
مي‌شوند تا آنجا که برای نرخ تماسهای زیاد مشکل کمبود حافظه پیش میآید. در چنین شرایطی سرور با ارسال خطای 500، تعدادی از تماسها را ناموفق می‌گذارد.
4-1-1- منابع پردازشی وحافظهای پروکسی
در این بخش اثر محدودیت حافظه و پردازنده را بر کارایی پروکسی بررسی میکنیم. در این آزمایشات 512 مگابایت حافظه به OpenSER تخصیص داده شده، سپس میزان حافظه استفاده شده در طول زمان تست نیز مانیتور شده است. همچنین تعداد پیامهای ارسالی، دریافتی و حذف شده از بافر SIP نیز مانیتور شدهاند.
درشکل10 منابع پردازشی استفاده شده در پروکسی حالتمند با تصدیق هویت نشان داده شده است. همانطور که مشاهده مي‌شود، با افزایش نرخ تماس، درصد استفاده از CPU توسط OpenSER و MySQL که بهترتیب عهدهدار پردازش بستههای SIP و مدیریت پایگاه داده کاربران هستند، افزایش مییابد تا اینکه در نرخ حدود 1100 (قبل از جهش نمودار میانگین زمان برقراری تماس) کارایی پردازنده تقریبا به 100% میرسد. از این پس با افزایش بار منابع پردازشی بیشتری به این دو فرایند اختصاص نمی یابند که در نتیجه این امر، از این نرخ به بعد، تأخیر برقراری تماسها شدیدا افزایش مییابد.
درشکل11 حداکثر میزان حافظه اشتراکی استفاده شده در پروکسی نشان داده شده است که بطور طبیعی تابعی صعودی از نرخ تماس است. در منحنی نقطهچین که پروکسی باتصدیق هویت و حالتمند است، درنرخ 1200 و 1300 تماس در ثانیه استفاده ازحافظه به بالاترین حد خود رسیده است. در این دوحالت سرور تقاضاهای بسیاری را تجزیه میکند و برای آنها ایجاد تراکنش می‌نماید، اما بدلیل کمبود 
شکل11: حداکثر میزان حافظه استفاده شده توسط فرایند OpenSER
منابع پردازشی، زمان برقراری تماس بسیار بالاست و تعدادی از تماسها با شکست مواجه میشوند. با بالاتر رفتن نرخ ایجاد تماس قسمت اعظم پیامها یا INVITE هستند و یا ارسال مجدد آن. درنتیجه پروکسی بیشتر درگیر تجزیه تماسها و انجام عملیات مربوط به تصدیق هویت و ارتباط با پایگاه داده است. بنابراین پیامهای کمتری به فاز تخصیص تراکنش و ارسال به مقصد می‌رسند که این منجر به کاهش حافظه مورد استفاده توسط پروکسی میشود. در منحنی بدون تصدیق هویت و حالتمند حافظه پروکسی در نرخهای بالاتر از 1800 تماس بر ثانیه به حد اشباع میرسد. در این وضعیت تعداد تراکنشهای فعال بسیار بالا میرود (بالغ بر70000) و چون سرور حافظه کافی برای تماسهای جدید ندارد با خطای 500 که به منزله خطای داخلی سرور است کاربرهای جدید را از اصرار بر تقاضای تماس منصرف میکند. همچنین با پرشدن حافظه پروکسی بر تعداد بستههای گم شده نیز افزوده میشود.
این دو نمودار نشان میدهند که کارایی پروکسی متاثر از دو عامل است: مقدار حافظه تخصیص یافته به آن و قدرت پردازشی پردازنده‌ای که پروکسی بر روی آن اجرا میشود. همانطور که ملاحظه شد اشباع پردازنده و کمبود حافظه هر دو باعث افت شدید کارایی پروکسی مي‌شوند. شایان ذکر است با محدود نمودن حافظه اختصاص داده شده به پروکسی میتوان آن را از قبول تماسهای بیش از ظرفیتش بازداشت. در چنین شرایطی پردازنده پروکسی هیچگاه به حد اشباع نخواهد رسید و با ارسال بسته 500 از جانب پروکسی تماسهای اضافی به وجود نمی‌آید. البته ذکر این نکته ضروری است که این سیاست تا حد مشخصی کارایی پروکسی را بهبود میدهد و با بالا رفتن نرخ تماسها پردازنده پروکسی که ناگزیر است تمامی بستههای دریافتی را جهت اطلاع از محتویات آنها تجزیه 
شکل12: بررسی میانگین زمان برقراری تماس با انجام DNS
نماید باز هم به اشباع خواهد رسید، اگرچه این رخداد تحت بارهای بالاتری اتفاق خواهد افتاد.
4-2- ارزیابی کارایی در تماسهای برون مرزی با وجود دو پروکسی
هنگامی که تماسها برون مرزی باشند مسیر سیگنالینگ بین پروکسی های مربوط به هر دامنه خواهد بود. مطابق شكل5 بار سیگنالینگ توسط دو عامل کاربر UAC و UAS تولید میشود. نرخ تولید مکالمه از مقدار کم شروع شده و تا نرخ مکالمه سنگین ادامه می یابد. وقتی که یک تقاضای خارج دامنهای به پروکسی میرسد، پروکسی ابتدا با ارسال تقاضای DNS، آدرس IP پروکسی شبکه مقصد را پیدا می کند و در ادامه تقاضا را به آن ارسال میکند. تماس با DNS تاخیر زمان برقراری تماس را کمی بیشتر میکند. یک راه حل، نگهداری آدرس پروکسیهای فعال اطراف، در حافظه نهان11 پروکسی است. البته این روش برای مواقعی که از DNS برای توزیع بار بین پروکسیهای مختلف استفاده میشود مناسب نیست [20].
در شکل12 تأخیر زمان برقراری تماس برای چهار حالت تست نشان داده شده است. در اینجا آدرس شبکه پروکسیهای اطراف در آدرس نهان وجود ندارد و برای هر تقاضا یک پروسه DNS انجام میشود. تفاوت این شکل با حالت تک پروکسی، بالاتر بودن تأخیر برقراری تماس در نرخهای یکسان و جهش تأخیر برقراری تماس در نرخهای کمتر است. این افزایش تأخیر بدلیل اضافه شدن یک پروکسی دیگر در مسیر سیگنالینگ و همچنین تقاضای DNS است. تاثیر پروسه DNS در تأخیر و مقیاس پذیری سرور هنگامی واضحتر میشود که بار پردازشی CPU مورد بررسی قرار گیرد. در شکل13 تاثیر پروسه DNS روی 
شکل13: بار پردازشی کل پردازنده و بار پردازشی پروسه OpenSER وقتی که پروکسی حالتمند و باتصدیق هویت است و وقتیکه بدون حالت و بدون تصدیق هویت است.
پروکسی حالتمند- با تصدیق هویت و بدون حالت-بدون تصدیق هویت نشان داده شده است. با توجه به این شکل تا قبل از اشباع سرور حالتمند و با تصدیق هویت روند مصرف CPU رو به افزایش است. اما برخلاف تصور در نرخهای بالاتر مصرف CPU و بار پردازشی پروسه OpenSER کاهش مییابد. این مساله برای سرور بدون حالت و بدون تصدیق هویت (کمترین بار اجرایی) نیز صادق است با این تفاوت که پردازنده هیچگاه اشباع نمي‌شود.
بررسیهای انجام شده نشان داد که علت بالارفتن تأخیر تماسها با وجود اشباع نبودن بار پردازنده در نرخهای بالا تأخیر پروسه DNS میباشد در حین ردوبدل شدن تقاضای DNS پردازنده عملا درحال انتظار میماند و بنابراین با وجود اشباع نبودن پردازنده پروکسی، پروکسی عملا از پردازش تماسها باز میماند.
با بهینه‌کردن پیادهسازی پروکسی میتوان از این زمانهای انتظار درجهت پذیرش تماسهای بیشتر استفاده نمود. همانطور که ذکر شد سیاست قراردادن آدرس ها در حافظه نهان، راه کار مناسبی برای افزایش کارایی پردازنده پروکسی میباشد. از همین رو در نمودار شکل14 پروسه DNS را حذف کردهایم و از آدرس‌دهی
شکل14: بررسی میانگین زمان برقراری تماس بدون انجام DNS
شکل15: میانگین زمان برقراری تماسها برحسب نرخ ایجاد تماس با استفاده از پروتکل TCP
مستقیم برای ارسال بستهها بین پروکسیها استفاده نمودهایم. دراین حالت دیگربار پردازنده پروکسی برخلاف شکل13 کاهش نمییابد و همچنین میزان حذف بستهها به کمترین حد خود میرسد.
با مقایسه شکل12 و شکل14 متوجه میشویم که میانگین زمان برقراری تماس بهبود پیدا کرده است و جهش تأخیر نیز در نرخ تماس بالاتری رخ میدهد. البته بدیهی است که تأخیر برقراری تماس از حالت تک پروکسی کمی بیشتر است. به‌علاوه بررسی وضعیت تماسها نشان میدهند که با حذف فرایند DNS تعداد تماسهای ناموفق هم کاهش یافتند.
4-3- تاثیر پروتکل لایه انتقال
درشکل15 میانگین زمان برقراری تماس هنگامیکه سیگنالینگ SIP توسط پروتکل انتقال TCP حمل میشود نشان داده شده است. در مقایسه با پروتکل UDP این منحنیها از نرخ 100 تا 1500 تماس در ثانیه تولید شدهاند زیرا در نرخهای بالاتر فرایند کنترل ازدحام TCP عملا از ارسال هرگونه بستهای به پروکسی جلوگیری میکند. رفتار کلی این نمودار مانند نمودارهای پروتکل UDP است با این تفاوت که تأخیر در نرخهای پایینتر در حالات مشابه کمی‌بالاتر است و همچنین جهشها در نرخ کمتری اتفاق افتادهاند. جهش زودهنگام منحنیها در این حالت (نسبت به استفاده از UDP) ناشی از بار پردازشی بیشتر و نیاز به حافظه بیشتر برای برقراری یک ارتباط TCP درمقایسه با UDP میباشد. همچنین فرایند کنترل ازدحام پروتکل TCP نرخ ارسال بستههای SIP را به پروکسی کاهش میدهد که باعث افزایش تأخیر ایجاد تماس میشود. بعلاوه برای ایجاد ارتباط TCP بین پروکسیها و بین عاملهای کاربر و پروکسیها احتیاج به یک دستدهی سه طرفه12 است که خود به تأخیر ایجاد تماس میافزاید.
شکل16: مقایسه بار پردازشی پروتکل TCP وUDP در هنگامی که سرور حالتمند و بدون تصدیق هویت است
در شکل16 میزان بار پردازشی برای حالتیکه پروتکل لایه انتقال UDP و TCP است مقایسه شده است. در این شکل میزان استفاده OpenSER از CPU و بار کلی CPU در شرایطی که پروکسی حالتمند و بدون تصدیق هویت است نشان داده شده است. طبق این شکل در نرخ حدود 900 که نقطه جهش نمودار تأخیر نیز میباشد، میزان استفاده از CPU به بالاترین حد خود رسیده است. این درحالی است که هنگامی که از پروتکل UDP استفاده میکنیم در نرخهای بالاتر هم پردازنده اشباع نمي‌شود. بنابراین میتوان نتیجه گرفت که اگرچه استفاده از TCP بدلیل دارا بودن مکانیزم کنترل ازدحام باعث تخفیف در افت گذردهی پروکسی میشود اما هزینه پردازشی و حافظهای فزایندهای را به پروکسی تحمیل میکند که باعث افزایش تأخیر برقراری تماس و کاهش ظرفیت پروکسی میشود.
5- مشاهدات و پیشنهادات
در این راستا دو راه حل بالقوه وجود دارد. اولین و ساده ترین آنها استفاده از پروتکل TCP بعنوان لایه انتقال برای SIP است. از آنجاییکه TCP بطور ذاتی دارای قابلیت کنترل جریان ترافیک و ازدحام است، میتوان امیدوار بود که در مواردیکه بار پروکسی زیاد است از ارسالهای بیهوده جلوگیری نماید. اما آزمایشات انجام شده نشان دادند که تأخیر ایجاد تماس در حالت TCP بسیار بالاتر از UDP است. علیرغم نتایج بدست آمده میتوان از پروتکل TCP برای ارتباط بین دو پروکسی استفاده نمود. در حقیقت در صورتی که ارتباطات TCP بین دو پروکسی بصورت بهینه پیادهسازی شده و تمامی تماسهای بین دو دامنه از طریق یک ارتباط TCP بین دو پروکسی سرویس دهی شوند پروتکل TCP مناسب عمل میکند. به هرصورت ارتباط کاربران با پروکسی طبق نتایج بدست آمده نامناسب است.
راه حل دیگر استفاده از UDP و کنترل بار اضافه است. ایده اصلی اینست که بجای قبول بار بیش از حد و ایجاد نشدن درصدی از تماسها بهتر است این تعداد تماس اصلا توسط پروکسی پردازش نشوند تا اینکه بار کمتر شده و تأخیر ایجاد تماس کاهش یابد. برای پیادهسازی چنین راه حلی میتوان از ارسال پیامهای ردۀ 500 به عاملهای کاربر استفاده نمود. عامل کاربر به محض دریافت این پیام از ادامه سیگنالینگ منصرف میشود و در نتیجه بار پروکسی را بیش از آنچه هست افزایش نمیدهد.
نظر به اینکه در شرایط اضافه بار، مخربترین پدیده که منجر به افزايش بيش از حد انتظار بار ورودي به سرور و نهايتا از کارافتادن آن مي‌شود، ارسالهای مجدد هستند، یک راه حل متفاوت براي کاهش بار مضاعف پروکسي، تغيير قانون تنظيم تایمر ارسال مجدد درعاملهای کاربر و سایر پروکسیهاست. برای این کار باید پس از هر بار انقضای تایمر مقدار آنرا بیش ازحالت استاندارد قرار داد. برای مثال میتوان تایمر را هربار که منقضی میشود بجای دو برابر کردن، سه برابر نمود. بدین صورت طی یک زمان مشخص درخواستهای کمتری و درنتیجه بار کمتری از طرف عامل کاربر به پروکسی تحمیل میشود. البته ایراد این راه حل اینست که اگر درشرایط بار متوسط یا کم، بستهای گم شود و تایمر مربوط به آن منقضی شود، زمان برقراری تماس بسیار طولانی خواهد شد. علیرغم این ایراد لازم است متذکر شویم که در شبکههای فعلی که نرخ گم شدن بستهها روی لینکها بسیار پایین است، احتمال وقوع چنین سناریویی بسیار کم است. غالبا گم شدن بستهها بدلیل ازدحام درشبکه اتفاق می افتد که در این شرایط اتفاقا هدف ما افزایش بیش از حد معمول مقدار تایمر است.
پیکربندی پروکسی از نظر تولید تراکنش به ازای هر تماس و پشتیبانی از تصدیق هویت نیز تاثیر بسزایی برکارایی پروتکل سیگنالینگ SIP و درنتیجه تأخیر برقراری تماس و نرخ تماسهای ناموفق دارد. این مسأله بوضوح با بررسی نتایج آزمایشهای انجام شده تحت پیکربندیهای مختلف تایید میشود. نتایج نشان میدهند که هزینه انجام تصدیق هویت برای هر تماس بسیار زیاد است و هزینه حالتمند رفتار کردن پروکسی نیز قابل توجه میباشد. لذا باید سعی نمود تا جاییکه ممکن است از این پیکربندیها اجتناب شود. به عنوان نمونه میتوان به چند راهکار زیر اشاره نمود.
يک راهکار براي اجتناب از تصديق هويت تک تک تماسها از جانب موسسهای که سرويس تماس SIP، مانند VoIP، را در اختيار مشترکان قرار ميدهد این است که، به هنگام اتصال مشترکین به شبکه، آنها را با هر مکانیزم دیگری چون RADIUS تصدیق هویت نموده، سپس اجازه دسترسی به شبکه و جزئی از آن که همان پروکسی SIP است صادر شود. در چنین شرایطی تنها کاربرانی که اشتراک سرویس SIP دارند میتوانند به شبکه وصل شوند و دیگر احتیاجی به تصدیق هویت نخواهد بود. البته ممکن است مشترکین از طریق یک شبکه دیگر (برای مثال از محل کار خود) بخواهند با پروکسی خود ارتباط برقرار نمایند که در اینصورت استفاده از تصدیق هویت اجتناب ناپذیر خواهد بود. در هر حال با این روش تعداد کاربرانی که نیاز به تصدیق هویت خواهند داشت به طور قابل ملاحظه‌ای کاهش مییابد.
استفاده از تکنولوژی VPN نیز میتواند به حذف تصدیق هویت در پروکسی SIP کمک کند. در شرایطی که مشترکین سرویس SIP، اتصال شبکه خود را از طریق دیگری بجز شرکتی که به آنها سرویس SIP میدهد فراهم میکنند، شرکت سرویس دهنده SIP میتواند به محض ثبت نمودن کاربر، به او یک اتصال VPN در شبکه خود بدهد. درچنین شرایطی کاربر اگرچه از اتصال شبکه دیگری استفاده میکند اما عملا جزو شبکه SIP محسوب میشود و دیگر برای برقراری تماس احتیاجی به تصدیق هویت در پروکسی نخواهد بود. البته اين راهکار زماني ناکارامد خواهد بود که تعداد مشترکيني که ثبت شوند اما لزوما درخواست برقراري تماس ندارند بسيار زياد باشد، که این شرایط منجر به ایجاد گلوگاه روی سرور VPN خواهد شد. بطور کلی باید خاطر نشان نمود که استفاده ازVPN به عنوان یک راه حل برای رفع مشکل تصدیق هویت همواره مطلوب نیست زیرا گلوگاه را از پروکسی SIP به سرور VPN منتقل میکند. بلکه این راه حل در شرایطی توصیه میشود که بنا به دلایلی کاربران دور، به شبکه سرویس دهنده SIP با استفاده از VPN وصل مي‌شوند. بعنوان مثال میتوان از حالتی نام برد که یک دانشگاه سرویس SIP را روی شبکه داخلی خودش در اختیار کارکنانش قرار میدهد و همچنین کارکنان میتوانند با استفاده از VPN از خارج دانشگاه به شبکه دانشگاه متصل شوند. در چنین حالتی دیگر حتی نیاز به تصدیق هویت کاربران خارج از دانشگاه هم نمیباشد.
نکته دیگری که باید به آن توجه داشت شرایطی است که هنگام جابجایی ترمینال بین دو شبکه یا دو زیر شبکه پدید میآید. منظور از زیر شبکه‌ها، مجموعه قلمروهای IP متفاوت هستند که زیر نظر یک مدیریت مرکزی اداره میشوند، مانند شبکههای دانشکدههای مختلف در دانشگاه یا تمامی قلمروهای IP متفاوتی که توسط یک ISP اداره میشوند. در صورتیکه عمل دستبهدستدهی بین دو زیرشبکه با مدیریت واحد انجام شود، برای بهنگام سازی مسیر جدید تماس، نیازی به تصدیق هویت با پروکسی نمیباشد زیرا کاربر قبلا به هنگام برقراری تماس (یا اتصال به شبکه) یک بار هویتش احراز شده است. در چنین حالتی زمان مورد نیاز برای دستبهدستدهی و همچنین احتمال ناموفق بودن آن کم است. اما اگر کاربر درحین تماس به شبکه متفاوتی دستبهدستدهی نماید حتما باید عمل تصدیق هویت توسط پروکسی SIP و یا هنگام درخواست اتصال به شبکه توسط سرویسی مانند RADIUS انجام شود که این باعث افزایش تأخیر دستبهدستدهی و احتمال بروز قطعی میشود. متاسفانه درچنین حالتی راه حل ساده‌ای وجود ندارد مگر اینکه بین مالکین دو شبکه از قبل قراردادهایی منعقد شده باشد. برای مثال اعتبارنامه‌های یکدیگر را قبول نمایند تا مشترک یک شبکه مجبور نباشد از ابتدا احراز هویت شود.
حالتمند رفتار نمودن پروکسی SIP از دیگر عواملی است که باعث افزایش تأخیر ایجاد تماس و احیانا افزایش تأخیر دستبهدستدهی میشود. لذا به عنوان یک راهکار میتوان در شرایطی از پروکسی در وضعیت بدون حالت استفاده نمود. البته در این صورت پروکسی قادر به پیگیری فرایند تماس
و ازآن جمله انجام اعمالی چون حسابرسی نخواهد بود. بنابراین یک راهکار مناسب آن است که از پروکسیهای حالتمند برای برقراری تماس استفاده شود اما تعدادی پروکسی بدون حالت نیز در نقش توزیع کننده بار بکار روند و ترافیک عاملهای کاربر را به یک پروکسی حالتمند با بار متعادل ارسال نمایند. با این کار میتوان از ایجاد اضافه بار روی پروکسیهای حالتمند و افزایش بیش ازحد تأخیر برقراری تماس و نرخ تماسهای ناموفق جلوگیری نمود. درعین حال پروکسیهای توزیع کننده بار در وضعیت بدون حالت کار میکنند و میتوانند بدون اینکه دچار اضافه بار شوند به تعداد درخواست بیشتری سرویس بدهند.
6- نتیجهگیری
دراین مقاله به تحلیل و بررسی اثر پذیری پارامترهای کیفیت تماس از جمله تأخیر ایجاد تماس، تأخیر پاسخگویی پروکسی، ارسال مجدد و نرخ خطا در ایجاد تماس به عنوان تابعی از میزان بار اعمال شده روی سرور، در پیکربندیهای مختلف پروکسی سرور SIP پرداختیم. بدین منظور با درنظر گرفتن یک سرور به ازای هر دامنه، هزینه فرایندهای امنیتی چون تصدیقهویت برای تمامی تماسهای برقرارشده و حالتمند یا بدون حالت بودن سرور، در شرایطی که تمام تماسها محلی بوده و در داخل یک دامنه صورت می‌گیرند و درحالتی که تماسها برون مرزی هستند بررسی گردید. به علاوه تاثیر پروتکل لایه انتقال استفاده شده در پیکربندیهای فوق نیز، مورد مطالعه قرارگرفت.
نتایج حاصل از آزمایشات انجام شده نشاندهنده تاثیر پیکربندی پروکسی روی کارایی آن میباشد. در این میان مهمترین عامل تاثیر گذار بر کارایی سرور SIP انجام تصدیق هویت و پس از آن حالتمند رفتار کردن پروکسی است که راه حل هایی نیز برای اجتناب از آنها در بخش 5- ذکر شد.
به منظور کاهش اثر نامطلوب بار پردازشی زیاد بر روی پروکسی، حافظه اختصاص داده شده به پروکسی مورد بررسی قرار گرفت و نشان داده شد که با تعیین مناسب حافظه اختصاصی پروکسی از پذیرش تماسهای بیش از ظرفیت پردازشگر تا حد زیادی جلوگیری میشود.
بررسی‌ها نشان دادند که پروتکل SIP در مواجهه با ازدحام چندان کارامد نمیباشد طوری که با بالا رفتن نرخ درخواست تماس، تأخیر ایجاد تماس به طور ناگهانی افزایش یافته، گذردهی پروکسی افت و نهایتا نرخ تماسهای ناموفق افزایش یابد. بنابراین بهبود این مکانیزم یک زمینه باز تحقیقاتی بوده و مورد توجه میباشد.
سپاسگزاری
این کار با پشتیبانی مادی و معنوی مرکز تحقیقات مخابرات ایران انجام گرفته است. بدینوسیله از این مرکز کمال تشکر به عمل میآید.
مراجع
[1] J. Rosenberg et al. , “SIP: Session Initiation Protocol”, IETF RFC 3261 , June 2002
[2] Schulzrinne, H., Narayanan, S., LENNOX, J., AND DOYLE, M., “SIPstone – Benchmarking SIP server performance”, Tech. rep., Columbia University, Apr. 2002. Available from http://www.columbia.edu/
[3] Raatikainen K., et al. "A Control Plane Benchmark for Telecommunications Signalling Applications", Linux Conf Europe, 5th September 2007
[4] M. Cortes, J. R. Ensor, and J. O. Esteban, “On SIP Performance”, Bell Labs Technical Journal, Volume 9, Issue 3, pp. 155-172, 2004
[5] S. Wanke1, M. Scharf1, S. Kiesel1, S. Wahl2, "Measurement of the SIP Parsing Performance in the SIP Express Router", Lecture Notes in Computer Science (including subseries Lecture Notes in Artificial Intelligence and Lecture Notes in Bioinformatics), Springer Berlin / Heidelberg, Volume 4606 LNCS, pp. 103-110, 2007
[6] SS Gokhale., “Signaling performance of SIP based VoIP: A measurement-based approach”, In Proc. of IEEE Globecom ’05, Vol. 2,pp. 761-765, Nov. 2005
[7] Caixia Chi, Dong Wang, Ruibing Hao, Wei Zhou, "Performance Evaluation of SIP Servers", 2008
[8] Erich M. Nahum, John Tracey, and Charles P. Wright, "Evaluating SIP Proxy Server Performance", 17th International workshop on Network and Operating Systems Support for Digital Audio & Video, 2007
[9] Vincent Planat, Nadjia Kara, "SIP Signaling Retransmission Analysis over 3G network', MoMM, 2006
[10] A. Munir, "Analysis of SIP-based IMS Session Establishment Signaling for WiMax-3G network", Proceedings of the Fourth International Conference on Networking and Services (icns 2008) ,Volume 00, pp.282-287, 2008
[11] V. K. Gurbani, R. Jain, "Transport Protocol Considerations for Session Initiation Protocol Networks", Bell Labs Technical Journal, Volume 9, Issue 1, pp. 83-97, 2004
[12] Masataka Ohta, "Performance Comparisons of Transport Protocols for Session Initiation Protocol Signaling", 2008
[13] Kaushik Kumar Ram, Ian C. Fedeli, Alan L. Cox, and Scott Rixner. "Explaining the Impact of Network Transport Protocols on SIP Proxy Performance", IEEE International Symposium on Performance Analysis of Systems and software, ISPASS,pp. 75-84, 2008
[14] M. Cortes, J.O. Esteban, H. Jun, " Towards Stateless Core: Improving SIP Proxy Scalability", IEEE Global Telecommunications Conference. GLOBECOM '06. , pp. 1-6, 2006
[15] Yul Pyun ,"SIP Deployment Notes at University of Hawaii", http://net.its.hawaii.edu/advanced/ sip/index.html
[16] Jan Janak, “SIP Server Effectiveness”, Master’s Thesis, Czech Technical University, Faculty Of Electrical Engineering, Department of Computer Science, 2003
[17] www.opensips.org
[18] Richard Gayraud, Olivier Jaques et al.: SIPp - SIP Load Generator., http://sipp.sourceforge. net/index.html
[19] D. Malas," SIP End-to-End Performance Metrics," Internet-Draft, October 31, 2008 (work in progress), http://www.ietf.org/ internet-drafts/draft-ietf-pmol-sip-perf-etrics-02.txt
[20] Kundan Singh and Henning Schulzrinne, “Failover, load sharing and server architecture in SIP telephony”, Computer Communications, Volume 30, Issue 5, pp.927-942, March 2007.
[1] .Internet Service Provider (ISP)
[2] 1.Inbound
[3] 2.Outbound
[4] 3.online
[5] 4.Short dotted line
[6] .forking
[7] .With Authentication-Stateful
[8] .With Authentication-Stateless
[9] .No Authentication – Stateful
[10] .No Authentication - Stateless
[11] .cache
[12] .Tree way handshaking
