11.8. سرویس‌های ارتباطی بلادرنگ
سرویس‌های ارتباطی بلادرنگ (RTC) شامل صوت، تصویر/دوربین، پیام‌رسانی فوری (IM) و اشتراک‌گذاری صفحه نمایش هستند. این قسمت به معرفی سه تا از سرویس‌های RTC می‌پردازد که عبارتند از: سرورهای TURN، SIP و XMPP. چگونگی طرح‌ریزی، نصب و مدیریت این سرویس‌ها به صورت کامل در راهنمای سریع ارتباطات بلادرنگ همراه با مثال‌های موجود برای دبیان آورده شده است.
هر دو سرویس SIP و XMPP می‌توانند عملکرد یکسانی را فراهم کنند. SIP بیشتر برای صوت و تصویر شناخته شده است در صورتی که XMPP از قبل برای پروتکل IM استفاده می‌شد. در حقیقت، هر دو می‌توانند برای هر کدام از این اهداف استفاده شوند. برای استفاده حداکثری از گزینه‌های ارتباطی، توصیه می‌شود که هر دو به صورت موازی اجرا شوند.
این سرویس‌ها برای اهداف احرازهویت و محرمانگی داده مبتنی بر گواهینامه‌های X.509 هستند. برای جزئیات مرتبط با ایجاد هر کدام،
قسمت 10.2.1.1, “زیرساخت کلید عمومی: easy-rsa”
را مشاهده کنید. همچنین،
راهنمای سریع ارتباطات بلادرنگ شامل برخی توضیحات مفید است:
11.8.1. تنظیمات DNS برای سرویس‌های RTC
سرویس‌های RTC نیازمند رکوردهای SRV و NAPTR از DNS هستند. یک پیکربندی نمونه که می‌تواند در ناحیه مرتبط با falcot.com قرار بگیرد عبارت است از:
; the server where everything will run
server1 IN A 198.51.100.19
server1 IN AAAA 2001:DB8:1000:2000::19
; IPv4 only for TURN for now, some clients are buggy with IPv6
turn-server IN A 198.51.100.19
; IPv4 and IPv6 addresses for SIP
sip-proxy IN A 198.51.100.19
sip-proxy IN AAAA 2001:DB8:1000:2000::19
; IPv4 and IPv6 addresses for XMPP
xmpp-gw IN A 198.51.100.19
xmpp-gw IN AAAA 2001:DB8:1000:2000::19
; DNS SRV and NAPTR for STUN / TURN
_stun._udp IN SRV 0 1 3467 turn-server.falcot.com.
_turn._udp IN SRV 0 1 3467 turn-server.falcot.com.
@ IN NAPTR 10 0 "s" "RELAY:turn.udp" "" _turn._udp.falcot.com.
; DNS SRV and NAPTR records for SIP
_sips._tcp IN SRV 0 1 5061 sip-proxy.falcot.com.
@ IN NAPTR 10 0 "s" "SIPS+D2T" "" _sips._tcp.falcot.com.
; DNS SRV records for XMPP Server and Client modes:
_xmpp-client._tcp IN SRV 5 0 5222 xmpp-gw.falcot.com.
_xmpp-server._tcp IN SRV 5 0 5269 xmpp-gw.falcot.com.
ًَُٔTURN سرویسی است که به برنامه‌های پشت مسیریاب‌ها و فایروال‌های NAT کمک می‌کند تا به بهترین شیوه راهی برای برقراری ارتباط با سایر برنامه‌ها و ارسال و دریافت داده‌های چندرسانه‌ای در صورت نبود مسیر مستقیم، پیدا کنند. توصیه می‌شود قبل از ارائه سایر سرویس‌های RTC که برای کاربر نهایی طراحی شده‌اند، سرور TURN راه‌اندازی شود.
پروتکل TURN و ICE از جمله استانداردهای باز به حساب می‌آیند. به منظور بهره‌گیری از این پروتکل‌ها، برای ارتباط حداکثری و پیچیدگی حداقلی، اطمینان از اینکه تمام برنامه‌ها از ICE و TURN پشتیبانی می‌کنند، از اهمیت بالایی برخوردار است.
به منظور کارآیی بهتر الگوریتم ICE، سرور باید حداقل دو نشانی IPv4 عمومی داشته باشد.
نصب بسته resiprocate-turn-server
فایل پیکربندی /etc/reTurn/reTurnServer.config را ویرایش کنید. یکی از مهم‌ترین کارها درج نشانی‌های IP سرور است.
# your IP addresses go here:
TurnAddress = 198.51.100.19
TurnV6Address = 2001:DB8:1000:2000::19
AltStunAddress = 198.51.100.20
# your domain goes here, it must match the value used
# to hash your passwords if they are already hashed
# using the HA1 algorithm:
AuthenticationRealm = myrealm
UserDatabaseFile = /etc/reTurn/users.txt
UserDatabaseHashedPasswords = true
راه‌اندازی سرویس
11.8.2.2. مدیریت کاربران TURN
استفاده از ابزار htdigest برای مدیریت فهرست کاربران سرور TURN.
# htdigest /etc/reTurn/users.txt myrealm joe
پس از تغییر فایل /etc/reTurn/users.txt یا فعال‌سازی ویژگی بازنشانی خودکار در /etc/reTurn/reTurnServer.config، از سیگنال HUP استفاده کنید تا سرور مجبور شود آن را بازنشانی کند.
یک سرور پروکسی SIP ارتباطات دریافتی و ارسالی بین سایر سازمان‌های SIP، فراهم‌کنندگان سرویس SIP، PBXهایی مانند Asterisk، تلفن‌های SIP و برنامه‌های WebRTC را مدیریت می‌کند.
به شدت توصیه می‌شود که قبل از راه‌اندازی SIP PBX ابتدا پروکسی آن را پیکربندی کنید. پروکسی SIP بسیاری از ترافیک دریافتی PBX را نرمال‌سازی می‌کند تا ارتباط و انعطاف‌پذیری بیشتری حاصل گردد.
بسته repro را نصب کنید. استفاده از بسته موجود در jessie-backports توصیه می‌شود چرا که شامل آخرین بهینه‌سازی‌های مربوطه است.
فایل پیکربندی /etc/repro/repro.config را ویرایش کنید. مهم‌ترین کار درج نشانی‌های IP سرور است. نمونه زیر چگونگی پیکربندی SIP به صورت عمومی و کاربرد WebRTC را با استفاده از TLS، IPv4 و IPv6 نشان می‌دهد:
# Transport1 will be for SIP over TLS connections
# We use port 5061 here but if you have clients connecting from
# locations with firewalls you could change this to listen on port 443
Transport1Interface = 198.51.100.19:5061
Transport1Type = TLS
Transport1TlsDomain = falcot.com
Transport1TlsClientVerification = Optional
Transport1RecordRouteUri = sip:falcot.com;transport=TLS
Transport1TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport1TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport2 is the IPv6 version of Transport1
Transport2Interface = 2001:DB8:1000:2000::19:5061
Transport2Type = TLS
Transport2TlsDomain = falcot.com
Transport2TlsClientVerification = Optional
Transport2RecordRouteUri = sip:falcot.com;transport=TLS
Transport2TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport2TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport3 will be for SIP over WebSocket (WebRTC) connections
# We use port 8443 here but you could use 443 instead
Transport3Interface = 198.51.100.19:8443
Transport3Type = WSS
Transport3TlsDomain = falcot.com
# This would require the browser to send a certificate, but browsers
# don't currently appear to be able to, so leave it as None:
Transport3TlsClientVerification = None
Transport3RecordRouteUri = sip:falcot.com;transport=WSS
Transport3TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport3TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport4 is the IPv6 version of Transport3
Transport4Interface = 2001:DB8:1000:2000::19:8443
Transport4Type = WSS
Transport4TlsDomain = falcot.com
Transport4TlsClientVerification = None
Transport4RecordRouteUri = sip:falcot.com;transport=WSS
Transport4TlsPrivateKey = /etc/ssl/private/falcot.com-key.pem
Transport4TlsCertificate = /etc/ssl/public/falcot.com.pem
# Transport5: this could be for TCP connections to an Asterisk server
# in your internal network. Don't allow port 5060 through the external
# firewall.
Transport5Interface = 198.51.100.19:5060
Transport5Type = TCP
Transport5RecordRouteUri = sip:198.51.100.19:5060;transport=TCP
HttpBindAddress = 198.51.100.19, 2001:DB8:1000:2000::19
HttpAdminUserFile = /etc/repro/users.txt
RecordRouteUri = sip:falcot.com;transport=tls
ForceRecordRouting = true
EnumSuffixes = e164.arpa, sip5060.net, e164.org
DisableOutbound = false
EnableFlowTokens = true
EnableCertificateAuthenticator = True
از ابزار htdigest استفاده کرده تا گذرواژه مدیر برای رابط مبتنی بر وب را مدیریت کنید. نام‌کاربری باید admin باشد و نام قلمرو آن باید با آنچه در repro.config موجود است مطابقت کند.
# htdigest /etc/repro/users.txt repro admin
سرویس را راه‌اندازی مجدد کنید تا از پیکربندی جدید استفاده کند.
11.8.3.2. مدیریت پروکسی SIP
با استفاده از رابط مبتنی بر وب واقع در http://sip-proxy.falcot.com:5080 پیکربندی را با افزودن دامنه‌ها، کاربران محلی و مسیرهای ایستا کامل کنید.
گام اول افزودن دامنه محلی است. پس از افزودن یا حذف دامنه‌ها به/از فهرست، فرآیند باید راه‌اندازی مجدد گردد.
پروکسی می‌داند چطور تماس‌ها را بین کاربران محلی و نشانی کامل SIP مسیریابی کند، بنابراین پیکربندی مسیریابی تنها برای تغییر این عملکرد پیشفرض مورد نیاز است. برای نمونه، به منظور افزودن شماره تلفن‌ها، پیشوند آن‌ها و مسیریابی از طریق یک فراهم‌کننده SIP.
سرور XMPP ارتباط بین کاربران محلی و سایر کاربران XMPP در دامنه‌های عمومی اینترنت را مدیریت می‌کند.
Prosody یک سرور محبوب XMPP است که قابلیت اعتماد بالایی در سرورهای دبیان دارد.
بسته prosody را نصب کنید. استفاده از بسته موجود در jessie-backports توصیه می‌شود چرا که شامل آخرین بهینه‌سازی‌های مربوطه است.
فایل پیکربندی /etc/prosody/prosody.cfg.lua را مرور کنید. مهم‌ترین کار درج UID کاربرانی است که مجاز به مدیریت سرور هستند.
admins = { "joe@falcot.com" }
برای هر دامنه به یک فایل پیکربندی جداگانه نیاز است. از فایل نمونه /etc/prosody/conf.avail/example.com.cfg.lua به عنوان نقطه آغاز پیکربندی استفاده کنید. در اینجا falcot.com.cfg.lua آورده شده است:
VirtualHost "falcot.com"
enabled = true
ssl = {
key = "/etc/ssl/private/falcot.com-key.pem";
certificate = "/etc/ssl/public/falcot.com.pem";
}
برای فعال‌سازی دامنه، یک پیوند نمادین از /etc/prosody/conf.d/ باید موجود باشد. به این صورت آن را ایجاد کنید:
# ln -s /etc/prosody/conf.avail/falcot.com.cfg.lua /etc/prosody/conf.d/
سرویس را راه‌اندازی مجدد کنید تا از پیکربندی جدید استفاده کند.
11.8.4.2. مدیریت سرور XMPP
برخی عملیات مدیریتی با استفاده از ابزار خط-فرمان prosodyctl قابل اجرا هستند. برای نمونه، به منظور افزودن حساب کاربری مدیر که در /etc/prosody/prosody.cfg.lua تعریف شده است.
# prosodyctl adduser joe@falcot.com
11.8.5. اجرای سرویس‌ها روی درگاه ۴۴۳
برخی مدیرسیستم‌ها ترجیح می‌دهند که تمام سرویس‌های RTC روی درگاه ۴۴۳ اجرا شوند. این امر به کاربرانی که از مکان‌های راه‌دور مانند هتل‌ها یا فرودگاه‌ها قصد ارتباط دارند اجازه می‌دهد که در صورت مسدود بودن سایر درگاه‌ها یا مسیریابی ترافیک اینترنت از طریق سرورهای پروکسی HTTP، به سرویس مورد نظر خود دسترسی داشته باشند.
برای استفاده از این راهبرد، هر سرویس (SIP، XMPP و TURN ) نیازمند یک نشانی IP متفاوت است. تمام سرویس‌ها می‌توانند روی یک میزبان قرار گیرند چرا که لینوکس از نشانی‌های IP گوناگون در یک رایانه پشتیبانی می‌کند. درگاه ۴۴۳ باید در فایل پیکربندی هر سرویس و رکوردهای SRV مربوط به DNS درج گردد.
فالکوت می‌خواهد به مشتریان خود اجازه دهد که از طریق وبسایت اقدام به برقراری تماس تلفنی کنند. مدیرسیستم‌های فالکوت همچنین می‌خواهند از WebRTC به عنوان بخشی از طرح بازیابی در موقع اضطرار استفاده کنند، تا کارکنان بتوانند از خانه خود با استفاده از مرورگر وب به سیستم تلفنی شرکت دسترسی داشته باشند، در زمان اضطرار.
WebRTC یک فناوری رو به رشد است و استفاده از بسته‌های موجود در توزیع‌های jessie-backports و Testing امری ضروری به حساب می‌آید.
JSCommunicator یک تلفن مبتنی بر WebRTC است که به هیچ اقدام سمت-سرور از جمله PHP نیاز ندارد. این ابزار به صورت انحصاری توسط HTML، CSS و JavaScript تولید شده است که پایه و اساس بسیاری از افزونه‌های WebRTC و چارچوب‌های نرم‌افزاری مبتنی بر وب به حساب می‌آید.
بسته
jscommunicator-web-phone یکی از ساده‌ترین روش‌های نصب تلفن WebRTC روی یک وبسایت است. این بسته نیازمند یک پروکسی SIP همراه با انتقال WebSocket است. توضحیات داخل
قسمت 11.8.3.1, “نصب پروکسی SIP”
شامل جزئیات لازم برای راه‌اندازی انتقال WebSocket درون پروکسی SIP
repro است.
پس از نصب jscommunicator-web-phone، راه‌های مختلفی برای استفاده از آن وجود دارد. یک راهبرد ساده رونوشت گرفتن از فایل پیکربندی /etc/jscommunicator-web-phone/apache.conf درون پیکربندی گروه مجازی آپاچی است.
زمانی که فایل‌های تلفن-وب در سرور موجود باشند، با سفارشی‌کردن /etc/jscommunicator-web-phone/config.js و اشاره به سرور TURN و پروکسی SIP، پیکربندی را انجام دهید. برای نمونه:
JSCommSettings = {
// Web server environment
webserver: {
url_prefix: null // If set, prefix used to construct sound/ URLs
},
// STUN/TURN media relays
stun_servers: [],
turn_servers: [
{ server:"turn:turn-server.falcot.com?transport=udp", username:"joe", password:"j0Ep455d" }
],
// WebSocket connection
websocket: {
// Notice we use the falcot.com domain certificate and port 8443
// This matches the Transport3 and Transport4 example in
// the falcot.com repro.config file
servers: 'wss://falcot.com:8443',
connection_recovery_min_interval: 2,
connection_recovery_max_interval: 30
},
...
وبسایت‌های پیشرفته‌تر از اسکریپت‌های سمت-سرور به منظور تولید فایل
config.js به صورت پویا استفاده می‌کنند. سورس کد
DruCall چگونگی استفاده از آن در PHP را نمایش می‌دهد.
این فصل به بررسی تنها قسمتی از نرم‌افزار سرور پرداخت؛ اگرچه، اکثر سرویس‌های متداول شبکه توضیح داده شدند. اکنون زمان بررسی یک فصل فنی‌تر فرا رسیده است. اکنون به بررسی مفاهیم مجازی‌سازی و جزئیات پیاده‌سازی آن می‌پردازیم.
