簡(jiǎn)介這是面向4G/5G網(wǎng)絡(luò)優(yōu)化工程師的VoLTE排障案例聚焦IMS返回503 ServiceUnavailable并導(dǎo)致用戶從5G回落到4G的典型問(wèn)題。文檔從拉網(wǎng)測(cè)試中部分手機(jī)呼叫失敗出發(fā)完整呈現(xiàn)了排障流程先跟蹤基站側(cè)trace發(fā)現(xiàn)核心網(wǎng)E-RAB SETUP REQUEST中上行請(qǐng)求最大帶寬為88kbps超過(guò)基站配置的52kbps上限從而回傳Radio-resource-not-available再經(jīng)信令確認(rèn)被叫側(cè)R6y日志中的max-requested-bandwidth-ul為88000同時(shí)SBC將主叫側(cè)INVITE中的SDP帶寬由49kbps改寫為80kbps因配置G711編解碼重算導(dǎo)致專用承載建立失敗。針對(duì)該根因文檔給出了華為SBC BCPLC中設(shè)置信任終端媒體帶寬為否、確保編解碼轉(zhuǎn)換后轉(zhuǎn)發(fā)INVITE不改變帶寬以及針對(duì)多方通話等高帶寬業(yè)務(wù)將基站QCI1帶寬提升至200kbps等具體調(diào)整方案并附有信令參數(shù)與關(guān)鍵配置截圖便于實(shí)際作業(yè)時(shí)對(duì)照實(shí)施。資源為1個(gè)docx文檔大小129KB內(nèi)容聚焦無(wú)冗余。已有406人學(xué)習(xí)下載適合從事5G語(yǔ)音優(yōu)化、核心網(wǎng)與無(wú)線側(cè)協(xié)同排障的工程師查閱。1. 5G網(wǎng)優(yōu)案例IMS直接報(bào)503 ServiceUnavailable用戶掉到4G拉網(wǎng)測(cè)試最怕的就是這種場(chǎng)景手機(jī)明明顯示5G滿格VoLTE呼叫卻直接失敗主叫側(cè)收到503 ServiceUnavailable信令里寫著media bearer lost用戶還沒(méi)反應(yīng)過(guò)來(lái)手機(jī)已經(jīng)悄悄掉到4G。這個(gè)案例我在多個(gè)項(xiàng)目里見(jiàn)過(guò)類似變種根因不是核心網(wǎng)掛了也不是基站故障而是SBC申請(qǐng)帶寬超出基站配置上限導(dǎo)致專用承載建立失敗。對(duì)一線網(wǎng)優(yōu)工程師來(lái)說(shuō)這類問(wèn)題如果不順著信令逐跳排查很容易在E-RAB建立失敗這一步就下了錯(cuò)誤結(jié)論。這篇筆記會(huì)把完整的定位思路、參數(shù)對(duì)應(yīng)關(guān)系和修復(fù)方案拆開(kāi)講透尤其適合剛接觸VoLTE承載優(yōu)化的從業(yè)者照著復(fù)現(xiàn)。2. 為什么是503而不是其他錯(cuò)誤VoLTE呼叫流程與承載建立鏈路2.1 VoLTE呼叫建立從INVITE到專用承載的四次握手VoLTE呼叫不是手機(jī)到手機(jī)直連而是手機(jī)通過(guò)基站接入再經(jīng)過(guò)IMS核心網(wǎng)完成呼叫控制。整個(gè)過(guò)程中QCI1專用承載的建立是關(guān)鍵。主叫發(fā)起INVITE請(qǐng)求后IMS核心網(wǎng)側(cè)的SBC會(huì)與被叫側(cè)完成SDP協(xié)商隨后通過(guò)Rx接口向PCRF發(fā)起AAR請(qǐng)求PCRF再通過(guò)Gx接口通知PGW建立專用承載。PGW向基站發(fā)送E-RAB SETUP REQUEST基站為這條承載分配空口資源如果分配成功就返回E-RAB SETUP RESPONSE承載建立完成VoLTE呼叫才能繼續(xù)。整個(gè)鏈路可以簡(jiǎn)化成下面這張流程對(duì)應(yīng)關(guān)系手機(jī) -- RRC -- 基站(enodeb) -- S1-U/S1-MME -- PGW -- Rx -- PCRF -- AAR -- SBC呼叫失敗時(shí)隨手抓一條信令看是卡在E-RAB建立前的哪一步。這個(gè)鏈路里最容易出問(wèn)題的節(jié)點(diǎn)有三個(gè)SBC的SDP帶寬重算、PCRF與PGW之間的策略下發(fā)、基站側(cè)的空口資源分配。本案例的問(wèn)題出在最后一個(gè)節(jié)點(diǎn)根因卻在第一個(gè)節(jié)點(diǎn)。如果不把整條鏈路拆開(kāi)看只盯基站告警大概率會(huì)做成調(diào)高基站帶寬、問(wèn)題暫時(shí)消失、下次換個(gè)場(chǎng)景又復(fù)發(fā)的無(wú)用功。2.2 503 ServiceUnavailable在VoLTE里的真實(shí)含義503 ServiceUnavailable在HTTP協(xié)議里表示服務(wù)器暫時(shí)無(wú)法處理請(qǐng)求在VoLTE信令里這個(gè)錯(cuò)誤碼由IMS核心網(wǎng)返回通常意味著媒體面資源沒(méi)有準(zhǔn)備好。具體到這個(gè)案例錯(cuò)誤原因值攜帶的是media bearer lost說(shuō)明QCI1專用承載在建立過(guò)程中丟失或被釋放。常規(guī)情況下VoLTE呼叫失敗返回的錯(cuò)誤碼還有480 Temporarily Unavailable、486 Busy Here、580 Precondition Failure等各自對(duì)應(yīng)的場(chǎng)景完全不同。480偏向被叫不可達(dá)486是用戶忙580多與SDP預(yù)條件不滿足有關(guān)。而503加上media bearer lost基本鎖定在媒體承載建立這條路線上需要重點(diǎn)排查空口資源、核心網(wǎng)策略和SBC帶寬計(jì)算這三個(gè)環(huán)節(jié)。排查時(shí)可以做一個(gè)快速分流用wireshark打開(kāi)抓包文件只看E-RAB相關(guān)消息# 在wireshark里過(guò)濾E-RAB建立相關(guān)的Diameter消息 diameter (diam.cmd.code 232 || diam.cmd.code 231)過(guò)濾結(jié)果中重點(diǎn)看E-RAB SETUP REQUEST和E-RAB SETUP RESPONSE這一對(duì)消息。E-RAB SETUP REQUEST里攜帶的是核心網(wǎng)期望建立的承載參數(shù)包括QCI、ARP、上下行帶寬等。E-RAB SETUP RESPONSE如果攜帶失敗原因值說(shuō)明基站側(cè)拒絕了承載建立這時(shí)要立刻展開(kāi)響應(yīng)消息里的Cause字段看具體是Radio-resource-not-available還是其他原因。這一步是整個(gè)排查的分水嶺原因值不同接下來(lái)往哪個(gè)方向查完全不同。2.3 承載建立失敗E-RAB SETUP RESPONSE里的失敗原因值本案例在E-RAB SETUP RESPONSE消息里攜帶的是Radio-resource-not-available直譯過(guò)來(lái)就是空口資源不可用。很多人看到這個(gè)原因值第一反應(yīng)是基站資源不足直接去查小區(qū)用戶數(shù)和PRB利用率。但查了半天用戶數(shù)不高PRB利用率也不滿問(wèn)題依然復(fù)現(xiàn)這就說(shuō)明根本不是真的資源不足而是請(qǐng)求的資源規(guī)格超出了基站允許的范圍。一個(gè)典型的信令展示如下E-RAB SETUP RESPONSE E-RAB ID: 1 E-RAB Setup Failed List Cause: Radio-resource-not-available E-RAB Setup List: (0 items)基站返回這個(gè)原因值的常見(jiàn)觸發(fā)條件有三個(gè)一是小區(qū)上行干擾過(guò)高導(dǎo)致可用PRB減少二是請(qǐng)求的GBR帶寬超過(guò)了基站側(cè)配置的最大帶寬三是QCI1承載數(shù)超過(guò)小區(qū)配置上限。本案例屬于第二種核心網(wǎng)請(qǐng)求的帶寬是88kbps基站配置的上下行最大帶寬只有52kbps那么無(wú)論小區(qū)有多空閑基站都會(huì)拒絕這條承載。這種配置型資源不足在信令上看不出小區(qū)擁塞痕跡只能靠對(duì)比請(qǐng)求值和配置值來(lái)定位這也是很多測(cè)試工程師在這個(gè)問(wèn)題上反復(fù)卡殼的原因。3. 信令鏈路逐跳拆解從E-RAB SETUP REQUEST到Radio-resource-not-available3.1 基站側(cè)Trace為什么請(qǐng)求帶寬88kbps被拒打開(kāi)基站側(cè)Trace找到核心網(wǎng)發(fā)給基站的E-RAB SETUP REQUEST消息里面有一條關(guān)鍵字段上行請(qǐng)求最大帶寬max-requested-bandwidth-ul。這個(gè)值以bps為單位案例中顯示為0x157c0換算成十進(jìn)制是88000也就是88kbps。E-RAB SETUP REQUEST e-RAB ID: 1 qCI: 1 e-RAB Level QoS Parameters gbr-UL: 88000 gbr-DL: 88000 maxRequestedBandwidth-UL: 88000 maxRequestedBandwidth-DL: 88000這三個(gè)參數(shù)需要分開(kāi)理解。GBR是保證比特率VoLTE語(yǔ)音一般不會(huì)太高maxRequestedBandwidth是最大請(qǐng)求帶寬理論上應(yīng)該覆蓋編碼器峰值速率加IP/RTP/UDP頭開(kāi)銷。案例里GBR和maxRequestedBandwidth都是88000說(shuō)明核心網(wǎng)給出的規(guī)格偏高超出了基站配置。對(duì)照基站側(cè)配置該小區(qū)上下行最大帶寬均為52kbps。這個(gè)配置值通常是基站側(cè)針對(duì)QCI1承載設(shè)置的Max Authorized Bandwidth參數(shù)。當(dāng)請(qǐng)求值大于配置值時(shí)基站的準(zhǔn)入控制邏輯直接判定不滿足條件返回Radio-resource-not-available過(guò)程短平快不涉及任何擁塞判斷?；救罩纠锬芸吹綄?duì)應(yīng)的拒絕記錄搜索關(guān)鍵字時(shí)可以關(guān)注以下字段# 基站的實(shí)時(shí)日志按E-RAB建立失敗過(guò)濾 tail -f log/gcell_erab.log | grep -i radio-resource-not-available如果日志里同時(shí)出現(xiàn)了請(qǐng)求帶寬和配置帶寬的對(duì)比輸出馬上能看到88和52的差異。這一步基本就能確認(rèn)到底是不是配置型拒絕。3.2 52kbps從哪里來(lái)基站側(cè)QCI1帶寬配置邏輯很多現(xiàn)場(chǎng)工程師會(huì)有疑問(wèn)VoLTE帶寬需求不是固定的嗎為什么基站要限制在52kbps這個(gè)值通常和現(xiàn)場(chǎng)采用的語(yǔ)音編碼策略有關(guān)。如果部署的是AMR-NB帶寬需求相對(duì)較小如果部署了AMR-WB或EVS帶寬需求會(huì)明顯上升。實(shí)際規(guī)劃時(shí)應(yīng)按以下邏輯設(shè)定基站的最大授權(quán)帶寬單路語(yǔ)音總帶寬 ≈ 編碼器速率 RTP頭開(kāi)銷 IP頭開(kāi)銷 傳輸開(kāi)銷以AMR-WB 23.85kbps為例加上RoHC未開(kāi)啟時(shí)的IP/RTP/UDP頭開(kāi)銷單路承載速率需求大概在40到50kbps左右所以很多早期基站配置取52kbps作為單用戶授權(quán)上限。但這個(gè)配置有個(gè)前提SBC不會(huì)在協(xié)商后重新計(jì)算并抬升帶寬。一旦SBC加入了G711編碼單路帶寬需求就會(huì)跳到80kbps以上52kbps的配置直接失去合理性。3.3 Diameter信令里的帶寬值max-requested-bandwidth-ul到底是誰(shuí)填的max-requested-bandwidth-ul是一個(gè)Diameter AVP由PCRF或PGW根據(jù)SBC發(fā)來(lái)的AAR消息內(nèi)容生成。也就是說(shuō)最終讓基站看到多少帶寬取決于SBC在AAR消息里傳輸?shù)膸捴?。如果SBC在轉(zhuǎn)發(fā)INVITE時(shí)修改了SDP的B行值A(chǔ)AR消息里的帶寬值也會(huì)跟著變最終在E-RAB SETUP REQUEST里體現(xiàn)出來(lái)。從SBC側(cè)抓包可以看到被叫側(cè)AAR消息的關(guān)鍵字段AAR (Diameter Credit-Control) avp: max-requested-bandwidth-ul (66) value: 88000這個(gè)值最直接地揭示了問(wèn)題的來(lái)源SBC申請(qǐng)的帶寬是88kbps超出了基站的授權(quán)上限。所以問(wèn)題鏈條其實(shí)是主叫SDP是49kbpsSBC重算后變成80kbps最終體現(xiàn)在AAR里變成了88kbps基站拒掉了。上下文里還出現(xiàn)了一個(gè)被叫側(cè)日志相關(guān)的標(biāo)記R6y以及一條Ix消息說(shuō)明問(wèn)題樣本量不少不同測(cè)試點(diǎn)觸發(fā)的概率較高。4. 真正的源頭在SBCINVITE帶寬為何從49變成80kbps4.1 SDP里的B行bAS:49與bAS:80的差異回看主叫側(cè)的信令手機(jī)發(fā)出的INVITE消息里SDP帶寬行是bAS:49代表應(yīng)用層帶寬需求為49kbps。但SBC轉(zhuǎn)發(fā)給被叫側(cè)的INVITE里B行變成了bAS:80。這一個(gè)數(shù)字的變化直接導(dǎo)致后續(xù)AAR帶寬申請(qǐng)?jiān)阶冊(cè)酱笞罱K突破了基站的授權(quán)上限。主叫側(cè)原始INVITE: v0 o- 123456 7890 IN IP4 192.168.1.100 cIN IP4 192.168.1.100 maudio 20000 RTP/AVP 97 98 artpmap:97 AMR-WB/16000 bAS:49 SBC轉(zhuǎn)發(fā)后的INVITE: v0 o- 123456 7890 IN IP4 192.168.1.101 cIN IP4 192.168.1.101 maudio 30000 RTP/AVP 0 97 98 artpmap:0 PCMU/8000 bAS:80對(duì)比兩邊就能看到SBC在轉(zhuǎn)發(fā)時(shí)做了兩件事一是在媒體協(xié)商里加入了G711編碼rtpmap:0 PCMU/8000二是根據(jù)G711的帶寬需求把bAS從49改成了80。為什么SBC會(huì)主動(dòng)加G711呢核心原因是該廠商SBC的C20版本默認(rèn)啟用了編解碼轉(zhuǎn)換也就是transcoding模式。SBC認(rèn)為對(duì)端網(wǎng)絡(luò)的編解碼配置可能不兼容AMR-WB就會(huì)在媒體面做一次語(yǔ)音編解碼轉(zhuǎn)換把AMR-WB轉(zhuǎn)成G711以便和傳統(tǒng)PSTN網(wǎng)絡(luò)互通。而G711是64kbps的裸語(yǔ)音編碼加上IP/RTP/UDP開(kāi)銷應(yīng)用層帶寬在80kbps左右所以SBC根據(jù)編碼協(xié)議重新計(jì)算了SDP的B行從49調(diào)整為80kbps。4.2 SBC編解碼轉(zhuǎn)換的帶寬重算邏輯SBC修改B行的邏輯本質(zhì)上是根據(jù)媒體協(xié)商的結(jié)果重新估算RTP媒體流的帶寬需求。不同編碼類型的帶寬參數(shù)不同G711A/U在凈負(fù)荷64kbps加上包頭開(kāi)銷在80kbps上下AMR-WB 23.85kbps加上開(kāi)銷在40kbps上下AMR-NB 12.2kbps總帶寬更低。SBC要做編解碼轉(zhuǎn)換時(shí)因?yàn)槊襟w面不再只是轉(zhuǎn)發(fā)而是真正解碼再編碼它會(huì)按照轉(zhuǎn)換后的編碼器類型重新計(jì)算帶寬并寫入SDP。在帶寬重算這一步里透?jìng)髋c轉(zhuǎn)換兩種模式的差別很大簡(jiǎn)要對(duì)比如下透?jìng)髂Ｊ絊BC不做編解碼轉(zhuǎn)換只轉(zhuǎn)發(fā)RTPSDP帶寬保持終端協(xié)商值不變 轉(zhuǎn)換模式SBC做編解碼轉(zhuǎn)換RTP終結(jié)在SBCSDP帶寬按目標(biāo)編碼類型重算本案例觸發(fā)的就是轉(zhuǎn)換模式。SBC把AMR-WB轉(zhuǎn)成G711后B行帶寬從49kbps變成80kbps帶寬申請(qǐng)一路傳導(dǎo)到基站側(cè)。如果SBC配置的是透?jìng)髂Ｊ郊葱湃谓K端媒體帶寬信息那么B行會(huì)保持49不變AAR帶寬申請(qǐng)也會(huì)維持在50kbps左右基站52kbps的授權(quán)上限就不會(huì)被突破。4.3 BCPLC參數(shù)信任終端媒體帶寬信息改為否SBC上有一個(gè)關(guān)鍵參數(shù)控制著這種行為即BCPLC配置里的信任終端媒體帶寬信息在英文界面中通常對(duì)應(yīng)Trust Terminal Media Bandwidth或類似名稱。默認(rèn)值是是也就是SBC信任終端在SDP里上報(bào)的帶寬不主動(dòng)修改B行。但當(dāng)該參數(shù)配置為否時(shí)SBC放棄信任終端上報(bào)值改為按自身策略計(jì)算帶寬填入SDP這樣出現(xiàn)G711編碼時(shí)帶寬被抬升到80kbps也就成了必然結(jié)果。把該參數(shù)改為否以后SBC在轉(zhuǎn)發(fā)INVITE時(shí)保留了終端的媒體帶寬信息修改后SBC轉(zhuǎn)發(fā)的INVITE: maudio 30000 RTP/AVP 0 97 98 bAS:49這樣可以保證AAR消息里的帶寬申請(qǐng)仍以終端上報(bào)值為基礎(chǔ)不再因?yàn)榫幋a轉(zhuǎn)換而翻倍。不過(guò)需要注意這種修改會(huì)把所有經(jīng)過(guò)該SBC的VoLTE呼叫設(shè)為不透?jìng)饔?jì)費(fèi)或帶寬信任模式會(huì)影響帶寬共享和長(zhǎng)期演進(jìn)規(guī)劃建議在測(cè)試驗(yàn)證后再上生產(chǎn)。5. 排查與避坑抓包、日志解讀與三個(gè)隱藏坑5.1 抓包時(shí)只看E-RAB消息會(huì)錯(cuò)過(guò)真正的源頭現(xiàn)象某次測(cè)試從基站側(cè)Trace里看到了E-RAB SETUP REQUEST里請(qǐng)求帶寬88kbps、基站返回Radio-resource-not-available于是判斷是基站側(cè)QCI1帶寬配置太低直接把基站帶寬調(diào)成200kbps結(jié)果故障復(fù)現(xiàn)用戶仍然聽(tīng)到呼叫失敗。原因把定位停在基站這一層沒(méi)有向上游追溯。真正的問(wèn)題是SBC側(cè)改了SDP帶寬才導(dǎo)致核心網(wǎng)請(qǐng)求的帶寬超標(biāo)。只調(diào)基站屬于治標(biāo)不治本帶寬申請(qǐng)邏輯沒(méi)改換個(gè)業(yè)務(wù)場(chǎng)景還會(huì)超限。解決排查一定要做完整信令鏈路比對(duì)從主叫INVITE的SDP、SBC轉(zhuǎn)發(fā)后的INVITE的SDP、AAR消息里的帶寬值、E-RAB SETUP REQUEST里的帶寬值這四個(gè)節(jié)點(diǎn)同時(shí)抓取對(duì)比每一跳的帶寬變化。哪一跳發(fā)生變化源頭就在哪里再往上追就找到了。5.2 基站的52kbps配置不能綁定單一編碼現(xiàn)象現(xiàn)場(chǎng)部分工程師認(rèn)為52kbps夠用因?yàn)楫?dāng)前手機(jī)終端上報(bào)的是AMR-WB帶寬需求只有40kbps左右語(yǔ)音質(zhì)量測(cè)試也通過(guò)。但加入多方通話或跨網(wǎng)呼叫時(shí)SBC一旦啟用G711轉(zhuǎn)換帶寬直接翻倍到80kbps以上52kbps的授權(quán)配額就不夠了。原因52kbps的配置只覆蓋了AMR-WB單編碼場(chǎng)景沒(méi)有把編解碼轉(zhuǎn)換后的G711開(kāi)銷算進(jìn)去。SBC加入G711后AAR帶寬請(qǐng)求值已經(jīng)超過(guò)基站授權(quán)上限必然被拒。解決按實(shí)際業(yè)務(wù)場(chǎng)景預(yù)留余量。如果SBC可能啟用G711轉(zhuǎn)換基站側(cè)QCI1最大授權(quán)帶寬應(yīng)調(diào)整到至少200kbps否則還要反復(fù)調(diào)參正確做法是直接按多方通話的峰值帶寬需求來(lái)規(guī)劃。5.3 日志時(shí)間戳不同步信令對(duì)不齊現(xiàn)象信令分析時(shí)發(fā)現(xiàn)SBC日志和基站日志時(shí)間對(duì)不上同一通呼叫的INVITE和E-RAB SETUP REQUEST時(shí)間戳相差數(shù)秒無(wú)法判斷到底是先改了SDP還是先觸發(fā)了承載建立失敗。原因不同網(wǎng)元設(shè)備的系統(tǒng)時(shí)間源不一致SBC可能用NTP同步基站用1588v2同步兩端存在秒級(jí)偏差?？缇W(wǎng)元聯(lián)合分析時(shí)沒(méi)有先做時(shí)間偏差校正。解決先看每臺(tái)設(shè)備的NTP同步狀態(tài)再取兩端的同一條標(biāo)準(zhǔn)消息如INVITE的Call-ID或Session ID做時(shí)間偏移對(duì)齊。更穩(wěn)妥的做法是在測(cè)試前就把所有網(wǎng)元時(shí)間統(tǒng)一到同一NTP服務(wù)器并在抓包時(shí)采集GPS時(shí)鐘參考這樣聯(lián)合分析時(shí)不會(huì)因?yàn)闀r(shí)間錯(cuò)位誤判事件順序。5.4 改完參數(shù)后沒(méi)有重新驗(yàn)證多方通話場(chǎng)景現(xiàn)象把BCPLC參數(shù)改成否后單路VoLTE呼叫測(cè)試全部通過(guò)帶寬請(qǐng)求恢復(fù)到49kbps基站側(cè)也不再返回Radio-resource-not-available以為問(wèn)題閉環(huán)了。但后續(xù)在多方通話場(chǎng)景再次出現(xiàn)503用戶從5G掉到4G。原因多方通話的媒體流數(shù)量是單路的倍數(shù)即使SBC不再重算帶寬多個(gè)媒體流疊加后的總帶寬請(qǐng)求也可能超過(guò)基站配額。單通測(cè)試通過(guò)不能代表多方通話場(chǎng)景沒(méi)問(wèn)題。解決在參數(shù)修改后做完整的回歸測(cè)試至少覆蓋單通、雙通、多方通話三個(gè)場(chǎng)景并同時(shí)監(jiān)測(cè)E-RAB SETUP REQUEST里的帶寬請(qǐng)求值。6. 落地修復(fù)與驗(yàn)證參數(shù)配置、回歸測(cè)試與信令閉環(huán)確認(rèn)修復(fù)不是簡(jiǎn)單地改一個(gè)參數(shù)就結(jié)束需要把SBC側(cè)和基站側(cè)放在一起調(diào)整并驗(yàn)證整條鏈路的帶寬申請(qǐng)恢復(fù)到終端真實(shí)需求值。SBC側(cè)把BCPLC配置里的信任終端媒體帶寬信息改為否保證轉(zhuǎn)發(fā)INVITE時(shí)保留終端的bAS原始值不做重算?；緜?cè)把QCI1最大授權(quán)帶寬從52kbps調(diào)整到200kbps以上以覆蓋多方通話和編碼轉(zhuǎn)換的峰值需求。兩個(gè)改動(dòng)必須同時(shí)生效。# SBC側(cè)典型配置示例實(shí)際命令以現(xiàn)場(chǎng)設(shè)備為準(zhǔn) # 開(kāi)啟終端帶寬信息信任禁止SBC重新計(jì)算 bcplc media bandwidth-mode trust-terminal改完后的信令驗(yàn)證我一般會(huì)強(qiáng)制走一遍完整流程先抓主叫原始INVITE、SBC轉(zhuǎn)發(fā)后的INVITE和E-RAB SETUP REQUEST三處消息的帶寬值進(jìn)行對(duì)比。如果轉(zhuǎn)發(fā)后的INVITE仍攜帶bAS:49而不是bAS:80且E-RAB SETUP REQUEST里的max-requested-bandwidth-ul不再超過(guò)基站配置值說(shuō)明核心問(wèn)題已經(jīng)消除。驗(yàn)證目標(biāo)值 主叫原始INVITE bAS:49 SBC轉(zhuǎn)發(fā)INVITE bAS:49 AAR帶寬請(qǐng)求值 ≤ 52000 E-RAB SETUP RESPONSE: setup success然后連續(xù)做10次以上的VoLTE呼叫測(cè)試不單是單通還要包含多方通話場(chǎng)景確認(rèn)不再出現(xiàn)503和Radio-resource-not-available用戶也不會(huì)在通話失敗后掉到4G。從那以后我每次處理503類的VoLTE失敗案例都會(huì)強(qiáng)制把INVITE和E-RAB兩側(cè)的信令拉通比對(duì)一遍確認(rèn)帶寬請(qǐng)求值的每一跳來(lái)源而不是看到Radio-resource-not-available就直接調(diào)基站參數(shù)。這套排查習(xí)慣幫我擋掉了不少返工希望也能幫到你。本文還有配套的精品資源點(diǎn)擊獲取