您當(dāng)前的位置是:  首頁 > 新聞 > 國內(nèi) >
 首頁 > 新聞 > 國內(nèi) >

FreeSWITCH 180還是183?

2019-01-07 10:31:56   作者:Seven Du   來源:CTI論壇   評論:0  點擊:


  在FreeSWITCH中怎么配置回180還是183,是一個經(jīng)常被問到的問題。然而,答案卻遠沒有你想象中的那么簡單。
  要明白怎么配置,首先你需要明白180和183的來龍去脈。另外,你自己還要知道你要干什么。
  “什么?我提的問題我當(dāng)然知道我要干什么!” 也許你會這樣咆哮,也許你真的知道你要干什么,但是,我不知道。所以,在你得到有效的回答之前,你得先學(xué)會讓我知道。
  好了,先不爭論這個,我們來說說什么是180和183。
  在SIP通信中,所有1開頭的響應(yīng)叫臨時響應(yīng),常見的有100,180和183。這些響應(yīng)一般是對INVITE請求的響應(yīng)。使用場景是這樣的:主叫用戶(A)在發(fā)起一個呼叫時,會向被叫用戶(B)發(fā)起一個INVITE請求,被叫用戶在收到這個請求后,會給主叫用戶一個響應(yīng),一般的響應(yīng)流程是回100,緊接著回180,或(和)183。
  INVITE
  A <-----------> B
  180/183
  其中,100主要是信令層的,它的作用是B告訴A它收到了A的INVITE請求。關(guān)于它的作用實際也可以講一講的,但那就到信令的底層了,大家一般可以不用關(guān)注。
  180/183的作用是B告訴A,你可以聽回鈴音了。
  什么是回鈴音?這要從更早的模擬電話時代講起。A給B打電話,B的話機會振鈴,同時A的話機回放回鈴音(嘟嘟聲),這樣,A就知道B的話機振鈴了。
  所以,回鈴音是模擬電話時代的事情,它的作用就是給A一個提示,對方的電話正在振鈴,這樣,A就可以放心地等待B接電話。當(dāng)然,隨著技術(shù)的進步和時代的發(fā)展,回鈴音也在進步,典型地,除了嘟嘟聲以外,電信運營商也會利用這段等待的時間給用戶放一些音樂,甚至是廣告,反正閑著也是閑著。這些音樂或廣告就稱為彩鈴,這些是在A與B正式通話前播放的,因此不對A收費。但是由于彩鈴也是資源,因此運營商可能會對B收費(B放音樂提高自己的逼格,或者放廣告提升自己的形象甚至獲取商業(yè)利益,收費也是有道理的)。
  到了SIP時代,就需要在SIP中描述這些回鈴音或彩鈴,這些回鈴音或彩鈴是真正的聲音數(shù)據(jù),稱為媒體(Media)。但為了將它與真正的媒體(即A與B真正的通話數(shù)據(jù))相區(qū)別,將其為早期媒體,即Early Media。
  SIP的全稱是(Session Initiation Protocol,即會話初始協(xié)議),它僅僅是完成會話的協(xié)商,但是實際的媒體如何傳輸卻需要另外一個協(xié)議來協(xié)商,負責(zé)描述媒體的協(xié)議稱為SDP(Session Description Protocol),即會話描述協(xié)議。不過,SDP寄生在SIP中,典型地,它寄生在INVITE消息和183消息中。當(dāng)A向B發(fā)起呼叫時,它需要把自己的SDP放到INVITE消息中發(fā)給B,同時,B在183消息中放入自己的SDP,回送給A。當(dāng)雙方都知道對方的SDP后,真正的媒體數(shù)據(jù)就可以傳輸了,這時,A才聽到B的Early Media。
  為了幫助大家理解SDP,我們再進一步。假設(shè)B接聽了電話,B會響應(yīng)200 OK消息,該消息也帶了SDP(可能跟183中的相同也可能不同),用于建立A與B真正的通話,畢竟A給B打電話是為了跟B通話,而不是為了聽Early Media中的音樂或廣告。
  所以,不管是183中的SDP,還是200 OK中的SDP,都是為了建立媒體服務(wù)的。區(qū)別只是一個叫Early Media,另一個叫Media。其實Early Media和Media差別除了一個是廣告一個是真正的B的聲音外,差別也不大,非要說差別的話,那就是運營商的收費方面有差別,因為Early Media是不收費的。
  也許有人開始嫌我羅嗦了,但是,我確信,有些人真的不是從根本上理解我上面說的這些,包括一些開始嫌我羅嗦的人。不信,耐心點接著往下看。
  好吧,183和200好像有點懂了,那180和183又有什么區(qū)別呢?
  180和183之間就差個3。
  你說我開玩笑?好吧,這些狗屎都是RFC定義的,RFC就沒定義他們的區(qū)別!
  不過,RFC劃出道來大家就要走啊,因此,大家就都按照自己的理解實現(xiàn)了180和183。
  現(xiàn)在最流行的實現(xiàn)方式是:180不帶SDP,183帶SDP。FreeSWITCH也遵守這種約定。
  所以,180與183的區(qū)別不是3,也不是其它的,關(guān)鍵是看它們帶不帶SDP,即180也可以帶SDP,183也可以不帶SDP。為了防止思維混亂,我們下面認為180不帶SDP,而183帶SDP。如上面所說,這些符合絕大多數(shù)人的思維。
  那么,帶SDP的183我們上面講過了,180不帶SDP有什么用呢?
  我們上面不是說到時代進步了嗎?SIP終端屬于智能終端,比以前的模擬電話可先進多了。其中的一點就是它能區(qū)別180和183。如果A的SIP終端收到183,它就協(xié)商媒體,將B端發(fā)過來的Early Media在自己的揚聲器里放出來;但如果收到的是180,沒有SDP就沒法協(xié)商媒體,因此,B就沒法給A發(fā)Early Media了。怎么辦,總不能讓主叫用戶干等著啊,所以,A的話機在這種情況下能自己產(chǎn)生一個回鈴音,或任何用戶在A話機上設(shè)置的音樂。
  好吧,到這里,不管你有沒有理解,反正我把該說的都說了。
  那么,言歸正傳,如何在FreeSWITCH中配置回180還是183呢?
  FreeSWITCH是一個多功能的SIP服務(wù)器,在此,為了簡單起見,我們先把它當(dāng)成一個普通的SIP UA。比方說,它就是B。
  在FreeSWITCH內(nèi)部,F(xiàn)reeSWITCH的行為靠一些稱為Application的功能函數(shù)控制的。當(dāng)一個呼叫到來時,F(xiàn)reeSWITCH會查找撥號計劃(Dialplan)來決定執(zhí)行哪些Application。如,下面的Dialplan,當(dāng)一個呼叫到來時,它首先執(zhí)行Answer,給對方回200 OK,然后執(zhí)行playback給對方放一段聲音(從聲音文件中讀。,然后掛機。
  
  
  
  如果你自己測試這段Dialplan,就會發(fā)現(xiàn),F(xiàn)reeSWITCH不會回180也不會回183,而是直接回200。這里,answer想當(dāng)于B摘機應(yīng)答,在SIP中就直接回200。
  當(dāng)然,“紙上得來終覺淺,絕知此事要躬行。” 至于真是是不是這樣你還自己自己去試,學(xué)習(xí)SIP最好的辦法不是看RFC,而是照著我說的這些(以及《FreeSWITCH權(quán)威指南上的例子》)自己抓包去看。如果試著不對的話,也不要怪我,也許是你的Dialplan里邊東西太多,在這幾個Application前執(zhí)行了你不知道的其它的Application。
  好吧,那怎么讓它回183呢?
  在上面的Dialplan中把answer那一行去掉,就回183了。
  為什么呢?
  因為playback的作用是向A播放一段聲音,但,在B向A發(fā)送聲音前要建立媒體通道。如果有answer,F(xiàn)reeSWITCH會發(fā)送200 OK,帶SDP建立媒體通道。如果沒有answer,那么FreeSWITCH就會發(fā)送183,帶SDP建立媒體通道,而這時,hello.wav的媒體內(nèi)容就成了Early Media。
  所以,送不送183就看你在answer前還是answer后執(zhí)行playback。
  那么180呢?也很簡單,那就是在發(fā)送180前執(zhí)行一個 ring_ready,即:
  
  
  
  
  在上面的例子中,如果你抓包,就可以看到180,但你很可能聽不到回鈴音。原因很簡單,answer執(zhí)行的太快了。嘗試在ring_ready和answer之間停頓一下,就可以聽到回鈴音了。下面例子中的sleep可以在發(fā)送完180后暫停2秒鐘(2000毫秒)再發(fā)送200 OK:
  
  
  
  我們已經(jīng)知道怎么讓FreeSWITCH發(fā)180還是183了,問題解決了嗎?
  顯然沒有,我知道你在實際應(yīng)用中沒這么簡單。我們在這里把FreeSWITCH當(dāng)成了B,但實際你希望FreeSWITCH是FreeSWITCH,B是B。什么意思呢?FreeSWITCH實際上是一個B2BUA,它是一個中間人,你希望的拓撲結(jié)構(gòu)是這樣的:
  A <--------> FreeSWITCH <---------> B
  哎呀呀,你看你看,我第一句話說中了吧,針對你提的問題,答案遠沒你想象的簡單。現(xiàn)在,我們需要列出(猜出)你想要的各種情況了。
  好吧,就算這回我猜中了,繼續(xù)往下說。
  中間人也是不好當(dāng)?shù),因為,他可以有N種不同的策略。至于使用哪種策略,看B的心情,也要看FreeSWITCH的心情。啊,說白了,又是沒有標準答案。所以你還是要把你想要的告訴我。如果你不告訴我,我就得猜,或者把所有N種可能的情況都告訴你。
  首先,我們先看一種熟悉的情況。FreeSWITCH可以假裝它就是B,這樣,配置方法跟上面講的基本一樣,只是它在假裝后還要假戲真做,要用bridge這個Application再去呼叫B,并把電話接通。
  
  
  
  
  
  所以在上面的配置中,至于是回180還是183,配置方式跟上面講的一模一樣,就沒必要多說了。
  其次,F(xiàn)reeSWITCH心情好,想聽聽B的意見。如果它即不執(zhí)行ring_ready,也不執(zhí)行answer,而是直接用bridge去呼叫B。
  
  這種情況其實也簡單,那就是,如果B向FreeSWITCH回復(fù)180,F(xiàn)reeSWITCH就向A回180;如果B回183,F(xiàn)reeSWITCH就向A回183。這種情況其實就相當(dāng)于FreeSWITCH不存在,所有消息都是透明的。(不過,要記。篎reeSWITCH是一個B2BUA,即它是一個中間人,它不會直接拿B回給它的180或183消息“轉(zhuǎn)”給A,而是自己新產(chǎn)生了一個180或183消息回給A。當(dāng)然,也許你不關(guān)心這個,但你說得越不清楚,我越累啊,要不然人家還會說我的回答不嚴謹呢。或者,萬一我猜錯的你問的意思呢?)
  再次,F(xiàn)reeSWITCH跟B這兩天不大對付,什么事情都擰把。B回180,F(xiàn)reeSWITCH就回183,B回183,F(xiàn)reeSWITCH就回180。
  好吧,看起來是越來越復(fù)雜了。又是兩種情況。
  先看B回180的情況。FreeSWITCH要想給A回一個183,由于B的180中不帶媒體,F(xiàn)reeSWITCH就要“造”一個媒體出來,因此,它想了這種一種辦法,在bridge之前造一個媒體:
  
  
  由于在執(zhí)行bridge之前還沒有B,因此FreeSWITCH不知道什么時候B回180還是183。通過在bridge之前使用set設(shè)置一個變量(ringback),實際上相當(dāng)于FreeSWITCH給bridge下了一個套,到了bridge階段,不管你什么時候B回180,F(xiàn)reeSWITCH都會向A播放事先“造”好的回鈴音ring.wav。當(dāng)然,F(xiàn)reeSWITCH要向A發(fā)送媒體前要先用183建立媒體通道,這就完成了180到183的轉(zhuǎn)換。
  所以,這也是FreeSWITCH設(shè)計精巧之處——同是一個bridge,通過一個ringback變量改變了它的行為。
  再看183變180的情況。
  如果B向FreeSWITCH回了183,F(xiàn)reeSWITCH要向A回180,那就不能把媒體信息送給A。所以,實現(xiàn)也很簡單,還是一個簡單的bridge,只是,把B送來的Early Media忽略掉就行了: 
  跟set不同。set是一個Application,它作用于當(dāng)前的Channel,即A那一個Channel(那時候還沒有B)。而{ignore_early_media=true}這種語法,在建立B端的Channel的同時,將ignore_early_media作用于B。再強調(diào)一次,F(xiàn)reeSWITCH是一個B2BUA,因此A跟B間的通話要產(chǎn)生兩個Channel,即所謂的a-leg和b-leg。
  在建立B通道的時候,ignore_early_media也是給bridge下了一個套。即不管什么時候B回了183,忽略它。由于我們選擇了忽略,因此,為了讓A仍能聽到回鈴音,我們用ring_ready在bridge前送一個180。嚴格來說,它不是183變180,因為FreeSWITCH以收到183前就已經(jīng)送出了180,但是,如果你不趴在FreeSWITCH內(nèi)部看,誰知道什么時候變得呢?
  N種情況講了N種了,永遠都會有N+1。既然FreeSWITCH位于中間,那它能不能把B發(fā)過來的廣告(彩鈴)換成它自己的廣告呢?能是能,但我不教你怎么做。不過,不幸的是,如果你不是特別笨的話,我上面已經(jīng)教會你了……
  讀到這里,你認為這個問題好答嗎?
【免責(zé)聲明】本文僅代表作者本人觀點,與CTI論壇無關(guān)。CTI論壇對文中陳述、觀點判斷保持中立,不對所包含內(nèi)容的準確性、可靠性或完整性提供任何明示或暗示的保證。請讀者僅作參考,并請自行承擔(dān)全部責(zé)任。

專題

CTI論壇會員企業(yè)