sip - 在 SIP UAC 上获得 RINGING 响应而不从其他 UAC 发送它

Question

我希望这是我关于这个 SIP 主题的最后一个问题，我已经设法克服了最后一个 issue我曾通过请一位 friend 从远程计算机帮助我，我能够在计算机之间进行连接，但根据所有 examples 的说法，事情就是这样。我看到，被叫方应该调用响铃响应，但在我的应用案例中，我还没有实现它，但我仍然在主叫方 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 session 进度

传入响应 9: 1275879038781 暂停服务

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

这有什么道理？ 50ms做什么？分析响应的时间 + 打开 RTP session 的时间 + 构建响应的时间 + 构建 SDP 的时间 + 服务器接收消息所需的时间 - 503 消息到达我的 UAC 所需的时间，不是这切割有点接近？我应该在哪一点响应服务器？

再次感谢您的帮助 Wiz。

Answer 1

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

响应 7 和 8 将导致您的软件电话响铃。对于响应 7, 180 Ringing，由您的网络电话产生音调。对于响应 8, 183 Session Progress with RTP，您的软电话将从 FreeSwitch 服务器收到它应该呈现的进度指示。

更新:您看到的时间安排的原因再次归结于您向 B2BUA(在本例中为 FreeSwitch)发出调用的事实。看起来它被配置为在收到新调用时自动发送振铃响应，同时它正在处理其拨号计划以计算出如何处理调用。在那个拨号计划的某个地方似乎有一个命令来指示 session 进度，这是 183 响应进入的地方，但它必须到达拨号计划的末尾或遇到导致 503 响应的错误。

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

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