تسعى مجموعة الوثائق لهذا المنتج جاهدة لاستخدام لغة خالية من التحيز. لأغراض مجموعة الوثائق هذه، يتم تعريف "خالية من التحيز" على أنها لغة لا تعني التمييز على أساس العمر، والإعاقة، والجنس، والهوية العرقية، والهوية الإثنية، والتوجه الجنسي، والحالة الاجتماعية والاقتصادية، والتمييز متعدد الجوانب. قد تكون الاستثناءات موجودة في الوثائق بسبب اللغة التي يتم تشفيرها بشكل ثابت في واجهات المستخدم الخاصة ببرنامج المنتج، أو اللغة المستخدمة بناءً على وثائق RFP، أو اللغة التي يستخدمها منتج الجهة الخارجية المُشار إليه. تعرّف على المزيد حول كيفية استخدام Cisco للغة الشاملة.
ترجمت Cisco هذا المستند باستخدام مجموعة من التقنيات الآلية والبشرية لتقديم محتوى دعم للمستخدمين في جميع أنحاء العالم بلغتهم الخاصة. يُرجى ملاحظة أن أفضل ترجمة آلية لن تكون دقيقة كما هو الحال مع الترجمة الاحترافية التي يقدمها مترجم محترف. تخلي Cisco Systems مسئوليتها عن دقة هذه الترجمات وتُوصي بالرجوع دائمًا إلى المستند الإنجليزي الأصلي (الرابط متوفر).
يصف هذا المستند الأساسيات لبروتوكولات VoIP المختلفة لمساعدة المهندسين في أستكشاف الأخطاء وإصلاحها بشكل فعال على جدران الحماية الآمنة.
لا توجد متطلبات خاصة لهذا المستند.
تم تصميم هذا المستند للاستخدام في سيناريوهات أستكشاف الأخطاء وإصلاحها مع هذه الأجهزة:
تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.
يعد التواصل عنصرا أساسيا للتفاعلات بين البشر، حيث أصبحت بروتوكولات نقل الصوت عبر بروتوكول الإنترنت (VoIP) تشكل أهمية لا غنى عنها للتواصل البشري. ولهذا السبب، من المهم معرفة الأجزاء الخاصة بهم عند أستكشاف أخطاء سيناريو يتضمن جدار حماية (FW) وإصلاحها.
يتكون بروتوكول VoIP من جزئين:
تبدأ إتصالات VoIP دائما بجزء إرسال إشارات لبدء مكالمة، ثم يتم بث الوسائط (الصوت أو الفيديو)، وفي النهاية ينتهي إرسال الإشارات المكالمة.
ملاحظة: بروتوكول SIP هو البروتوكول الأكثر إستخداما، لذلك يتم تمثيله بشكل ثابت كأيقونة SIP Voice Server في العديد من المخططات.
تلميح: عند أستكشاف أخطاء صوت ASA أو FTD وإصلاحها، من المهم للغاية مراعاة السيناريو من منظور المستخدم. تحتاج إلى تحديد ما إذا كانت المكالمة قد تم إنشاؤها أو ما إذا كان هناك صوت أو صوت أحادي الإتجاه. توفر هذه المعلومات أدلة قيمة حول ما إذا كانت المشكلة تقع على بروتوكول الإشارات أو بروتوكول الوسائط (الصوت أو الفيديو).
تلميح: يمكن للجهاز الصوتي إدارة حركة مرور بروتوكول نقل الصوت في الوقت الفعلي (RTP) أو حركة مرور الإشارات أو كليهما في الوقت نفسه. عند أستكشاف مشكلات الصوت وإصلاحها، فمن الضروري تذكر هذه المفاهيم الرئيسية:
++خوادم إرسال الإشارات: هذه الخوادم مسؤولة عن معالجة حركة مرور الإشارات فقط.
++خوادم الوسائط: تتعامل هذه الخوادم مع حركة مرور بيانات RTP الصوتية بشكل حصري.
++يمكن لبعض الأجهزة معالجة كلا المهمتين.
يعد بروتوكول إرسال الإشارات جزءا من مكالمة تعمل على بدء الاتصال الصوتي، وليس ذلك فحسب، بل إنه يقوم أيضا بأداء الوظائف التالية:
تساعد الأنواع المختلفة من بروتوكولات إرسال الإشارات في إنشاء مكالمة، ومن أكثرها شيوعا ما يلي:
تلميح: من الضروري تحديد بروتوكول إرسال الإشارات المستخدم لتحديد المنافذ المناسبة لالتقاط الحزمة على ASA أو FTD. وبالإضافة إلى ذلك، فإن وجود تدفق مكالمات وهيكل الشبكة مفيد لفهم مسار الإشارات.
ملاحظة: تتضمن حزم إرسال الإشارات عناوين IP للمصدر والوجهة، مما يساعد في تعريف الأطراف المعنية في إرسال تدفق وسائط RTP واستقباله.
بعد اكتمال إرسال الإشارات واتفاق مكونات إرسال الإشارات (الأجهزة أو الخوادم) على نوع الوسائط، يتم تشغيل بروتوكول الوقت الفعلي (RTP) لبدء إرسال الوسائط (الصوت و/أو الفيديو) إلى جميع الأطراف المعنية.
RTP هو بروتوكول إنترنت يستخدم للوسائط المتدفقة التي يتم إرسالها فقط بعد إنشاء الاستدعاء وتشغيله عبر بروتوكول مخطط بيانات المستخدم (UDP).
ملاحظة: يمكن أن تكون الوسائط إما صوتا و/أو فيديو وتنتقل على حزم RTP.
تحدد مكونات إرسال الإشارات (الأجهزة أو الخوادم) المنافذ التي يتم إستخدامها لإرسال الوسائط (الصوت و/أو الفيديو) أو تلقيها. عادة ما يكون نطاق المنفذ الأكثر شيوعا ل RTP بين 16384 و 32767 لمعظم الأجهزة.
ملاحظة: تستخدم بعض أجهزة Cisco، مثل الأنظمة الأساسية ل ASR و ISR G3 مثل النظام الأساسي ISR4K، نطاق منفذ RTP معاييرا يتراوح من 8000 إلى 48200. ومن المهم التحقق من نطاق منفذ RTP المحدد الذي تم تكوينه على أجهزتك، نظرا لأنه يمكن أن يختلف عن هذه القيم الموحدة ويمكن أن يختلف عبر أجهزة الطرف الثالث.
تلميح: في بعض الأحيان يختلف مسار RTP عن مسار الإشارات، مما يجعل من الضروري تحديد الأجهزة المسؤولة عن إرسال حزم RTP الصوتية واستقبالها. هذا يضمن أن أنت على قبض udp حركة مرور بين الأداة يجتاز ال ASA أو FTD.
هناك إثنان من دفق الوسائط أو دفق RTP التي يتم إنشاؤها في مكالمة صوتية عادية:
ملاحظة: لأغراض التوضيح، يتم إستخدام أيقونة خادم SIP لتمثيل خادم الإشارات أو خادم الوسائط في جميع الصور.
عند مناقشة دفق الإعلام في مكالمة صوتية، من المهم تسليط الضوء على سيناريوهين رئيسيين:
تدفق الوسائط هو وضع تتم فيه معالجة كل من الوسائط (الصوت و/أو الفيديو) وحزم إرسال الإشارات بواسطة نفس الجهاز.
تدفق تدفق الوسائط هو وضع يتم فيه معالجة حزم الإشارات بواسطة مكونين منفصلين لإرسال الإشارات (أجهزة أو خوادم)، بينما تتم إدارة تدفق الوسائط (الصوت أو الفيديو) بواسطة جهاز ثالث معروف باسم جهاز الوسائط.
يوضح هذا الوضع أدوار الأجهزة المعنية والتمييز بين الإشارات وتدفقات أو أجهزة الوسائط.
ملاحظة: وهذا مهم بشكل خاص لذكره عند أستكشاف أخطاء قائمة الوصول التي تم إنشاؤها وإصلاحها قد يسمح بمكونات إرسال الإشارات (الأجهزة أو الخوادم)، ولكن إذا كان دفق الوسائط يستخدم جهاز وسائط آخر، فنحن بحاجة إلى السماح به أيضا على قائمة الوصول الخاصة بجهاز FW.
SIP هو بروتوكول تحكم من طبقة التطبيقات تم تعريفه من قبل فريق عمل هندسة الإنترنت (IETF) في RFC 3261.
SIP هو بروتوكول مستند إلى نص. وهذا يعني أن رسائل SIP تتألف من نص يمكن قراءته من قبل الإنسان، يشبه كيفية عمل HTTP.
تم تصميم SIP لمعالجة وظائف الإشارات وإدارة الجلسات داخل شبكة مهاتفة الحزمة.
SIP يمكنها:
يمكن إستخدام SIP إما UDP أو TCP على المنفذ الموحد 5060. وإذا تم تشفير بروتوكول SIP باستخدام أمان طبقة النقل (TLS)، فيمكنه إستخدام المنفذ الموحد 5061.
ملاحظة: عند تشفير إشارات SIP، لا تكون حزم SIP الفعلية مرئية في التقاط الحزم على أجهزة ASA أو FTD. ومع ذلك، ما تزال قادرا على ملاحظة مصافحة TCP التي تليها مصافحة TLS بين عملاء SIP وأجهزة خادم SIP.
ملاحظة: يتم تمكين فحص SIP بشكل افتراضي على Cisco Secure Firewall Threat Defense (FTD) وأجهزة الأمان المعدلة لجدار الحماية الآمن (ASA).
تحذير: يدعم دائما المنافذ التي يتم إستخدامها لإرسال الإشارات. تذكر أن بروتوكول SIP يستخدم عادة المنافذ 5060 أو 5061، ولكن بعض عمليات النشر يمكن أن تنحرف عن هذه المعايير وتستخدم منافذ مختلفة لبروتوكول SIP.
هناك ثلاثة سيناريوهات يمكن العثور عليها عند أستكشاف أخطاء إرسال إشارات SIP وإصلاحها:
رسائل SIP الرئيسية لإنشاء مكالمة صوتية وإنهائها هي التالية:
رسائل خيارات SIP مهمة لتحديد ما إذا كان جهاز SIP متصلا وقادرا على الاستجابة. إنها مثل رسالة ping ICMP ولكنها موجودة على عالم SIP.
رسالة SIP أخرى يمكنك العثور عليها أثناء جلسة أستكشاف أخطاء جدار الحماية وإصلاحها هي رسالة سجل SIP، والتي تمكن الجهاز من التسجيل مع خادم SIP.
يوضح التقاط الحزمة هذا الطلبات والاستجابات من جهازي SIP وكذلك حركة مرور الوسائط (الصوت):
هذا مثال على تدفق كل من إشارات SIP ووسائط RTP (الصوت):
بروتوكول وصف جلسة العمل (SDP) هو تمثيل قياسي يستخدم لوصف تدفقات الوسائط لجلسات عمل الوسائط المتعددة. لا يحمل الوسائط نفسه ولكنه يستخدم للتفاوض حول نوع الوسائط وتنسيقها بين نقاط النهاية. يتم إستخدام SDP بالاقتران مع بروتوكول بدء جلسة العمل (SIP) لإدارة خصائص الوسائط والتفاوض عليها لجلسة عمل.
ملاحظة: ويتضمن بروتوكول بوابة الحدود المتعددة الوسائط مفهوم السياسة الإنمائية، الذي يستخدم للغرض نفسه.
هذا مثال على رسالة SDP داخل بروتوكول SIP:
INVITE sip:2003@192.168.245.9:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.245.6:5060;branch=z9hGXXX5763
Remote-Party-ID: ;party=calling;screen=no;privacy=off
From: ;tag=4E3XXXC-A9F
To:
Date: Thu, 17 Aug 2025 13:48:52 GMT
Call-ID: 2A7BE22B-XXXXXXXXX-XXXXXXXXX-F940DC75@192.168.245.6
Supported: 100rel,timer,resource-priority,replaces,sdp-anat
Min-SE: 1800
Cisco-Guid: 0350227076-XXXXXXXXX-XXXXXXXXX-1670485135
User-Agent: Cisco-SIPGateway/IOS-15.5.3.S4b
Allow: INVITE, OPTIONS, BYE, CANCEL, ACK, PRACK, UPDATE, REFER, SUBSCRIBE, NOTIFY, INFO, REGISTER
CSeq: 101 INVITE
Timestamp: 150299CC32
Contact:
Expires: 180
Allow-Events: telephone-event
Max-Forwards: 69
Content-Type: application/sdp <=======Session Description Protocol message start
Content-Disposition: session;handling=required
Content-Length: 266
v=0
o=CiscoSystemsSIP-GW-UserAgent 7317 4642 IN IP4 192.168.245.6
s=SIP Call
c=IN IP4 192.168.245.6
t=0 0
m=audio 8266 RTP/AVP 18 127
c=IN IP4 192.168.245.6
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:127 telephone-event/8000
a=fmtp:127 0-16
a=ptime:20
ملاحظة: تحتوي بعض رسائل SDP على هذه المعلمات في المثال:
++دخل c IP4: عنوان IP الخاص بخادم الوسائط
++M=الصوت: هذا يشير إلى أن نوع الوسائط هو صوت.
++8266: هذا هو رقم المنفذ الذي يتم إرسال تدفق الصوت عليه.
++RTP/AVP: هذا يحدد بروتوكول النقل، وهو RTP باستخدام ملف تعريف الصوت/الفيديو (AVP).
++18 127: هذه هي أنواع الحمولة لبرامج تشفير الصوت. يماثل نوع الحمولة 18 بشكل خاص ترميز G.729، و 127 هو نوع حمولة ديناميكي يمكن تعيينه إلى ترميز حسب التفاوض بين نقاط النهاية.
يمكن العثور على بروتوكول وصف جلسة العمل (SDP) داخل العديد من رسائل SIP مثل: دعوة، جلسة 183 قيد التقدم، 200 موافق، ACK، وهكذا. يعمل SDP كطريقة جواب لتبادل إمكانيات الصوت و/أو الفيديو بين الأطراف. عند أستكشاف أخطاء المكالمات وإصلاحها، فمن الضروري فهم ثلاثة مفاهيم رئيسية:
ملاحظة: من المهم فهم وجهة رسائل SDP، حيث يمكن لميزة الفحص على جدار الحماية تعديل عناوين IP ليس فقط داخل رؤوس SIP ولكن أيضا في قسم SDP.
هنا يتم العثور على معلمات الوسائط على SDP داخل رسائل INVITE و 200 OK SIP.
على هذه الطريقة، يتم العثور على بروتوكول SDP على 200 رسالة OK و ACK SIP.
يتم إرسال الوسائط الأولى من خلال رسالة SIP محددة تعرف باسم الاستجابة لتقدم الجلسة 183. تتضمن هذه الرسالة بروتوكول وصف جلسة العمل (SDP) الذي يحتوي على معلمات الوسائط للطرف المستدعي. يستخدم بشكل شائع من قبل شركات الاتصالات وموفري نظام SIP لإرسال رسائل صوتية مؤتمتة أو وسائط أخرى إلى المتصل قبل توصيل المكالمة رسميا.
H.323 هو مجموعة من البروتوكولات التي حددها الاتحاد الدولي للاتصالات السلكية واللاسلكية (ITU) لاتصالات الصوت والفيديو والبيانات عبر الشبكات التي يتم تحويلها إلى حزم، مثل الإنترنت.
يتألف بروتوكول H.323 من مكونين رئيسيين:
الميناء أن يكون استعملت ب H.323 signaling بروتوكول 1718، 1719، و 1720.
تلميح: قد تواجه إتصالات بروتوكول H.323 الآمنة مشاكل عند التحويل من UDP إلى TCP بسبب إستخدام TLS للتشفير، والذي يمكن أن يتسبب في قيام جدار الحماية بحظر الاتصال عن طريق الخطأ كنشاط مريب، لذلك من المهم تكوين جدار الحماية للسماح بكل من حركة مرور UDP و TCP لنقاط النهاية أو الخوادم H.323.
H.323 هو بروتوكول يحتوي على وضعي تشغيل: بداية بطيئة وبداية سريعة.
يكون هذا البروتوكول مسؤولا عن إعداد المكالمة وإنهاء مكالمة صوتية عند توقف أحد الطرفين.
يوفر H.245 هذه الوظائف:
ملاحظة: إن المصطلحين "سيد" و"تابع" المستخدمين في هذا المستند تم ترميزهما في بروتوكول H.323 الأصلي ولا يعكسان سياسات أو قيم شركتنا. ونحن ملتزمون بتعزيز لغة شاملة للجميع ومحترمة.
يتم إرسال بروتوكول H.245 بعد تلقي رسالة اتصال H.225.
يساعد هذا بروتوكول في تحديد بروتوكول الصوت المستخدم ل RTP، ويتم تحديده على القناة المنطقية المفتوحة وإغلاق رسائل القناة المنطقية له.
يوضح التقاط الحزمة هذا الطلبات والاستجابات من جهازين H.323 مع H.225 و H.245 وأيضا الوسائط(الصوت) حركة مرور:
هذا مثال على تدفق كل من إشارات H.323 مع H.225 و H.245 ووسائط RTP (الصوت):
ملاحظة: يتم تمكين فحص H.323 بشكل افتراضي على Cisco Secure Firewall Threat Defense (FTD) وأجهزة الأمان المعدلة لجدار الحماية الآمن (ASA).
في وضع البدء البطيء، تتضمن عملية إعداد المكالمة عدة خطوات إرسال إشارات قبل إنشاء قنوات الوسائط. تتضمن الخطوات الإعداد ومتابعة المكالمة والتنبيه والاتصال. بعد هذه الخطوات، يتم إجراء تفاوض وسائط H.245 بشكل منفصل. وهذا يعني أنه لا يتم إنشاء قنوات الوسائط إلا بعد اكتمال إرسال إشارات المكالمات الأولية، مما يمكن أن يؤدي إلى وقت إعداد أطول.
في المقابل، يسمح وضع البدء السريع بإجراء تفاوض الوسائط ضمن رسالة الإعداد الأولي. وهذا يعني أنه يمكن إنشاء قنوات الوسائط بسرعة أكبر، حيث يتم إجراء التفاوض كجزء من إعداد المكالمة الأولية. تعمل البداية السريعة على تنظيم العملية من خلال تقليل عدد الرسائل المتبادلة ومقدار المعالجة المطلوب قبل إنشاء قنوات الوسائط.
بروتوكول Skinny للتحكم في العملاء (SCCP)، والذي غالبا ما يشار إليه باسم Skinny، هو بروتوكول لإرسال الإشارات خاص من Cisco. ويتم إستخدامه بشكل أساسي بواسطة موجهات Cisco Unified Communications Manager (CUCM) وموجهات Cisco Unified Communications Manager Express (CME) وهواتف Cisco IP لتسهيل إعداد المكالمات والتحكم فيها.
يستخدم بروتوكول SCCP بروتوكول TCP على المنفذ 2000 ل SCCP غير الآمن ويستخدم المنفذ 2443 لبروتوكول SCCP الآمن.
هذه هي رسائل SCCP الشائعة التي يمكنك العثور عليها على مكالمة SCCP:
يوضح التقاط الحزمة هذا الطلبات والاستجابات من جهازين SCCP وأيضا حركة مرور الوسائط (الصوت):
هذا مثال على تدفق كل من إشارات SCCP ووسائط RTP (الصوت):
ملاحظة: يتم تمكين فحص SCCP بشكل افتراضي على Cisco Secure Firewall Threat Defense (FTD) وأجهزة الأمان المعدلة لجدار الحماية الآمن (ASA).
بروتوكول التحكم في عبارة الوسائط (MGCP) هو بروتوكول يستخدم للتحكم في مكالمات VoIP بواسطة جهاز التحكم في المكالمات، على سبيل المثال CUCM.
يتم تحديد بروتوكول إرسال الإشارات MGCP على RFC 2705 ويستخدم منفذ TCP 2428 ومنفذ UDP 2427 للاتصالات.
حزم MGCP العادية التي تتوقعها لاتصال المكالمة هي:
ملاحظة: لم يتم تمكين فحص MGCP في سياسة التفتيش الافتراضية على Cisco Secure Firewall Threat Defense (FTD) وجهاز الأمان القابل للتكيف (ASA) لجدار الحماية الآمن من Cisco، لذلك يجب تمكينه إذا كنت بحاجة إلى هذا الفحص.
يظهر التقاط الحزمة هذا الطلبات والاستجابات من جهازين MGCP وأيضا الوسائط (الصوت) حركة مرور:
هذا مثال على تدفق كل من إشارات MGCP ووسائط RTP (الصوت):
بالنسبة إلى ASA:
ملاحظة: تذكر أن أجهزة الصوت أو الوسائط هذه يمكن أن تختلف عن مكونات إرسال الإشارات (الأجهزة أو الخوادم).
بالنسبة إلى FTD:
عند أستكشاف مشكلات الصوت وإصلاحها، يلزمك معرفة ما إذا كانت المشكلة هي الإشارات أو الوسائط (الصوت أو الفيديو) أو كليهما، فيما يلي بعض الأمثلة التي يمكن أن ترشدك إلى التمييز بين هذه الأمور:
مثال على مشاكل الإشارات:
++يبلغ المستخدم عن عدم إنشاء المكالمة.
++يتعذر على المستخدم الاتصال بمستخدمين أو أرقام أخرى.
++خط اتصال SIP لا يظهر، لأن رسالة SIP للخيارات لا تتلقى إستجابة.
++جهازي غير قادر على التسجيل.
مثال على مشاكل الوسائط (الصوت أو الفيديو):
++هناك مشكلة صوتية أحادية الإتجاه.
++لا يوجد صوت قيد الاتصال.
++لا يوجد فيديو على الإطلاق.
++المكالمة صامتة.
تلميح: وخلال مكالمة فيديو، يمكن لبروتوكول SDP التفاوض حول ما يصل إلى ثلاثة خطوط وسائط (m-line): الصوت والفيديو والصورة. يتوافق كل خط من خطوط M مع تدفق منفصل لبروتوكول نقل الوقت الفعلي (RTP) لكل ساق اتصال، مما يعني أنه يمكن أن يكون هناك ما يصل إلى ثلاثة مسارات RTP منفصلة - واحد لكل نوع وسائط - في كل نقطة من الاتصال.
لاستكشاف أخطاء جزء الإشارات وإصلاحها، يجب التأكد من:
++التعرف على جميع مكونات إرسال الإشارات (الأجهزة أو الخوادم) المعنية في المكالمة من كل من واجهة الدخول والخروج وتكوين معايير المطابقة المناسبة على لقطات الحزمة على واجهة سطر الأوامر (CLI) لأي من "تأمين FW".
++تذكر أن عدد رسائل الإشارات في واجهة الدخول يجب أن يطابق واجهة المخرج.
++التقاط الحزمة يمكن جعله أكثر فعالية من خلال تحديد ما إذا كان بروتوكول إرسال الإشارات يستخدم TCP أو UDP ومن خلال التصفية لرقم المنفذ المتوقع. ونظرا لأن جميع بروتوكولات إرسال الإشارات تعمل عبر IP، يساعد تطبيق عوامل التصفية هذه على واجهة سطر الأوامر (CLI) على تقييد مقدار حركة مرور البيانات التي تراها في عمليات الالتقاط الخاصة بك.
++لواجهات الخروج فقط، تأكد من تحديد عنوان NAT IP الذي تم تعيينه لحركة المرور الصادرة في عامل تصفية التقاط الحزمة. هذا يضمن أنت التقط الحركة مرور صحيح كما هو يظهر على المخرج قارن.
ملاحظة: تذكر أنه بغض النظر عن أي بروتوكول إرسال الإشارات يتم إستخدامه للصوت، يجب أن يكون هناك دائما طلب ورد، ويجب أن يكون ثابتا على كل من واجهات الدخول والخروج.
ملاحظة: تأكد كلما أمكن ذلك من أنه لا يوجد سوى جدار حماية واحد مشترك في مسار الاتصال. في بعض عمليات النشر، يمكن أن تجتاز إشارات الصوت ودفقات الوسائط جدران حماية منفصلة. في هذه الحالات، تأكد من تضمين جميع جدران الحماية ذات الصلة في عملية أستكشاف الأخطاء وإصلاحها
من وجهة نظر FW، سيكون هناك 4 عمليات دفق يجب تحليلها عند أستكشاف مشكلات الصوت أحادي الإتجاه أو مشكلات الصوت المزدوجة الإتجاه أو عدم وجود صوت:
تدفق RTP من المتصل إلى المتصل (واجهة الدخول).
تدفق RTP من المتصل إلى المتصل (واجهة الخروج).
تدفق RTP من المتصل إلى المتصل (واجهة الخروج).
تدفق RTP من المتصل إلى المتصل (واجهة الدخول).
ملاحظة: تأكد من تنفيذ أستكشاف الأخطاء وإصلاحها باستخدام حزم واجهة سطر الأوامر (CLI) على وضع ASA أو LINA على FTD، حيث يوفر ذلك مرونة أكبر لتطبيق تطابقات متعددة داخل التقاط حزمة واحد.
عند أستكشاف أخطاء الصوت وإصلاحها على وضع FW الآمن (ASA أو FTD)، يلزمك تنفيذ الخطوات التالية:
تلميح: كما يجب أن تكون رسائل إرسال إشارات SIP التي تدخل FW هي نفسها التي تترك FW.
ملاحظة: يمكن أيضا تطبيق تلميحات أستكشاف المشكلات وإصلاحها ل SIP على بروتوكولات H.323 و MGCP و SCCP.
المراجعة | تاريخ النشر | التعليقات |
---|---|---|
1.0 |
06-Aug-2025
|
الإصدار الأولي |