11.8. خدمات التواصل في الزمن الحقيقي
تشمل خدمات التواصل في الزمن الحقيقي (Real-Time Communication أو RTC اختصاراً) خدمات نقل الصوت، والفيديو أو كميرات الوب، والتواصل المباشر (instant messaging — IM) ومشاركة سطح المكتب. يقدم هذا الفصل مدخلاً مختصراً إلى ثلاثة خدمات مطلوبة لتشغيل RTC، يشمل إعداد مخدم TURN، ومخدم SIP ومخدم XMPP. هناك تفاصيل موسعة عن كيفية التخطيط لهذه الخدمات وتثبيتها وإدارتها في دليل البدء السريع مع اتصالات الزمن الحقيقي (Real-Time Communications Quick Start Guide) الذي يحوي أمثلة خاصة بدبيان.
يوفر كلاً من SIP وXMPP نفس الوظائف. لكن SIP معروف أكثر في مجال الصوت والفيديو بينما يعتبر XMPP تقليدياً بروتوكولاً للمراسلة الفورية (IM). في الواقع، يمكن استخدام أي منهما لأي من هذه الأغراض. من المستحسن استخدام الاثنين معاً على التوازي لزيادة خيارات الاتصال.
11.8.1. إعدادات DNS لخدمات RTC
تحتاج خدمات RTC لسجلات DNS SRV وNAPTR. هذا مثال عن إعداد يمكن وضعه في ملف المنطقة الخاص بنطاق 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 والجدران النارية على اكتشاف الطريق الأكثر فعالية للتواصل فيما بينهم ونقل تيار البيانات (stream) إذا لم يعثروا على طريق مباشر لنقل الوسائط. ينصح بشدة بتثبيت مخدم TURN قبل إتاحة أي خدمة RTC أخرى للمستخدمين النهائيين.
TURN وبروتوكول ICE المرتبط بها هما معياران مفتوحان. من المهم أن تضمن أن كافة برمجيات العملاء تدعم ICE وTURN للاستفادة من هذين المعيارين وتحقيق أعظم قدر من الاتصالية وتقليل خيبات المستخدمين إلى أدنى حد.
يجب أن يملك المخدم عنواني IPv4 عموميين حتى تعمل خوارزمية ICE بفعالية.
11.8.2.1. تثبيت مخدم TURN
ثبت الحزمة 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
استخدم إشارة HUP لجعل المخدم يعيد تحميل الملف /etc/reTurn/users.txt بعد تعديله أو فعّل ميزة إعادة التحميل الآلي في /etc/reTurn/reTurnServer.config.
يدير مخدم بروكسي SIP اتصالات SIP الواردة والصادرة بين المنظمات الأخرى، أو مزودي SIP trunking، أو مقاسم SIP الهاتفية الخاصة (Private Automatic Branch eXchange أو PBX اختصاراً) مثل Asterisk، أو هواتف SIP، أو تطبيقات المهاتفة وWebRTC المعتمدة على SIP.
ننصح بشدة أن تثبت بروكسي SIP وتضبطه قبل محاولة تثبيت SIP PBX (المقسم الهاتفي الخاص). ينظم بروكسي SIP جزءاً كبيراً من البيانات الواردة إلى PBX ويسمح بدرجات أعلى من القدرة على الاتصال والمتانة.
11.8.3.1. تثبيت بروكسي SIP
ثبّت الحزمة repro. ننصح بشدة باستخدام الحزمة من jessie-backports، لأنها تحوي آخر التحسينات لزيادة القدرة على الاتصال والمتانة.
حرر ملف الإعداد /etc/repro/repro.config. أهم شيء تفعله هو إدخال عناوين IP المخدم. يوضح المثال أدناه طريقة إعداد SIP عادي وأيضاً WebSockets/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 كما يجب أن يطابق اسم realm القيمة المحددة في الملف repro.config.
# htdigest /etc/repro/users.txt repro admin
إعادة تشغيل الخدمة لاعتماد الإعدادات الجديدة.
11.8.3.2. إدارة بروكسي SIP
انتقل إلى واجهة الوب على http://sip-proxy.falcot.com:5080 لإكمال الإعداد بإضافة النطاقات، والمستخدمين المحليين، والمسارات الستاتيكية (static routes).
الخطوة الأولى هي إضافة النطاق المحلي. يجب إعادة تشغيل العملية بعد إضافة أو حذف النطاقات من القائمة.
يعرف البروكسي كيفية توجيه الاتصالات بين المستخدمين المحليين وعناوين SIP الكاملة، لن تحتاج إلى ضبط التوجيه إلا إذا أردت تغيير السلوك الافتراضي، مثلاً، للتعرف على أرقام الهواتف، وإضافة سابقة لها وتوجيهها إلى مزود SIP.
يدير مخدم XMPP الاتصالات بين مستخدمي XMPP المحليين ومستخدمي XMPP في النطاقات الأخرى على الإنترنت العام.
Prosody هو مخدم XMPP شهير يعمل بشكل موثوق على مخدمات دبيان.
11.8.4.1. تثبيت مخدم XMPP
ثبّت الحزمة prosody. ننصح بشدة باستخدام الحزمة من jessie-backports، لأنها تحوي آخر التحسينات لزيادة القدرة على الاتصال والمتانة.
راجع ملف الإعداد /etc/prosody/prosody.cfg.lua. أهم شيء تفعله هو إدخال JIDs للمستخدمين الذين يُسمَح لهم بإدارة المخدم.
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. تشغيل الخدمات على المنفذ 443
بفضل بعض مديرو النظم تشغيل كافة خدمات RTC على المنفذ 443. يساعد هذا المستخدمين على الاتصال من المواقع البعيدة مثل الفنادق والمطارات لأن المنافذ الأخرى قد تحجب أو قد تستخدم مخدمات HTTP وسيطة لتمرير الاتصال بالإنترنت.
لاستخدام هذه الاستراتيجية، ستحتاج كل خدمة (SIP، وXMPP وTURN) لعنوان IP مختلف. يمكن أن تبقى الخدمات كلها على المضيف نفسه حيث يدعم لينكس تعدد عناوين IP للمضيف الواحد. يجب تحديد رقم المنفذ 443 في ملفات الإعداد لكل عملية وأيضاً في سجلات DNS SRV.
تريد فلكوت السماح للزبائن بالاتصال هاتفياً مباشرة من موقع الوب. كما يريد مديرو النظم في فلكوت أيضاً استخدام WebRTC كجزء من خطتهم للإنقاذ من الكوارث، بحيث يستطيع الموظفون استخدام متصفحات الوب من بيوتهم للدخول إلى نظام الشركة الهاتفي والعمل بشكل طبيعي في حالات الطوارئ.
WebRTC تقنية تتطور بسرعة ومن المهم استخدام الحزم من jessie-backports أو التوزيعة الاختبارية.
JSCommunicator هو هاتف WebRTC عام، وليس له علامة تجارية، ولا يحتاج لسكربتات على طرف المخدم مثل PHP. مبني بالكامل باستخدام HTML، وCSS، وJavaScript. وهو الأساس في خدمات WebRTC عديدة أخرى بالإضافة إلى وحدات لأطر النشر على الوب الأكثر تقدماً.
أسرع طريقة لتثبيت هاتف WebRTC على موقع وب هي عن طريق الحزمة
jscommunicator-web-phone. تحتاج الخدمة لبروكسي SIP مع نقل WebSocket. تتضمن التعليمات في
قسم 11.8.3.1, “تثبيت بروكسي SIP” التفاصيل اللازمة لتفعيل نقل WebSocket في
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.
استعرض هذا الفصل جزءاً من برمجيات المخدمات المتاحة فقط؛ لكنه شرح معظم الخدمات الشبكية الشائعة. حان الوقت الآن للدخول في فصل تقني أكثر: سوف نتعمق في تفاصيل بعض المفاهيم، ونشرح عمليات التنصيب على نطاق واسع، والحوسبة الظاهرية.
