关于服务器录音请求中SIP invite字段处理的问题
我正在与你联系，希望任何人能分享一些关于我现在正在处理的问题的文档或信息，我不是在请求手把手的指导，但任何可以引导我走向正确方向的提示都将非常感谢！
我将在一般视图中概述问题，让您了解我正在寻找什么。
长话短说:我正在尝试使用genesys engage产品在服务器上编写呼叫记录脚本。根据文档，在发送呼叫记录请求到SIP服务器之后，请求被转发到媒体服务器，媒体服务器开始呼叫记录，然后将音频流转发到请求中指定的套接字端点，但是，我设置的套接字在请求被处理后似乎没有接收到任何连接(我已经从其他服务器实例使用telnet检查了套接字本身，并且我非常确定它正在正确侦听，并且在记录请求之后SIP服务器响应给我ACK，所以我知道此位工作正常，所以我将省去在这里粘贴所有样板)。
检查日志后，我看到媒体服务器正在以以下方式发送invite：
INVITE sip:record=KOAG2VPNA57H1BTJ81493PTKGK000001@[my_socket_host_name]:5060;CallUUID=KOAG2VPNA57H1BTJ81493PTKGK000001;recordDN=123456789;DN=123456789 SIP/2.0
Via: SIP/2.0/TCP 10.213.181.94:7090;branch=z9hG4bK000000001C4207504d1794
From: <sip:Genesys@[media_server_ip]:7090>;tag=9650B629-68CF-4B21-DF97-5C7D9D33E14E
To: <sip:record=KOAG2VPNA57H1BTJ81493PTKGK000001@ my_socket_host_name:5060>;CallUUID=KOAG2VPNA57H1BTJ81493PTKGK000001;recordDN=123456789;DN=123456789
Max-Forwards: 70
CSeq: 1 INVITE
Call-ID: 0138A2FF-24D9-47B7-D4A0-1792FBB33E45-7090@10.213.180.94
Contact: <sip:Genesys@[media_server_ip]:7090>
Content-Length: 228
Content-Type: application/sdp
Route: <sip:0000000009EC6080@[GVP_server_ip]:5060;transport=TCP;lr;gvp.rm.datanodes=1%7C2;confinstid=UQFF7NJJH53NBC7MH6OJ67TKKK000001;idtag=0000002E>
X-Genesys-GVP-Session-ID: 0FB9EF88-2FF5-4091-71B9-CF167D5629B1;gvp.rm.datanodes=1|2;gvp.rm.tenant-id=101_MSML_Profile
X-Genesys-GVP-Session-Data: callsession=0FB9EF88-2FF5-4091-71B9-CF167D5629B1;1;2;sip:[SIP_server_ip]:5060;;;Resources;MSML_Profile;;0;MSML_Profile
Supported: timer, uui
v=0
o=- 0268835512 0 IN IP4 [media_server_ip]
s=phone-call
c=IN IP4 10.213.181.94
t=0 0
m=audio 50106 RTP/AVP 8 0 101
a=rtpmap:8 pcma/8000
a=rtpmap:0 pcmu/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendonly在执行wireshark跟踪之后，我注意到请求不是直接发送到侦听套接字的主机地址，而是在最后一个八位字节中使用.252和.255的广播地址发送的(无法指定确切的数据包，因为所有数据包流似乎都是加密的，但在运行脚本的跟踪会话期间，媒体服务器没有向任何其他地址发送任何数据包，甚至没有提到侦听套接字的地址)。因此，现在我正在尝试找出请求URI和to标头字段背后的逻辑，它们使用相同的语法: my_socket_host_name:5060>;CallUUID=KOAG2VPNA57H1BTJ81493PTKGK000001;recordDN=123456789;DN=123456789
无论我在哪里查看有关sip数据包流的资源，我似乎都找不到任何类似这种语法的示例，特别是在to字段中，它似乎总是指向特定的DN或主机/ip地址，而没有这个记录请求位，所以这就是现在让我头疼的原因。
我假设，invite请求是以以下方式广播的，因为在那之后，genesys应该将指向我的侦听主机的确切指针返回到媒体服务器或通过gvp服务器转发它，并且解决方案本身可能会非常特定于产品，但另一方面，我想了解这些类型的invite请求是如何在sip电话中处理的，所以如果有人能分享一些关于这个主题的信息，我将不胜感激，谢谢！
回答 1
Stack Overflow用户
发布于 2021-03-24 23:07:10
所以现在我正在尝试弄清楚请求URI和to标头字段背后的逻辑，它们使用相同的语法: my_socket_host_name:5060>;CallUUID=KOAG2VPNA57H1BTJ81493PTKGK000001;recordDN=123456789;DN=123456789
无论我在哪里查看有关sip数据包流的资源，我似乎都找不到任何类似这种语法的示例，特别是在to字段中，它似乎总是指向特定的DN或主机/ip地址，而没有这个记录请求位，所以这就是现在让我头疼的原因。
此URI格式定义用于SIP服务器和GVP之间的内部信令。用户部分URL标识记录的呼叫，并在CallUUID record=KOAG2VPNA57H1BTJ81493PTKGK000001装饰中重复。总之，该URL特定于Genesys实现，且不参与公共SIP通道上传输。
我假设，invite请求是以以下方式广播的，因为在那之后，genesys应该向媒体服务器返回指向我的监听主机的确切指针，或者通过gvp服务器转发它，并且解决方案本身可能是非常产品。
- ，但另一方面我想了解这些类型的invite请求在sip电话中是如何处理的，所以如果有人能分享一些关于这个主题的信息，我将不胜感激，谢谢！
我不确定是否能完全理解您的问题，但恐怕您还没有看到松散路由头部：
Route: <sip:0000000009EC6080@[GVP_server_ip]:5060;transport=TCP;lr;gvp.rm.datanodes=1%7C2;confinstid=UQFF7NJJH53NBC7MH6OJ67TKKK000001;idtag=0000002E>这条路由确保后续请求将通过GVP_server_IP，魔术就在那里。
https://stackoverflow.com/questions/66633496
复制相似问题
腾讯云开发者
