在SIP UAC上获取RINGING响应，而不从其他UAC发送

时间：2010-06-06 19:40:47

标签： sip sdp

我希望这是关于这个SIP主题的最后一个问题，我已经设法通过要求朋友从远程计算机帮助我来克服最后的issue，我能够连接到计算机，但这是事情，根据我看到的所有examples，Callee应该调用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： 1275879030656 响铃

传入回复8： 1275879038734 会话进度

传入回复9： 1275879038781 服务不可用

我不明白这里的逻辑，我从第一次响铃到会话进度有8秒，但是从会话进度到服务不可用我有47ms？

这有什么意义？ 50毫秒做什么？分析响应的时间+打开RTP会话的时间+构建响应的时间+构建SDP的时间+服务器接收消息的时间 - 503消息到达我的UAC所花费的时间，不是这个切割有点接近？我想在哪一点回应服务器？

再次感谢您的所有帮助。

1 个答案:

答案 0 :(得分：2)

因为您正在呼叫的FreeSwitch服务器是B2BUA，并且必须配置为独立于转发的呼叫支路生成回铃。如果您呼叫的服务器是没有B2BUA功能的SIP代理服务器，则在远端的SIP设备响应之前，您不会收到任何响铃或其他响应。

响应7和8将导致您的软电话响铃。对于响应7,180振铃，由软电话决定是否产生音调。对于响应8,183使用RTP进行会话进度，您的软电话将从FreeSwitch服务器收到应该呈现的进度指示。

更新：您所看到的时间安排的原因再次归结于您将呼叫置于B2BUA，在本例中为FreeSwitch。看起来它被配置为在收到新呼叫时自动发送振铃响应，同时它正在处理其拨号方案以确定如何处理呼叫。在该拨号方案的某处，似乎有一个命令来指示会话进度，这是183响应进入的地方但是它必须到达拨号方案的末尾或遇到导致503响应的错误。

如果您直接与UAS通信，则不太可能获得相同的响应模式。

您在呼叫结束时所需的唯一操作是作为UAC，确认最终响应，在本例中为503.您的SIP堆栈确实需要对180和183响应做一些事情让let用户知道发生了什么，但您不需要回应它们，因为它们是所谓的信息响应，而UAS不希望对它们做出响应。 SIP标准实际上有一个增强处理临时响应的可靠处理，但它是可选的，如果我是你，我现在不会担心它。

相关问题
最新问题