PJSIP开发者指南：SIP协议栈详解

pjsip

4星 · 超过85%的资源需积分: 32 140 浏览量更新于2024-07-29 1 收藏 939KB PDF 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

"PJSIP开发文档" PJSIP是一个用C语言编写的轻量级、高性能的SIP（Session Initiation Protocol）堆栈。它被设计用于实现VoIP（Voice over IP）和其他基于SIP的应用，如视频通话、即时消息等。PJSIP遵循GNU General Public License（GPL）进行分发，同时也提供其他授权选项。更多详细信息可访问http://www.pjproject.net查询。这份开发者指南是PJSIP的官方文档，由Benny Prijono编写并根据GNU Free Documentation License version 1.2发布。文档允许自由复制和分发，但禁止修改原始内容。文档的修订历史记录了自0.5.0版本以来的主要更新和改进： - 在0.5.4版本中，增加了dlg_terminate()、inv_terminate()等函数，对事件订阅（Event Subscription, EVSUB）的API进行了审查，并添加了即时消息（IM）和正在输入（Composing）功能的章节，还引入了PJSUA抽象层。 - 0.5.2版本引入了事件框架、呈现（Presence）和引用（Refer）事件包。 - 0.5.1版本要求应用程序在创建UAS（User Agent Server）事务后调用pjsip_tsx_recv_msg()。 - 0.5.0版本增加了通用能力管理到端点，并对模块结构进行了调整。在深入学习PJSIP之前，了解SIP协议的基础知识至关重要。SIP是一种用于建立、修改和终止多媒体通信会话的协议，常用于VoIP系统。PJSIP的模块化设计使得开发者可以灵活地选择需要的功能，如媒体处理、传输层支持、会话边界控制器（SBC）等。 PJSIP的主要组件包括： 1. **会话（Session）管理**：处理会话的建立、操作和终结，如INVITE、ACK、BYE等SIP消息。 2. **事务（Transaction）层**：管理SIP事务，确保消息正确传递和响应。 3. **URI和路由**：解析和处理SIP URI，以及路由请求到正确的目的地。 4. **注册（Registration）**：用于用户代理向服务器报告其当前位置。 5. **媒体（Media）处理**：支持RTP/RTCP，用于音频和视频数据的传输。 6. **会话描述协议（SDP）**：用于协商媒体参数。 7. **会话保持性（Presence）**：允许用户共享其在线状态信息。 8. **事件（Event）框架**：支持订阅、通知和引用等SIP扩展功能。 9. **PJSUA库**：提供高级API，简化了与PJSIP的交互，适用于快速开发应用程序。学习PJSIP开发涉及以下知识点： - SIP消息结构和流程：理解基本的SIP消息类型，如请求消息和响应消息，以及它们之间的交互。 - PJSIP API：熟悉PJSIP提供的各种函数和结构，用于创建、管理和操作SIP会话、事务和注册。 - 错误处理：理解和处理PJSIP库返回的错误代码。 - 网络和传输：了解PJSIP如何处理底层网络连接，包括TCP、UDP和TLS等传输协议。 - 多媒体集成：如果应用包含音频或视频，需要掌握RTP/RTCP和SDP的知识。 - 能力协商：理解如何通过SDP进行媒体能力的协商。 - 模块化设计：了解如何根据需求选择和配置PJSIP的不同模块。开发者在实践中，还需要关注性能优化、内存管理、线程安全以及网络环境的适应性等方面。PJSIP提供了丰富的示例代码和文档，帮助开发者快速上手。通过深入学习和实践，开发者可以利用PJSIP构建高效、可靠的SIP应用。

资源详情

资源推荐

PJSIP Developer’s Guide
The on_rx_request() and on_rx_response() function pointers are the primary 
means for the module to receive SIP messages from endpoint (pjsip_endpt) or 
from other modules. The return value of these callbacks is important. If a callback 
has returned non-zero (i.e. true condition), it semantically means that the module 
has taken care the message; in this case, the endpoint will stop distributing the 
message to other modules. Section 2.1.3 Incoming Message Processing by
Modules will describe this in more detail.
The on_tx_request() and on_tx_response() function pointers are called by 
transport manager before a message is transmitted. This gives an opportunity for 
some types of modules (e.g. sigcomp, message signing) chance to make last 
modification to the message. All modules MUST return PJ_SUCCESS (i.e. zero 
status), or otherwise the transmission will be cancelled.  Section 2.1.4 Outgoing
Message Processing by Modules will describe this in more detail.
The on_tsx_state() function pointer is used to receive notification every time a 
transaction state has changed, which can be caused by receipt of message, 
transmission of message, timer events, or transport error event. More 
information about this callback will be described in next section 2.1.5 
“Transaction User and State Callback”.
2.1.2 Module Priorities
Module priority specifies the order of which modules are called first to process the 
callback. Module with higher priority (i.e. lower priority number) will have their 
on_rx_request() and on_rx_response() called first, and on_tx_request() and 
on_tx_response() called last.
The values below are the standard to set module priority.
enum pjsip_module_priority
{
PJSIP_MOD_PRIORITY_TRANSPORT_LAYER = 8, // Transport 
PJSIP_MOD_PRIORITY_TSX_LAYER = 16, // Transaction layer.
PJSIP_MOD_PRIORITY_UA_PROXY_LAYER = 32, // UA or proxy layer
PJSIP_MOD_PRIORITY_DIALOG_USAGE = 48, // Invite usage, event subscr. framework.
PJSIP_MOD_PRIORITY_APPLICATION = 64, // Application has lowest priority.
};
Code 4 Module Priorities
Note   : remember that lower priority    number    means higher priority!  
The priority PJSIP_MOD_PRIORITY_TRANSPORT_LAYER is the priority used by 
transport manager. This priority currently is only used to control message 
transmission, i.e. module with lower priority than this (that means higher priority 
number!) will have the on_tx_request()/on_tx_response() called before the 
message is processed by transport layer (e.g. destination is calculated, message 
is printed to contiguous buffer), while module with higher priority than this will 
have the callback called after the message has been processed by transport 
layer. Please see 2.1.4Outgoing Message Processing by Modules for more 
information.
PJSIP_MOD_PRIORITY_TSX_LAYER is the priority used by transaction layer 
module. The transaction layer absorbs all incoming messages that belong to a 
transaction.
PJSIP_MOD_PRIORITY_UA_PROXY_LAYER is the priority used by UA layer (i.e. 
dialog framework) or proxy layer. The UA layer absorbs all incoming messages 
that belong to a dialog set (this means forked responses as well).
Page 16

PJSIP Developer’s Guide

PJSIP_MOD_PRIORITY_DIALOG_USAGE is for dialog usages. Currently PJSIP

implements two types of dialog usages: invite sesssion and event subscription

session (including REFER subscription). The dialog usage absorbs messages inside

a dialog that belong to particular session.

PJSIP_MOD_PRIORITY_APPLICATION is the appropriate value for typical

application modules, when they want to utilize transactions, dialogs, and dialog

usages.

2.1.3 Incoming Message Processing by Modules

When incoming message arrives, it is represented as receive message buffer

(struct pjsip_rx_data, see section 5.1 “Receive Data Buffer”). Transport

manager parses the message, put the parsed data structures in the receive

message buffer, and passes the message to the endpoint.

The endpoint distributes the receive message buffer to each registered module by

calling on_rx_request() or on_rx_response() callback, starting from module with

highest priority (i.e. lowest priority number) until one of them returns non-zero.

When one of the module has returned non-zero, endpoint stops distributing the

message to the remaining of the modules, because it assumes that the module

has taken care about the processing of the message.

The module which returns non-zero on the callback itself may further distribute

the message to other modules. For example, the transaction module, upon

receiving matching message, will process the message then distributes the

message to its transaction user, which in itself must be a module too. The

transaction passes the message to the transaction user (i.e. a module) by calling

on_rx_request() or on_rx_response() callback of that module, after setting the

transaction field in the receive message buffer so that the transaction user

module can distinguish between messages that are outside transactions and

messages that are inside a transaction.

The following diagram shows an example of how modules may cascadely call

other modules.

MODULE

TRANSACTION

rdata

MODULE

DIALOG

MODULE

Event Subscriptn.

(SIMPLE)

rdata

MODULE

APPLICATION

rdata

ENDPOINT

Figure 4 Cascade Module Callback

2.1.4 Outgoing Message Processing by Modules

An outgoing request or response message is represented by a transmit data

buffer (pjsip_tx_data), which among other things, contains the message

structure itself, memory pool, contiguous buffer, and transport info.

When pjsip_transport_send() is called to send a message, transport manager

calls on_tx_request() or on_tx_response() for all modules, starting with modules

with lowest priority (i.e. highest priority number). When these callbacks are

called, the message may have or have not been processed by the transport layer.

The transport layer is responsible for managing these information inside a

transmit buffer:

 transport info, and

 printing the message structure to contiguous buffer.

Modules with priority lower than PJSIP_MOD_PRIORITY_TRANSPORT_LAYER (i.e.

has higher priority number) will receive the message before these information

Page 17

PJSIP Developer’s Guide

are obtained. That means the destination address has not been calculated, and

message has not been printed to contiguous buffer.

If modules want to modify the message structure before it is printed to buffer,

then it must set its priority number higher than transport layer priority. If

modules want to see the actual packet bytes as they are transmitted to the wire

(e.g. for logging purpose), then it should set its priority number to lower than

transport layer.

A practical case where a module wants to set its priority higher than transport layer (i.e. has lower

priority number) is the logging module, where it wants to print outgoing message after it has been

printed to contiguous buffer and destination address has been calculated.

In all cases, modules MUST return PJ_SUCCESS for the return value of these

callbacks. If a module returns other error codes, the transmission will be

cancelled and the error code is returned back to pjsip_transport_send() caller.

2.1.5 Transaction User and State Callback

A special callback in the module definition (on_tsx_state) is used to receive

notification from a particular transaction when transaction state has changed.

This callback is unique because transaction state may change because of non-

message related events (e.g. timer timeout and transport error).

This callback will only be called after the module has been registered as

transaction user for a particular transaction. Only one transaction user is allowed

per transaction. Transaction user can be set to transaction on per transaction

basis.

For transactions created within a dialog, the transaction user is set to the UA

layer module on behalf of a particular dialog. When applications creates the

transaction manually, they may set themselves as the transaction user.

The on_tsx_state() callback will not be called upon receipt of request or response

retransmissions. Note that transmission or receipt of provisional responses are

not considered as retransmissions, which means that receipt or transmission of

provisional responses will always caused this callback to be called.

2.1.6 Module Specific Data

Some PJSIP components have a container where modules can put module specific

data in that component. This container is named as mod_data by convention, and

is an array of pointer to void, which is indexed by the module ID.

For example, an incoming packet buffer (pjsip_rx_data) has the following

declaration for module specific data container:

struct pjsip_rx_data

{

...

struct {

void *mod_data[PJSIP_MAX_MODULE];

} endpt_info;

};

Code 5 Module Specific Data

The mod_data array is indexed by module ID. The module ID is determined when

the module is registered to endpoint.

Page 18

PJSIP Developer’s Guide

2.1.8 Sample Callback Diagrams

Incoming Message Outside Transaction and Outside Dialog

ENDPOINT

(2) lookup /

not found

(1) rdata

endpt_transport_callback()

Transaction

Hash Table

Dialog

Hash Table

USER AGENT

TRANSACTION

DIALOG

TRANSPORT MANAGER

APPLICATION

on_rx_xxx()

(5) rdata

(3) rdata

on_rx_xxx()

(4) lookup /

not found

Figure 6 Processing of Incoming Message

Outside Transaction/Dialog

The processing is as follows:

1) Transport manager (pjsip_tpmgr) passes

all received messages to endpoint (after

parsing the message).

2) Endpoint (pjsip_endpt) distributes the

message to all registered callbacks. First

in the callback list is transaction layer.

Transaction layer looks up the message

in transaction table, and couldn’t find a

matching transaction.

3) Endpoint distributes the message to next

callback in the list, which is user agent.

4) User agent looks up the message in

dialog’s hash table and couldn’t find

matching dialog set.

5) Endpoint continues distributing the

message to next registered callbacks

until it reaches application. Application

processes the message (e.g. respond

statelessly, create UAS transaction, or

proxy the request, or create dialog, etc.)

Incoming Message Inside Transaction

ENDPOINT

(2) lookup /

found !

(1) rdata

endpt_transport_callback()

Transaction

Hash Table

Dialog

Hash Table

USER AGENT

(3) rdata

TRANSACTION

on_rx_xxx()

DIALOG/APPLICATION

TRANSPORT MANAGER

on_rx_xxx()

(4) rdata +tsx

(5) rdata +tsx +dlg

(6) notify state

on_tsx_state()

(7) notify dialog state

Figure 7 Processing of Incoming Message

Inside Transaction

The processing is as follows:

1) Transport manager (pjsip_tpmgr) passes

all received messages to endpoint (after

parsing the message).

2) Endpoint (pjsip_endpt) distributes the

message to all registered callbacks. First

in the callback list is transaction layer.

Transaction layer looks up the message

in transaction table, and found a

matching transaction.

3) Because transaction’s callback returns

PJ_TRUE, endpoint does not distribute

the message further.

4) The transaction processes the response

(e.g. updates the FSM). If the message is

a retransmission, the processing stops

here. Otherwise transaction then passes

the message to it’s transaction user (TU),

which can be a dialog or application.

5) If the TU is a dialog, the dialog processes

the response then pass the response to

it’s dialog user (DU, e.g. application).

6) If the arrival of the message has changed

transaction’s state, transaction will notify

it’s TU about the new state.

7) If TU is a dialog, it may further notify

application about dialog’s state changed.

Page 20

剩余111页未读，继续阅读

fancw

粉丝: 14
资源: 23

PJSIP开发者指南：SIP协议栈详解

PJSIP-PJSUA2开发文档（英文）

PJSIP中文开发文档

pjsip接口api中文说明

go-pjsip中文文档

pjsip开发指南中文版

pjsip 开发示例

pjsip移植到keil

pjsip怎么启动服务

pjsip 嵌入式 怎么使用

pjsip developer guide

stm32如何使用pjsip

pjsip的sipek sdk

pjsip 使用--disable-shared 为什么无法编译pjsip.so文件

php怎么使用pjsip

pjsip android gb28181

android pjsip 本地视频预览模糊

ubuntu qt pjsip

vs2015 编译 pjsip

鸿蒙上使用pjsip

使用pjsip实现语音通话c++ windows

最新资源

pjsip 嵌入式怎么使用