miniSipPhone来了!
新年伊始,我们将miniSipPhone产品升级到V2版本,并于今天正式发布!
在新版本中,我们增加了一些功能,可以极大方便终端用户。例如,大部分VoIP用户都遇到过语音单通的问题,在MSP V2版本中,我们内置了STUN功能,这样,用户不必单独配置STUN信息即可解决大部分语音单通问题。
新版本功能增强了,用户体验上将尽可能简单。您会发现MSP V2是非常容易使用的。我们希望您能喜欢这个产品。
如果你对MSP有兴趣,请访问我们的网站下载试用:
MyVoIPApp出品的各种产品
新年伊始,我们将miniSipPhone产品升级到V2版本,并于今天正式发布!
在新版本中,我们增加了一些功能,可以极大方便终端用户。例如,大部分VoIP用户都遇到过语音单通的问题,在MSP V2版本中,我们内置了STUN功能,这样,用户不必单独配置STUN信息即可解决大部分语音单通问题。
新版本功能增强了,用户体验上将尽可能简单。您会发现MSP V2是非常容易使用的。我们希望您能喜欢这个产品。
如果你对MSP有兴趣,请访问我们的网站下载试用:
我们非常兴奋地发布miniSipServer最新的V11版本!这是个非常棒的版本,因为现在我们可以将Gtalk的呼叫转移到SIP网络!
这意味着什么呢?意味着您的VoIP网络可以和Gtalk网络连接在一起了。Gtalk用户可以直接呼叫到您的分机、使用您的VoIP业务,等等。我们将Gtalk用户带入到您的VoIP网络中来,很有趣吧!
如果您对此感兴趣,请参考我们的在线文档了解该特性的更多细节:
http://www.myvoipapp.com/cn/docs/mss_services/gtalk/index.html
有部分虚拟PBX客户登录账户后发现,他们配置的外线信息不见了。
发生了什么事?外线配置怎么了?
这个现象的根本原因在于:用户在配置外线数据时,可能配置了错误的信息,例如配置了错误的密码。cloud-mss根据这些错误的信息向voip运营商注册,很显然会注册失败。当然,cloud-mss会继续尝试注册很多次。这样,对端的voip运营商很有可能将cloud-mss视为垃圾消息发送者或者不怀好意的攻击者,因此可能对cloud-mss实施消息过滤或者屏蔽,对其他cloud-mss用户造成恶劣影响。
为了避免这种情况,如果cloud-mss尝试注册外线达到一定次数后,始终无法注册成功,cloud-mss系统会判定外线配置错误并把这一信息通知后台管理系统,因此该外线将被系统自动删除。
这就是为什么会丢失掉虚拟IPPBX系统中的外线配置。如果你发现自己的账户出现了这种情况,请检查您的外线配置信息或者与您的VoIP运营商进行协调,然后在虚拟系统中重新配置外线即可。
最新的Ubuntu 12.10版本在前两天发布了. 这毫无疑问是个重要的消息. 考虑到过往linux系统升级导致的各种兼容性问题, 我们在第一时间下载并安装了最新的Ubuntu/Xubuntu/Kubuntu版本, 在这些版本中, 我们尝试安装我们最新的V10.5版本的miniSipServer.
结果非常好! MSS能顺利运行在上述版本中, 不需要进行任何单独的修改.
在另一方面, 我们推荐您安装Xubuntu和Kubuntu系统. 根据我们的测试结果, Ubuntu系统实在是太慢了, 除非您的硬件配置非常高端, 否则Ubuntu的运行速度几乎让人难以忍受. 而Xubuntu以及Kubuntu则运行很流畅, 尤其是Xubuntu, 堪称完美.
众所周知,大部分SIP设备缺省都采用基于UDP的SIP协议,然而有部分SIP设备或者SIP服务器仅仅支持基于TCP的SIP协议。不得不说,这实在是非常奇怪。不过我们的客户需要MSS与这些设备对接,因此我们将MSS升级到V10.5版本来支持基于TCP的SIP协议。
在MSS中很容易配置该特性。如果您对这个特性有兴趣,请参考以下文档了解更多的细节:
http://www.myvoipapp.com/cn/docs/mss_services/sip-over-tcp/index.html
您可能知道,我们可以采用Python脚本语言来提供业务。这种方式可以非常灵活地满足许多客户各种各样的需求。
例如,MSS内部的卡号业务就是采用Python脚本实现。在某些地方部署该业务时,客户会有些不同的需求,例如播放某种语音,或者不播放某条语音,提示这种情况,或者提示另一种情况,等等。我们可以根据客户的需求,更新python脚本文件,而不需要对MSS核心做任何改动。
但是某些东西就不那么灵活,例如业务的触发方式。以前的MSS版本在卡号业务中,固定了业务触发方式。也就是说,只有被叫号码是‘*300*’的呼叫才会触发卡号业务。有些客户就是不喜欢这个号码,还有些客户希望能支持更多的号码来触发业务。
最新的V10.4版本可以支持客户自己配置Python业务的触发方式,实际上,我们可以根据呼叫的拨号计划以及被叫号码来触发Python业务。现在就完美了!客户不仅可以实现定制化的业务,也可以自由地根据自己的需求选择如何触发业务。您不喜欢”*300*”?没问题,只需要配置另外一条数据即可。
请参考用户手册,了解Python业务触发的更多细节信息:
http://www.myvoipapp.com/cn/docs/mss_services/manual/index.html#python_services
Cloud-MSS升级到新版本,以支持离线即时消息(IM)特性。
在统一通信环境中,用户经常需要发送和接收离线消息,尤其是某些客户采用Cloud-MSS作为他们的统一通信工具进行部署,这方面的需求就更加迫切。
本次升级后,Cloud-MSS将支持以下IM特性:
(1)如果被叫用户在线,Cloud-MSS会立刻将TA的IM发送过去。
(2)如果被叫用户不在线,Cloud-MSS将缓存TA的离线IM消息。每个用户可以缓存最多10条IM,每条IM应少于200字符。
(3)如果被叫用户重新在线后,Cloud-MSS自动将TA的离线IM信息发送给该用户。
您不需要对这个特性做任何配置,系统默认就提供离线IM的各项要求,因此构建一个基于云通信的统一通信环境现在是如此的简单,您为什么现在不试试呢?:-)
根据部分客户的反馈意见, 我们新增加了500客户的SIP服务器版本. 新版本支持500客户在线.
同时, 我们在公共产品列表中删除了原有的1000客户版本产品. 如果您需要的话, 仍然可以邮件联系我们获取, 只是我们不公开提供这个版本而已. 1000客户版本与其他各版本有比较大的差异, 客户在安装, 配置, 管理该版本时, 都需要更多的帮助和支持, 因此我们认为这个版本不太适合小企业或者家庭企业使用, 实际上1000客户版本更适合(虚拟)运营商客户使用和部署.
考虑到Ubuntu长期支持版本已经升级到12.04版本, 因此最近我们也全部升级了开发和测试环境中的Ubuntu版本. 与此同时, 我们也升级了Linux平台的MSS版本. 新MSS版本将只支持Ubuntu系列(包括Kubuntu, Xubuntu等)12.04版本. 旧Ubuntu平台以及其他linux发布版本将不在我们的技术支持考虑范围中.
MSS V10版本已经释出, 主要是支持TTS(文本到语音)特性. 在以前的版本中, 如果我们想播放语音, 我们需要使用一些工具进行录音, 并保存到wav文件, 然后加载到MSS中. 虽然我们认为这个过程比较简单, 但是仍然有部分客户认为还是太过复杂. 因此我们发布了TTS特性!
有了TTS特性, 您不再需要创建wav语音文件. 您仅仅需要用文本将您的语音内容写出来, MSS将为您播放这些内容. 很酷! 对吗? 🙂
让我们先看一下以前的自动话务员业务的XML-IVR文件. 我们需要指示语音ID, MSS才能播放相应的语音:
<playaudio> <id>0a080001</id> </playaudio>
现在, 我们可以修改成以下方式:
<playaudio> <text voicename="zh+f2">欢迎您, 请输入分机号</text> </playaudio>
MSS将自动向主叫用户播放语音”欢迎您, 请输入分机号”, 我们不再需要创建单独的WAV文件, 也不要向MSS加载该语音文件.
缺省情况下, MSS采用英文播音, 因此在上述示例中, 我们需要明确指示”voicename”属性, 其中”zh”代表中文, “f2″代表第二种女声. 如果仅仅是”zh”, MSS默认将采用男声播音.
请参考IVR-XML技术规范文档了解更多细节.
另外, MSS将V9版本号保留给Cloud-MSS系统使用.
昨天我们收到了一位中国客户报告的问题: 系统运行几十分钟后, MSS丢失了和MySQL数据库之间的连接,错误原因是“2006, ‘MySQL server has gone away’”。
这是我们首次接到这个问题的报告。在MSS系统中, 一旦和MySQL数据库建立连接后,MSS会每1.5小时自动向MySQL数据库发送ping消息,以保持双方的连接。而MySQL数据库激活定时器缺省值为28800秒,即8小时。我们猜测,可能是MySQL数据库中的缺省值被修改了, 导致MSS试图连接MySQL数据库时, 发生连接丢失的情况。
因此我们请客户在MySQL的命令行管理界面中,输入以下命令进行检查:
show variables like '%out%';
其中,我们关心interactive_timeout和wait_timeout两个参数的值。在客户的环境中,这两个参数被修改为1200秒。
我们不确定是新版本的MySQL将缺省值修改为1200秒,还是某位管理员人工修改了这些值。如果您的环境中也有类似的问题,请进行同样的检查并将这些参数修改为超过1.5小时的值。我们建议保持原有的缺省值,即28800秒。
一旦修改了这些参数,请重启MySQL和MSS,以确保双方的连接采用新的定时器值。