本產品的文件集力求使用無偏見用語。針對本文件集的目的,無偏見係定義為未根據年齡、身心障礙、性別、種族身分、民族身分、性別傾向、社會經濟地位及交織性表示歧視的用語。由於本產品軟體使用者介面中硬式編碼的語言、根據 RFP 文件使用的語言,或引用第三方產品的語言,因此本文件中可能會出現例外狀況。深入瞭解思科如何使用包容性用語。
思科已使用電腦和人工技術翻譯本文件,讓全世界的使用者能夠以自己的語言理解支援內容。請注意,即使是最佳機器翻譯,也不如專業譯者翻譯的內容準確。Cisco Systems, Inc. 對這些翻譯的準確度概不負責,並建議一律查看原始英文文件(提供連結)。
本文說明一些最佳實踐,以便在Cisco IOS/IOS-XE語音路由器中收集語音調試。
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
就本檔案而言,所用元件如下:
本文中的資訊是根據特定實驗室環境內的裝置所建立。文中使用到的所有裝置皆從已清除(預設)的組態來啟動。如果您的網路運作中,請確保您瞭解任何指令可能造成的影響。
這些平台中的調試收集過程存在挑戰,並且可能會影響裝置的效能。當語音路由器中建立多個活動呼叫時,挑戰和風險會增加。在某些情況下,如果沒有正確收集調試,則會導致CPU過大,從而影響路由器的容量,甚至導致軟體崩潰。本檔案將討論思科整合邊界元件(CUBE)和TDM/類比閘道之間的差異。
TDM語音閘道器主要用於將內部電話系統與其他私人分支交換器(PBX)或公共交換電話網路(PSTN)互連。 TDM閘道中使用的連線型別是T1/E1控制器(ISDN或CAS)和類比電路,例如FXS和FXO連線埠。數位訊號處理器(DSP)將音訊從原始形式轉換為RTP資料包。類似地,DSP處理完這些RTP資料包並在特定電路上傳送音訊後,RTP資料包被轉換為原始音訊。這些網關可以在VoIP端與H323、MGCP或SCCP互動操作,而在TDM端可以將ISDN PRI電路或類比電路作為到PSTN或終端的最常見連線。
如圖所示,TDM網關在您的內部VoIP基礎設施與模擬或ISDN服務提供商之間提供了一個網橋。
隨著VoIP的引入,客戶開始迅速將其傳統系統轉變為現代VoIP基礎設施。運營商端也發生了同樣的情況,他們現在使用連線將本地電話服務與運營商VoIP基礎設施互聯,並擴展其功能以提供更好的服務。目前使用的最常見的VoIP協定是會話初始協定(SIP),目前被世界各地的客戶和網際網路電話服務提供商(ITSP)廣泛使用。
引入CUBE是為了通過將SIP作為主要VoIP協定的ITSP將這些內部VoIP系統與外部世界進行內部連線。CUBE只是IP-IP網關,它不再需要任何TDM型別的連線,如T1/E1控制器或模擬埠。CUBE與TDM網關運行在同一平台上。
最常用的VoIP協定是SIP(用於呼叫建立和解除),以及RTP(用於媒體傳輸)。在CUBE中,除非需要一個轉碼器,否則不需要一個DSP。RTP流量從ITSP到終端端對端流動,CUBE充當中間人,地址隱藏是其提供的眾多功能之一。
如圖所示,CUBE將您的內部VoIP基礎設施與SIP ITSP區分開來:
語音功能運行在不同平台清單上,例如ISR、ASR、CAT8Ks等,但是它們使用的是通用軟體,即Cisco IOS或Cisco IOS-XE(Cisco IOS和Cisco IOS-XE之間的差異不在本文章中介紹)。 讓我們從有關如何訪問Cisco IOS路由器的基本知識開始。
與任何其它基於CLI的裝置一樣,路由器需要終端監控器才能通過Secure Shell(SSH)或Telnet訪問運行命令。SSH是目前最常用的訪問裝置協定,因為它提供了到裝置的安全加密連線。用於訪問路由器CLI的一些常用終端監視器包括:
收集CLI輸出的方法多種多樣。建議從路由器的CLI將資訊匯出到單獨的檔案中。這樣可以更輕鬆地與外部各方共用資訊。
從裝置收集輸出的幾種方法如下:
稍後,可以使用Copy All to Clipboard選項從終端監控器收集資訊,並將輸出貼上到文本檔案中:
附註:如果沒有指定其他名稱,則使用預設日誌檔名稱,按一下「瀏覽」按鈕可準確瞭解檔案儲存的位置,以便稍後查詢。另外請確保不要覆蓋同一檔案路徑中的另一個putty.log檔案。
在進行任何debug收集之前,需要使用show命令從路由器收集基本資訊。Show命令收集速度很快,而且大多數情況下不會對路由器的效能產生任何影響。僅使用show命令輸出即可立即開始隔離問題。
連線到路由器後,終端長度可以設定為0。這樣可以更快地收集以同時顯示所有輸出,並且避免使用空格鍵。用於收集路由器詳細資訊的命令是「show tech」,您也可以收集show tech voice,此命令顯示特定於路由器中啟用的語音功能的資料:
Router# terminal length 0
Router# show tech
!or
Router# show tech voice
Router# terminal default length !This cmd restores the terminal length to default
Cisco IOS/IOS-XE中的調試輸出收集有時可能是一個挑戰,因為存在路由器崩潰的風險。下面幾節將介紹一些最佳做法,以避免出現任何問題。
啟用任何調試之前,需要確保有足夠的記憶體來將輸出儲存在緩衝區中。
運行命令show process memory,找出可以分配多少記憶體以記錄緩衝區中的所有輸出:
提示:使用命令terminal length default或terminal length <num_lines> 返回終端中顯示的有限行數。
Router# show process memory
Processor Pool Total: 8122836952 Used: 456568400 Free: 7666268552
lsmpi_io Pool Total: 6295128 Used: 6294296 Free: 832
在本例中,有7666268552個位元組(7.6GB)可供路由器使用。此記憶體由路由器在所有系統進程之間共用,這意味著您不能使用整個可用記憶體來記錄緩衝區的輸出,但您可以根據需要使用大量的系統記憶體。
大多數情況至少需要10 MB才能收集足夠的調試輸出,然後輸出才會丟失或覆蓋。在極少數情況下需要收集大量資料,在那些特定情況下,您可以在緩衝區中獲得50MB到100MB的輸出,或者只要存在可用記憶體,還可以進一步收集。
如果可用記憶體不足,則可能存在記憶體洩漏問題。如果是這種情況,請架構技術支援中心團隊修正導致記憶體不足的原因。
CPU受系統中處於活動狀態的進程、功能和呼叫數量的影響。系統中啟用的功能或呼叫越多,CPU就越繁忙。
一個好的基準是確保路由器的CPU佔用30%或更少,這意味著您可以安全地啟用從基本到高級的調試(使用高級調試時始終監視CPU)。 如果路由器CPU佔大約50% ,則可以運行基本調試並仔細監控CPU。如果CPU使用率超過80%,請立即停止調試(如本文稍後所示),並請求TAC協助。
使用show process cpu sorted |排除0.00命令,檢查最後5秒、60秒和5分鐘的CPU值以及排名靠前的進程。
Router# show processes cpu sorted | exclude 0.00
CPU utilization for five seconds: 1%/0%; one minute: 0%; five minutes: 0%
PID Runtime(ms) Invoked uSecs 5Sec 1Min 5Min TTY Process
211 4852758 228862580 21 0.15% 0.06% 0.07% 0 IPAM Manager
84 3410372 32046994 106 0.07% 0.04% 0.05% 0 IOSD ipc task
202 3856334 114790390 33 0.07% 0.05% 0.05% 0 VRRS Main thread
在輸出中,路由器沒有太多活動,CPU較低,可以安全地啟用調試。
注意:如果最大CPU進程為50%或更高,且最大進程為語音進程,則要特別注意活動的最大CPU進程,否則只能啟用基本調試。使用命令持續監控CPU,以確保路由器的整體效能不受影響。
每台路由器具有不同的容量閾值。檢查路由器中有多少呼叫處於活動狀態,以確保其容量不接近最大值,這一點非常重要。思科統一邊界要素版本12產品手冊提供了有關每個平台容量的資訊以供參考。
使用show call active total-calls命令可瞭解系統中處於活動狀態的呼叫數:
Router# show call active total-calls
Total Number of Active Calls : 0
使用show call active voice summary命令獲取有關處於活動狀態的特定呼叫型別的更詳細資訊:
Router# show call active voice summary
Telephony call-legs: 0
SIP call-legs: 0
H323 call-legs: 0
Call agent controlled call-legs: 0
SCCP call-legs: 0
STCAPP call-legs: 0
Multicast call-legs: 0
Total call-legs: 0
一些常用值包括:
要將路由器配置為將調試輸出儲存在緩衝區中,可進入configure terminal模式以手動調整CLI中的設定。此組態不會對路由器產生影響,但如前幾節所示,如果需要回滾組態,則需要從路由器發出show tech或show running-config命令。
下面是一個配置示例,這是TAC工程師使用的通用基線。該示例分配了10MB的緩衝記憶體,但可以根據需要增加:
# configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
logging buffered 10000000
no logging console
no logging monitor
logging queue-limit 10000
logging rate-limit 10000
voice iec syslog
這些命令可完成以下任務:
有時,問題可能是隨機的,需要一種連續收集調試資訊直至事件發生的方法。在緩衝區中儲存debug時,它會連續收集它們。請注意,限製為可分配的記憶體量,一旦達到該記憶體量,緩衝區將繞圈並丟棄最早的消息,從而導致隔離問題所需的有價值資訊不完整。
使用Syslog,路由器可以將所有調試消息傳送到外部伺服器,Syslog伺服器軟體將外部伺服器以文本檔案形式儲存。儘管這是收集調試輸出的好方法,但並非日誌收集的首選方法。由於伺服器擁塞,系統日誌伺服器往往會跳過或丟棄來自所接收輸出的行,因為調試輸出可能會使伺服器不堪重負,或者資料包可能會由於網路條件而被丟棄。但在某些情況下,系統日誌是解決問題的唯一途徑。
如有可能,使用可靠的傳輸方法(如TCP)以避免資訊丟失,並建議將系統日誌伺服器連線到路由器所連線的同一台交換機或儘可能靠近路由器。它仍然不能保證所有資料都儲存在檔案中,但減少了資料丟失的機率。
預設情況下,系統日誌伺服器使用UDP作為埠514上的傳輸協定。
#configure terminal
service timestamps debug datetime msec localtime show-timezone year
service timestamps log datetime msec localtime show-timezone year
service sequence-numbers
!Optional in case you still want to store debug output in the buffer.
logging buffered 10000000
no logging console
no logging monitor
logging trap debugging
!Replace the 192.168.1.2 with the actual Syslog Server IP Address
logging host 192.168.1.2 transport [tcp|udp] port
配置命令後,路由器立即將消息轉發到Syslog伺服器IP地址。
啟用調試後,必須先清除緩衝區,然後才能重現問題。這樣做是為了確保輸出儘可能乾淨,並避免分析時不需要的任何額外資料。執行命令clear log,這可確保緩衝區被清除。如果路由器中有其他呼叫處於活動狀態並且調試已啟用,輸出將立即顯示在緩衝區中。
Router# clear log
Clear logging buffer [confirm]
Router#
重現問題後,立即禁用調試以停止緩衝區中的更多輸出。然後收集日誌。您可以使用以下命令轉儲終端中的所有輸出:
Router# undebug all
Router# terminal length 0
Router# show log
有時PuTTY會關閉,因為它無法同時處理所有輸出,這是正常現象,並不意味著發生了故障,如果發生故障,請重新開啟會話並正常繼續。如果日誌記錄緩衝區過大或者終端監視器由於需要列印的資料量而崩潰,請使用show log命令直接將緩衝區輸出複製到外部裝置 |重定向:
Router# show log | redirect ftp://username:password@192.168.1.2/debugs.txt
此指令將整個緩衝區輸出複製到IP位址為192.168.1.2、檔案名稱為debug.txt的ftp中。必須始終指定檔名。可用於匯出該資料的其他目標包括:
Router# sh log | redirect ?
bootflash: Uniform Resource Locator
flash: Uniform Resource Locator
ftp: Uniform Resource Locator
harddisk: Uniform Resource Locator
http: Uniform Resource Locator
https: Uniform Resource Locator
nvram: Uniform Resource Locator
tftp: Uniform Resource Locator
每個呼叫流程和功能型別(TDM、CUBE或SCCP(媒體資源))都不同,您可以啟用特定調試。必須同時啟用所有需要的調試。當一次僅捕獲一個調試時,該調試是無效的,並且會在分析資料時造成更多混亂。
在CLI執行提示級別Router#中啟用調試,該級別要求您具有特權執行模式許可權。
有基本和高級調試。基本調試用於收集SIP、H323或MGCP中的信令資訊,其中顯示了路由器與其對等裝置的會話。
高級調試非常詳細,如果出現基本調試無法顯示的內部堆疊錯誤,通常使用這些調試收集詳細資訊。這些調試通常佔用大量CPU。
提示:啟用調試後,請記得運行命令clear logging。此命令可確保清空緩衝區,以便更乾淨地捕獲調試。
在每個Cisco IOS/IOS-XE路由器內部都有一個呼叫控制API,負責不同VoIP應用或協定與資料平面元件(如RTP、DSP、語音卡等)之間的通訊。為了從此層捕獲資料,可以使用一個特定的調試:
debug voip ccapi inout
此調試有其他選項,但debug voip ccapi inout涵蓋所有基本撥號方案和呼叫建立資訊,這些資訊通常足以瞭解此層的狀態。
提示:debug voip ccapi inout通常對路由器的CPU影響最小,建議與任何信令調試一起啟用,以便提供包含呼叫及其不同狀態資訊的完整日誌集。
這些調試是最常用於SIP呼叫流的調試,並且可以在CUBE和TDM網關內啟用,在路由器和CUCM或任何其他SIP伺服器/代理之間具有SIP分支。
debug ccsip messages
debug ccsip error
debug ccsip non-call !Optional, applies for SIP OPTIONS and SIP REGISTER Messages.
debug ccsip all
debug ccsip verbose
debug voice ccapi inout
以下偵錯適用於主要速率介面(PRI)T1/E1或基本速率介面(BRI):
debug isdn q931
debug isdn q921
當涉及類比電路(如Foreigh eXchange Subscriber, FXS)或Foreign Xchange Office(FXO)埠時,使用以下調試:
debug vpm signal
debug voip vtsp all
將MGCP用作語音網關和CUCM之間的語音協定時,會使用這些調試。
debug mgcp packets
debug mgcp errors
debugs ccm-manager用於跟蹤CUCM和語音網關之間的配置下載、MoH和PRI/BRI回程消息。這些調試會根據需要使用,並且取決於故障情況。
debug ccm-manager backhaul !For PRI and BRI Deployments
debug ccm-manager errors
debug ccm-manager events
debug ccm-manager config-download !Troubleshoot Configuration download issues from CUCM TFTP
debug ccm-mananger music-on-hold !Troubleshoot internal MoH Process
debug mgcp all
儘管H323並未得到廣泛使用,但是仍存在一些配置H323的部署:
debug h225 asn1
debug h245 asn1
debug h225 events
debug h245 events
debug cch323 h225
debug cch323 h245
debug cch323 all
這些調試用於排查精簡型呼叫控制協定(SCCP)媒體資源問題,這些問題涉及註冊到Cisco Unified Communications Manager(CUCM)伺服器的媒體終端點(MTP)或轉碼器:
debug sccp messages
debug sccp events
debug sccp errors
debug sccp all
隨著Cisco IOS-XE 17.4.1和17.3.2的推出,在思科統一邊界元素(CUBE)內捕獲語音日誌有一個新選項。 這個新功能稱為VoIP跟蹤。這是一個新的可維護性框架,用於記錄SIP信令和事件,而無需啟用任何調試。
VoIP跟蹤預設啟用,可以根據需要隨時禁用。VoIP跟蹤僅捕獲SIP呼叫的特定資訊:
如前所述,預設情況下啟用此功能。啟用此功能的命令為:
Router# configuration terminal
Router(config)# voice service voip
Router(conf-voi-serv)# trace
Router(conf-serv-trace)#
要禁用此功能,命令如下:
Router(conf-serv-trace)# no trace
!or
Router(conf-serv-trace)# shutdown
注意:禁用VoIP跟蹤後,將清除所有記憶體並丟失資訊。
跟蹤配置模式中可用的命令有:
Router(conf-serv-trace)# ?
default Set a command to its defaults
exit Exit from voice service voip trace mode
memory-limit Set limit based on memory used
no Negate a command or set its defaults
shutdown Shut Voip Trace debugging
記憶體限制確定VoIP跟蹤用於儲存資料所用的記憶體量。預設情況下,平台中可用記憶體的10%,但可以將其更改為最大1GB,最小10MB。記憶體是動態分配的,這意味著該功能只根據需要使用記憶體,並且取決於呼叫量。達到可用的最大記憶體後,它會循環並刪除舊條目。
當記憶體限制被修改為大於10%的可用記憶體時,命令列介面中會顯示一條消息:
Router(conf-serv-trace)# memory-limit 1000
Warning: Setting memory limit more than 10% of available platform memory (166 MB) will affect system performance.
要設定預設的10%記憶體使用率,可使用命令memory-limit platform:
Router(conf-serv-trace)# memory-limit platform
Reducing the memory-limit clears all VoIP Trace statistics and data.
If you wish to copy this data first, enter 'no' to cancel,
otherwise enter 'yes' to proceed. Continue? [no]:
注意:當記憶體限制降低時,所有VoIP跟蹤資料都將丟失。在減少記憶體之前,必須收集資料的備份。
要顯示VoIP跟蹤中的資料,我們需要使用特定的show命令。資料可以在同一個終端會話中顯示,也可以通過Syslog傳送到出廠設定的syslog伺服器。
附註:從收到呼叫的BYE時間起32秒後轉儲跟蹤。
附註:SIP信令按支路顯示,而不是像常規調試那樣組合在一起。常規調試(如debug ccsip messages)以事件發生的確切順序顯示呼叫的SIP信令。在VoIP跟蹤中,每個支路是獨立的。要確定正確的順序,使用時間戳。
可用於顯示資料的命令有:
Router# show voip trace ?
all Display all VoIP Traces
call-id Filter traces based on Internal Call Id
correlator Filter traces based on FPI Correlator
cover-buffers Display the summary of all cover buffers
session-id Filter traces based on SIP Session ID
sip-call-id Filter traces based on SIP Call Id
statistics Display statistics for VoIP Trace
此命令顯示緩衝區中可用的所有VoIP跟蹤資料。使用此命令會影響路由器的效能。輸入命令後,會顯示警告消息以警告風險並確認繼續:
Router# show voip trace all
Displaying 11858 cover buffers
This may severely impact system performance.
Continue? [yes/no] no
此命令顯示在VoIP跟蹤下報告的所有呼叫的呼叫詳細資訊的概述。每個呼叫段都建立一個覆蓋緩衝區,其中包含記錄的呼叫的摘要。
Router# show voip trace cover-buffers
------------------ Cover Buffer ---------------
Search-key = 8845:3002:659
Timestamp = *Sep 30 01:17:33.615
Buffer-Id = 1
CallID = 659
Peer-CallID = 661
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 20857880-1ec12085-13b930-411b300a@10.48.27.65
SIP Session ID = 2b1289c400105000a0002c3ecf872659
GUID = 208578800000
-----------------------------------------------
------------------ Cover Buffer ---------------
Search-key = 8845:3002:661
Timestamp = *Sep 30 01:17:33.634
Buffer-Id = 2
CallID = 661
Peer-CallID = 659
Correlator = 4
Called-Number = 3002
Calling-Number = 8845
SIP CallID = 8D6DEC28-1F111EB-829FD797-1B22F6DB@10.48.55.11
SIP Session ID = 0927767800105000a0005006ab805584
GUID = 208578800000
-----------------------------------------------
有關每個欄位的詳細資訊,請參閱下表:
欄位 | 說明 |
Search-Key | 包含呼叫、被叫號碼和呼叫ID的組合 |
時間戳 | 覆蓋緩衝區的建立時間 |
Buffer-ID |
封面緩衝區的緩衝區ID |
Call-id |
到覆蓋緩衝區的各個呼叫段的呼叫ID |
Peer-CallID |
對等支路的呼叫ID |
相關器 |
呼叫的FPI相關器 |
Called-number |
覆蓋緩衝區的各個呼叫段的被叫號碼 |
Calling-number |
覆蓋緩衝區的各個呼叫段的呼叫號碼 |
Sip Call-ID |
覆蓋緩衝區的各個呼叫段的SIP呼叫ID |
Sip會話ID |
覆蓋緩衝區的各個呼叫段的SIP會話ID |
GUID |
封面緩衝區的相應呼叫的GUID |
錨腿 |
如果各自的呼叫支路是來電轉駁流或媒體代理部署中的錨支路,則錨支路設定為yes |
分叉腿 |
如果各自的呼叫分支是呼叫分支流或媒體代理部署中的錨點,則Forked Leg設定為yes |
關聯的CalI ID |
關聯的分支腿的呼叫ID |
為了過濾覆蓋緩衝區,可以使用include和section命令:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
!or
Router# show voip trace cover-buffers | section Search-key | 8845 | 3002
Search-key = 8845:3002:661
結合使用上述命令,show voip trace call-id 可用於查詢呼叫。識別call-id後,此命令可用於顯示有關特定呼叫段的所有資訊:
Router# show voip trace cover-buffers | include Search-key | 8845 | 3002
Search-key = 8845:3002:661
Router# show voip trace call-id 661
此show命令顯示有關狀態、記憶體消耗、錯誤或故障呼叫、成功呼叫、最新和最早條目的時間戳等的詳細輸出。
Router# show voip trace statistics
VoIP Trace Statistics
Tracing status : ENABLED at *Sep 12 06:44:02.349
Memory limit configured : 803209216 bytes
Memory consumed : 254550928 bytes (31%)
Total call legs dumped : 2
Oldest trace dumped : *Sep 12 07:29:21.077 Search-key: 9898:30000:64
Latest trace dumped : *Sep 12 07:29:21.010 Search-key: 9898:30000:63
Total call legs captured : 11858
Total call legs available : 11858
Oldest trace available : *Sep 12 06:57:23.923, Search-key: 5250001:4720001:11
Latest trace available : *Sep 13 05:08:25.353, Search-key: 19074502232:30000:13177
Total traces missed : 0
有關每個欄位的詳細資訊,請參閱下表:
欄位 | 說明 |
跟蹤狀態 |
顯示跟蹤狀態,包括啟用VoIP跟蹤的時間和日期。 |
配置的記憶體限制 |
顯示配置的記憶體限制。這是處理器池記憶體大小的10% |
耗用的記憶體 |
顯示VoIP跟蹤動態消耗的記憶體量 |
已轉儲的呼叫段總數 |
顯示轉儲到日誌記錄緩衝區的失敗呼叫段數。轉儲呼叫是指與IEC錯誤關聯的呼叫段 |
已轉儲最早的跟蹤 |
顯示自啟用VoIP跟蹤以來最早失敗的呼叫的時間戳和搜尋鍵 |
已轉儲最新跟蹤 |
顯示自啟用VoIP跟蹤以來最新失敗呼叫的時間戳和搜尋金鑰 |
捕獲的呼叫總支路 |
顯示啟用VoIP跟蹤後捕獲的總分支 |
可用呼叫總腿數 |
顯示歷史記錄中可用的呼叫段總數。與捕獲的呼叫總支路相比,這可以相同或不同,具體取決於記憶體限制。 |
可用的最早跟蹤 |
顯示記憶體中可用的最舊覆蓋緩衝區的時間戳和搜尋鍵 |
最新跟蹤可用 |
顯示記憶體中可用的最新封面緩衝區的時間戳和搜尋鍵 |
丟失的跟蹤總數 |
顯示由於記憶體限制而錯過的呼叫段數。 |
欄位 | 使用 | 說明 |
show voip trace correlator <correlator> |
show voip trace correlator 4 |
過濾並顯示從覆蓋緩衝區開始的特定呼叫ID的VOIP跟蹤 |
show voip trace session-id <session-id> |
show voip trace session-id 87003120822b5dbd8fd80f62d8e57c48 |
根據SIP會話ID過濾和顯示呼叫的VOIP跟蹤。可以使用sip消息的會話ID報頭中的本地或遠端UUID來顯示呼叫的兩段。 |
show voip trace sip-call-id <call-id> |
show voip trace sip-call-id 01e60dfa9d8442848336d79e3155a8a1 |
根據SIP Call-ID過濾和顯示VOIP跟蹤 |
修訂 | 發佈日期 | 意見 |
---|---|---|
1.0 |
13-Aug-2021 |
初始版本 |