• 全部
  • 经验案例
  • 典型配置
  • 技术公告
  • FAQ
  • 漏洞说明
  • 全部
  • 全部
  • 大数据引擎
  • 知了引擎
产品线
搜索
取消
案例类型
发布者
是否解决
是否官方
时间
搜索引擎
匹配模式
高级搜索

SIP注册成功,外呼正常,呼入不进来

2025-11-06提问
  • 0关注
  • 0收藏,411浏览
粉丝:0人 关注:34人

问题描述:

分公司客服要接听电话对外提供解答问题

现在话机SIP注册成功,能直接通过话机拨打比如我的手机,通话正常。

可是从手机打400,按照导航提示按键接入。听见人工坐席忙。客服已经上线系统了。但是接不到电话

 

分公司防火墙NAT映射——总部防火墙——SIP服务端

 

已经按照供应商要求,在服务侧和总部侧都开通过防火墙相关端口。

这是什么原因?

 

最佳答案

粉丝:145人 关注:1人

🎯 现象总结

  • 分公司话机 SIP 注册成功

  • 可呼出外线(如手机),语音正常 ✅

  • 呼入(通过 400 或 IVR 转人工)时:

    • IVR 可听见

    • 但分公司坐席听不见响铃,也接不到电话 ❌

    • 系统显示“坐席忙”或未空闲


🧩 一、原理概览

SIP 业务分为两个方向:

  • 信令(SIP,5060端口):建立、修改、挂断呼叫;

  • 媒体(RTP,一般是 10000–20000 端口):实际的语音流。

注册成功说明:

SIP 信令能从分公司 → 总部 → 服务器方向通信。

但呼入失败通常是因为:

外部呼叫时,服务器需要反向建立信令会话或发 RTP 到分公司,但 NAT 未正确映射回来。


⚙️ 二、常见原因分析

1️⃣ SIP ALG 或 NAT 行为问题

现象: 注册正常,但外部呼入时,SIP INVITE 报文无法正确回到分公司话机。
原因: 防火墙 NAT 会改变 SIP 报文头部的地址,但有的设备没有正确处理 Contact / Via 字段,导致信令方向反了。

建议:

  • 在分公司和总部防火墙上 关闭 SIP ALG 功能

  • 在话机或注册配置中启用:

    NAT keep-alive / STUN / Outbound Proxy
  • 确保注册包中 Contact: 字段反映的是公网可达的地址。


2️⃣ RTP 媒体端口未放通

现象: 呼叫建立但无语音,或服务器判定坐席无响应。
原因: SIP 建立会话后,服务器要通过 RTP(随机端口)向分公司发送语音包,若防火墙未开放动态端口范围,则通信失败。

建议:

  • 在防火墙上放通服务侧要求的 RTP 端口范围(如 UDP 10000–20000)。

  • 如果防火墙支持 SIP ALG 会话检测,需确保能自动建立动态端口映射。

  • 若不行,可通过 SBC(Session Border Controller) 做中继代理。


3️⃣ 呼叫分配逻辑问题(IVR/ACD)

现象: 系统提示坐席忙,而实际坐席空闲。
可能原因:

  • 坐席注册的分机号和系统登录的工号未绑定;

  • ACD 系统把分公司坐席分组错误;

  • 呼叫中心系统认为该坐席当前不可达(注册 IP 不可达)。

建议:

  • 在服务器侧查看该分机的注册状态(是否显示正确公网IP);

  • 在坐席系统里核对分机号和登录账号的绑定;

  • 抓包看服务器是否有发 INVITE 到分公司。


4️⃣ NAT 会话老化 / Keepalive 缺失

注册正常但过几分钟后呼入失败,说明:

NAT 表项被回收,外部呼叫方向的信令包被丢弃。

解决:

  • 在话机上启用 NAT Keepalive(30秒发送一次 REGISTER 或 OPTIONS)。

  • 在防火墙上增加 SIP UDP session timeout(默认60秒可调大至180秒)。


🧰 三、排查步骤建议

步骤 目标 方法
1 确认防火墙是否启用 SIP ALG 关闭后重测
2 用抓包工具查看 INVITE 是否到达话机 在分公司出口或话机侧抓包
3 核对注册表项中的公网地址 是否与分公司 NAT 出口一致
4 测试 STUN / Outbound Proxy 功能 确认能穿透 NAT
5 检查防火墙 UDP 会话老化时间 设置 >= 180s
6 若条件允许,用总部测试机直连同网段注册验证 排除服务端或ACD逻辑

💡 四、总结建议

场景 推荐做法
分公司多台话机 统一配置 outbound proxy(总部 SBC 或 SIP relay)
防火墙 NAT 复杂 使用 SBC 统一处理 SIP/RTP
单台测试 启用 STUN / Keepalive
系统提示坐席忙 从 SIP 报文看 INVITE 是否到达分机


2 个回答
已采纳
粉丝:144人 关注:9人

nat sip开了吗


2.6  配置NAT ALG

(1)     进入系统视图。

system-view

(2)     开启指定或所有协议类型的NAT ALG功能。

nat alg sip

缺省情况下,DNS、FTP、ICMP差错报文、PPTP、RTSP协议类型的NAT ALG功能处于开启状态,其他协议类型的NAT ALG功能处于关闭状态。

配上这条命令后,能接听电话了。多谢

bkmz_yoush 发表时间:2025-11-07 更多>>

把安全策略ANY-ANY全允许了,也没有打进去。检查本地防火墙配置里面没有ALG这个单词

bkmz_yoush 发表时间:2025-11-06
回复bkmz_yoush:

什么型号设备

zhiliao_sEUyB 发表时间:2025-11-06
回复zhiliao_sEUyB:

F1000AI-35

bkmz_yoush 发表时间:2025-11-07

https://www.h3c.com/cn/d_202509/2646269_30005_0.htm#_Toc208865275

zhiliao_sEUyB 发表时间:2025-11-07

支持的啊

zhiliao_sEUyB 发表时间:2025-11-07

配上这条命令后,能接听电话了。多谢

bkmz_yoush 发表时间:2025-11-07
军刺 五段
粉丝:3人 关注:0人

结合你 “分机可外呼、400 呼入提示坐席忙” 的现象,以及 “分公司防火墙 NAT 映射 — 总部防火墙 —SIP 服务端” 的组网,问题核心大概率出在呼入链路的信令转发异常、坐席 / 队列配置错误,或防火墙 NAT / 策略未适配 SIP 协议特性上。以下按从易到难的顺序,给出具体排查和解决步骤:

一、优先排查:坐席与呼叫中心系统配置(最快定位非网络问题)

提示 “人工坐席忙”,先排除系统层面的呼入路由未指向客服的问题,而非直接查网络:
  1. 确认客服坐席的 “上线状态”
    • 登录呼叫中心系统后台,查看客服账号是否处于 **“签入 / 空闲” 状态 **(而非 “签出”“置忙”“小休”)。部分系统需手动选择 “接听队列”,若未勾选对应队列,呼入会判定为 “无空闲坐席”。
    • 测试同一队列内分机互拨(如分公司客服分机拨总部客服分机),若能接通,说明坐席基础配置正常;若不通,优先检查坐席分机与系统的绑定关系。
  2. 核查 IVR 导航与队列绑定
    • 确认 400 电话的 IVR 导航中,用户按键对应的队列是否为客服所在队列。比如用户按 “1” 转人工,该按键是否正确关联分公司客服队列,而非其他已满员 / 未启用的队列。
    • 查看队列配置:是否设置了 “最大坐席数”“无空闲时转接” 等规则,避免因队列参数错误导致呼入被拦截。
  3. 查看 SIP 服务端的呼入日志
    • 登录 SIP 服务端(如 IP-PBX、呼叫中心平台),导出呼入日志,筛选 400 号码的呼入记录:
      • 若日志显示 “无可用坐席”,聚焦系统队列 / 坐席配置;
      • 若日志显示 “呼入请求发送失败”“超时”,则转向网络链路排查;
      • 若日志显示 “分机未响应”,重点查分公司话机与服务端的信令连通性。

二、核心排查:NAT 映射与 SIP 协议穿透问题

SIP 话机注册成功仅代表 “话机→服务端” 的主动注册链路通,但呼入是 “服务端→分公司防火墙→话机” 的反向链路,NAT 配置不当会导致信令 / 媒体流中断,进而触发 “坐席忙” 假象:
  1. 确认 NAT 映射端口完整且正确
    SIP 通信包含信令端口媒体流端口,仅映射信令端口会导致呼入信令无法触发话机振铃,或振铃后无声音,系统误判坐席未响应。
    • 必映射端口
      1. 信令端口:SIP 默认用 UDP 5060(部分系统用 TCP 5060),需将分公司防火墙的公网端口 5060 映射到客服话机的内网 IP:5060;
      2. 媒体流端口:SIP 通话的语音数据走 RTP 协议,端口通常是动态范围(如 10000 - 20000),需将该端口段整体映射到话机内网 IP,且两端防火墙均放行该范围。
    • 验证方法:登录分公司防火墙,核对 NAT 映射规则,确保 “协议类型(UDP 为主)、公网端口、内网 IP + 端口” 完全匹配话机配置。
  2. 关闭防火墙的 SIP ALG 功能(关键坑点)
    多数防火墙默认开启 SIP ALG(应用层网关),用于 “修复” SIP 信令中的内网地址,但该功能常因适配问题篡改信令包,导致服务端无法正确识别分公司话机的地址,呼入请求被丢弃。
    • 操作:在分公司防火墙和总部防火墙中,找到 “SIP ALG” 开关(不同品牌名称可能为 “SIP 助手”“SIP 穿透”),直接关闭。这是 SIP 组网中解决呼入异常的高频操作。
  3. 延长防火墙 UDP 会话超时时间
    SIP 信令常用 UDP 协议,而防火墙默认 UDP 会话超时较短(如 30 秒),若话机与服务端的心跳间隔超过超时时间,会话会被断开,呼入时服务端无法连接话机。
    • 调整:将分公司防火墙的 UDP 会话超时时间改为300 秒以上,确保 SIP 信令链路长期保持。

三、进阶排查:总部与分公司的防火墙策略

你提到已开放端口,但可能存在 “端口方向错误”“未放行 SIP 服务端 IP” 等细节问题:
  1. 确认防火墙放行规则的方向
    • 分公司防火墙:需放行从总部 SIP 服务端 IP 到分公司话机 IP的流量(入方向),包含 SIP 信令端口 5060 和 RTP 媒体端口段;
    • 总部防火墙:需放行从公网(400 线路接入侧)到 SIP 服务端的呼入流量,以及从 SIP 服务端到分公司防火墙公网 IP 的转发流量。
  2. 排除 ACL 误拦截
    检查总部和分公司防火墙的 ACL 规则,确认未将 SIP 服务端 IP、400 线路的接入 IP 加入黑名单,或误拦 SIP(协议类型)、RTP(端口段)流量。可临时添加一条 “放行 SIP 服务端与分公司话机 IP 双向通信” 的测试规则,验证是否为 ACL 问题。

四、终极验证:抓包定位链路断点

若以上步骤仍未解决,通过抓包可精准定位呼入流量卡在哪个环节:
  1. 在分公司防火墙外网口抓包
    过滤 SIP(端口 5060)和 RTP(端口段 10000 - 20000)流量,拨打 400 测试:
    • 无 SIP INVITE 请求包:说明呼入流量未到达分公司防火墙,问题在总部侧(如总部防火墙未转发、SIP 服务端未下发呼入指令);
    • 有 INVITE 包但无话机响应包:说明 NAT 映射或话机配置异常,检查话机是否监听 5060 端口、NAT 是否正确转发到话机。
  2. 在 SIP 服务端抓包
    查看是否收到 400 的呼入请求,以及是否向分公司话机发送了 INVITE 指令:
    • 若服务端未向分公司发送 INVITE:问题在服务端的队列 / 路由配置;
    • 若发送了 INVITE 但无回执:问题在总部到分公司的链路或防火墙拦截。

五、补充:SIP 话机的基础配置核对

  1. 确认话机的分机号、注册服务器地址、端口与 SIP 服务端一致,无拼写错误;
  2. 部分话机需手动配置 “NAT 地址”(填写分公司防火墙公网 IP),协助服务端识别反向链路地址,可尝试开启该配置。
按以上步骤排查,优先解决系统队列 / 坐席状态、NAT 映射完整性、SIP ALG 这三个高频问题,基本能解决呼入提示坐席忙的问题。若排查中发现某环节日志异常(如服务端提示 “分机不可达”),可针对性聚焦该环节的配置。

编辑答案

你正在编辑答案

如果你要对问题或其他回答进行点评或询问,请使用评论功能。

分享扩散:

提出建议

    +

亲~登录后才可以操作哦!

确定

亲~检测到您登陆的账号未在http://hclhub.h3c.com进行注册

注册后可访问此模块

跳转hclhub

你的邮箱还未认证,请认证邮箱或绑定手机后进行当前操作

举报

×

侵犯我的权益 >
对根叔社区有害的内容 >
辱骂、歧视、挑衅等(不友善)

侵犯我的权益

×

泄露了我的隐私 >
侵犯了我企业的权益 >
抄袭了我的内容 >
诽谤我 >
辱骂、歧视、挑衅等(不友善)
骚扰我

泄露了我的隐私

×

您好,当您发现根叔知了上有泄漏您隐私的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您认为哪些内容泄露了您的隐私?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)

侵犯了我企业的权益

×

您好,当您发现根叔知了上有关于您企业的造谣与诽谤、商业侵权等内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到 pub.zhiliao@h3c.com 邮箱,我们会在审核后尽快给您答复。
  • 1. 您举报的内容是什么?(请在邮件中列出您举报的内容和链接地址)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
  • 3. 是哪家企业?(营业执照,单位登记证明等证件)
  • 4. 您与该企业的关系是?(您是企业法人或被授权人,需提供企业委托授权书)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

抄袭了我的内容

×

原文链接或出处

诽谤我

×

您好,当您发现根叔知了上有诽谤您的内容时,您可以向根叔知了进行举报。 请您把以下内容通过邮件发送到pub.zhiliao@h3c.com 邮箱,我们会尽快处理。
  • 1. 您举报的内容以及侵犯了您什么权益?(请在邮件中列出您举报的内容、链接地址,并给出简短的说明)
  • 2. 您是谁?(身份证明材料,可以是身份证或护照等证件)
我们认为知名企业应该坦然接受公众讨论,对于答案中不准确的部分,我们欢迎您以正式或非正式身份在根叔知了上进行澄清。

对根叔社区有害的内容

×

垃圾广告信息
色情、暴力、血腥等违反法律法规的内容
政治敏感
不规范转载 >
辱骂、歧视、挑衅等(不友善)
骚扰我
诱导投票

不规范转载

×

举报说明