جلسه دوم دوره CCNA Collaboration – پروتکل SIP

0
198

جلسه دوم

موضوع: جلسه دوم دوره CCNA Collaboration – پروتکل SIP

پروتکل SIP

پروتکل Session Initiation Protocol (SIP) یک پروتکل سیگنالینگ است که برای شروع، نگهداری و خاتمه session های بلادرنگ یا همان real-time که شامل برنامه های صوتی، تصویری و پیام رسانی است استفاده می‌شود. SIP برای سیگنالینگ (علامت‌گذاری) و کنترل session های ارتباطات مالتی مدیا در برنامه های تلفن اینترنتی برای تماس های صوتی و تصویری در سیستم های IP Phone در تماس های صوتی و تصویری، در پیام های فوری از طریق شبکه مبتنی بر IP و همچنین تماس های تلفن همراه در بستر VoLTE می‌باشد.

بنابر تعریف ITU، سیگنالینگ مبادله اطلاعات بین بخش های مختلف یک شبکه ارتباطی است و طبق تعریف زبانی است که تجهیزات مخابراتی را قادر به برقراری ارتباط می‌کند و نظیر سایر زبان ها از لغاتی تشکیل شده است که دارای معانی مختلف و ابعاد گوناگون می باشد.

سیگنالینگ به مجموعه ای از پیام های ارسالی و دریافتی در یک ارتباط مخابراتی گفته می‌شود که وظیفه مدیریت و کنترل یک ارتباط را دارد. به عبارت دیگر تمامی عملیاتی که شما یا طرف مقابل و یا واسط (به عنوان مثال، مرکز مخابراتی) برای یک ارتباط انجام می‌دهید که می توان به شماره گیری ، بوق اشغال ، بوق تماس ، کالر آی دی و … نام برد بر عهده سیگنالینگ است.

در گذشته ( ابتدای همه گیر شدن ارتباطات تلفنی )سیگنالینگ توسط فرد یا افرادی که در مرکز مخابراتی مستقر بودند انجام می‌شد به طوری که شما اگر قرار بود با شخصی ارتباط تلفنی برقرار نمایید ، گوشی تلفن را برداشته و به اپراتور درخواست ارتباط با ایشان را ارائه می‌کردید. اما با گذشت زمان و پیشرفت فن آوری، این چرخه، کار خود را به سیگنال های ارسالی و دریافتی داد، به طوری که در حال حاضر با برداشتن گوشی تلفن و شماره گیری سیگنال ها به سوییچ مخابراتی ارسال شده و به صورت خودکار ارتباط شما با مقصد برقرار می شود.

این پروتکل قالب خاصی از پیام های رد و بدل شده و ترتیب ارتباطات برای همکاری شرکت کنندگان را تعریف می‌کند. SIP یک پروتکل مبتنی بر متن است که بسیاری از عناصر پروتکل های HTTP و SMTP را ترکیب می‌کند. تماس برقرار شده با SIP ممکن است شامل چندین جریان مدیا باشد، اما هیچ جریان جداگانه ای برای برنامه هایی مانند پیام متنی که دیتا را به عنوان payload در پیام SIP تبادل می‌کند وجود ندارد.

SIP به همراه چندین پروتکل دیگر که انتقال مدیا session را کنترل و حمل می‌کند کار می‌کند. به طور معمول، مذاکره درباره نوع رسانه و پارامتر و تنظیم مدیا توسط Session Description Protocol (SDP) انجام می‌شود که به عنوان payload در پیام های SIP حمل می‌شود. SIP به گونه ای طراحی شده است که مستقل از پروتکل حمل که می‌تواند با پروتکل هایی مانند UDP، TCP و SCTP کار کند است. برای انتقال امن پیام های SIP در لینک های شبکه های نا امن، این پروتکل ممکن سات توسط TLS رمزنگاری شود. برای انتقال جریان های رسانه ای مانند صدا و تصویر، SDP payload که در پیام های SIP حمل می‌شود، معمولا از Real-Time Transport Protocol (RTP) یا Secure Real-Time Transport Protocol (SRTP) استفاده می‌کند.

SIP در ابتدا توسط مارک هندلی، هنینگ شولزرین، ایوشولر و جاناتان روزنبرگ در سال 1996 طراحی شد تا ایجاد session های مالتی مدیا در Mbone را تسهیل کند. این پروتکل در سال 1999 به عنوان RFC 2543 استاندارد شد. در نوامبر سال 2000، SIP به عنوان پروتکل سیگنالینگ 3GPP و عنصر دائمی معماری IMS برای خدمات مالتی مدیا یا همان چند رسانه ای در شبکه های تلفن همراه پذیرفته شد. در ژوئن 2002 مشخصات SIP مورد بازبینی قرار گرفته شده و الحاقات و توضیحات مختلف در RFC 3261 منتشر شد.

SIP به منظور ارائه یک پرتکل سیگنالینگ و راه‌اندازی تماس برای ارتباطات مبتنی بر IP طراحی شده است که از عملکردها و ویژگی های پردازش تماس موجود در شبکه های PSTN با چشم اندازی از برنامه های مالتی مدیا جدید پشتیبانی می‌کند. این برنامه برای کنفرانس ویدئویی، پخش مدیا استریمینگ، پیام های فوری، اطلاعات حضور، انتقال فایل، فکس اینترنتی و بازی های آنلاین گسترش داده شده است.

SIP توسط هوادارن خود به دلیل ریشه در جامعه اینترنتی به جای صنعت مخابرات متمایز شده است. SIP در ابتدا توسط IETF استاندارد شده، در حالی که سایر پروتکل ها مانند H.323 به طروی سنتی و با ITU مرتبط هستند.

SIP فقط در عملیات پیام رسانی session ارتباطات رسانه ای دخیل است و عمدتا برای راه‌اندازی و خاتمه تماس های صوتی یا تصویری استفاده می‌شود. از SIP می‌توان برای ایجاد جلسات دو طرفه (Unicast)، یا چند طرفه (Multicast) استفاده کرد. همچنین امکان تغییر تماس های موجود را فراهم می‌کند. این تغییر می‌تواند شامل تغییر آدرس ها یا پورت ها، دعوت از شرکت کنندگان بیشتر و افزدون یا حذف جریان های رسانه ای باشد.

هر ریسورس در شبکه SIP، مانند ایجنت کاربر، روترهای تماس و صندوق پستی صوتی توسط یک Uniform Resource Identifier (URI) شناسایی می‌شود. سینتکس URI از سینتکس یا نحو استاندارد عمومی که در سرویس وب و ایمیل استفاده می‌شود پیروی می‌کند. طرح URI استفاده شده برای SIP، sip است و یک SIP URI معمول داری فرم sip:[email protected] یا sip:[email protected] است، در جایی که domainname نیازمند رکورد DNS SRV برای مشخص کردن موقعیت سرورها برای دامنه SIP مورد نظر است و hostport می‌تواند یک IP آدرس یا یک FQDN هاست و پورتش باشد. اگر انتقال امن مورد نیاز باشد، طرح sips مورد استفاده قرار می‌گیرد. SIP از عناصر مشابه مدل HTTP برای درخواست و پاسخ به مدل انتقال استفاده می‌کند. هر انتقال شامل یک درخواست مشتری که یک روش یا عملکرد خاص را روی سرور فراخوانی می‌کند و حداقل یک پاسخ است. SIP از بیشتر فیلدهای header، قوانین رمزنگاری و وضعیت کدهای HTTP برای ارائه یک قالب قابل خواندن مبتنی بر متن استفاده می‌کند.

SIP می‌تواند توسط چندین پروتکل لایه transport مانند TCP، UDP و SCTP حمل شود. کلاینت های SIP معمولا از TCP و یا UDP بروی پورت های 5060 و 5061 برای انتقال ترافیک SIP به سرورها و دیگر endpoint ها استفاده می‌کنند. پورت 5060 معمولا برای ترافیک های غیررمزنگاری شده سیگنالینگ استفاده می‌شود، در حالیکه پورت 5061 معمولا برای ترافیک رمزشده با TLS استفاده می‌شود.
شبکه های تلفن مبتنی بر SIP اغلب ویژگی های پردزاش تماس را از Signaling System 7 (SS7) اجرا می‌کند. هر چند این دو پروتکل بسیار متفاوت از یکدیگرند اما برای SS7 در SIP پسوندهای ویژه ای برای استفاده وجود دارد.

عناصر شبکه SIP

عناصر شبکه ای که از SIP برای ارتباط استفاده می‌کنند SIP user agent نامیده می‌شوند. هر User Agent (UA) کار یک User Agent Client (UAC) را هنگامی که درخواست سرویس می‌کند و یک User Agent Server (UAS) را هنگامی که پاسخ به درخواست می‌دهد اجرا می‌کند. در عمل هر دو endpoint ممکن است بدون دخالت عوامل زیرساختی SIP کار کنند. با این حال، به دلایل عملیاتی در شبکه، برای ارائه خدمات عمومی و برای سرویس های دایرکتوری، SIP چندین نوع خاص از عناصر شبکه را تعریف می‌کند. هر کدام از این عناصر به مدل کلاینت-سرور در قالب UAC و UAS ارتباط برقرار می‌کنند.

User Agent (UA)

User Agent (UA) یک endpoint لاجیکال شبکه است که پیام ها SIP را ارسال و دریافت کرده و session های SIP را مدیریت می‌کند. UA ها اجزای کلاینتی و سروری دارند. User Agent Client (UAC)، SIP Request را ارسال می‌کند. UAS درخواست ها را دریافت کرده و SIP Response را در پاسخ بر می‌گرداند. بر خلاف سایر پروتکل های شبکه که نقش سرویس گیرنده و سرور ثابت است (به عنوان مثال در HTTP، که در آن مرورگر وب فقط به به عنوان سرویس گیرنده عمل می‌کند و هرگز نقش سرور ندارد)، SIP به هر دو peer یا دو سمت ارتباط برای اجرای هر دو نقش کلاینت و سرور نیاز دارد. به همین دلیل است که پروتکل SIP را نمی‌توان در پشت NAT استفاده نمود، زیرا endpoint سرویس گیرنده، لحظه دیگر به عنوان سرور سرویس دهنده عمل می‌کند که از خارج از شبکه NAT شده در دسترس نخواهد بود. نقش های کلاینت و سروری فقط در زمان انتقال اطلاعات SIP وجود دارد.

SIP phone یک IP Phone است که عملکردهای سرویس گیرنده و سرور مربوط به یک SIP User Agent را انجام می‌دهد و کارهای ستنی مربوط به یک تلفن مانند شماره گیری، پاسخ، رد، نگهداشتن تماس و انتقال تماس را ارائه می‌دهد. تلفن های SIP ممکن است به عنوان یک دستگاه سخت‌افزاری یا به عنوان یک نرم‌افزار اجرا شوند. با توجه به اینکه وندورها به طور فزاینده ای SIP را به عنوان یک استاندارد پلت فرم تلفن پیاده سازی می‌کنند، و از آنجایی که عناصر SIP در عملکردهای فریم ور های اصلی بسیاری از دستگاه هایی که قادر به استفاده از بستر IP هستند مانند تلفن های هوشمند پیاده سازی می‌شود، تمایز بین تلفن های نرم‌افزاری و سخت‌افزاری SIP مبهم است.

در SIP، مانند HTTP، UA ممکن است خود را با استفاده از یک پیام در فیلد header (User-Agent)، شامل توضیحات متنی از نرم‌افزار، سخت‌افزار و یا نام محصول شناسایی کند. فیلد user-agent در پیام های درخواستی ارسال می‌شود که به این معنی است که سرور دریافت کننده SIP می‌تواند این اطلاعات را برای انجام تنظیمات خاص دستگاه یا فعال سازی ویژگی ها ارزیابی کند.

Proxy Server

یک Proxy Server یک سرور شبکه با اجزا UAC و UAS است که به عنوان یک نهاد واسط عمل می‌کند. Proxy Server در درجه اول نقش مسیریابی تماس را انجام می‌دهد. این سرور SIP Request را برای سرور دیگری که به مقصد نزدیکتر است ارسال می‌کند. سرورهای پروکسی همچنین برای اعمال پالیسی ها مانند تعیین اینکه آیا کاربر مجاز به برقراری تماس است، مفید هستند. پراکسی قسمت های خاصی از پیام درخواست را پیش از ارسال تفسیر کرده و در صورت لزوم بازنویسی می‌کند.

Redirect Server

Redirect Server یک UAS است که پاسخ های 3xx (redirection) را به درخواست های دریافتی اش تولید می‌کند و کلاینت را برای ارتباط با یک مجموعه از URI (Uniform Resource Identifier) ها هدایت می‌کند. یک Redirect Server به Proxy Server ها اجازه می‌دهد تا دعوت نامه های SIP را به دامنه های خارجی هدایت کند.

ثبات (Registrar)

یک ثبات یا registrar یک SIP endpoint است که سرویس location را ارائه می‌دهد. ثبات register request ها را می‌پذیرد، آدرس و سایر پارامترها را از UA ضبط می‌کند. برای درخواست های بعدی، اقدامات لازم برای مکان یابی peer های احتمالی داخل شبکه را فراهم می‌کند. سرویس location یک یا چند IP آدرس را به SIP URI از ایجنت ثبت کننده لینک می‌کند. چندین UA ممکن است برای یک URI ثبت نام کنند، در نتیجه تمام ایجنت های کاربران ثبت شده تماس ها را با همان URI دریافت می‌کنند.

sip register flow

Session Border Controller (SBC)

Session Border Controller (SBC) به عنوان middlebox بین UA ها و سرورهای SIP برای انواع مختلف عملکردها مانند Network Topology Hiding و کمک در NAT Traversal عمل می‌کنند.

Gateway

Gateway ها می‌توانند برای اتصال یک شبکه SIP به دیگر شبکه ها مانند PSTN که از پروتکل ها و تکنولوژی های متفاوتی به نسبت SIP استفاده می‌کنند است.

SIP Message

SIP یک پروتکل مبتنی بر متن با نحو یا سینتکس مشابه پروتکل HTTP است. دو نوع مختلف از پیام های SIP وجود دارد: درخواست ها – پاسخ ها.

اولین خط درخواست دارای یک متد است که ماهیت درخواست را مشخص می‌کند. سپس یک Request-URI که نشان می‌دهد درخواست برای کجا باید ارسال شود.

Request ها

Request ها عملکرد پروتکل را آغاز می‌کنند. آنها توسط یک سرویس گیرنده به سرور ارسال می‌شوند و با یک یا چند SIP Response پاسخ داده می‌شود که وضعیت ارتباط را که می‌تواند شامل موفقیت، شکست یا وضعیت های دیگر باشد را نشان می‌دهد.

sip request table

Response ها

Response ها توسط یک UAS برای مشخص کردن نتیجه دریافت یک request دریافتی است. چندین کلاس از response ها وجود دارند که با محدوده عددی کدهای نتیجه تعیین می‌شوند:

• 1xx: پاسخ های موقت به request ها نشان می‌دهد که request معتبر بوده و در حال پردازش است.

• 2xx: تکمیل موفقیت‌آمیز درخواست. به عنوان پاسخ به یک invite، این کلاس مشخص کننده این است که تماس برقرار شده است. رایج ترین کد 200 است که گزارش موفقیت‌آمیز بودن است.

• 3xx: جهت تکمیل درخواست، redirect کردن تماس مورد نیاز است. درخواست باید توسط یک مقصد جدید تکمیل شود.

• 4xx: درخواست به دلایل مختلفی مانند bad request syntax (code 400) نمی‌تواند در سمت سرور تکمیل شود.

• 5xx: سرور به دلایلی مانند خطای داخلی سرور نتوانسته یک درخواست به ظاهر معتبر را انجام دهد.

• 6xx: درخواست در هیچ سرور قابل انجام نیست. این اتفاق نشان دهنده یک failure عمومی است، مانند رد تماس توسط مقصد.

Transaction یا انتقال

SIP مکانیزم انتقال را برای کنترل تبادل بین endpoint ها و رساندن پیام ها به صورت مطمئن را تعریف می‌کند. یک انتقال یک وضعیت از session است که توسط تایمرهای مختلف کنترل می‌شود. Client Transaction ها درخواست ها را ارسال کرده و Server Transaction ها به این درخواست ها با یک یا چند response پاسخ می‌دهند. پاسخ ها ممکن است شامل پاسخ های موقت با یک response code در قالب 1xx و یا چند پاسخ نهایی (2xx – 6xx) باشد.

Transaction ها به عنوان دو نوع invite و non-invite طبقه بندی می‌شوند. Transaction های از نوع invite از این نظر متفاوتند که می‌توانند یک مکالمه بلند مدت برقرار کنند، که در SIP به آن دیالوگ یا گفتگو گفته می‌شود و بنابراین شامل یک تصدیق (ACK) از هر نوع پاسخ نهایی non-failing مانند 200 OK می‌باشد.

مثال زیر را در نظر بگیرید:

User1 یک Invite Client Transaction برای شروع invite (1) ارسال می‌کند.

اگر پس از مدت زمان انتظار کنترل شده توسط تایمر، پاسخی دریافت نشد، UAC ممکن است transaction را لغو کرده و مجددا invite ارسال کند.

پس از دریافت پاسخ، User1 مطمئن است که invite به طور کامل تحویل داده شده است. پس از آن User1 باید دریافت پاسخ را تایید کند.

هنگام تحویل ACK (2)، transaction کامل شده است. در این حالت، ممکن است یک گفتگو ایجاد شود.

sip call flow

برای دیدن فهرست مطالب دوره CCNA Collaboration اینجا کلیک کنید.

ارسال یک پاسخ

لطفا دیدگاه خود را وارد کنید!
لطفا نام خود را در اینجا وارد کنید