简介ekiga-3.2.7 是一套面向 Linux 环境的开源视频会议软件源码包目标用户是希望部署、学习或二次开发 SIP/H.323 通信方案的开发者与运维人员。软件最初基于 VoIP 实现视频会议后续兼容 SIP 协议实测 SIP 功能稳定H.323 相对弱化因此在搭建 VoIP 或 SIP 音视频通话系统时可优先参考。整个 rar 包共含 937 个文件压缩后约 10.23MB其中 .cpp/.h/.c 构成核心代码实体.png/.xpm/.svg 提供界面图标与图片资源.po 为多语言翻译configure.ac、Makefile.am、am/in 等则是 autotools 构建体系所需文件整体目录结构清晰便于按模块阅读。该资源已有 234 人在线学习与下载。通过这份源码读者可以拿到完整编译工程、本地化资源、调试分析脚本ekiga-debug-analyser以及说明文档既能深入理解 SIP 注册、呼叫协商与音视频传输的实现流程也能为后续二次开发、功能裁剪或 H.323 扩展提供可直接修改的代码基础。1. ekiga-3.2.7十几年后还在双栈视频会议方案里值得留的一个老客户端做过视频会议项目的人大概率绕不开一个尴尬局面手头设备跟不同厂商对接时SIP终端和H.323终端各说各话会议室里两台设备互相看不见。ekiga-3.2.7就是那种“一个客户端同时讲SIP和H.323”的老派软电话在GNOME桌面时代被大量Linux用户当默认视频通话工具用。现在拿出来看它编译依赖有点旧界面也谈不上现代但在需要低成本验证双栈协议、或者给内网实验室搭一套不依赖云平台的视频会议链路时它依然能当一块好用的试验田。这篇笔记就把解压、编译、注册、排错、对接现网的全过程拆开讲适合要在Linux下搭视频会议测试环境、或者想搞清楚SIP与H.323协议差异的工程师参考。2. 双栈不是福利是负担SIP与H.323信令在同一个客户端里怎么共存2.1 协议选型两套信令各自的边界在哪先说结论ekiga能同时支持SIP和H.323核心功劳不在界面而在它底层的opal协议栈。opal是Open Phone Abstraction Library它把两套信令抽象成统一的呼叫控制接口上层界面只管拨号、接听、挂断至于走SIP还是H.323由账号配置决定。很多新手有个误区觉得“支持双协议”就是开个开关那么简单。实际使用中这俩协议的信令交互、端口使用、鉴权方式差异非常大。SIP基于文本类似HTTP的请求/响应模式调试方便用sngrep或者Wireshark看包一目了然。H.323则是二进制编码的ITU标准族包含H.225呼叫信令、H.245媒体控制、H.235安全认证还有一个RASRegistration Admission Status通道专门跟网守通信。你在一台机器上同时保活这两套逻辑意味着要处理两套NAT穿透策略、两套端口映射规则、两套超时重传机制。所以做选型时要清楚SIP适合直连、Interop环境丰富、排错工具多H.323在传统视频会议硬件、老式MCU、广电级设备里依然存在而且它设计之初就是面向“多点会议”的网守的带宽管理和号码翻译能力比SIP的注册服务器要重得多。ekiga两个都支持但不代表你配置时可以只填一个账号就完事——每套协议有各自的账号配置项和端口策略。对比维度SIPH.323信令格式文本类似HTTP二进制ASN.1 PER编码注册/定位Registrar Location ServiceGatekeeper RAS媒体控制SDP协商H.245能力交换互联网穿透天然适合STUN/TURN生态成熟依赖网守和静态映射穿透困难调试工具sngrep、Wireshark、SIPpWireshark dissector典型存量设备IP话机、软交换、IMS老式视频终端、MCU、H.323网关2.2 SIP侧REGISTER与INVITE里的几个关键字段激活ekiga里的SIP账号后客户端会往Registrar发REGISTER请求。我建议在配置阶段先用Wireshark过滤sip或sip2看三个关键字段Request-URI里的用户部分、To头域里的AORAddress of Record、以及Contact头域里的连接地址。常见做法是# 抓包只看SIP注册和呼叫信令 sudo tcpdump -i eth0 -s0 -w /tmp/ekiga_sip.pcap udp port 5060等到抓包文件落在本地后用Wireshark打开过滤sip.Request-Line能直接看到REGISTER事务。重点检查Contact头域里的IP和端口ekiga默认会让opal自己选一个本地端口作为信令源端口并不一定就是你路由器上映射的那个。如果你的客户端在NAT后面这里填的IP很可能是内网地址对方回包就找不到路。另一种我常用的验证方式是直接用sipsak发一个OPTIONS请求试探# 用sipsak测试SIP服务器是否响应 sipsak -s sip:1000192.168.1.10 -vv返回的响应码如果一直是408/480说明请求根本没到达对方应用层这时候优先检查网络路由而不是应用配置。2.3 H.323侧Gatekeeper发现与RAS流程H.323要正常呼叫第一步不是打电话而是先找到网守。ekiga在H.323账号配置里有一项Gatekeeper地址填IP或域名都行。启动后客户端会向网守发送GatekeeperRequestGRQ网守回GatekeeperConfirmGCF带上自己的RAS通道地址此后客户端用RAS消息注册、呼叫、鉴权。H.323的调试比SIP更考验耐心因为它信令是二进制的Wireshark里虽然能解析但过滤器没有sip那么直白。我用的是这两个# 只抓H.323相关端口RAS端口1719和呼叫信令端口1720 sudo tcpdump -i eth0 -s0 -w /tmp/ekiga_h323.pcap udp port 1719 or tcp port 1720打开后看RAS消息最常出现的异常是“RejectReason”字段里面会写明是securityDenied还是gatekeeperResources。前者多半是密码/ID不对后者说明网守侧并发上限到了。另一个要盯的地方是H.245的媒体端口协商H.323和SIP不一样媒体端口不是固定的而是通过H.245在呼叫过程中动态交换所以防火墙策略不能只放行一个固定UDP端口段否则视频流根本传不出去。3. 从rar到能喊话编译安装与首次注册的完整步骤3.1 解压后先分清五个目录再去动configure拿到ekiga-3.2.7的rar包后先别急着解压就configure先把目录结构摸清楚。这个版本的代码组织方式对新手不太友好几个子目录存放的内容差别很大不搞明白后面遇到编译错误会很被动。# 解压源码包假设文件名是ekiga-3.2.7.rar rar x ekiga-3.2.7.rar cd ekiga-3.2.7 ls -la重点关注这几个目录和文件lib/这里面放的不是编译产物而是运行时依赖的脚本和描述文件。src/ekiga主程序源码UI、账号管理、呼叫控制都在这里。plugins/编解码器插件、协议插件SIP/H.323都算协议插件的源码目录。opal被编译成库后插件机制负责在运行时加载不同的编解码器。configure.acautoconf脚本的输入文件里面能看到这个版本依赖哪些库、有哪些开关选项。pixmaps/图标资源编译时会被安装到系统目录。解压完成之后我一般会先执行一次autogen.sh或者直接看README里对依赖的说明。ekiga-3.2.7这个年代的项目依赖的不是pkg-config能全覆盖的现代库而是GTK2、opal、ptlib这一串老库。你在干净的新系统上编译大概率会缺一堆头文件比如libglib2.0-dev、libgtk2.0-dev、libopal-dev、libpt-dev。3.2 configure、make与一条最常见的编译报错configure这一步的参数直接决定后面编出来的是“能跑的客户端”还是“只带G.711的哑巴”。我常用的最小化参数是这样# 进到源码根目录先清理可能的旧缓存 make distclean 2/dev/null # configure打开IPv6、同时保留H.323和SIP ./configure --prefix/usr/local \ --enable-ipv6 \ --with-ffmpeg \ --with-ldapno \ --with-gnomeyes \ --with-ssl参数说明--enable-ipv6默认不一定开。如果你的网络环境有IPv6地址建议开着否则某些双栈环境里客户端解析到AAAA记录后会因为能力不足而回退失败。--with-ffmpeg必须开。这决定了H.264、MPEG4这些视频编码可用性不开的话只剩H.263跟现在的主流终端互通会非常费劲。--with-ldapno很多内网环境用不到通讯录集成不开能少装一堆依赖。--with-sslH.235鉴权和SIP的TLS都会用到。configure通过后进入编译环节。这一步最容易翻车的地方是“PTLib和opal的版本时序不对”。ekiga-3.2.7编译时强制要求opal的API版本匹配否则编译器会报类似error: PConfig::GetBoolean was not declared in this scope这一类的错误。这不是你代码写错纯粹是底层库版本不兼容。解决办法是去看opal源码头文件的版本号保证和ekiga源码里configure.ac声明的opal版本一致。# 编译建议先单线程跑等报错信息完整暴露 make -j1单线程编译虽然慢但好处是错误信息不会被打乱能看清第一个报错在哪。确认通过后建议再做一次全量安装sudo make install sudo ldconfig3.3 首次启动SIP注册的配置路径与参数对照安装完成后首次启动ekiga会弹一个配置向导。如果是命令行环境或者想在配置文件里预置账号可以手动改配置文件。这个版本的配置不是放在/etc下而是写在用户主目录里。# 找到配置文件 find ~ -name *ekiga* -type f 2/dev/null常见路径是~/.gnome2/Ekiga/ekiga.conf里面是键值对格式核心参数长这样[general] username 1000 protocol sip [sip] registrar 192.168.1.10 proxy 192.168.1.10 auth_user 1000 auth_password your_password use_tls false outbound_proxy 参数说明protocol切换SIP/H.323两种模式改这个字段就能让同一个客户端走不同协议。registrar注册服务器地址域名或IP都行。proxy出局代理。如果环境里有独立SIP代理这里填代理地址没有就留空ekiga会直接向被叫方发INVITE。auth_user和auth_password鉴权用的账号密码很多场景里username和auth_user不一样千万别混。这里有一个我踩过的坑配置完保存后客户端不会自动重读配置文件必须完全退出进程再启动。而且ekiga的进程退出并不干净有时候后台还挂着用pkill -f ekiga杀掉再重启才能让新配置生效。4. 排查实录注册成功却喊不通的四个典型坑4.1 注册返回403认证模式不是猜出来的现象SIP账号配置完全按服务器给的参数填了REGISTER发出去服务器回403 Forbidden。原因ekiga默认的鉴权方式和服务端要求不一致。有些软交换只支持Digest MD5有些还要求HTTP Digest算法带algorithmSHA-256而老版本opal对SHA-256支持并不好。另外还有一种常见情况是服务端开启了IP白名单限制注册来源IP跟客户端本身配置无关。解决先在抓包里看REGISTER的Authorization头域带没带是什么算法。如果是algorithmSHA-256优先改服务器端为MD5因为ekiga-3.2.7这个版本对SHA-256的兼容性确实一般。如果是空Authorization头说明客户端没正确读取auth_user变量把配置里auth_user改成与username完全一致重新注册。# 实时过滤注册响应 sudo tcpdump -i eth0 -vv -A udp port 5060看响应报文里的WWW-Authenticate头域它直接告诉你服务器期望哪种摘要算法。4.2 呼叫建立但只有单通RTP端口与防火墙的账现象两台ekiga都能注册成功A呼叫B双方都能听到对方铃音、看到接通状态但对话时只有一方能听到声音另一方完全没有音频。原因这是双栈客户端最容易翻车的地方。H.323和SIP的音视频流走的是RTP而RTP端口是opal在启动时动态分配的不是固定写在配置文件里的。如果你的部署环境有防火墙只放行了TCP 5060/UDP 5060RTP流会被直接丢弃。H.323尤其麻烦因为媒体端口是H.245在呼叫过程中动态协商的范围可能落在1024到65535之间的任意端口。解决一个土办法把防火墙策略改为放行全部UDP端口这在内部测试环境里不算危险但生产环境肯定不行。更规范的方案是给opal限制RTP端口范围。ekiga的配置文件里有一个rtp_port_range的设置可以把它限定在一个较小的区间内然后在防火墙上只放行这个区间。[network] rtp_port_range 10000-20000改完重启进程再抓包确认RTP流的源端口确实落在10000-20000区间。这一步是很多老手的工作习惯因为无限放行端口只是“让它跑通”限制端口范围才是“能部署给别人”。4.3 IPv6优先导致INVITE挂起现象ekiga能注册但拨打电话时INVITE发出后一直收不到100 Trying最后超时。原因客户端解析被叫方地址时优先拿到了IPv6地址但网络链路里没有配置IPv6路由或者对端防火墙没放行IPv6。opal在拿到AAAA记录后不会自动回退到IPv4导致信令包发出后石沉大海。解决三步走。第一步用dig或nslookup查一下被叫域名是不是真的解析出AAAA记录dig short example.com AAAA如果确实有而你的网络没有IPv6可用直接在系统层面禁用IPv6# 临时禁用 sudo sysctl -w net.ipv6.conf.all.disable_ipv61第二步确认ekiga是不是走了IPv6在抓包里看SIP的Via和Contact字段如果都是[IPv6地址]格式那基本就是这个问题。第三步最省事的方法是把被测号码直接配置成IP而不是域名绕开DNS解析顺序问题。内网测试环境我一般直接填IP省掉这个坑。4.4 画面黑屏编解码器协商失败现象呼叫接通了语音正常但双方视频窗口黑屏或者只有本地预览没有远端画面。原因视频编解码器协商失败。ekiga-3.2.7默认的H.264不是标准打包模式它跟现代终端互通时SDP里的packetization-mode经常对不上。而H.263由于实现年头早格式支持倒反而更通用。另外确认编译时是否带上了ffmpeg如果没带H.264基本不可用。解决在ekiga的编解码器设置里把H.264优先级调低把H.263提到最前面。配置文件里找到codec列表手动调整一下顺序[codecs] video_codec_order H.263,H.263,H.264同时检查一个隐藏开关如果编译时加了--with-ffmpegH.264编码器名可能是FFMPEG.H.264而不是裸的H.264。在抓包里看SDP的mvideo行能直接看到协商出的具体编码名。这一步需要耐心但只要能协商成H.263老客户端之间的视频互通基本就稳了。5. 对接现网当软终端接入IMS网关与SIP Trunk5.1 什么样的现网环境还值得让ekiga进场把ekiga接进生产网络之前先把话说明白这不适合做大规模办公电话终端毕竟协议栈老、认证方式弱安全性和审计能力都不如现代软电话。但两个场景里它非常值一是实验室里搭语音网关、SIP Trunk需要一台能随便蹂躏、坏了不心疼的软终端专门用来模拟终端侧异常行为二是和老的H.323 MCU或视频会议硬件做互通验证因为现代软电话基本不支持H.323而ekiga是少数还能在Linux上跑起来的双栈客户端。另外在云视频会议盛行的时代这套老设备的定位是“本地信令钉子户”。当你想验证一条业务规则——比如SIP Trunk上的呼叫先经过代理服务器再落地IMS——ekiga的日志和抓包接口比很多黑盒话机透明得多。5.2 对接参数对照表从域名、端口到编解码优先级在我对接过的IMS和软交换环境里ekiga侧需要确认的参数可以整理成一张对照表配置项推荐值说明TransportUDP老版本对TCP/TLS支持有限优先UDPRegistrar端口5060确认运营商或软交换是否用非标端口Proxy端口5060与Registrar分成两个字段填别混Outbound Proxy按需填写如果业务要求所有呼叫先经过SBC必须填这里认证用户名运营商分配的号码很多SIP Trunk用主叫号码作为认证名主叫号码与认证用户名一致呼出时P-Asserted-Identity容易对不上编解码优先级G.711A G.729内网用G.711A带宽受限再用G.729DTMF模式RFC2833新版本ekiga支持SIP INFO但老设备间互通推荐RFC2833这副表里的每一项都来自实战。尤其是主叫号码和认证用户名不一致的问题经常表现为“注册成功但一呼出就被服务端拒绝”很多人查了半天最后发现是SIP From头域里的号码和鉴权用户对不上。5.3 用sngrep把注册和呼叫过程拉出来看到这一步能不能排错就看工具够不够顺手。sngrep是我在SIP项目里最依赖的命令行抓包工具它能按会话把UDP 5060的包聚合成一行一行的对话流比Wireshark的列表视图直观得多。# 安装sngrep后抓取SIP信令并实时显示 sudo sngrep -d eth0 -r -q udp port 5060操作说明-d eth0指定抓包网卡。-r相对时间戳看两条消息之间隔了多久能判断超时问题。-q静默模式不打印抓包统计省得干扰阅读。在sngrep界面里按Enter进入某个会话能看到完整的SIP消息流。我一般按这个顺序排查先看REGISTER是407还是200再看INVITE的SDP里有没有被服务端改写IP最后看BYE之前有没有发RTP——如果全程没有maudio后的sendrecv说明媒体协商有问题。5.4 边界能力回声抑制与自动应答的一次配置ekiga有些配置项藏在界面点击不到的地方需要在配置文件里手工改。比如对接SIP Trunk时如果对端网关回音比较大ekiga默认的回声消除强度未必够可以在配置文件里调高参数[audio] echo_cancellation true echo_tail_length 50另一个有用的能力是自动应答。在测试自动化场景里我要让一台ekiga自动接起呼叫不需要人工点那个“接听”按钮。修改配置[general] auto_answer true auto_answer_time 0这里有个注意点auto_answer_time填0表示立刻接听但媒体协商需要时间如果对端刚发INVITE就等了很久没收到200 OK很容易误判为超时。我一般填1秒auto_answer_time 1这个参数在对接自动拨测系统时很关键填太小不行、填太大影响拨测时长各自环境调一调就好。6. 验证呼叫链路从抓包过滤器到CDR核对的一条龙习惯最后一章不讲新功能讲一个我自己的验证习惯。每次用ekiga参与测试无论注册多顺利、界面显示多正常我都不会直接说“能用了”而是强制走三条验证线。第一条是信令线。用sngrep或Wireshark把一次完整呼叫抓下来过滤udp port 5060确认从REGISTER到INVITE再到BYE每个关键响应码都在预期范围。重点看INVITE的响应是不是经过代理返回的、Via头域有没有被异常改写以及BYE是谁先发起的——如果是被叫方先BYE但没有发原因头域意味着呼叫可能被某些中间设备静默拆断。第二条是媒体线。只验证信令不够还要确认RTP流存在且有实际载荷。我的习惯是在抓包里过滤双边RTP的SSRC# 确认RTP是否双向传输 tshark -r /tmp/ekiga_call.pcap -Y rtp.ssrc udp -T fields -e rtp.ssrc -e udp.srcport -e udp.dstport | head -20如果只看到一方的RTP说明是单通如果两个SSRC都有但包间隔抖动过大说明网络层面的QoS有问题媒体线的账要算到网络身上。第三条是CDR核对线。对接软交换或IMS环境时呼叫挂断后去服务器的呼叫明细表里看这条记录的起始时间、结束时间、主叫号码、被叫号码拿这四个字段和ekiga界面上显示的时长比对。时间对不上百分百有环节出问题通常不是网络丢包就是信令消息在某个地方超时重传。这三条线走完我才会把“呼叫成功”四个字写进测试报告里。实际上这套习惯不是我天生就有而是被教训换来的。有一回测试SIP Trunk对接REGISTER一直200我偷懒没抓包就声称链路通了结果第二天业务方反馈呼入电话全部单通查了半天才发现SDP里协商出的编解码是G.729而运营商侧只开了G.711A媒体协商在握手阶段就错了。那次之后信令线、媒体线、CDR线三线验证成了我每次搞视频会议测试的固定流程谁也不许跳过。希望这套验证习惯对你能有帮助。本文还有配套的精品资源点击获取