opensips文档

openstack开发文档编辑整理：尊敬的读者朋友们：这里是精品文档编辑中心，本文档内容是由我和我的同事精心编辑整理后发布的，发布之前我们对文中内容进行仔细校对，但是难免会有疏漏的地方，但是任然希望（openstack开发文档）的内容能够给您的工作和学习带来便利。

同时也真诚的希望收到您的建议和反馈，这将是我们进步的源泉，前进的动力。

本文可编辑可修改，如果觉得对您有帮助请收藏以便随时查阅，最后祝您生活愉快业绩进步，以下为openstack开发文档的全部内容。

OpenStack Kilo install2015年12月29日目录一、实验拓扑架构4二、基础系统的安装6三、安装完之后的处理103.1、本地yum的制作103。

2网络yun的准备113.3其它相关操作11四、建立集群134.1配置各节点134.2验证各网络15五、集群环境的基本配置175.1控制节点服务器175。

2其它节点175.3管理结点的基础包安装18六、Keystone身份认证服务206.1安装和配置206。

2校验keystone服务266.3创建openstack的用户脚本28七、Glnace镜像服务297。

1keystone的添加297。

2安装与配置307.3验证服务33八、块存储服务358.1keystone服务的添加358。

2服务的安装与配置37A、Controller结点的配置37B、存储结点的安装与配置398。

3验证服务42九、对象存储服务449。

1keystone服务的添加449。

2安装与配置44A、管理节点的安装与配置44B、存储节点的安装与配置45C、管理节点的操作509。

3验证服务50十、nova的服务5110。

1keystone服务的添加5110。

2安装与配置51A、管理节点操作51B、计算结点操作5310。

3验证服务54十一、neutron服务5611。

1keystone的添加5611。

2安装与配置56A、管理节点的安装配置56B、网络节点的配置(同管理节点合并）59C、计算结点的配置6211.3服务验证6411.4网络验证65十二、Horizon6612。

opensips load_balance函数
在VoIP通信系统中，load_balance函数是一个重要的功能。

它可以确保对于呼叫请求的负载均衡，将请求发送到可用的服务器上，以实现系统的高可靠性和可扩展性。

在OpenSIPS中，load_balance函数可以通过使用OpenSIPS的routing语言来实现。

它可以从一组服务器中选择一个最适合的服务器处理请求，并在需要时自动切换到下一个备用服务器。

这个函数使用一些负载均衡算法，如最小连接数或轮流调度，来选择服务器。

这些算法可以根据实际情况进行调整，以确保系统性能最优。

例如，如果一个服务器过载，load_balance函数将自动将请求转发到其他可用的服务器。

同时，如果一个服务器变得可用，请求将自动切换回该服务器，以确保最大程度地提高系统的可用性。

总之，OpenSIPS的load_balance函数是一个非常有用的功能，可以确保系统的高可靠性和可扩展性。

如果您正在构建一个VoIP通信系统，它是必不可少的一部分。

- 1 -。

OpenSips+FreeSwitch负载均衡1. 基本配置 这个简单⼀点（）负载均衡可⽤的opensipsctl fifo whichopensipsctl fifo lb_list # 查看负载均衡的配置是否⽣效 Wireshark软件的Telephony菜单⾥有⼀个VoIP Call菜单项，可以⾃动发现sip呼叫，可以整理出呼叫过程中，所有消息的流程图。

分析流程图可以找到问题所在，然后去搜索解决⽅案，就⽐较容易了。

FreeSwitch的三种媒体处理⽅式： 录⾳这个顺序很重要，不能把顺序和bridge的弄反了，否则会录⾳不成功： vim /usr/local/freeswitch/conf/dialplan/public.xml<extension name="fs2os"><condition field="destination_number" expression="^(2(.*))$"><!--action application="bridge" data="sofia/external/2001@192.168.2.160;fs_path=sip:192.168.2.160:5060"/--><action application="set" data="RECORD_STEREO=true"/><action application="record_session" data="/tmp/record.wav"/><action application="bridge" data="sofia/external/$1@192.168.2.160"/></condition></extension> acl配置，注意是cidr⽽不是domain： vim /usr/local/freeswitch/conf/autoload_configs/acl.conf.xml 脚本主要修改的地⽅：# 注销掉location的查找，就可以不验证，直接打电话了。

OpenStack Kilo install2015年12月29日目录一、实验拓扑架构5二、基础系统的安装9三、安装完之后的处理133.1、本地yum的制作133.2网络yun的准备143.3其它相关操作15四、建立集群174.1配置各节点174.2验证各网络19五、集群环境的基本配置225.1控制节点服务器225.2其它节点235.3管理结点的基础包安装24六、Keystone身份认证服务276.1安装和配置276.2校验keystone服务366.3创建openstack的用户脚本39七、Glnace镜像服务417.1keystone的添加417.2安装与配置437.3验证服务47.八、块存储服务498.1keystone服务的添加498.2服务的安装与配置51A、Controller结点的配置51B、存储结点的安装与配置548.3验证服务60九、对象存储服务619.1keystone服务的添加619.2安装与配置61A、管理节点的安装与配置61B、存储节点的安装与配置63C、管理节点的操作729.3验证服务72十、nova的服务7410.1keystone服务的添加7410.2安装与配置75A、管理节点操作75B、计算结点操作7710.3验证服务80十一、neutron服务8211.1keystone的添加8211.2安装与配置83A、管理节点的安装配置83B、网络节点的配置（同管理节点合并）87C、计算结点的配置9411.3服务验证9811.4网络验证99十二、Horizon10012.1安装与配置10012.2登陆测试101十三、问题解决10213.1防火墙10213.2ERROR:the server has either erred or is incapable of performing therequested operation10313.3vnc访问的解决10513.4虚拟机获取不到IP10513.4最终的配置文件106十四、虚拟机的操作108一、实验拓扑架构实验用电脑的配置为i7，16G内存，150G硬盘空间；centos7.1的镜像版本为：CentOS-7-x86_64-Everything-1503-01.iso，可以根据个人的实际情况进行修改。

开启一个全面的文章评估并撰写opensips control panel（OCP）的功能和应用，以帮助你更深入地理解这个主题。

1. opensips control panel 简介opensips control panel（OCP）是一个基于opensips SIP服务器的管理界面，它提供了一系列功能和工具，用于管理opensips服务器和呼叫路由。

OCP可以帮助管理员更轻松地监控服务器状态、配置路由规则、管理用户账号等。

2. OCP的功能和应用OCP提供了丰富的功能和应用，包括但不限于以下几点：- 实时监控：通过OCP，管理员可以实时监控opensips服务器的状态，包括注册用户、并发呼叫数、负载情况等，以便及时发现和解决问题。

- 路由管理：OCP允许管理员配置和管理呼叫路由规则，包括路由策略、转发规则等，以实现呼叫的灵活控制和管理。

- 用户管理：管理员可以通过OCP管理用户账号，包括添加新用户、修改权限、查看用户使用情况等，以保证用户的正常使用和安全性。

3. 从简到繁的探讨OCP在深入探讨OCP的功能和应用时，我们可以从简到繁地进行：- 从OCP的基本功能入手，介绍其界面布局和常用功能，帮助你轻松上手。

- 逐步介绍OCP的高级功能，如实时监控、路由管理、用户管理等，以帮助你更全面地理解其强大之处。

- 可以讨论一些高级应用场景，如如何通过OCP实现负载均衡、高可用性等，以帮助你更深入地理解其在实际项目中的应用。

4. 个人观点和理解在我看来，OCP是一个非常实用和强大的工具，它可以帮助管理员更轻松地管理opensips服务器，提高系统的稳定性和安全性。

通过OCP的实时监控和灵活的配置管理，可以更好地满足实际项目的需求，提升系统的性能和用户体验。

总结回顾通过本文的深入探讨，相信你已经对opensips control panel有了更深入的了解。

你可以通过实践和深入研究，进一步挖掘其更多的功能和应用，以应对复杂的实际项目需求。

Ubuntu下kamailio服务器搭建的部分注意事项SIP服务器搭建实验1 SIP实验基础1.1 Sip服务器端软件∙OpenSIPS(kamailio)∙Asterisk∙SipXecs∙FreeSWITCH1.2 SIP客户端软件∙X-lite（免费使用、不开源、对应商业收费软件eyeBeam）∙LinPhone（开源 C）∙Yate∙Twinkle1.3 抓包工具∙WireShark∙ngrep∙iptool2 OpenSIPS(kamailio)介绍OpenSIPS是一个成熟的开源SIP服务器，除了提供基本的SIP代理及SIP路由功能外，还提供了一些应用级的功能。

OpenSIPS的结构非常灵活，其核心路由功能完全通过脚本来实现，可灵活定制各种路由策略，可灵活应用于语音、视频通信、IM以及Presence等多种应用。

同时OpenSIPS性能上是目前最快的SIP服务器之一，可用于电信级产品构建。

3 Kamailio安装及配置3.1 安装环境ubuntu 11.10（S）3.2 安装步骤step 1 安装mysql服务端$sudo apt-get install mysql-serverstep 2 安装其他需要软件$sudo apt-get install git-core gcc flex bison libmysqlclient15-dev make libcurl4-openssl-dev libxml2-dev libpcre3-devstep 3 建立项目文件目录$sudo mkdir -p /usr/local/src/kamailio-3.0.0$cd /usr/local/src/kamailio-3.0.0step 4 用git下载源码并建立分支$sudo git clone --depth 1 git:///sip-router kamailio$cd kamailio$sudo git checkout -b kamailio_3.0 origin/kamailio_3.0step 5 编译前配置$sudo make cfg①vi modules.lst②Remove db_mysql from the variable exclude_modules.③Save the modules.lst and exit.（①②③建议用$sudo gedit modules.lst 命令操作移除db_mysql并作保存，用vi编辑器修改操作比较困难）$sudo make include_modules="db_mysql dialplan" cfgstep 6 编译$sudo make allstep 7 安装$sudo make install3.3 配置3.3.1 常用配置文件目录/usr/local/sbin 可执行文件目录/usr/local/etc/kamailio 配置文件目录/usr/local/lib/kamailio/modules/ 模块目录/usr/local/lib/kamailio/modules_k/ 模块目录/usr/local/share/doc/kamailio/ 文档目录3.3.2 kamctlrc配置（注意：要去掉前面的注释#号）/usr/local/etc/kamailio/kamctlrc 配置SIP_DOMAIN=ps.sip.uniza.skDBENGINE=MYSQLDBHOST=localhostDBNAME=kamailioDBRWUSER=openserDBRWPW="openserrw"DBROUSER=openserroDBROPW=openserroDBROOTUSER="root"ALIASES_TYPE="DB"CTLENGINE="FIFO"OSER_FIFO="/tmp/kamailio_tmp"VERBOSE=1PID_FILE=/var/run/kamailio.pid建议在/usr/local/etc/kamailio/目录下用$sudo gedit kamctlrc进行编辑修改。

关于opensips的书籍-回复OpenSIPS 是一种开源的会话初始协议（SIP）服务器，它具有强大的扩展性和高性能，可以用于构建大规模VoIP和实时通信系统。

对于那些想要深入了解OpenSIPS 的人来说，有一些很有价值的书籍可以提供帮助。

在本文中，我们将探讨一些关于OpenSIPS 的书籍，并回答一些关于这些书籍的常见问题。

首先，让我们来看一下《Building Telephony Systems with OpenSIPS 1.6》这本书。

这本书由Flavio E. Goncalves 和Bogdan-Andrei Iancu 合著，是OpenSIPS 官方认可的首部指南性书籍。

该书重点介绍了如何使用OpenSIPS构建VoIP和实时通信系统。

书中提供了丰富的代码示例和实际应用案例，以帮助读者更好地理解和掌握OpenSIPS的功能和用法。

《Building Telephony Systems with OpenSIPS 1.6》这本书的内容涵盖了OpenSIPS的基础知识、安装和配置、SIP消息处理、路由策略、用户认证、负载均衡等方面。

此外，这本书还介绍了OpenSIPS与其他常用工具和技术的集成，如MySQL数据库、Radius服务器、Kamailio等。

对于那些已经熟悉OpenSIPS基础知识并希望进一步深入其高级功能和扩展性的读者来说，《OpenSIPS 101: Building Telephony Systems with OpenSIPS》这本书是一个不错的选择。

该书由Liviu Chircu 写作，重点介绍了OpenSIPS的高级用法和概念。

这本书从一个实际的场景出发，向读者介绍了如何使用OpenSIPS构建一个大规模、高性能的实时通信系统。

《OpenSIPS 101: Building Telephony Systems with OpenSIPS》这本书的内容包括OpenSIPS的高级路由策略、安全和认证、重订阅、故障转移、高可用性等方面。

1.1. OverviewThe module contains record routing logic1.2. Dialog supportOpenSIPS is basically only a transaction statefull proxy, without any dialog support build in. There are many features/services which actually requires a dialog awareness, like storing the information in the dialog creation stage, information which will be used during the whole dialog existence.The most urging example is NA T traversal, in dealing with the within the dialog INVITEs (re-INVITEs). When processing the initial INVITE, the proxy detects if the caller or callee is behind some NA T and fixes the signalling and media parts - since not all the detection mechanism are available for within the dialog requests (like usrloc), to be able to fix correspondingly the sequential requests, the proxy must remember that the original request was NA T processed. There are many other cases where dialog awareness fixes or helps.The solution is to store additional dialog-related information in the routing set (Record-Route/Route headers), headers which show up in all sequential requests. So any information added to the Record-Route header will be found (with no direction dependencies) in Route header (corresponding to the proxy address).As storage container, the parameters of the Record-Route / Route header will be used - Record-Route parameters mirroring are reinforced by RFC 3261 (see 12.1.1 UAS behavior).For this purpose, the modules offers the following functions:add_rr_param() - see Section 1.5.4, “ add_rr_param(param) ”check_route_param() - see Section 1.5.5, “ check_route_param(re) ”Example 1.1. Dialog support in RR moduleUAC OpenSIPS PROXY UAS---- INVITE ------> record_route() ----- INVITE ---->add_rr_param(";foo=true")--- reINVITE -----> loose_route() ---- reINVITE --->check_route_param(";foo=true")<-- reINVITE ------ loose_route() <--- reINVITE ----check_route_param(";foo=true")<------ BYE ------- loose_route() <----- BYE -------check_route_param(";foo=true")1.3. Dependencies1.3.1. OpenSIPS ModulesThe following modules must be loaded before this module:No dependencies on other OpenSIPS modules.1.3.2. External Libraries or ApplicationsThe following libraries or applications must be installed before running OpenSIPS with this module loaded:None.1.4. Exported Parameters1.4.1. enable_full_lr (integer)If set to 1 then “;lr=on” instead of just “;lr” will be used. This is to overcome problems with broke n UAs which strip “;lr” parameter when generating Route header fields from Record-Route (“;lr=on” seems to help).Default value is 0 (no).Example 1.2. Set enable_full_lr parameter...modparam("rr", "enable_full_lr", 1)...1.4.2. append_fromtag (integer)If turned on, request's from-tag is appended to record-route; that's useful for understanding whether subsequent requests (such as BYE) come from caller (route's from-tag==BYE's from-tag) or callee (route's from-tag==BYE's to-tag)Default value is 1 (yes).Example 1.3. Set append_fromtag parameter...modparam("rr", "append_fromtag", 0)...1.4.3. enable_double_rr (integer)There are some situations when the server needs to insert two Record-Route header fields instead of one. For example when using twodisconnected networks or doing cross-protocol forwarding from UDP->TCP. This parameter enables inserting of 2 Record-Routes. The server will later remove both of them.Default value is 1 (yes).Example 1.4. Set enable_double_rr parameter...modparam("rr", "enable_double_rr", 0)...1.4.4. add_username (integer)If set to a non 0 value (which means yes), the username part will be also added in the Record-Route URI.Default value is 0 (no).Example 1.5. Set add_username parameter...modparam("rr", "add_username", 1)...1.5. Exported Functions1.5.1. loose_route()The function performs routing of SIP requests which contain a route set. The name is a little bit confusing, as this function also routes requests which are in the “strict router” format.This function is usually used to route in-dialog requests (like ACK, BYE, reINVITE). Nevertheless also out-of-dialog requests can have a “pre-loaded route set” and my be routed with loose_route. It also takes care of translating between strict-routers and loose-router.The loose_route function analyzes the Route: headers in the requests. If there is no Route: header, the function returns FALSE and routing should be done with normal lookup functions. If a Route: header is found, the function returns 1 and behaves as described in section 16.12 of RFC 3261. There is only one exception: If the request is out-of-dialog (no to-tag) and there is only one Route: header indicating the local proxy, then the Route: header is removed and the function returns FALSE.Make sure your loose_routing function can't be used by attackers to bypass proxy authorization.The loose_routing topic is very complex. See the RFC3261 for more details (grep for “route set” is a good starting point in this comprehensive RFC).This function can be used from REQUEST_ROUTE.Example 1.6. loose_route usage...loose_route();...1.5.2. record_route() and record_route(string)The function adds a new Record-Route header field. The header field will be inserted in the message before any other Record-Route header fields. If any string is passed as parameter, it will be appended as URI parameter to the Record-Route header. The string must follow the “;name=value” scheme and it may contain pseudo-variables.This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.Example 1.7. record_route usage...record_route();...1.5.3. record_route_preset(string)This function will put the string into Record-Route, don't use unless youknow what you are doing.Meaning of the parameters is as follows:string- String to be inserted into the header field; it may contain pseudo-variables.This function can be used from REQUEST_ROUTE, BRANCH_ROUTE and FAILURE_ROUTE.Example 1.8. record_route_preset usage...record_route_preset("1.2.3.4:5090");...1.5.4. add_rr_param(param)Adds a parameter to the Record-Route URI (param must be in “;name=value” format. The function may be called also before or after the record_route() call (see Section 1.5.2, “ record_route() and record_route(string) ”).Meaning of the parameters is as follows:param - String containing the URI parameter to be added. It must follow the “;name=value” scheme; it may contain pseudo-variables.This function can be used from REQUEST_ROUTE, BRANCH_ROUTEand FAILURE_ROUTE.Example 1.9. add_rr_param usage...add_rr_param(";nat=yes");...1.5.5. check_route_param(re)The function checks if the URI parameters of the local Route header (corresponding to the local server) matches the given regular expression. It must be call after loose_route() (see Section 1.5.1, “ loose_route() ”). Meaning of the parameters is as follows:re - regular expression to check against the Route URI parameters.This function can be used from REQUEST_ROUTE.Example 1.10. check_route_param usage...if (check_route_param("nat=yes")) {setflag(6);}...1.5.6. is_direction(dir)The function checks the flow direction of the request. As for checking it's used the “ftag” Route header parameter, the append_fromtag (see Section 1.4.2, “append_fromtag (integer)”module parameter must be enabled. Also this must be called only after loose_route() (see Section 1.5.1, “ loose_route() ”).The function returns true if the “dir” is the same with the request's flow direction.The “downstream” (UAC to UAS) direction is relative to the initial request that created the dialog.Meaning of the parameters is as follows:dir - string containing the direction to be checked. It may be “upstream” (from UAS to UAC) or “downstream” (UAC to UAS).This function can be used from REQUEST_ROUTE.Example 1.11. is_direction usage...if (is_direction("upstream")) {xdbg("upstream request ($rm)\n");}...Chapter 2. Developer GuideThe RR module provides an internal API to be used by other OpenSIPS modules. The API offers support for SIP dialog based functionalities - for more about the dialog support offered by RR module, see Section 1.2, “Dialog support”.For internal(non-script) usage, the RR module offers to other module the possibility to register callback functions to be executed each time a local Route header is processed. The callback function will receive as parameter the register parameter and the Route header parameter string. 2.1. Available Functions2.1.1. add_rr_param( msg, param)Adds a parameter to the requests's Record-Route URI (param must be in “;name=value” format).The function returns 0 on success. Otherwise, -1 is returned.Meaning of the parameters is as follows:struct sip_msg* msg - request that will has the parameter “param” added to its Record-Route header.str* param - parameter to be added to the Record-Route header - it must be in “;name=value” format.2.1.2. check_route_param( msg, re)The function checks for the request “msg” if the URI parameters of the local Route header (corresponding to the local server) matches the given regular expression “re”. It must be call after the loose_route was done. The function returns 0 on success. Otherwise, -1 is returned.Meaning of the parameters is as follows:struct sip_msg* msg - request that will has the Route header parameters checked.regex_t* param - compiled regular expression to be checked against the Route header parameters.2.1.3. is_direction( msg, dir)The function checks the flow direction of the request “msg”. As for checking it's used the “ftag” Route header parameter, the append_fromtag (see Section 1.4.2, “append_fromtag (integer)” module parameter must be enables. Also this must be call only after the loose_route is done.The function returns 0 if the “dir” is the same with the request's flow direction. Otherwise, -1 is returned.Meaning of the parameters is as follows:struct sip_msg* msg - request that will have the direction checked.int dir- direction to be checked against. It may be “RR_FLOW_UPSTREAM” or “RR_FLOW_DOWNSTREAM”.2.1.4. get_route_param( msg, name, val)The function search in to the “msg”'s Route header parameters the parameter called “name” and returns its value into “val”. It must be call only after the loose_route is done.The function returns 0 if parameter was found (even if it has no value). Otherwise, -1 is returned.Meaning of the parameters is as follows:struct sip_msg* msg - request that will have the Route header parameter searched.str *name - contains the Route header parameter to be serached.str *val- returns the value of the searched Route header parameter if found. It might be empty string if the parameter had no value.2.1.5. register_rrcb( callback, param)The function register a new callback (along with its parameter). The callback will be called when a loose route will be performed for the local address.The function returns 0 on success. Otherwise, -1 is returned.Meaning of the parameters is as follows:rr_cb_t callback - callback function to be registered.void *param - parameter to be passed to the callback function.2.2. ExamplesExample 2.1. Loading RR module's API from another module...#include "../rr/api.h"...struct rr_binds my_rrb;....../* load the RR API */if (load_rr_api( &my_rrb )!=0) {LM_ERR("can't load RR API\n");goto error;}....../* register a RR callback */if (my_rrb.register_rrcb(my_callback,0))!=0) { LM_ERR("can't register RR callback\n");goto error;}...。