أستكشاف أخطاء مكالمات VoIP وإصلاحها

المقدمة

يصف هذا المستند التقنيات والأوامر الأساسية لاستكشاف أخطاء شبكات VoIP وإصلاحها.

المتطلبات الأساسية

المتطلبات

توصي Cisco بأن تكون لديك معرفة بالمواضيع التالية:

• تكوين بروتوكول VoIP

• جودة خدمة الصوت

• تصميم شبكات الصوت عبر بروتوكول الإنترنت (VoIP) ونشرها

المكونات المستخدمة

لا يقتصر هذا المستند على إصدارات برامج ومكونات مادية معينة. ومع ذلك، تستند المخرجات الموضحة إلى برنامج Cisco IOS® الإصدار 12.3(8).

تم إنشاء المعلومات الواردة في هذا المستند من الأجهزة الموجودة في بيئة معملية خاصة. بدأت جميع الأجهزة المُستخدمة في هذا المستند بتكوين ممسوح (افتراضي). إذا كانت شبكتك قيد التشغيل، فتأكد من فهمك للتأثير المحتمل لأي أمر.

الاصطلاحات

للحصول على مزيد من المعلومات حول اصطلاحات المستندات، ارجع إلى اصطلاحات تلميحات Cisco التقنية.

معلومات أساسية

يوضّح هذا المستند الأساليب والأوامر الأساسية لاستكشاف أخطاء شبكات VoIP وإصلاحها. يتم تقديم نظرة عامة على تدفق المكالمات الصوتية والبُنى التقنية الهاتفية في أحد موجّهات Cisco، متبوعًا بنهج استكشاف الأخطاء وإصلاحها خطوة بخطوة عبر VoIP المُقدّم في الخطوات التالية:

1. التحقق من الإشارات الرقمية والتناظرية.

2. تحقق من الأرقام التي تم إستلامها وإرسالها من منافذ الصوت التناظرية والرقمية.

3. التحقق من إرسال إشارات VoIP الشاملة.

4. فهم مشكلات جودة خدمة (QoS) بروتوكول VoIP.

5. تعرف على تفاصيل أكواد السبب وقيم تصحيح الأخطاء ل VoIP.

ملاحظة: لا يشرح هذا المستند كل واجهة من بنية Cisco IOS المستخدمة في بوابات وبوابات Cisco VoIP. بدلا من ذلك، فإنه يهدف إلى إظهار أي الأوامر يمكن إستخدامه وأي الحقول من مخرجات الأمر يمكن أن تكون أكثر قيمة.

تحذير: يتطلب تصحيح أخطاء برنامج Cisco IOS معالجات كثيرة. توخ الحذر عند إستخدام تصحيح الأخطاء المدرجة في هذا المستند. لمزيد من المعلومات، ارجع إلى معلومات مهمة حول أوامر التصحيح.

يجب تشغيل تصحيح الأخطاء مع تمكين الطوابع الزمنية في السجل. قم بتمكين ختم الوقت باستخدام الأوامر: تصحيح أخطاء datetime msec للأختام الزمنية للخدمة، service timestampslog datetime msec في وضع التمكين. تساعد الطوابع الزمنية في تحديد الفاصل الزمني بين تغييرات الحالة.

تدفق المكالمات في الشبكة

من العوامل المهمة التي يجب مراعاتها قبل بدء أي أستكشاف أخطاء VoIP وإصلاحها أو تصحيح أخطائها أن مكالمات VoIP تتكون من ثلاثة أرجل اتصال. وأرجل المكالمات هذه هي مصدر أنظمة الهاتف القديمة العادية (POTS)، و VoIP، و POTS الوجهة. هذا موضح في هذا الرسم التخطيطي. يجب أولا التركيز على أستكشاف المشكلات وحلها وتصحيح أخطائها كل على حدة ثم التركيز على مكالمة VoIP ككل.

تدفق مكالمات الموجه

توضح هذه التعريفات وظيفة المكونات الرئيسية المعروضة في الرسم التخطيطي لتدفق إستدعاء الموجه:

واجهة برمجة التطبيقات (API) للتحكم في المكالمات— يستخدم ثلاثة عملاء واجهة برمجة التطبيقات (API) للتحكم في المكالمات. العملاء الثلاثة هم CLI، وكيل بروتوكول إدارة الشبكة البسيط (SNMP)، وتطبيق جلسة العمل. الوظائف الرئيسية لواجهة برمجة التطبيقات الخاصة بالتحكم في المكالمات (يشار إليها أيضا باسم CCAPI) هي:

• التعرف على أرجل الاتصال (على سبيل المثال، من أي نظير اتصال هو؟ من أين جاء؟ ).

• تحديد تطبيق جلسة العمل الذي يتلقى المكالمة (على سبيل المثال، من يعالجها؟).

• إستدعاء معالج الحزمة.

• إمكانية عقد المؤتمرات معا.

• بدء تسجيل إحصائيات المكالمات.

تطبيق جلسة العمل ومخطط خطة الطلب— يستخدم تطبيق جلسة العمل معين خطة الطلب لتعيين رقم إلى نظير الطلب (POTS المحلي أو VoIP البعيد). يستخدم معين خطة الطلب جدول نظير الطلب للعثور على نظائر الطلب النشطة.

واجهة مزود خدمة Telephony و VoIP (SPI)—تتصل واجهة SPI الهاتفية بنظم POTS (التناظرية: FXS، FXO، e&m Digital: ISDN، QSIG، e&m، وما إلى ذلك) لنظراء الطلب. إن VoIP SPI هي الواجهة المحددة لنظراء VoIP. توفر برامج التشغيل الهاتفية/DSP الخدمات إلى SPI الهاتفية بينما يعتمد SPI الخاص بتقنية VoIP على بروتوكولات الجلسات.

بنية واجهة الهاتف

يوضح هذا المخطط بنية كتل إنشاء Cisco Router Telephony وكيفية تفاعلها مع بعضها البعض.

تصف هذه القائمة وظائف وتعريفات مكونات المخطط الرئيسي:

• واجهة برمجة تطبيقات التحكم في المكالمات (CCAPI)—وحدة البرامج التي تنشئ أرجل الاتصال وتنتهي منها وتسودها.

• مزود خدمة الهاتف الصوتي (VTSP)—عملية Cisco IOS التي تقدم طلبات من واجهة برمجة التطبيقات (API) الخاصة بالتحكم في المكالمات وتصاغ الطلبات المناسبة لمعالج الإشارة الرقمية (DSP) أو VPM.

• الوحدة النمطية لمعالج الصوت (VPM)— تتولى وحدة إدارة الموارد ل DSP مسؤولية ربط عمليات إرسال الإشارات وتنسيقها بين جهاز حالة إرسال إشارات المنافذ الهاتفية (SSM)، ومدير موارد DSP، و VTSP.

• مدير موارد DSP— يوفر DSPRM واجهات يمكن ل VTSP من خلالها إرسال الرسائل واستقبالها من وإلى DSPs.

• معالج الحزم — يقوم معالج الحزم بإعادة توجيه الحزم بين DSPs وأرجل إستدعاء النظير.

• الند المتصل — الند المتصل هو ساق الاتصال المعاكسة. يمكن أن يكون هذا اتصال صوتي هاتفي آخر (POTS)، أو VoFR، أو VoATM، أو اتصال VoIP.

التحقق من إرسال الإشارات الرقمي والتناظري (POTS Call-LEG)

يتم التحقق من الإشارات الرقمية والتناظرية إلى:

• حدد أنه يتم تلقي الإشارات التناظرية أو الرقمية المناسبة في وضع عدم الاتصال أو عدم الاتصال.

• حدد تكوين إرسال إشارات E&M و FXO و FXS المناسبة على كل من الموجه والمحول (CO أو PBX).

• تحقق من أن DSPs في وضع التجميع الرقمي.

يمكن إستخدام الأوامر الموضحة في هذه الأقسام للتحقق من الإشارات.

إظهار وحدات التحكم T1 / E1 (رقمي)

show controllers t1 [slot/port]- أستخدم هذا الأمر أولا. وهو يوضح ما إذا كان اتصال T1 الرقمي بين الموجه والمحول (CO أو PBX) مرتفعا أو أسفل وما إذا كان يعمل بشكل صحيح. يبدو إخراج هذا الأمر كما يلي:

router# show controllers T1 1/0
T1 1/0 is up.
Applique type is Channelized T1
Cablelength is short 133
No alarms detected.
Framing is ESF, Line Code is B8ZS, Clock Source is Line
Primary.
Data in current interval (6 seconds elapsed):

	0 Line Code Violations, 0 Path Code Violations
	0 Slip Secs, 0 Fr Loss Secs, 0 Line Err Secs, 
  0 Degraded Mins
	0 Errored Secs, 0 Bursty Err Secs, 0 Severely Err Secs,
  0 Unavail Secs

إن يستعمل أنت E1 العرض جهاز تحكم e1 أمر. لمزيد من المعلومات، راجع:

• أستكشاف أخطاء الطبقة الأولى وإصلاحها في T1

• T1 أستكشاف أخطاء المخطط الانسيابي وإصلاحها

• أستكشاف أخطاء الخط التسلسلي وإصلاحها

show voice port

show voice portslot-number/port— أستخدم هذا الأمر لعرض حالة المنفذ والمعلمات التي تم تكوينها على المنفذ الصوتي لبطاقات واجهة الصوت (VIC) من Cisco. مثل جميع أوامر Cisco IOS، لا يتم عرض الإعدادات الافتراضية في show running-config، ولكنها تعرض باستخدام هذا الأمر.

هذا نموذج للمخرجات لمنفذ صوت E&M:

router# show voice port 1/0:1
recEive and transMit Slot is 1, Sub-unit is 0, Port is 1
Type of VoicePort is E&M 
Operation State is DORMANT
Administrative State is UP
No Interface Down Failure
Description is not set
Noise Regeneration is enabled
Non Linear Processing is enabled
Music On Hold Threshold is Set to -38 dBm
In Gain is Set to 0 dB
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Out Attenuation is Set to 0 dB
Echo Cancellation is enabled
Echo Cancel Coverage is set to 16 ms
Connection Mode is normal (could be trunk or plar)
Connection Number is not set
Initial Time Out is set to 10 s
Interdigit Time Out is set to 10 s
Call-Disconnect Time Out is set to 60 s
Region Tone is set for US

Voice card specific Info Follows:
Signal Type is wink-start
Operation Type is 2-wire
E&M Type is 1
Dial Type is dtmf
In Seizure is inactive
Out Seizure is inactive
Digit Duration Timing is set to 100 ms

InterDigit Duration Timing is set to 100 ms
Pulse Rate Timing is set to 10 pulses/second
InterDigit Pulse Duration Timing is set to 500 ms
Clear Wait Duration Timing is set to 400 ms
Wink Wait Duration Timing is set to 200 ms
Wink Duration Timing is set to 200 ms
Delay Start Timing is set to 300 ms
Delay Duration Timing is set to 2000 ms
Dial Pulse Min. Delay is set to 140 ms

debug vpm (وحدة معالج الصوت)

يتم إستخدام هذه الأوامر لتصحيح أخطاء واجهة VPM الهاتفية:

• debug vpm signal — يتم إستخدام هذا الأمر لجمع معلومات تصحيح الأخطاء لأحداث الإشارات ويمكن أن يكون مفيدا لحل المشاكل المتعلقة بالإشارات إلى PBX.

• debug vpm spi — يتتبع هذا الأمر كيفية واجهات واجهة موفر خدمة الوحدة النمطية للمنفذ الصوتي (SPI) مع واجهة برمجة التطبيقات (API) للتحكم في المكالمات. يعرض الأمر debug هذا معلومات حول كيفية معالجة كل إشارة شبكة وطلب تطبيق.

• debug vpm dsp — يعرض هذا الأمر الرسائل من DSP على VPM إلى الموجه ويمكن أن يكون مفيدا إذا كنت تشك في أن VPM لا يعمل. إنها طريقة بسيطة للتحقق من إستجابة وحدة ذاكرة VPM لمؤشرات غير صحيحة وتقييم الوقت لإرسال رسائل الإشارات من الواجهة.

• debug vpm all — يوفر أمر EXEC هذا جميع أوامر debug vpm: debug vpm spi، و debug vpm signal، وdebug vpm dsp.

• debug vpm port — أستخدم هذا الأمر لتحديد إخراج تصحيح الأخطاء على منفذ معين. على سبيل المثال، يعرض هذا الإخراج رسائل تصحيح الأخطاء vpm للمنفذ 1/0/0 فقط:

debug vpm dsp 

debug vpm port 1/0/0 

Sample Output forDebug vpm SignalCommand

maui-voip-austin#debug vpm signal


!--- FXS port 1/0/0 goes from the "on-hook" to "off-hook" !--- state.

htsp_process_event: [1/0/0, 1.2 , 36] 
fxsls_onhook_offhook htsp_setup_ind
*Mar 10 16:08:55.958: htsp_process_event: 
[1/0/0, 1.3 , 8] 


!--- Sends ringing alert to the called phone.

*Mar 10 16:09:02.410: htsp_process_event: 
[1/0/0, 1.3 , 10] htsp_alert_notify
*Mar 10 16:09:03.378: htsp_process_event: 
[1/0/0, 1.3 , 11] 


!--- End of phone call, port goes "on-hook".

*Mar 10 16:09:11.966: htsp_process_event: 
[1/0/0, 1.3 , 6] 
*Mar 10 16:09:17.218: htsp_process_event: 
[1/0/0, 1.3 , 28] fxsls_offhook_onhook
*Mar 10 16:09:17.370: htsp_process_event: 
[1/0/0, 1.3 , 41] fxsls_offhook_timer
*Mar 10 16:09:17.382: htsp_process_event: 
[1/0/0, 1.2 , 7] fxsls_onhook_release

إذا لم يتم إرسال الإشارات بشكل صحيح إلى وضع الاتصال وإيقاف الاتصال، فتحقق من هذه العناصر:

• تحقق من صحة الكبلات.

• دققت أن على حد سواء المسحاج تخديد والمحول (CO أو PBX) ركنت بشكل صحيح.

• تحقق من أن كلا طرفي الاتصال لهما تكوينات إرسال إشارات مكافئة. قد تتسبب التكوينات غير المتطابقة في إرسال إشارات غير كاملة أو أحادية الإتجاه.

لمزيد من المعلومات حول أستكشاف أخطاء E&M وإصلاحها، ارجع إلى فهم أنواع واجهات E & M التناظرية وترتيبات الأسلاك واستكشاف أخطائها وإصلاحها.

Sample Output forDebug vpm spiCommand

maui-voip-austin#debug vpm spi   
Voice Port Module Session debugging is enabled


!--- The DSP is put into digit collection mode.

*Mar 10 16:48:55.710: dsp_digit_collect_on: 
[1/0/0] packet_len=20 channel_id=128
 packet_id=35 min_inter_delay=290 
 max_inter_delay=3200 mim_make_time=18 max_make
_time=75 min_brake_time=18 max_brake_time=75

التحقق من الأرقام التي تم تلقيها وإرسالها (POTS Call-Leg)

بمجرد التحقق من صحة إرسال الإشارات داخل الجهاز وخارجه بشكل صحيح، تحقق من تلقي الأرقام الصحيحة أو إرسالها على المنفذ الصوتي (الرقمي أو التناظري). لا يتطابق نظير الطلب أو لا يتمكن المحول (CO أو PBX) من ربط المحطة الصحيحة إذا تم إرسال أرقام غير كاملة أو غير صحيحة أو تلقيها. بعض الأوامر التي يمكن إستخدامها للتحقق من الأرقام التي تم تلقيها/إرسالها هي:

• show dialplan number — يتم إستخدام هذا الأمر لإظهار نظير الطلب الذي يتم الوصول إليه عند طلب رقم هاتف معين.

• debug vtsp session — يعرض هذا الأمر معلومات حول كيفية معالجة كل إشارة شبكة وطلب تطبيق، ومؤشرات إرسال الإشارات، ورسائل التحكم في DSP.

• debug vtsp dsp — الإصدار الأقدم من الإصدار 12.3 من برنامج Cisco IOS Software، يعرض هذا الأمر الأرقام كما يتم استقبالها بواسطة منفذ الصوت. ومع ذلك، في الإصدار 12.3 من برنامج Cisco IOS Software والإصدارات الأحدث، لم يعد إخراج الأمر debug يعرض الأرقام. يمكن إستخدام مجموعة تفاصيل تصحيح أخطاء HPI وdebug hpinoization لعرض الأرقام الواردة.

• debug vtsp all — يقوم هذا الأمر بتمكين هذه الأوامر debug voice telephony service provider (VTSP): debug vtsp session، debug vtsp error ، و debug vtsp dsp.

إظهار رقم خطة الاتصال

show dialplan number <digit_string>— يعرض هذا الأمر نظير الطلب الذي تطابق بسلسلة من الأرقام. إذا كان يمكن مطابقة العديد من أنداد الطلب، يتم عرض جميع هذه الأجهزة بالترتيب الذي تمت مطابقتها به.

ملاحظة: تحتاج إلى إستخدام علامة # في نهاية أرقام الهاتف الخاصة بأقران الطلب ذوي الطول المتغير للمطابقة على أنماط الوجهة التي تنتهي ب T.

يبدو إخراج هذا الأمر كما يلي:

maui-voip-austin#show dialplan number 5000
Dial string terminator: #
Macro Exp.: 5000

VoiceOverIpPeer2
        information type = voice,
        tag = 2, destination-pattern = `5000',
        answer-address = `', preference=0,
        group = 2, Admin state is up, Operation
        state is up,
        incoming called-number = `', 
        connections/maximum = 0/unlimited,
        application associated: 
        type = voip, session-target = 
        `ipv4:192.168.10.2',
        technology prefix: 
        ip precedence = 5, UDP checksum = 
        disabled, session-protocol = cisco, 
        req-qos = best-effort, 
        acc-qos = best-effort, 
        dtmf-relay = cisco-rtp, 
        fax-rate = voice,   
        payload size =  20 bytes
        codec = g729r8,   
        payload size =  20 bytes,
        Expect factor = 10, Icpif = 30,
        signaling-type = cas,
        VAD = enabled, Poor QOV Trap = disabled, 
        Connect Time = 25630, Charged Units = 0,
        Successful Calls = 25, Failed Calls = 0,
        Accepted Calls = 25, Refused Calls = 0,
        Last Disconnect Cause is "10  ",
        Last Disconnect Text is "normal call 
        clearing.",
        Last Setup Time = 84427934.
        Matched: 5000   Digits: 4
        Target: ipv4:192.168.10.2

debug vtsp جلسة

يعرض الأمر debug vtsp session معلومات حول كيفية تفاعل الموجه مع DSP استنادا إلى إشارات مكدس الإشارات والطلبات من التطبيق. يعرض الأمر debug هذا معلومات حول كيفية معالجة كل إشارة شبكة وطلب تطبيق، ومؤشرات إرسال الإشارات، ورسائل التحكم في DSP.

maui-voip-austin#debug vtsp session 
Voice telephony call control session debugging is on


!--- Output is suppressed. 
!--- ACTION: Caller picked up handset. 
!--- The DSP is allocated, jitter buffers, VAD 
!--- thresholds, and signal levels are set.


*Mar 10 18:14:22.865: dsp_set_playout: [1/0/0 (69)]
packet_len=18 channel_id=1 packet_id=76 mode=1 
initial=60 min=4 max=200 fax_nom=300
*Mar 10 18:14:22.865: dsp_echo_canceller_control: 
[1/0/0 (69)] packet_len=10 channel_id=1 packet_id=66
flags=0x0
*Mar 10 18:14:22.865: dsp_set_gains: [1/0/0 (69)] 
packet_len=12 channel_id=1 packet_id=91 
in_gain=0 out_gain=65506
*Mar 10 18:14:22.865: dsp_vad_enable: [1/0/0 (69)] 
packet_len=10 channel_id=1 packet_id=78 
thresh=-38act_setup_ind_ack 
*Mar 10 18:14:22.869: dsp_voice_mode: [1/0/0 (69)] 
packet_len=24 channel_id=1 packet_id=73 coding_type=1
 voice_field_size=80 
VAD_flag=0 echo_length=64 comfort_noise=1 
inband_detect=1 digit_relay=2 
AGC_flag=0act_setup_ind_ack(): dsp_dtmf_mod
e()act_setup_ind_ack: passthru_mode = 0, 
no_auto_switchover = 0dsp_dtmf_mode
(VTSP_TONE_DTMF_MODE)


!--- The DSP is put into "voice mode" and dial-tone is 
!--- generated.


*Mar 10 18:14:22.873: dsp_cp_tone_on: [1/0/0 (69)] 
packet_len=30 channel_id=1 packet_id=72 tone_id=4 
n_freq=2 freq_of_first=350 freq_of_second=440 amp_of_first=
4000 amp_of_second=4000 direction=1 on_time_first=65535 
off_time_first=0 on_time
_second=65535 off_time_second=0

في حالة تحديد عدم إرسال الأرقام أو إستلامها بشكل صحيح، فمن المحتمل أن يكون من الضروري إستخدام أداة إختبار الحروف الرقمية أو مختبر T1 للتحقق من إرسال الأرقام في الفاصل الزمني الصحيح للتردد والتوقيت. إذا تم إرسالها "بشكل غير صحيح" للمحول (CO أو PBX)، فقد تحتاج بعض القيم على الموجه أو المحول (CO أو PBX) إلى التعديل حتى تتوافق ويمكن أن تعمل معا. وعادة ما تكون هذه المدة ذات أرقام وقيم المدة بين الأرقام. عنصر آخر لفحص ما إذا كانت الأرقام تظهر أنها تم إرسالها بشكل صحيح هو أي جداول ترجمة أرقام في المحول (CO أو PBX) التي يمكنها إضافة أرقام أو إزالتها.

التحقق من إرسال إشارات بروتوكول VoIP الشاملة (اتصال VoIP)

بعد التحقق من عمل إرسال إشارات منفذ الصوت بشكل صحيح واستلام الأرقام الصحيحة، قم بالنقل إلى أستكشاف أخطاء التحكم في مكالمات VoIP وإصلاحها وتصحيح الأخطاء. وتفسر هذه العوامل لماذا يمكن أن يصبح تصحيح أخطاء التحكم في المكالمات مهمة معقدة:

• تستخدم بوابات Cisco VoIP إشارات H.323 لإكمال المكالمات. يتكون H.323 من ثلاث طبقات من التفاوض بشأن المكالمات وتثبيت المكالمات: H.225، H.245، و H.323. تستخدم هذه البروتوكولات مجموعة من بروتوكول TCP و UDP لإعداد مكالمة وتأسيسها.

• يعرض تصحيح أخطاء بروتوكول VoIP الشامل عددا من أجهزة حالة Cisco IOS. قد تتسبب المشاكل مع أي جهاز حالة في فشل المكالمة.

• يمكن أن يكون تصحيح أخطاء بروتوكول VoIP النهائي سريعا جدا وأن يؤدي إلى إنشاء الكثير من مخرجات تصحيح الأخطاء.

debug voIP ccapi inout

الأمر الأساسي لتصحيح أخطاء مكالمات VoIP الشاملة هو تصحيح أخطاء نقل الصوت عبر بروتوكول الإنترنت . يتم عرض الإخراج من تصحيح أخطاء الاستدعاء في هذا الإخراج.

!--- Action: A VoIP call is originated through the 
!--- Telephony SPI (pots leg) to extension 5000. 
!--- Some output is omitted.


maui-voip-austin#debug voip ccapi inout
voip ccAPI function enter/exit debugging is on


!--- Call leg identification, source peer: Call 
!--- originated from dial-peer 1 pots 
!--- (extension 4000).


*Mar 15 22:07:11.959: cc_api_call_setup_ind 
(vdbPtr=0x81B09EFC, callInfo={called=, 
calling=4000, fdest=0 peer_tag=1}, callID=0x81B628F0)

!--- CCAPI invokes the session application.


*Mar 15 22:07:11.963: cc_process_call_setup_ind
(event=0x81B67E44) handed call to app "SESSION"
*Mar 15 22:07:11.963: sess_appl: 
ev(23=CC_EV_CALL_SETUP_IND), cid(88), disp(0)


!--- Allocate call leg identifiers "callid = 0x59"


*Mar 15 22:07:11.963: ccCallSetContext 
(callID=0x58, context=0x81BAF154)
*Mar 15 22:07:11.963: ccCallSetupAck 
(callID=0x58)


!--- Instruct VTSP to generate dialtone
. 

*Mar 15 22:07:11.963: ccGenerateTone 
(callID=0x58 tone=8)


!--- VTSP passes digits to CCAPI.


*Mar 15 22:07:20.275:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=5, flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:20.279: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:20.279: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:20.279: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:20.327: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=5
, duration=100)
*Mar 15 22:07:20.327: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:20.327: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.975:cc_api_call_digit_begin
(vdbPtr=0x81B09EFC,callID=0x58,digit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:21.979: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:21.979: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:21.979: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:22.075: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:22.079: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:22.079: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.235: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, dgit=0, 
flags=0x1, timestamp=0xC2E63BB7, expiration=0x0)
*Mar 15 22:07:23.239: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:23.239: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:23.239: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:23.335: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=150)
*Mar 15 22:07:23.339: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:23.339: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDes
t(0)
*Mar 15 22:07:25.147: cc_api_call_digit_begin
(vdbPtr=0x81B09EFC, callID=0x58, d
igit=0, flags=0x1, timestamp=0xC2E63BB7, 
expiration=0x0)
*Mar 15 22:07:25.147: sess_appl: 
ev(10=CC_EV_CALL_DIGIT_BEGIN), cid(88), disp(0)
*Mar 15 22:07:25.147: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)
*Mar 15 22:07:25.147: ssaIgnore cid(88), 
st(0),oldst(0), ev(10)
*Mar 15 22:07:25.255: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=0
, duration=160)
*Mar 15 22:07:25.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:25.259: ssaTraceSct: 
cid(88)st(0)oldst(0)cfid(-1)csize(0)in(1)fDest(0)


!--- Matched dial-peer 2 voip. Destination number !--- 5000


*Mar 15 22:07:25.259: ssaSetupPeer cid(88) 
peer list:tag(2) called number(5000) 
*Mar 15 22:07:25.259: ssaSetupPeer cid(88), 
destPat(5000), matched(4), prefix(),
peer(81C04A10)


!--- Continue to call an interface and start the !--- next call leg.


*Mar 15 22:07:25.259: ccCallProceeding 
(callID=0x58, prog_ind=0x0)
*Mar 15 22:07:25.259: ccCallSetupRequest 
(Inbound call = 0x58, outbound peer =2,
dest=, params=0x81BAF168 mode=0, 
*callID=0x81B6DE58)
*Mar 15 22:07:25.259: callingNumber=4000, 
calledNumber=5000, redirectNumber=


!--- VoIP call setup.


*Mar 15 22:07:25.263: ccIFCallSetupRequest:
(vdbPtr=0x81A75558, dest=, 
callParams={called=5000, calling=4000,
fdest=0, voice_peer_tag=2}, mode=0x0)
*Mar 15 22:07:25.263: ccCallSetContext 
(callID=0x59, context=0x81BAF3E4)
*Mar 15 22:07:25.375: ccCallAlert 
(callID=0x58, prog_ind=0x8, sig_ind=0x1)


!--- POTS and VoIP call legs are tied together.


*Mar 15 22:07:25.375: ccConferenceCreate 
(confID=0x81B6DEA0, callID1=0x58, callI
D2=0x59, tag=0x0)
*Mar 15 22:07:25.375: cc_api_bridge_done 
(confID=0x1E, srcIF=0x81B09EFC, srcCall
ID=0x58, dstCallID=0x59, disposition=0, 
tag=0x0)


!--- Exchange capability bitmasks with remote 
!--- the VoIP gateway 
!--- (Codec, VAD, VoIP or FAX, FAX-rate, and so forth).


*Mar 15 22:07:26.127: cc_api_caps_ind 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59,caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20, 
signal_type=0})


!--- Both gateways agree on capabilities.

*Mar 15 22:07:26.127: cc_api_caps_ack 
(dstVdbPtr=0x81B09EFC, dstCallId=0x58, src
CallId=0x59, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:26.139: cc_api_caps_ack 
(dstVdbPtr=0x81A75558, dstCallId=0x59, src
CallId=0x58, caps={codec=0x4, fax_rate=0x2, 
vad=0x2, modem=0x1 codec_bytes=20,
signal_type=0})
*Mar 15 22:07:35.259: cc_api_call_digit 
(vdbPtr=0x81B09EFC, callID=0x58, digit=T
, duration=0)
*Mar 15 22:07:35.259: sess_appl: 
ev(9=CC_EV_CALL_DIGIT), cid(88), disp(0)
*Mar 15 22:07:35.259: ssaTraceSct: 
cid(88)st(4)oldst(3)cfid(30)csize(0)in(1)
fDest(0)-cid2(89)st2(4)oldst2(1)
*Mar 15 22:07:35.399: cc_api_call_connected
(vdbPtr=0x81A75558, callID=0x59)
*Mar 15 22:07:35.399: sess_appl: 
ev(8=CC_EV_CALL_CONNECTED), cid(89), disp(0)
*Mar 15 22:07:35.399: ssaTraceSct: 
cid(89)st(4)oldst(1)cfid(30)csize(0)in(0)
fDest(0)-cid2(88)st2(4)oldst2(4)


!--- VoIP call is connected.


*Mar 15 22:07:35.399: ccCallConnect 
(callID=0x58)


!--- VoIP call is disconnected. Cause = 0x10
 

*Mar 15 23:29:39.530: ccCallDisconnect 
(callID=0x5B, cause=0x10 tag=0x0)

إذا فشل الاتصال وبدا السبب في جزء VoIP من إعداد المكالمة، قد تحتاج إلى النظر في جزء H.225 أو H.245 TCP من إعداد المكالمة، بدلا من جزء UDP فقط من إعداد H.323. الأوامر التي يمكن إستخدامها لتصحيح أخطاء إعداد إستدعاء H.225 أو H.245 هي:

• debug ip tcp حركة وdebug ip tcp packet— تفحص هذه الأوامر جزء TCP من تفاوض H.225 و H.245. إنهم يرجعون عناوين IP، ومنافذ TCP، وحالات إتصالات TCP.

• debug cch323 h225 — يفحص هذا الأمر جزء H.225 من تفاوض المكالمة ويتبع انتقال الحالة لجهاز حالة H.225 استنادا إلى الحدث الذي تمت معالجته. فكر في هذا على أنه الجزء الأول من إعداد مكالمات H.323 من الأجزاء الثلاثة.

• debug cch323 h245 — يفحص هذا الأمر جزء H.245 من تفاوض المكالمة ويتبع انتقال الحالة لجهاز حالة H.245 استنادا إلى الأحداث التي تمت معالجتها. فكر في هذا على أنه الجزء الثاني من إعداد مكالمات H.323 من الأجزاء الثلاثة.

فهم مشكلات جودة خدمة (QoS) بروتوكول VoIP

عندما يتم إنشاء مكالمات VoIP بشكل صحيح، فإن الخطوة التالية هي التحقق من جودة الصوت. على الرغم من أن هذا المستند لا يشمل أستكشاف أخطاء جودة الخدمة وإصلاحها، إلا أنه يجب مراعاة هذه الإرشادات لتحقيق جودة صوت جيدة:

• تعرف على حجم النطاق الترددي الذي يستهلكه مكالمة VoIP مع كل برنامج ترميز. ويتضمن ذلك رؤوس بروتوكول الإنترنت (IP)/UDP/RTP من الطبقة 2. لمزيد من المعلومات، ارجع إلى تعديل حساب إستهلاك النطاق الترددي للمكالمات الصوتية.

• تعرف على خصائص شبكة IP التي تنقلها المكالمات. على سبيل المثال، يختلف النطاق الترددي لشبكة ترحيل الإطارات في CIR كثيرا عن ذلك أعلاه-CIR (أو اندفاع)، حيث يمكن إسقاط الحزم أو وضعها في قائمة الانتظار في سحابة ترحيل الإطارات. ضمان التحكم في التأخير والتشوه والقضاء عليهما قدر الإمكان. يجب ألا يتجاوز تأخير الإرسال أحادي الإتجاه 150 مللي ثانية (وفقا لتوصية G.114).

• أستخدم تقنية قوائم الانتظار التي تسمح بتعريف حركة مرور بيانات VoIP وتحديد أولوياتها.

• عندما تقوم بإرسال VoIP عبر الارتباطات منخفضة السرعة، أستخدم تقنيات تجزئة حزمة الطبقة 2، مثل MLPPP مع تجزئة الارتباط والتداخل (LFI) على إرتباطات من نقطة إلى نقطة، أو FRF.12 على إرتباطات ترحيل الإطارات. يسمح تجزئة حزم البيانات الأكبر حجما بتقليل التشويش والتأخر في إرسال حركة مرور VoIP لأنه يمكن تقسيم حزم VoIP إلى الارتباط.

• حاول إستخدام برنامج ترميز مختلف وحاول إجراء المكالمة مع تمكين VAD وتعطيلها لإمكانية تضييق الإصدار إلى DSP، بدلا من شبكة IP.

باستخدام بروتوكول VoIP، يتم إسقاط الأشياء الرئيسية التي يجب البحث عنها عند أستكشاف أخطاء جودة الخدمة وإصلاحها والحزم المعطلة للشبكة التي يمكن أن تتسبب في التأخير والتشوه.

بحث عن:

• عمليات إسقاط الواجهة

• عمليات إسقاط المخزن المؤقت

• إزدحام الواجهة

• إزدحام الوصلات

يلزم فحص كل واجهة في مسار مكالمة VoIP. كما يمكنك التخلص من حالات السقوط والازدحام. ويلزم أيضا خفض التأخير في الذهاب والعودة قدر الإمكان. إختبارات الاتصال بين نقاط نهاية بروتوكول VoIP تعطي إشارة إلى تأخر رحلة الذهاب والعودة الخاصة بارتباط ما. يجب الا يتجاوز تأخير الذهاب والعودة 300 ميللي ثانية كلما امكن ذلك. وإذا كان لا بد من أن يتجاوز التأخير هذه القيمة، يلزم بذل جهود لضمان أن يكون هذا التأخير دائما، وذلك لعدم إحداث تشويش أو تأخير متغير.

كما يجب إجراء التحقق من الصحة لضمان أن تضع آلية قوائم انتظار Cisco IOS حزم VoIP داخل قوائم الانتظار المناسبة. يمكن أن تساعد أوامر Cisco IOS، مثل show queue interface أو show priority في التحقق من قوائم الانتظار.

تفاصيل أكواد السبب وقيم تصحيح الأخطاء ل VoIP

أستخدم هذه الجداول عند قراءة تصحيح الأخطاء والقيم المرتبطة ضمن تصحيح الأخطاء.

أسباب قطع اتصال الاتصال ب Q.931 (CAUSE_CODE من تسجيل الخروج من Debug voip ccapi)

¹ يمكن أن تحدث هذه المشكلة بسبب عدم تطابق برنامج الترميز ضمن إعداد H323، لذلك فإن خطوة أستكشاف الأخطاء وإصلاحها الأولى هي ترميز الطلب - نظير VoIP ترميزا ثابتا لاستخدام برنامج الترميز الصحيح.

قيم تفاوض برنامج الترميز (من تضمين Debug voip ccapi)

لمزيد من المعلومات حول برامج الترميز، ارجع إلى فهم برامج الترميز: التعقيد ودعم الأجهزة و MOS والتفاوض.

أنواع النغمة

قيم معدل الفاكس وقدرات الأجهزة الافتراضية (VAD)

معلومات ذات صلة

• أستكشاف أخطاء الطبقة الأولى وإصلاحها في T1
• أستكشاف أخطاء T1 وإصلاحها
• أستكشاف أخطاء الخط التسلسلي وإصلاحها
• استكشاف أخطاء خدمة IP الهاتفية من Cisco وإصلاحها
• الدعم الفني والتنزيلات من Cisco