Asterisk 1.8 sip 协议栈分析 2

原创

voipmaker 2022-11-14 19:32:42 博主文章分类：SIP ©著作权

文章标签 processing audio allocation authentication domain 文章分类 OpenStack 云计算

©著作权归作者所有：来自51CTO博客作者voipmaker的原创作品，请联系作者获取转载授权，否则将追究法律责任

上一篇文章分析了 sip注册消息的流程，下面分析一下 invite请求的处理流程。

从handle_request_invite入口，invite请求此处处理replace请求头，如果为replace则认为是咨询，此时不会创建新的通道，而是找到一个通道植入（masqued），大多数情况下是根据invite创建新的请求，所以此处我们从这里开始，不考虑咨询情况

首先检查此请求是否为重复请求，if (!req->ignore) ，接下来调用check_via检查via头域,这个函数涉及到nat穿越问题，此函数解析rport头域参数，如果via头域有rport= ，则设置标记此请求包含rport 域标志，同时检查maddr= 域是否存在，如果此处rport=存在则设置nat mode 为 nat,否则为no nat, 至此check_via结束。

返回 invite函数，这里 invite 有两种情况，一个为 call-id已经存在，则asterisk认为此请求是re-invite(!p->owner),否则认为是一个新的invite，关于re-invite有很多故事，涉及到asterisk是b2bua还是proxy的问题，下面先讨论非 re-invite请求。

从打印信息看到

ast_verbose("Using INVITE request as basis request - %s/n", p->callid);

Using INVITE request as basis request - ZjRiYjZkYzYzZDNjNDRmMjhmMmNlNzdmODE4NTYzZmE.

如果开启sip history 可以看到会调用，

append_history(p, "Invite", "New call: %s", p->callid);

接下来调用parse_ok_contact （）函数保存此invite的contact头域，以备将来做响应(200 ok,bye, re-invite)

fullcontact 变量保存全部cantact头域,用来做bye,re-invite，okcontacturi保存uri of acks, bye, re-invite.

接下来调用下面代码：

if (!p->lastinvite && !req->ignore && !p->owner) {        // 全新invite
  /* This is a new invite */
  /* Handle authentication if this is our first invite */
  int cc_recall_core_id = -1;
  set_pvt_allowed_methods(p, req);
  res = check_user_full(p, req, SIP_INVITE, e, XMIT_RELIABLE, addr, &authpeer);
  if (res == AUTH_CHALLENGE_SENT) {
   p->invitestate = INV_COMPLETED;  /* Needs to restart in another INVITE transaction */
   res = 0;
   goto request_invite_cleanup;
  }

对于第一次请求会做验证，调用check_user_full，下面分析一下此函数。

此函数用请求的 from 头域的usr name 和 peer的 ip/port做匹配，check_user_full 调用get_calleridname 从from头域分理出

callid_name，最终调用 check_peer_ok ，check_peer_ok内部查找 peer name 是否在 peers 链表中存在。这里先尝试用

from 头域中的 user name查找，找不到则用 ip/port查找。

这里找到后输出如下。

if (debug)
ast_verbose("Found peer '%s' for '%s' from %s/n",
peer->name, of, ast_sockaddr_stringify(&p->recv));

Found peer '1501159973' for '1501159973' from 10.10.10.84:59584

然后把peer 相关属性拷贝到为此peer创建的channle中，如 acc,language,amaflags。callgroup，fullcontact等，

设置定时器管理事务。。。

接下来调用 dialog_initialize_rtp函数初始化此peer的rtp信息。

是否peer有RTP,有则设置编码。设置RTP 引擎，这里需要说明的是 asterisk1.8开始RTP协议栈改动很大，默认使用Asteirsk提供的rtp协议栈，开发者可以自己嵌入其他rtp协议栈。

设置完协议栈后设置此peer 建立rtp会话的默认编码规则。

Found peer '1501159973' for '1501159973' from 10.10.10.84:59584
[Dec 21 15:30:13] DEBUG[28437]: rtp_engine.c:344 ast_rtp_instance_new: Using engine 'asterisk' for RTP instance '0xc1c0078'
[Dec 21 15:30:13] DEBUG[28437]: res_rtp_asterisk.c:472 ast_rtp_new: Allocated port 18084 for RTP instance '0xc1c0078'
[Dec 21 15:30:13] DEBUG[28437]: rtp_engine.c:353 ast_rtp_instance_new: RTP instance '0xc1c0078' is setup and ready to go
[Dec 21 15:30:13] DEBUG[28437]: res_rtp_asterisk.c:2370 ast_rtp_prop_set: Setup RTCP on RTP instance '0xc1c0078'

此处路线： check_peer_ok->dialog_initialize_rtp->ast_rtp_instance_new->ast_rtp_instance_set_timeout

ast_rtp_instance_set_hold_timeout

ast_rtp_instance_set_prop

ast_rtp_instance_set_qos

do_setnat

上面为一些列调用过程，初始化此peer的RTP信息，包括 qos，nat mode，rtcp,dtmf几项任务。check_peer_ok函数做了很多工作哇。。。。

至此验证通过，RTP信息也初始化完毕，返回 handl_request_invite函数，开始处理 SDP啦。。。。

/* We have a successful authentication, process the SDP portion if there is one */
if (find_sdp(req)) {

if (process_sdp(p, req, SDP_T38_INITIATE)) {
    /* Asterisk does not yet support any Content-Encoding methods. Always
     * attempt to process the sdp, but return a 415 if a Content-Encoding header
     * was present after processing fails. */
    if (!ast_strlen_zero(get_header(req, "Content-Encoding"))) {
     transmit_response_reliable(p, "415 Unsupported Media type", req);
    } else {
     /* Unacceptable codecs */
     transmit_response_reliable(p, "488 Not acceptable here", req);
    }

。。。。

可以看到，开始处理SDP...

首先当然是从invite请求中找sdp 了，，调用find_sdp （）,

/*!
/brief 返回sip invite请求包中是否存在SDP信息，

*/
static int find_sdp(struct sip_request *req)

此处当然是找到了。。

调用 process_sdp 处理SDP,

/*! /brief Process SIP SDP offer, select formats and activate RTP channels
If offer is rejected, we will not change any properties of the call
Return 0 on success, a negative value on errors.
Must be called after find_sdp().
*/
static int process_sdp(struct sip_pvt *p, struct sip_request *req, int t38action)

解析SDP包头。。。

[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8197 process_sdp: Processing session-level SDP v=0... UNSUPPORTED.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8197 process_sdp: Processing session-level SDP o=- 0 2 IN IP4 10.10.10.84... UNSUPPORTED.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8197 process_sdp: Processing session-level SDP s=CounterPath X-Lite 3.0... UNSUPPORTED.
[Dec 21 15:30:13] DEBUG[28437]: netsock2.c:125 ast_sockaddr_split_hostport: Splitting '10.10.10.84' gives...
[Dec 21 15:30:13] DEBUG[28437]: netsock2.c:155 ast_sockaddr_split_hostport: ...host '10.10.10.84' and port '(null)'.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8197 process_sdp: Processing session-level SDP c=IN IP4 10.10.10.84... OK.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8197 process_sdp: Processing session-level SDP t=0 0... UNSUPPORTED.

首先扫描 m=头域，media stream

这里包含一些SDP 信息，解释如下

SDP Data from Example

SDP Parameter	Parameter Name
v=0	Version number
o=Tesla 2890844526 2890844526 IN IP4 lab.high-voltage.org	Origin containing name
s=Phone Call	Subject
c=IN IP4 100.101.102.103	Connection
t=0 0	Time
m=audio 49170 RTP/AVP 0	Media
a=rtpmap:0 PCMU/8000	Attributes

Connection IP address (100.101.102.103);
Media format (audio);
Port number (49170);
Media transport protocol (RTP);
Media encoding (PCM μ Law);
Sampling rate (8,000 Hz).

每个SDP头域包含 m,o,c，等对不同SDP头域的处理，

每种类型调用 process_sdp_类型函数处理，

如连接地址处理函数process_sdp_c,这里最重要的是 process_sdp_a_媒体类型，此函数处理SDP包的属性，如音频，则为

process_sdp_a_audio，关于SDP处理的核心位置都在这个函数中。。。process_sdp根据SDP包属性(媒体编码类型)匹配支持的编码类型。

[Dec 21 15:30:13] DEBUG[28437]: rtp_engine.c:535 ast_rtp_codecs_payloads_set_m_type: Setting payload 98 based on m type on 0xb7b30490
Found RTP audio format 8
[Dec 21 15:30:13] DEBUG[28437]: rtp_engine.c:535 ast_rtp_codecs_payloads_set_m_type: Setting payload 8 based on m type on 0xb7b30490
Found RTP audio format 101
[Dec 21 15:30:13] DEBUG[28437]: rtp_engine.c:535 ast_rtp_codecs_payloads_set_m_type: Setting payload 101 based on m type on 0xb7b30490
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=alt:1 1 : Bwd30+5D C9DdG2tq 10.10.10.84 50946... UNSUPPORTED.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=fmtp:101 0-15... UNSUPPORTED.
Found audio description format BV32 for ID 107
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:107 BV32/16000... OK.
Found audio description format BV32-FEC for ID 119
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:119 BV32-FEC/16000... OK.
Found audio description format SPEEX for ID 100
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:100 SPEEX/16000... OK.
Found audio description format SPEEX-FEC for ID 106
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:106 SPEEX-FEC/16000... OK.
Found audio description format SPEEX-FEC for ID 105
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:105 SPEEX-FEC/8000... OK.
Found audio description format iLBC for ID 98
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:98 iLBC/8000... OK.
Found audio description format telephone-event for ID 101
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=rtpmap:101 telephone-event/8000... OK.
[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:8384 process_sdp: Processing media-level (audio) SDP a=sendrecv... OK.

至此，关于此peer的 SDP信息及 RTP信息都已初始化完毕。

回到 handle_request_invite()

/* Check number of concurrent calls -vs- incoming limit HERE */
ast_debug(1, "Checking SIP call limits for device %s/n", p->username);

开始检查 peer的 call-limit

如果此peer达到上限，则返回 480 Temporarily Unavailable (Call limit)响应。。。所以当调试时返回此响应我们应该猜测到此设备已经达到并发上限。。。。

接下来调用get_destination（），我们得给此请求送到哪？???

此函数用 invite请求的 to 头域作为请求地址，

根据请求的peer name@ip 查找请求的peerr是否在我这check_sip_domain（）。。。找不到则到dialplan中查找。。。。。

/* If we don't have a peer (i.e. we're a guest call),
   * overwrite the original context */
  if (!ast_test_flag(&p->flags[1], SIP_PAGE2_HAVEPEERCONTEXT) && !ast_strlen_zero(domain_context)) {
   ast_string_field_set(p, context, domain_context);
  }

这里是当我们在sip config 里设置润许guest invite时设置 context为默认。。

当在dialplan中找到对应分机时我们得给此SIP 请求创建 channle啦。。

调用 sip_new()...这里，sip_new函数是真正创建sip通道的地方，此函数在呼入请求，及外呼请求时调用，分别为函数 sip_request_call及handle_request_invite函数。。。

sip_new函用 sip_pvt结构创建sip structuer, 设置此通道的编码类型，dtfm, caller id等信息。。。

调用ast_channel_alloc 宏（channel.c）创建sip channle,创建细节在__ast_channel_alloc_ap 函数中，channle的分配用

ao2_alloc函数，同时指定了析构函数释放通道，申请channel内存后设置管道句柄初始状态，创建此channle调度器上下文，

1.8新增了 caller party information 统计信息，所以此处先初始化这些结构，接下来申请channle无名管道，

if (pipe(tmp->alertpipe)) {
   ast_log(LOG_WARNING, "Channel allocation failed: Can't create alert pipe! Try increasing max file descriptors with ulimit -n/n");
   return ast_channel_unref(tmp);
  } else {
   flags = fcntl(tmp->alertpipe[0], F_GETFL);
   if (fcntl(tmp->alertpipe[0], F_SETFL, flags | O_NONBLOCK) < 0) {
    ast_log(LOG_WARNING, "Channel allocation failed: Unable to set alertpipe nonblocking! (%d: %s)/n", errno, strerror(errno));
    return ast_channel_unref(tmp);
   }
   flags = fcntl(tmp->alertpipe[1], F_GETFL);
   if (fcntl(tmp->alertpipe[1], F_SETFL, flags | O_NONBLOCK) < 0) {
    ast_log(LOG_WARNING, "Channel allocation failed: Unable to set alertpipe nonblocking! (%d: %s)/n", errno, strerror(errno));
    return ast_channel_unref(tmp);
   }
  }

把创建的管道加入fd列表监听。。。。这里channle fd数量是有限制的，默认一个channle最大10个。

/* Always watch the alertpipe */
ast_channel_set_fd(tmp, AST_ALERT_FD, tmp->alertpipe[0]);
/* And timing pipe */
ast_channel_set_fd(tmp, AST_TIMING_FD, tmp->timingfd);

接下来初始化uniqueid，linkeid,这里uniqueid 最大150个字符，包括系统名字（最大127）+unix时间戳+递增序列。。。

初始化channle的amaflags，accountcode，context以便于计费使用(cdr)。

接下来开始分配此 channle cdr 结构并初始化。。

tmp->cdr = ast_cdr_alloc();// 分配
ast_cdr_init(tmp->cdr, tmp);//初始化
ast_cdr_start(tmp->cdr); //设置起始时间，，，cdr->start..

ast_cel_report_event(tmp, AST_CEL_CHANNEL_START, NULL, NULL, NULL);// cdel引擎启动。。发channle start事件。。

1.8多了个CEL ,也是在这里初始化。。把channle放到 channles 容内部器。。

channle建立完毕，，，发送ami事件 Newchannel。。完毕后返回创建channle 到sip_new

sip为一种通道类型，实际创建为channle.c中的ast_channle 结构，此结构为众多通道的接口层，。。

这里设置 SIPURI，SIPDOMAIN，parkinglot，accountcode，language，等全局数据，初始化 fd 事件，值得注意的是 asterisk 1.8中支持了 epoll 异步Io,在一些情况下对系统的并发应该提高很多。

接下来 SIP_new 对于有rtp的peer,则初始化 jt引擎(rtp 抖动)，

然后，此函数调用 Ast_pbx_start进入Asterisk内核。。。。ast_pbx_start 启动新的线程处理此channle..

返回后，调用build_route（），记录 record_Route头域，此处作用是记录路由路径作为未来的请求。

ast_debug(2, "%s: New call is still down.... Trying... /n", c->name);

至此，channle 已经建立完成，发个临时响应吧。。。transmit_provisional_response(p, "100 Trying", req, 0);

[Dec 21 15:30:13] DEBUG[28437]: chan_sip.c:21609 handle_request_invite: SIP/1501159973-0000000b: New call is still down.... Trying..

<--- Transmitting (no NAT) to 10.10.10.84:59584 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.10.10.84:59584;branch=z9hG4bK-d87543-7c6375234a299e1c-1--d87543-;received=10.10.10.84;rport=59584
From: "1501159973"<sip:1501159973@10.10.10.182>;tag=e648a101
To: "6969 (Softphone)"<sip:6969@10.10.10.182>
Call-ID: ZjRiYjZkYzYzZDNjNDRmMjhmMmNlNzdmODE4NTYzZmE.
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.2-rc1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:6969@10.10.10.182:5060>
Content-Length: 0

这里，我们可以看到，via头域多了一个received及rport有值了，解决nat穿透。。。

同时记住 100 trying没有 sdp信息。。调用顺序，sip_xmit<-send_response<--transmit_response<---transmit_provisional_response<--Handle_request_response.

接下来执行 dialplan.......至此一次呼入系统的请求基本完成。