在SIP UAC上獲得RINGING響應，而不從其他UAC發送它

Question

我希望這將是我對這個SIP主題的最後一個問題，我設法克服了最後一個issue我通過讓朋友幫助我從遠程計算機，我可以在計算機之間進行連接，但根據我看到的所有examples，被調用者都應該調用Ringing響應，但在我的應用程序中，我還沒有實現它，但我仍然收到在主叫方UAC一個振鈴響應，這是在呼叫者端的SIP消息：

呼出請求5：

INVITE sip:320@hostName.hn SIP/2.0 
Contact: "Client 310" <sip:310@hostName.hn> 
From: "Client 310" <sip:310@hostName.hn> 
Max-Forwards: 32 
CSeq: 2 INVITE 
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx 
Allow: INVITE,CANCEL,ACK,BYE,OPTIONS 
Content-Type: application/sdp 
Proxy-Authorization: Digest username="310",nonce="012afffb",realm="asterisk",uri="sip:310@hostName.hn",algorithm=MD5,response="d19ca5b98450b4be7bd4045edb8a3a2f" 
Via: SIP/2.0/UDP hostName.hn:5060 
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200 
Content-Length: 257 

v=0 
o=310 7108915969559970847 7108915969559970847 IN IP4 xxx.xxx.x.xxx 
s=- 
i=Nu-Art Software - TacB0sS VoIP information 
c=IN IP4 xxx.xxx.x.xxx 
m=audio 3312 RTP/AVP 0 8 101 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 

傳入響應6：

SIP/2.0 100 Trying 
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233 
From: "Client 310" <sip:310@hostName.hn> 
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200 
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx 
CSeq: 2 INVITE 
User-Agent: Freeswitch 1.2.3 
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO 
Supported: replaces 
Contact: <sip:320@yy.yy.yy.yy> 
Content-Length: 0 

傳入響應7：

SIP/2.0 180 Ringing 
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233 
From: "Client 310" <sip:310@hostName.hn> 
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200 
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx 
CSeq: 2 INVITE 
User-Agent: Freeswitch 1.2.3 
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO 
Supported: replaces 
Contact: <sip:320@yy.yy.yy.yy> 
Content-Length: 0 

電話：320@hostName.hn正在振鈴

傳入響應8 ：

SIP/2.0 183 Session Progress 
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233 
From: "Client 310" <sip:310@hostName.hn> 
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200 
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx 
CSeq: 2 INVITE 
User-Agent: Freeswitch 1.2.3 
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO 
Supported: replaces 
Contact: <sip:320@yy.yy.yy.yy> 
Content-Type: application/sdp 
Content-Length: 264 

v=0 
o=root 27669 27669 IN IP4 yy.yy.yy.yy 
s=session 
c=IN IP4 yy.yy.yy.yy 
t=0 0 
m=audio 10914 RTP/AVP 0 8 101 
a=rtpmap:0 PCMU/8000 
a=rtpmap:8 PCMA/8000 
a=rtpmap:101 telephone-event/8000 
a=fmtp:101 0-16 
a=silenceSupp:off - - - - 
a=ptime:20 
a=sendrecv 

傳入響應9：

SIP/2.0 503 Service Unavailable 
Via: SIP/2.0/UDP hostName.hn:5060;branch=f8d171d3278788df9e03eb9cf3acba70-xxx.xxx.x.xxx-2-invite-hostName.hn-5060333732;received=79.181.6.233 
From: "Client 310" <sip:310@hostName.hn> 
To: "Client 320" <sip:320@hostName.hn>;tag=as5a8fa200 
Call-ID: f8d171d3278788df9e03eb9cf3acba70@xxx.xxx.x.xxx 
CSeq: 2 INVITE 
User-Agent: Freeswitch 1.2.3 
Allow: INVITE,ACK,CANCEL,OPTIONS,BYE,REFER,SUBSCRIBE,NOTIFY,INFO 
Supported: replaces 
Content-Length: 0 

我不迴應的邀請，這就是爲什麼這一切正在發生的事情，但爲什麼我得到一個響，如果我不是一個發送它。

謝謝，

亞當。

更新：

如果你會發現，我得到的響應時間：

傳入響應7： 振鈴

傳入響應8： 會話進度

傳入響應9： 服務不可用

我不明白這裏的邏輯，我從第一振鈴的會話進度8秒，但是從會話進程到服務不可用我有47ms？

這有什麼意義？ 50毫秒做什麼？時間來分析響應+打開RTP會話的時間+構建響應的時間+構建SDP +的時間服務器接收消息所需的時間 - 503消息到達我的UAC所需的時間不是這個切割點很近？在這一點上，我想回應服務器？再次

感謝您的所有幫助奇才。

Answer 1

因爲您呼叫的FreeSWITCH的服務器是B2BUA，並且必須被配置成獨立地向後轉移的呼叫支路的生成環。如果您打電話的服務器是沒有B2BUA功能的SIP代理服務器，則在遠端的SIP設備作出響應之前，您將不會獲得任何響鈴或其他響應。

迴應7,8會導致網絡電話振鈴。對於響應7,180響鈴，取決於您的軟電話來產生音調。對於響應8,183會話進度和RTP，您的軟電話將從FreeSwitch服務器收到它應該呈現的進度指示。

更新：您所看到的計時原因再次歸結於您將呼叫置於B2BUA（在本例中爲FreeSwitch）的事實。它看起來像是配置爲在收到新的呼叫時自動發送響鈴響應，同時它正在處理其撥號計劃以確定如何處理呼叫。在那個撥號方案的某個地方，似乎有一個指示會話進度的命令，這是183響應進入的地方，但是它必須到達撥號方案的結尾或者遇到導致503響應的錯誤。

這是不太可能你會得到的，如果你直接傳送給UAS的反應相同的模式。

呼叫結束時唯一需要作爲UAC的動作是確認最終響應，在本例中爲503.您的SIP堆棧確實需要對180和183響應進行操作讓用戶知道發生了什麼，但不需要對它們做出響應，因爲它們就是所謂的信息響應，UAS不希望對它們做出響應。 SIP標準實際上是對臨時響應的可靠處理進行了改進，但它是可選的，如果我是你，我現在不會擔心這一點。