如何从 CCXML 发送 182 排队 SIP 消息？
我正在构建一个语音应用程序，当我的应用程序尝试设置出站呼叫时，该应用程序需要长时间响铃。在此期间，呼叫必须保持无人应答。
我正在使用连接到媒体网关的基于 SIP 的 Genesys GVP 8.1 IVR。
我遇到的问题是因为呼叫无人接听，30 秒后超时。我需要向媒体网关发送某种保持活动的消息，以表明呼叫仍在进行中。
我尝试过使用这个：
<send target="inConnectionID" targettype="'x-connection'" data="'connection.progressing'"/>
它将生成 180 振铃...但我已经发送了 180 振铃消息，并且我认为 SIP 服务器不会将其传递到网络，因为它已经处理了 180 消息。
理想情况下，我想尝试发送 182 排队消息，但我在 CCXML 或扩展 GVP CCXML 文档中找不到任何说明如何执行此操作的内容。
我的 Wireshark SIP 跟踪如下所示：
您可以看到第二个 180 24 秒振铃没有被传递到媒体网关。
如何让 GVP/CCXML 发送 182 排队 SIP 消息？
I'm building a voice application that requires a long period of ringing while my application attempts to setup an outbound call. During this time, the call must remain unanswered.
I'm using a SIP based Genesys GVP 8.1 IVR connected to a media gateway.
The problem I have is because the call is unanswered, it times out after 30 seconds. I need to send some kind of keep-alive message to the media gateway to say that the call is still ongoing.
I've tried using this:
<send target="inConnectionID" targettype="'x-connection'" data="'connection.progressing'"/>
which will generate a 180 Ringing... but I've already sent a 180 Ringing message, and I think the SIP Server doesn't pass this on down the network because it's already processed a 180 message.
Ideally, I want to try sending a 182 Queued message, but I can't find anything in the CCXML or extended GVP CCXML documentation to say how to do this.
My Wireshark SIP trace looks like this:
You can see the second 180 Ringing at 24 seconds isn't being passed up to the media gateway.
How can I get GVP/CCXML to send a 182 Queued SIP message?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
服务器应该转发您的 180，尽管它没有有 - 但它应该转发，因为第一个 180 可能会在它和媒体服务器之间丢失（尽管服务器可能会重新发送 INVITE） 。
然而，正如 sipwiz 所指出的，可能的问题是媒体服务器配置的接受呼叫的最大超时。 182 不太可能有帮助（尽管在不了解媒体服务器的情况下很难确定）。
另外，您应该大约每 1 分钟重新传输 180（并且 sip 服务器应该将其通过），以避免规范允许的可能的 3 分钟超时。某些 SIP 堆栈（例如 eXosip）默认会在 3 分钟内没有 1xx 响应的情况下使 INVITE 超时。
The server should forward your 180, though it doesn't have to - but it should since the first 180 could be lost between it and the media server (though the server would re-send the INVITE probably).
However, as sipwiz indicates, the likely issue is the media server's configured max timeout to accept a call. 182 is unlikely to help (though without understanding the media server it's hard to be definitive).
Also, you should re-transmit the 180 (and the sip server should pass it through) every circa 1 min to avoid the possible 3-minute timeout allowed by the spec. Some SIP stacks like eXosip default to timing out an INVITE if 3 min go by with no 1xx response.
我同意媒体网关不应在 34.7 取消。我还认为 SIP 服务器应该在向leg2 发送出站邀请之前在leg1 上发送100 尝试返回。如果媒体网关使用 SRV 翻转算法，这将阻止来自leg1 UAC 的任何重传并防止任何故障转移。
I agree that the media gateway should not cancel at 34.7. I also think the SIP Server should send a 100 trying back on leg1 before it sends the outbound invite for leg2. This will stop any retransmissions coming from leg1 UAC and prevent any failover if media gateway is using a SRV rollover algorithm.