Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537 Warning: error_log(/data/www/wwwroot/hmttv.cn/caches/error_log.php): failed to open stream: Permission denied in /data/www/wwwroot/hmttv.cn/phpcms/libs/functions/global.func.php on line 537
本來是一直用jupyter跑R的,自己看過程什么的都沒有問題,但是身邊的同學大多數用的都是spss,很尷尬,想把自己的結果分析過程給同學瞅瞅就很麻煩,今天發現了一個可以幫助我的利器R Markdown。
嘗試著給大家寫寫,關注我!你不會后悔的,嘿嘿。
介紹R Markdown之前先介紹Markdown!
MarkDown是一種輕量級的【標記語言】,目前也被越來越多的寫作愛好者,撰稿者廣泛使用。一旦熟悉MarkDown這種語法規則,就可以享有一勞永逸的排版效果。
而R Markdown就是將R代碼和Markdown整合而成的幫助我們排版或者出版R代碼的。利用R Markdown我們可以將自己的數據分析過程轉換為PDF或HTML格式,方便我們快速做總結或書寫文檔和與他人共享。
R markdown可以記錄你使用的raw data,記錄你處理和清理數據的每一個步驟的code,可以顯示你使用的挖掘算法和可視化圖表,可以完整的說明整個task的思路和最終得到的結果。
R markdown可以讓你更好的展示或者報告分享自己的數據分析過程,哪怕你的受眾并不使用R也無所謂,Markdown可生成包括HTML、PDF、WORD、PPT等各種形式的內容。
如上圖,新建一個text file,因為今天是第一次寫R Markdown,我就沒有直接新建R Markdown了,是為了大家更好理解。大家也可以選擇直接新建R Markdown,不過你會發現新建的是一個演示文檔。
新建text file完成后將其保存,如下圖以Rmd為擴展名進行命名,此時我們的R Markdown就建好了。
為了更好的給大家說明,此次依然用一個很簡單的R project作為例子,譬如,我們在console中做了如下分析
data("cars")
str(cars)
summary(cars)
plot(cars)
hist(cars$speed)
boxplot(cars$dist)
上面的代碼都超級簡單,但是不懂R的人也看不明白。
好了,現在我想把我所做的上面的工作分享給我的同學,可是人家都不用R,也看不明白R代碼,怎么樣能讓他知道我的代碼的運行過程和究竟做了什么事呢,讓我們一起用R markdown來美觀清晰又易懂的展示我們的工作吧。
#Codewar 的第一個markdown,歡迎關注哦
**第一部分**
```{r}
data(cars)
str(cars)
summary(cars)
plot(cars)
```
***第二部分***
```{r}
hist(cars$speed)
boxplot(cars$dist)
```
車車的平均速度是 `r mean(cars$speed)`.
#完畢,歡迎關注codewar!
上面就是我寫的我的第一個R markdown代碼,這段markdown代碼完全重復了上面代碼塊中的分析過程,具體細節稍微解釋一下,以后的文章會詳細解釋,歡迎關注:比如說#這個符號就是標題,```{r}就是代碼塊,`r就是行內代碼,等等,R markdown還有很多妙用,我也正在學習,以后慢慢給大家分享。
上面的markdown代碼運行后點擊Knit你可以選擇輸出為html,pdf,ppt等等,比如我選擇輸出為html就是下圖中的樣子,這下不用R的同學也可以非常清楚的知道你的分析過程是怎樣的啦。
其余的markdown的用法,大家大可以參考R自帶的參考文件,當然你自己不愿意看的話,關注我就好啦,我講給你聽。
今天很簡單的給大家寫了R markdown的使用,其實R markdown還有很多東西我自己也不會正在學,以后會慢慢寫出來,同時今天文章中的markdown代碼我也一并上傳到百度云了,大家關注后私信自取,感謝大家耐心看完。發表這些東西的主要目的就是督促自己,希望大家關注評論指出不足,一起進步。內容我都會寫的很細,用到的數據集也會在原文中給出鏈接,你只要按照文章中的代碼自己也可以做出一樣的結果,一個目的就是零基礎也能懂,因為自己就是什么基礎沒有從零學Python和R的,加油。
(站外鏈接發不了,請關注后私信回復“數據鏈接”獲取本頭條號所有使用數據)
R數據分析:如何用R做數據模擬
/朱利中
語音呼叫仍然是目前運營商和企業業務必不可少的營銷手段。從獲利角度講,其業務收益雖然在運營商的收入占比中呈下降趨勢,但是收入仍然比較可觀。因此,無論是運營商還是企業客戶都一直對其業務中的灰色地帶-騷擾電話/語音營銷,或者批量呼叫業務沒有完全放棄。隨著STIR/SHAKEN的呼叫身份驗證技術的不斷推進,和FCC的強制要求,其業務量也開始迅速萎縮。運營商的營收也面臨巨大壓力。如何對語音業務進行升級或者突破,是運營商面臨的一個非常大的挑戰。最近,一些比較大的國外的運營商正在嘗試在呼叫身份驗證基礎上開發的新業務模式-rich call data或者中文翻譯為富呼叫數據。簡單來說,企業用戶呼出時,通過身份驗證的呼叫會攜帶呼叫方號碼,呼叫方地址和公司logo等信息,被呼叫方手機終端會顯示企業完整的呼叫身份。通過富呼叫數據提供的增值服務,運營商和企業客戶獲得了雙贏的局面,也避免了傳統運營商語音業務的萎縮的態勢。Rich call data的技術實現流程相對比較復雜,其處理流程涵蓋了多個技術節點和第三方的數據管理等問題。為了讓讀者全面了解需要的技術支撐,現在,筆者具體介紹關于rich call data或者富呼叫數據的實現流程,rfc7095,PASSporT以及在運營商SBC等處理的相關技術。另外,筆者增加了更多關于呼叫身份確認技術STIR/SHAKEN的實現所面臨的各種技術和商業方面的挑戰,包括如何實現SIP呼叫轉移到傳統PSTN的支持,如何通過SBC實現身份驗證,以及呼叫身份過濾以后的對用戶的更新過濾和sip div 頭中使用轉移標識和PASSporT 令牌以及綁定的呼叫號碼的細節,最后,筆者還補充了馬上在國內要執行的關于信息安全技術 基于密碼令牌的主叫用戶可信身份鑒別技術規范意見稿。還有,此章節內容也是筆者系列文章-SIP協議及新IP企業通信網絡技術概論中針對運營商方面的一個最新的補充內容,此文章作為概論的結尾章節。
關于SIP協議及新IP企業通信網絡技術概論其他章節內容,筆者可以參考最新歷史文檔和最早的文檔,例如:
SIP協議及新IP企業通信網絡技術概論-SIP網絡中完整NAT問題和處理方式和SBC在IMS網絡虛擬化NFV中部署討論分享
SIP協議及新IP企業通信網絡技術概論-核心SIP技術介紹-1
因為此文章章節比較多,多個章節還有一定的關聯關系,筆者專門單獨列出每個重點章節結合圖例做針對性地深入討論。本文章主要討論的內容如下:
關于RCD-rich call data背景介紹和基本概念
在我們日常生活中,我們經常會陌生人打來的電話。一些是客戶的咨詢電話,一些可能是其他教育機構,金融中介等的電話。這些電話一部分是真正的用戶或者其他客戶的電話,有一部分是騷擾電話或者騙子打來的電話。陌生人的電話到底是接還是不接? 如果漏接了客戶的電話,擔心自己錯過一個億的生意。接的話,這些電話有可能是營銷電話或者騙子的電話,浪費時間。
此圖例以及以下部分討論來自于互聯網資源
騷擾電話作為世界性難題,其他國家也面臨這些問題。人們已經不再接聽未知的呼叫。一些呼叫中心或者金融機構的客服系統產生了大量的垃圾呼叫,接通率逐年下降,呼叫中心效率大大折扣。根據福布斯引用Hiya 2020年呼叫報告,大約94%的未確認身份的呼叫最后成為未接聽的呼叫。另外,First Orion的數據表明,90%的比較可靠的呼叫是帶標識的呼叫。另外,根據businesswire的報道,美國幾大運營商-Verizon, T-Mobile, CTIA and iconectiv在SIPNOC 2022的大會上,針對任何提高Call Answer Rates,恢復消費者信心對部署RCD也做了分享研究。大概73%的行業領導者公司正在評估和考慮使用集中式的數據服務整合STIR/SHAKEN和RCD來降低用戶的損失,增加對機器人騷擾電話的過濾作用。目前,美國的一些運營商已經開始強制要求支持STIR/SHAKEN技術,并且運營商也正在積極推動RCD的技術應用,通過呼叫身份識別來進一步加強用戶接聽電話的安全體驗。關于STRI/SHAKEN 騷擾電話的技術實現方式,筆者在歷史文檔中
解決騷擾電話問題,道路是曲折的,前途是光明的-關于電話呼叫方身份驗證規范和STIR/SHAKEN騷擾加密技術的再討論 都做了非常詳細的分享說明。
對于RCD內容,我們需要進一步補充。讓我們大概了解RCD其概念原理。RCD是目前比較好的辦法,通過RCD就會更加方便地讓被呼叫方能夠識別呼叫方的公司標識,呼叫原因等相關的數據,這樣的話,被呼叫方也能夠明確所接聽的目的, 被呼叫方可以根據其驗證的信息決定是否接聽。
用戶渴望能夠顯示更多呼叫方豐富信息的支持。RCD(rich call data)就顯得比較重要了,它也是當前呼叫業務的一個的必然選擇。我們以前傳統的號碼顯示是通過運營商的CNAM或者其他增值服務來實現,為呼叫方推送和號碼相關的一些數據,但是,其數據往往缺乏實時性和準確性。因為騷擾電話的不斷增加,被呼叫方的訴求是當呼叫接聽時,被呼叫方手機端應該顯示準確的呼叫方信息,包括公司信息,呼叫原因等。因此,和以前的CNAM號碼服務方式比較,對被呼叫方來說,顯然,rich call data增加了很多的實用性。其基本概念也非常簡單,rich call data 利用了SHAKEN的呼叫技術,通過呼叫驗證,然后對此呼叫添加了部分呼叫號碼的屬性參數,最后為被呼叫方提供顯示呼叫方富數據屬性數據。最終,被呼叫方手機終端顯示了一些必要的富呼叫數據,例如,公司名稱,呼叫原因,公司logo,公司地址,驗證狀態等必要的富呼叫數據。在以下的示例中,支持了富呼叫數據的呼叫在被呼叫方的手機終端會顯示其響應的必要數據。 以下示例也展示了手機端顯示的必要信息,幫助被呼叫方判斷是否接聽此呼叫。
RCD的基本的業務處理方式如下:
關于rich call data相關基本介紹
Rich call data或者富呼叫數據利用了筆者已經介紹過的STIR/SHAKEN的技術提供了呼叫驗證,利用網絡帶外技術,添加了公司logo和公司地址,呼叫原因等數據,同時在STIR/SHAEKN中增加了其PASSporT擴展的支持,通過數字簽名和身份的方式包括了Rich Call Data (RCD)RCD的支持。RCD的支持格式是通過 JSON支持,其對象中聲明了關于呼叫的富呼叫數據屬性類別,包括了幾個核心的屬性數據:
關于以上RCD的說明,讀者可以參考PASSporT Extension for Rich Call Data-raft-ietf-stir-passport-rcd-19的五章節的關于PASSporT Claim "rcd" Definition and Usage。這里不再做過多介紹,在此文章的后續部分讀者會進一步涉及此內容。
以下示例中,我們可以看到,發起呼叫時就帶了有效的身份驗證的Identity。這里的示例僅說明了呼叫服務發起時帶的一個有效身份驗證。當然,我們后續還要介紹如何處理更加復雜的非法驗證的處理。
在發起呼叫時攜帶的有效的身份驗證頭
我們通過基本的概念介紹和處理流程的說明,讀者應該基本了解了其主要的處理步驟。接下來,我們會根據其每個環節的具體細節,為讀者說明如何實現RCD的處理。
關于RCD實現方式的討論
如果要實現企業用戶的RCD數據,運營商或者用戶首先需要輸入或者通過應用程序添加用戶的相關的信息,包括地址,公司名稱,JSON card的URL地址等等相關的信息。這些信息可以根據運營商針對STIR/SHAKEN服務部署的策略存儲到STIR/SHAKEN服務中。
企業用戶呼叫到運營商以后,運營商SBC需要轉發呼叫,通過SBC驗證,然后添加rich data。
具體示例數據如下:
"rcd": {
"jcd": ["vcard",
[ ["version",{},"text","4.0"],
[“fn",{},"text","Q Branch"],
[“org",{},"text","MI6;Q Branch Spy Gadgets"],
["photo",{},"uri",
"https://example.com/photos/quartermaster-256x256.png"],
["logo",{},"uri",
"https://example.com/logos/mi6-256x256.jpg"],
["logo",{},"uri",
"https://example.com/logos/mi6-64x64.jpg"]
]
],
"nam": "Q Branch Spy Gadgets"
}
更多關于JSON card 處理格式,讀者參考rfc7095。 關于運營商的SBC處理解決方案,讀者可以ribbon SBC參考以下示例:
通過以上示例,我們可以看出,第三方CA證書處理中心來實現集中實時處理。除了SHAKEN的PASSporT需要處理以外,RCD的其他數據有時也可能更新,例如URL,公司地址,或者logo鏈接等。這些數據需要在運營商對被呼叫方發送呼叫前都要分別執行驗證服務,然后支撐發送到被呼叫方。這里的呼叫認證ppt中支持了兩個類型,一個是SHAKEN類型,另外一個是RCD類型。具體的身份信息格式如下:
Identity: sv5CTo05KqpSmtHt3dcEiO/1CWTSZtnG3iV+1nmurLXV/HmtyNS7Ltrg9
dlxkWzoeU7d7OV8HweTTDobV3itTmgPwCFjaEmMyEI3d7SyN21yNDo2ER/Ovgt
w0Lu5csIppPqOg1uXndzHbG7mR6Rl9BnUhHufVRbp51Mn3w0gfUs=;
info=<https://biloxi.example.org/biloxi.cer>;alg=ES256;
ppt="rcd"
在以下的驗證中,運營商會對SHAKEN服務中心查詢SHAKEN和RCD的身份,包括x5u, logo鏈接,呼叫方運營商,目的地運營商等數據。在運營商B對被呼叫方執行最終呼叫時,同時攜帶了SHAKEN,RCD和身份頭。
除了通過RCD顯示呼叫方用戶呼叫數據的方式以外,筆者也在以前的文章中討論過關于新呼叫業務的支持。是否可以通過VoNR新通話技術利用數據通道實現其數據的展示?這可能也是未來在VoNR上疊加的功能。
對最新5G網絡中VoNR新通話技術白皮書的思考和關于SIP/IMS網絡/4G-VoLTEG和5G-VoNR中的業務和技術全面解讀
關于實現STIR/SHAKEN所面臨的各種挑戰
如果運營商想實現RCD和呼叫身份驗證的支持,首先從技術角度來說需要集成或者支持很多的服務。這些服務基本上需要運營商方面努力推動,包括部署新的服務,重新建構呼叫流程設置。這些對運營商來說可能都不是太大的問題。根據一份權威的市場調研報告來看,截止到2022年最近日期,目前用戶收到的呼叫絕大部分仍然是未進行SHAKEN認證的呼叫:
但是,同時運營商也正在逐漸增加對SHAKEN的支持:
實現SHAKEN技術部署的其中一個比較關注的問題是如何實現終端的顯示是運營商可能面對的極大挑戰。這里可能涉及到了手機操作系統平臺的介入問題。實際上,企業客戶想顯示更多關于呼叫方的信息,方便企業的營銷。但是,手機終端操作系統平臺可能會過濾或者屏蔽某些信息,這可能影響設計制造商的業務收益。可能運營商會支付一定的費用還是企業客戶支付使用,只能作為我們討論業務方面的話題,也是RCD業務面臨的一個比較大的風險。
另外一個風險是運營商是否有意愿更換當前比較老舊的傳統的PSTN設備。這些設備不能支持網絡接口,也不能實現數據集成。傳統的PSTN網絡環境中,硬件設備已經相當老舊,如果需要支持STIR/SHAKEN只能更新其設備,從傳統的PSTN設備更新為支持STIR/SHAKEN的接入網關設備。另外,一般的傳統PSTN網絡環境中缺乏對數據中心處理的支持,這些呼叫號碼如何集成仍然是一個問題,還有各種SIP網絡中SIP消息的兼容性支持,例如一些SIP呼叫中的P-Asserted-Identity的處理。另外,一些歐洲國家已經目前截止到2025年,語音網絡將全部升級為純IP網絡,而且需要實現STIR/SHAKEN的支持。運營商的固有的TDM網絡如何實現對STIR/SHAKEN升級,這也仍然是歐洲很多運營商面臨的嚴峻調整。為了實現其更換目標,運營商只能通過IP化改造來完成STIR/SHAKEN的服務支持。以下示例是一個關于TDM進行IP化改造以后對STIR/SHAKEN的支持。以下示例中,通過帶外STIR支持方式,實現STIR/SHAKEN服務。
在以上示例中,在現有的TDM網絡環境中,一般情況下,終端首先對運營商的TDM交換機進行呼叫,然后通過PSTN網絡路由到另外一個目的地運營商的TDM交換機,最后呼叫對端終端。但是,如果實現IP化的STIR/SHAKEN支持的話,傳統的TDM交換機在呼叫PSTN網絡前,TDM交換機增加了一個TDM-SIP網關的STIR/SHAKEN服務支持。首先需要通過一個TDM-SIP網關的呼叫處理,TDM-SIP支持了STIR/SHAKEN服務以后,POST PASSporT進行查詢數據庫,返回結果以后,再對PSTN網絡進行呼叫。呼叫抵達對端以后,TDM交換機同樣需要進行TDM-SIP網關的STIR/SHAKEN查詢支持,通過擴展出來的TDM-SIP網關執行STIR/SHAKEN查詢,返回查詢結果和驗證結果后,決定對此呼叫進行繼續轉發還是過濾。關于傳統TDM交換機實現對STIR/SHAKEN支持的規范細節,讀者可以參考RFC8816以及RFC8224。在此規范中,羅列了5種關于實現TDM網絡支持STIR/SHAKEN的用戶場景,包括了:
此規范中介紹了關于PASSporT的存儲和獲取的處理流程以及Call Placement Service (CPS)數據庫的處理機制。其實現流程細節如下:
前面我們介紹了關于傳統TDM交換機支持STIR/SHAKEN的實現方式。在當前的網絡環境中,基于IP語音的交換方式已經在現代企業通信環境中起到了絕對的支撐作用。因此,在傳統PSTN線路運營到IP語音交換的呼叫路徑上或者IP呼叫的話,需要通過另外一種處理方式來實現關于PASSporT的驗證處理。為了實現PASSporT的驗證處理,需要在運營商的SBC實現PASSporT支持。這里我們可以看到,呼叫發起以后,首先需要通過運營商的STIR/SHAKEN 服務對呼叫進行認證服務,此呼叫支持了簽名支持以后,運營商通過運營商自己的SBC對CPS服務數據庫發送PASSporT。然后此呼叫被發送到PSTN網絡。在對端運營商接收到呼叫以后,對端運營商的SBC首先需要獲取此呼叫的PASSporT,然后運營商對帶PASSporT的這個呼叫進行STIR/SHAKEN 驗證服務。獲取到驗證的呼叫以后,運營商根據驗證結果決定是否把這個呼叫發送到目的地終端客戶。
綜上所述,結合目前網絡的推進速度,從以上網絡架構來看,運營商現在不僅僅面臨繼續對5G或者6G網絡的投資,如果想實現對STIR/SHAKEN支持的話,還要對傳統PSTN網絡投入SBC,增加其驗證流程。所以,很多運營商可能也正在觀望中,沒有太多動力推動來推動此業務的升級。
關于STIR/SHAKEN技術針對呼叫轉移的技術挑戰
在以上的章節中,筆者介紹了關于PSTN網絡和IP網絡環境中針對STIR/SHAKEN的業務支持的解決方案分享。但是,在具體的業務場景中,關于呼叫身份的驗證仍然具有很多挑戰,例如呼叫轉移以后的呼叫身份驗證問題。用戶可以想象一下,假設,一個號碼呼出以后,到對方接聽以后,然后發起了一個呼叫轉移,呼叫轉移以后,號碼身份狀態就會隨之發生變化。如果沒有完整更新其呼叫身份的話,那么最終用戶可能看到的是一個未進行呼叫身份驗證的呼叫。這樣的話,整個呼叫身份驗證流程就會失敗。如何跟蹤此呼叫的路徑中完整的身份狀態是一個需要面對的挑戰。在IP或者SIP網絡環境中,轉移的呼叫一般稱之為diverted的呼叫。具體的支持策略是,通過在SHAKEN中增加一個擴展支持- “div” PASSporT。通過九個步驟的流程處理來實現全程呼叫轉移的身份驗證跟蹤。
在以上處理流程中, 對于呼叫轉移的號碼進行了完整的驗證和跟蹤處理。具體流程已經在圖例中進行了標識。在整個呼叫流程的處理過程中,讀者需要注意的是在TN-b 對呼叫進行轉移處理時,在INVITE中包含了另外一個身份,此身份的div中添加了orig/dest/div 三個參數, 它們分別是a/c和b。呼叫接收方然后再次轉發此呼叫到最終呼叫目的地。在最終呼叫目的地仍然需要進行STIR/SHAKEN的三方驗證服務,檢查其關聯性,然后對最終目的地呼叫方返回驗證的INVITE。最終呼叫目的地運營商最后對TN-c 發起呼叫。從以上對呼叫轉移的處理中,我們可以看到一個div頭, 此div header是SIP協議的一個擴展,它支持了PASSporT來驗證其身份狀態。在下面的章節中,筆者進一步為讀者介紹一些關于div PASSporT的細節內容。
關于SIP invite中的div頭處理細節
在討論Call Diversion時,筆者必須首先說明幾個主要的關于呼叫業務的概念和區別,避免讓讀者迷糊。從籠統的或者比較寬泛的概念中,呼叫轉移可能存在以下幾個方面的解釋,它們有著非常大的區別。筆者對部分內容進行了標識,和Call Diversion,Redirect和Retarget的不同概念說明:
Call Diversion: Any call feature that updates the destination telephone number of a call to a new or alternate telephone number. Example call features include the various forms of call forwarding, find-me/follow-me (simultaneous or sequential ringing), and automatic call distribution.
Redirect: As defined in RFC 3261 [Ref 6], "redirect" refers to the process where a SIP entity redirects a SIP request to a new destination by responding to the request with a 3xx Redirection class response. This specification addresses redirection only for INVITE requests, and only for the case where the 3xx response is handled by a recursing SIP proxy that retargets the INVITE request to the new destination.
Retarget: As defined in RFC 7044 [Ref 9], "retarget" refers to the process where a SIP entity updates the RequestURI of a SIP request. This specification narrows the scope of the RFC 7044 [Ref 9] definition to include only INVITE requests, and only for cases where the update changes the canonical value of the telephone number identified by the INVITE Request-URI.
這里我們重點討論Call Diversion。其他兩個概念不再進行討論。讀者如果有興趣的話,可以自己進一步研究。當然,如果需要實現STIR/SHAKEN支持的話,那是另外一個話題,比如IPPBX中的STIR/SHAKEN 呼叫業務的支持等。筆者將在未來的文章中對其處理過程進行深入討論。以下示例是一個完整的關于經過呼叫轉移的SIP INITE攜帶兩個ldentity,分別支持了不同的ppt 類型,一個是SHAKEN,另外一個就是呼叫轉移的div 擴展。
針對SHAKE和div的PASSporT的token 令牌分別是:
在保護頭中包含了身份證明信息,例如ppt類型,證書路徑等。在payload中包括了呼叫運營商,呼叫初始號碼,轉接號碼和最終目的地號碼等。關于div的PASSporT令牌的規范說明,讀者可以參考RFC8946(Personal Assertion Token (PASSporT) Extension for Diverted Calls)。關于SHANEK的PASSporT,讀者可以參考https://art.tools.ietf.org/id/draft-ietf-stir-passport-shaken-03.html和RFC8225 關于PASSporT的令牌的定義使用。
上面我們討論了關于呼叫轉移流程中實現div PASSporT的處理流程。接下來,我們進一步討論在呼叫轉移過程中,如果轉移的網絡是非IP網絡,例如接入到PSTN網絡中的技術處理策略。在以下圖例中,如果發送呼叫轉移的話,呼叫轉移的網絡在新的身份中支持了PASSporT-div-o, 并且包含了一個opt(
Original PASSporT)要素。
讀者一定要注意這里的INVITE 呼叫所包含的身份信息。在div-o 的PASSpoorT中,它包含了一個opt 要素, 并且在opt中還包含了一個原始的SHAKEN PASSporT的完整拷貝,而不是在SIP INVITE中包含多個身份的方式。在前面的示例中,INVITE中包含了兩個身份。這是呼叫轉移到IP網絡和非IP網絡(PSTN)它們之間的根本區別。 在實現呼叫轉移到非IP網絡或者PSTN網絡的驗證中,這個流程處理大概經過11個主要步驟。這個新的PASSporT存儲到CPS服務數據庫,并且將會通過CPS 數據庫進行驗證。最終呼叫目的地的PSTN網絡將根據從SHAKEN獲得的服務驗證,然后轉移此呼叫到最終目的地號碼。另外,其身份中的PPT類型也發生了變化,ppt現在是div-o, 而不是以前的div類型。更多關于div-o的細節,讀者查閱RFC8946的第五章節關于div-o的使用。
利用呼叫分析引擎技術來過濾騷擾電話
除了運營商通過本身的SHAKEN驗證中心來驗證呼叫身份以外,運營商也可以以第三方分析引擎結合SHAKEN來實現呼叫身份的驗證。呼叫分析引擎具體實現方式如下:
企業用戶或者其他終端用戶需要呼叫到運營商SBC端,如果非法侵入的用戶可能無有效的PASSporT。呼叫發送到運營商的SBC端,然后SBC呼叫發起一個INVITE攜帶PASSporT,通過分析引擎驗證以后,最后符合呼叫的身份,如果是一個非法呼叫或者被標識了無效的PASSporT是無法通過其認證的。分析引擎可以通過SHAKEN服務訪問以及匯聚第三方其他數據來集中進行判斷分析。
關于呼叫身份的后處理問題討論
前面我們花費了很多精力討論如何實現呼叫身份的確認以及其呼叫轉移后的SHAKEN處理。運營商通過在呼叫路徑中不同的技術手段實現了其呼叫身份的驗證。成功驗證的呼叫當然可以順利抵達呼叫終端。但是,我們也可能會經常遇到未成功認證的呼叫身份。未認證成功的呼叫可能就被運營商過濾掉了。如何處理過濾掉的呼叫,或者如何讓呼叫方獲悉其呼叫已經被過濾,過濾的原因等等。FCC對其處理有一個規定,要求運營商過濾掉呼叫以后,必須對呼叫方返回過濾提示,推薦使用的SIP錯誤碼為607和608. 在過濾解封的處理流程中,呼叫分析引擎通過和SHAKEN集成,支持了vcard來獲取完整的過濾原因和聯系方式等信息。
如果集成了傳統網絡的話,返回了608的話,在SIP頭中可以增加Call-Info header。
在這個頭中必須包括"jwscard"的目的參數。在jwscard中必須包含有效的json 格式簽名。下面我們可以看一個支持了SHAKEN的INVITE:
INVITE sip:+12155550113@tel.one.example.net SIP/2.0
Max-Forwards: 69
Contact: <sip:+12155550112@[2001:db8::12]:50207;rinstance=9da3088f3>
To: <sip:+12155550113@tel.one.example.net>
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
P-Asserted-Identity: "Alice"<sip:+12155550112@tel.two.example.net>,
<tel:+12155550112>
CSeq: 2 INVITE
Allow: SUBSCRIBE, NOTIFY, INVITE, ACK, CANCEL, BYE, REFER, INFO,
MESSAGE, OPTIONS
Content-Type: application/sdp
Date: Tue, 16 Aug 2016 19:23:38 GMT
Feature-Caps: *;+sip.608
Identity: eyJhbGciOiJFUzI1NiIsInR5cCI6InBhc3Nwb3J0IiwicHB0Ijoic2hha2V
uIiwieDV1IjoiaHR0cDovL2NlcnQuZXhhbXBsZTIubmV0L2V4YW1wbGUuY2VydCJ9.eyJ
hdHRlc3QiOiJBIiwiZGVzdCI6eyJ0biI6IisxMjE1NTU1MDExMyJ9LCJpYXQiOiIxNDcx
Mzc1NDE4Iiwib3JpZyI6eyJ0biI6IisxMjE1NTU1MDExMiJ9LCJvcmlnaWQiOiIxMjNlN
DU2Ny1lODliLTEyZDMtYTQ1Ni00MjY2NTU0NDAwMCJ9.QAht_eFqQlaoVrnEV56Qly-OU
tsDGifyCcpYjWcaR661Cz1hutFH2BzIlDswTahO7ujjqsWjeoOb4h97whTQJg;info=
<http://cert.example2.net/example.cert>;alg=ES256
Content-Length: 153
v=0
o=- 13103070023943130 1 IN IP6 2001:db8::177
c=IN IP6 2001:db8::177
t=0 0
m=audio 54242 RTP/AVP 0
a=sendrecv
一個SIP中介實體返回了:
SIP/2.0 608 Rejected
Via: SIP/2.0/UDP [2001:db8::177]:60012;branch=z9hG4bK-524287-1
From: "Alice" <sip:+12155550112@tel.two.example.net>;tag=614bdb40
To: <sip:+12155550113@tel.one.example.net>
Call-ID: 79048YzkxNDA5NTI1MzA0OWFjOTFkMmFlODhiNTI2OWQ1ZTI
CSeq: 2 INVITE
Call-Info: <https://block.example.net/complaint-jws>;purpose=jwscard
最終這個呼叫的最小的jcard數據是這樣的:
["vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Robocall Adjudication"], // 機器人呼叫
["email", {"type":"work"}, "text",
"remediation@blocker.example.net"] // 聯系方式
]
]
關于呼叫認證過濾后的返回處理機制,讀者可以進一步學習一些RFC。關于607 code, 參考rfc8197,關于608 code,參考rfc8688。
構建騷擾電話協同處理機制來解決呼叫身份驗證問題
通過筆者的一系列介紹中我們可以看出,技術手段的實現都最終需要運營商落實。其實,最終要杜絕或者消滅騷擾電話的話,從國家層面或者國際合作的層面才能解決這個問題。目前可以看到的美國運營商已經開始行動了,對運營商強制要求執行。美國國會議員已經正式提交了關于機器人騷擾電話濫用犯罪的法案-TRACED Act Implementation(Telephone Robocall Abuse Criminal Enforcement and Deterrence). 在此法案中明確規定運營商必須強制使用STIR/SHAKEN 呼叫身份認證工具,并且列出了實施路徑和時間表。
FCC已經正式發布了網關接入的強制要求。美國本土運營商必須支持STIR/SHAKEN的呼叫認證服務, 國外運營商接入到美國本土網絡時需要通過FCC 數據庫進行記錄登記。
在部署STIR/SHAKEN時,當然各種運營商和國際之間的運營商接入都會發生一定的變化。如何防范國際呼叫的騷擾電話和對其呼叫進行跟蹤,如何讓國際呼叫支持STIR/SHAKEN身份認證服務,這些都需要通過國際電信組織來完善,例如建立國際間的STIR/SHAKEN服務方式:
如果建立起了比較完善的STIR/SHAKEN 呼叫身份跟蹤機制,支持STIR/SHAKEN的聯盟之間就可以針對騷擾電話號碼,以及為騷擾電話提供線路服務的運營商進行標識,根據其令牌和證書進行跟蹤標識,對其服務進行評估,然后采取進一步的強制措施,包括通過公開的Robocall Mitigation Database 查詢其運營商的服務水平和質量,倒逼運營商減少對騷擾電話服務支持。例如,從SHAKEN的認證信息中體現了完整的呼叫身份信息,從x5u中我們可以查詢到證書簽發機構,從origid中可以查詢到騷擾電話的運營商認證信息。
讀者也可以查詢公開的FCC 關于Robocall Mitigation Database
https://fccprod.servicenowservices.com/rmd?id=rmd_listings
另外,除了運營商需要繼續努力來支持STIR/SHAKEN 呼叫認證服務以外,也可以通過手機平臺對呼叫進行設置或者標識的支持來降低騷擾電話的問題。但是,電話已經接入到用戶端,其用戶已經受到騷擾,這種方式缺乏規范性,同時也對解決呼叫身份驗證沒有太大的幫助,只是一種被動防范的方式。
雖然運營商都在努力部署和支持SHAKEN,但是,打通整個運營商的呼叫數據仍然需要更高層級的運營商之間的協同。各種非法電話已經讓FCC倍感壓力。
來自于:https://tracebacks.org/wp-content/uploads/2021/08/ITG-Report-Combatting-Illegal-Robocalls.pdf
Industry Traceback Group是FCC設計的一個呼叫回溯的組織。目前,其會員數量達到30多個,會員基本上都是美國比較主流的運營商,這樣可以杜絕大家互相扯皮,踢皮球。Traceback 是一種跟蹤回溯機制,通過約定的策略和機制來保證呼叫身份的正常和狀態更新。Traceback根據認定的呼叫身份進行互聯互通和響應反饋。關于 ITG 的POLICIES AND PROCEDURES的細節讀者可以查看參考鏈接中的PDF文件。
國內關于呼叫身份驗證的推動進程
前面筆者介紹了大量的關于SHAKEN的技術和具體在運營商之間部署的技術流程,包括了其他呼叫業務中所面臨的技術問題,以及如何支持傳統的PSTN網絡的SHAKEN認證。其實,國內的推進速度也非常快。全國信息安全標準化技術委員會也根據SHAKEN的一些缺點,推動發布了基于SHAKEN的CHAKEN技術。由牽頭單位中國科學院大學、參與單位中國電信集團有限公司和微位 (深圳)網絡科技有限公司一起對本標準中的 CHAKEN 方案進行了試驗驗證,并且在2022年03月30日發布了關于關于國家標準《信息安全技術 基于密碼令牌的主叫用戶可信身份鑒別技術規范》稿征求意見的通知。其實現架構如下:
讀者有興趣的話,可以查閱此意見稿,通過參考鏈接下載關于信息安全技術 基于密碼令牌的主叫用戶可 信身份鑒別技術規范。
其SIP INVITE信息格式如下:
INVITE sip:alice@example.com SIP/2.0
Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bKnashds8
To: Alice <sip:alice@example.com>
From: Bob <sip:12155551212@example.com;user=phone>;tag=1928301774>
Call-ID: a84b4c76e66710@example.com
CSeq: 314159 INVITE
Max-Forwards: 70
Identity: tokenindex=v_tokenIndex@address;ppt=CHAKEN;
總結
本文章討論了多個目前運營商針對呼叫身份驗證STIR/SHAKEN,和富呼叫數據-RCD,以及部署SHAKEN所面臨的挑戰和目前國內即將執行的CHAKEN技術以及基于密碼令牌的主叫用戶可 信身份鑒別技術規范。RCD是運營商業務的新的服務突破點,它會給用戶帶來很多更好的呼叫業務體驗。通過SHAKEN技術實現呼叫身份驗證,幫助用戶杜絕騷擾電話和騙子電話,以及各種非法呼叫。目前,國內的騷擾電話也非常猖狂,運營商貌似也無可奈何。
通過CHAKEN技術從呼叫源頭對呼叫進行身份跟蹤,能夠極大降低騷擾電話的發生。
在針對SHAKEN的部署環節中,筆者主要深入討論了如何實現PSTN網絡對SHAKEN身份的支持,通過SHAKEN和SBC,以及呼叫分析引擎對呼叫進行全程跟蹤,同時筆者又對呼叫業務中呼叫轉移的技術實現進行了詳解,幫助讀者進一步深入了解呼叫轉移的流程和對每個節點的SHAKEN的支持,查詢等。
另外,部署執行FCC的SHAKEN技術,需要各個運營商或者全世界的運營商共同構建一個SHAKEN的聯盟,通過SHAKEN來跟蹤不同國家,不同運營商的呼叫,同時能夠實現實時協同來提高SHAKEN服務的效率。
國內即將部署的CHAKEN可能也會面對美國運營商所面臨的技術問題和運營商之間,呼叫業務,運營商不同網絡之間的協同的問題,我們希望國內的CHAKEN技術能夠更加完善,快速推向市場,提高用戶對呼叫業務的體驗。
說明,我們討論的RCD,SHAKEN技術以及CHAKEN技術都是正在更新的技術,文章中的一些規范或者技術實現方式可能會不斷更新。另外,筆者水平有限。因此,文章中難免會存在很多錯誤,望諒解!
文共3997字,預計學習時長8分鐘
圖片來源:pexels.com/@pixabay
由于R語言生態系統內容繁復并在不斷發展,人們往往容易忽視一些切實有用的知識。這些技巧往往非常簡單,但對于完成工作有很大的幫助。
本文將介紹十個能夠讓R語言編程工作更加輕松的小知識。
在if語句基于其他變量值來選定某個值時,switch可以很方便地縮短if語句。這個技巧在編程中需要根據之前的抉擇加載一個不同的數據集時非常有用。比如說,現在有一個變量“animal”,編程需要根據animal是dog,cat還是rabbit來加載一個不同的數據集。利用switch函數,可以輸入以下代碼:
data <-read.csv( switch(animal, "dog" ="dogdata.csv", "cat" ="catdata.csv", "rabbit" ="rabbitdata.csv") )
當需要根據一個或多個輸入菜單選擇在Shiny應用程序中加載不同的數據集甚至環境文件時,這個技巧非常有用。
和R hack軟件系統相比,RStudio IDE(IntegratedDevelopment Environment,集成開發環境)中更常用到這一類技巧。這些常用命令的快捷鍵非常有用,可以節省很多敲鍵盤的時間。比如Ctrl+Shift+M(用于管道操作符%>%)和Alt+-(用于賦值運算符<-)兩個快捷鍵。想要了解更多方便好用的快捷鍵,可以在RStudio中輸入Atl+Shift+K查看。
如果想要創建一個能快速啟動和高效運行的Shiny儀表盤,可以選擇flexdashboard。這個包提供簡單的HTML快捷方式,可以簡化側邊欄創建和構建行列展示。還有超級便捷的標題欄,可以把應用程序編譯到不同的頁面,以及把圖標和鏈接放入Github代碼和郵件地址等。
由于flexdashboard包基于RMarkdown進行操作,它允許把所有應用程序放在一個Rmd文件中,而不必像shinydashboard那樣把程序分成獨立的服務器和UI(User Interface,用戶界面)文件。在需要創建一個簡單的儀表盤初始版本并將其并入更高級的設計版本時,flexdashboard包十分好用。利用flexdashboard包可以在一個小時內啟動和運行儀表盤。
R Shiny常常讓人崩潰,特別是在彈出一般性錯誤提醒而程序員又一頭霧水的時候。隨著Shiny的發展,越來越多的驗證函數和測試函數加入了Shiny,幫助程序員更好地診斷和提醒錯誤。
當操作環境中沒有其他變量時,req()函數可以悄無聲息地阻止一個操作的發生,并且不彈出錯誤提醒。程序員因而可以在此前的操作中有條件地展示UI元件。以第一個小技巧中提到的例子為例:
output$go_button<- shiny::renderUI({ # only display button if an animal input hasbeen chosen shiny::req(input$animal) # display button shiny::actionButton("go", paste("Conduct", input$animal, "analysis!") ) })
validate()函數則可以在輸出結果前進行檢查。如果某個條件沒有滿足,特定的錯誤提醒會彈出。比如說當用戶上傳了錯誤的文件時:
# get csv inputfile inFile <-input$file1 data <-inFile$datapath # render table onlyif it is dogs shiny::renderTable({ # check that it is the dog file, not cats orrabbits shiny::validate( need("Dog Name" %in%colnames(data)), "Dog Name column not found - did youload the right file?" ) data })
如果在分享代碼時,設置了數據庫登錄憑證或類似的設置,可以利用系統環境,防止憑證被上傳到Github或其他地方造成代碼泄露。可以把這些憑證作為命名環境變量放在R session中。比如:
Sys.setenv( DSN = "database_name", UID = "User ID", PASS = "Password" )
這些環境變量可以用來登錄分享的腳本。比如:
db <-DBI::dbConnect( drv = odbc::odbc(), dsn = Sys.getenv("DSN"), uid = Sys.getenv("UID"), pwd = Sys.getenv("PASS") )
更加簡便的是,如果頻繁使用某些憑證,可以在操作系統中把它們設置為環境變量。如此,用R語言系統工作時,便無需在代碼中輸入就可以隨時使用這些憑證。(注意有憑證權限的人。)
界面上有很多代碼,然而它們并不像你想要的那樣整潔,你也沒有時間進行多線編輯。不要擔心。styler包有多個函數可以自動編輯代碼,生成tidyverse風格。只需要簡單地運行styler::style file(),它就會完成大部分(并不是所有)的工作。
當你分析了一大堆關于狗的事實并寫完一個滿意的R Markdown文件時,你被告知,“我還是對貓更感興趣”。這要怎么辦呢?不要擔心。如果參數化了R Markdown文件,只要通過一個命令,就可以自動生成一份相似的關于貓的報告。
具體來說,需要在R Markdown文件的YAML標頭中設置參數,并給每個參數賦值。比如:
--- title: "AnimalAnalysis" author: "KeithMcNulty" date: "21March 2019" output: html_document: code_folding: "hide" params: animal_name: value: Dog choices: - Dog - Cat - Rabbit years_of_study: input: slider min: 2000 max: 2019 step: 1 round: 1 sep: '' value: [2010, 2017] --
然后只需把這些變量用R語言,如params$animal_name和params$years_of_study寫進文件中就可以了。如果正常轉換文件,那么每個參數就會被設置成默認值。但是,如果在轉換文件選擇參數時,選擇了RStudio中Knit下拉列表中的選項(或使用了kint_with_parameters()函數),一個菜單就會出現,來在轉換文件前選擇參數。非常棒!
參數轉換
revealjs包內嵌R代碼,可以使用直觀的幻燈片導航菜單在HTML中創建賞心悅目的演示文稿。它可以在R Markdown中使用,并有非常直觀的HTML快捷方式,可以創建具有嵌套和邏輯結構的各種風格的漂亮幻燈片。HTML格式的演示文稿也意味著人們在聽演講時可以繼續使用平板電腦或手機。這真的很方便。可以通過安裝包并在YAML標頭中調用來設置一個revealjs演示文稿。下面展出了使用revealjs做的一個演講的YAML標頭。
--- title:"Exporing the Edge of the People Analytics Universe" author: "KeithMcNulty" output: revealjs::revealjs_presentation: center: yes template: starwars.html theme: black date: "HRAnalytics Meetup London - 18 March, 2019" resource_files: - darth.png - deathstar.png - hanchewy.png - millenium.png - r2d2-threepio.png - starwars.html - starwars.png - stormtrooper.png ---
revealjs助你輕而易舉完成線上演示文稿
R Shiny中有110種HTML標簽,可以為各種各樣的HTML命令,如格式化,提供快捷方式。然而,大部分人都沒有充分利用這些標簽。比如創建了一個shiny應用程序,該程序在執行某個任務時需要花費大量的時間。用戶希望在等待完成該任務的過程中,能夠執行其他的多項任務,所以可以利用tags$audio這一標簽,讓該應用程序在完成任務時播放勝利號角來提醒用戶。
praise包具有極其簡單但十分有用的功能,即贊美用戶。盡管這一功能看起來是毫無意義的自我贊賞,它實際上發揮著巨大的作用。它可以在用戶成功地完成一個任務時,對用戶進行贊美或鼓勵。程序員也可以把這個包放在已完成的腳本的最后,在程序順利運行之后享受它帶來的幸福瞬間。
praise包
留言 點贊 關注
我們一起分享AI學習與發展的干貨
歡迎關注全平臺AI垂類自媒體 “讀芯術”
*請認真填寫需求信息,我們會在24小時內與您取得聯系。