首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >问答首页 >UAC应如何处理SIP 183会话进度

UAC应如何处理SIP 183会话进度
EN

Server Fault用户
提问于 2011-12-02 15:07:39
回答 1查看 1.3K关注 0票数 0

我有以下情况:

2 UAC正在尝试通过远程SIP服务器(openSER/Kamailio 3.1.3) =客户端基础设施进行对话。UAC软件是使用星号在本地测试基础设施上开发的,在那里可以建立一个正常的调用。

问题是在客户端基础设施上进行测试,没有音频。

我不知道完整的客户端基础设施,但是从来自服务器的日志/响应(路由头字段)可以得出结论,存在一个代理授权服务器、一个CiscoSystem SIP以及PSTN。尤其是我们支持NAT,客户也支持NAT。AFAIK没有使用电击器。

呼叫流程的主要区别在于,在测试基础结构中,我们总是接收到180条消息(振铃),而在客户端基础结构中,我们接收到183条会话正在进行中。在日志中可以看到,这两种设备都开始发送rtp流,但仍然没有音频。

我也有一个商业软件,我们用它测试客户端基础设施,它可以工作。我们已经比较了从商业软件发送的信息,我们的客户和几乎没有区别。

我能够找到的唯一不同之处是,在inv/407/ack循环之后的消息中:

商业软件:

开始新的分支机构编号x

  • 发送inv + auth字符串-分支/trans x
  • 获取响应分支/trans x。
  • 发送ack消息-分支/trans x

我们的客户:

开始新的分支机构编号y

  • 发送inv + auth字符串-分支/trans y
  • 获取响应分支/trans y。
  • 发送ack消息-一个新的分支/事务-z

这是否是导致丢失音频问题的一个原因?同样的场景在星号中也能正常工作。

EN

回答 1

Server Fault用户

回答已采纳

发布于 2011-12-04 13:55:50

(我假设涉及的实体是RFC 3261 SIP设备,而忽略了与RFC 2543设备的互操作。)

如果涉及NAT,您首先应该检查的是

  • SDP有效负载中的c=头中的IP
  • Contact头中的IP

特别是,这些综合方案都应可由另一方接触。

在您的“inv/407/ ACK”场景中,非2xx响应的ACK应该具有相同的branch id。但是,2xx响应终止了INVITE事务,因此对2xx响应的ACK将具有与INVITE不同的branch

(当然,RFC 3261是SIP的最终资源,但我发现RFC 3665对于了解事情是如何工作的非常有帮助。)

票数 1
EN
页面原文内容由Server Fault提供。腾讯云小微IT领域专用引擎提供翻译支持
原文链接:

https://serverfault.com/questions/337044

复制
相关文章

相似问题

领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档