Asterisk 1.8 sip 协议栈分析

引用自：http://blog.csdn.net/z1623866465/archive/2011/01/02/6113057.aspx

看了一下 asterisk 1.8 ，chan_sip 更新了许多内容，下面结合asterisk 1.4 asterisk 1.6 分析一下sip协议栈。

此笔记为本人学习记录，有些地方描述其他人可能看不懂，望见谅。

分析路线

sipsock_read->parse_request->find_call->handle_inconming->handle_request_方法名。。。。

协议栈初始化：load_module() 函数加载SIP配置信息，解析sip.conf挂载到全局变量中。

     首先初始化user,peer,register全局链表（1.6 版本中已经改为hash存储 估计性能提高不少），这三个链表分别存储用户，peer,register三个实体。

   接下来创建 调度器，IO管理器，这里IO即监听socket fd句柄上的IO事件，chan_sip用poll异步IO实现此功能，io_context 结构封装了此功能。

 创建IO调度器后注册各种app， load_module（）最后调用restart_monitor()函数创建一个线程（do_monitor()）监听sip 端口（5060）上的事件， 在do_monitor()函数中首先将sip socket 句柄添加到之前创建的IO管理器中，同时指定此sip socket句柄上的IO事件对应的回调函数(sipsock_read)，即当监听的sip socket 句柄上有事件发生时调用 sipsocket_read函数，此函数是所有sip包的入口，负责接收监听端口(5060)上的数据包。do_monitor函数接下来，遍历全局sip channle 链表iflock ，遍历的同时 考虑 channle 的重载 （cli reload）, ，挂断那些不符合规则的sip channel,比如 rtp 超时，onhold rtp 超时、释放sip channle 资源(调用sip_destroy()函数), 锁的释放，rtp，vrtp,udps 等 结构的释放。

现在回到 sipsock_read函数：

sipsock_read 函数调用 经典的udp socket 函数 recvfrom（1.8版本中已将这些经典函数封装） 读取网络数据包，保存到buffer中，

 此函数中声明sip_request 结构，此结构如下：

struct sip_request {

ptrdiff_t rlPart1;     
 ptrdiff_t rlPart2;     
 int len;               
 int headers;           
 int method;            
 int lines;             
 unsigned int sdp_start;
 unsigned int sdp_count;
 char debug;            
 char has_to_tag;       
 char ignore;           
 ptrdiff_t header[SIP_MAX_HEADERS];
 ptrdiff_t line[SIP_MAX_LINES];    
 struct ast_str *data; 
 struct ast_str *content;
 
 struct sip_socket socket;         
 AST_LIST_ENTRY(sip_request) next;
};

对于每一个udp数据都作为为是一次请求，此结构封装了sip 协议的消息头，方法，body,及此请求的socket 句柄，保存此次请求数据的data字段，此处只是将sipsock_read读到的数据包保存到sip_request 结构的 data字段，数据包的处理留给 parse_request（）函数处理。

sipsock_read函数接下来调用handle_request_do(&req, &addr); 函数处理此次请求，参数为sip_request 结构及此此数据包的来源。

handle_request_do(&req, &addr) 函数内部首先 对 pedanticsipchecking 处理，此处解释一下 pedanticsipchecking

pedanticsipchecking 为sip.conf文件的一个配置选项，表示是否开启将多个请求头放在一个请求头里的情况，我们知道sip消息由若干个消息头（from, to,contact 等）组成，每个请求头部用\r\n分隔，但是有些情况下所有sip轻轻头放在一个轻轻头部，而没有用\r\n分隔，所以当pedanticsipchecking 设置为yes时handle_request_do 会调用lws2sws函数处理此种情况，如果不显示设置pedanticsipchecking  为no，貌似1.8中默认为yes了，如果将sip debug打开，

if (req->debug) {
  ast_verbose("\n<--- SIP read from %s:%s --->\n%s\n<------------->\n",
   get_transport(req->socket.type), ast_sockaddr_stringify(addr), req->data->str);
 }

此处应该可以看到数据包的内容，在我的平台上

注册消息 在handle_request_do 内部打印内容如下：

<--- SIP read from UDP:10.10.10.84:51126 --->
REGISTER sip:10.10.10.182 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.84:51126;branch=z9hG4bK-d87543-b525b54eb12a8030-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:15011599734@10.10.10.84:51126;rinstance=aa35be9f21f51771>
To: "15011599734"<sip:15011599734@10.10.10.182>
From: "15011599734"<sip:15011599734@10.10.10.182>;tag=dc3d5677
Call-ID: OWIyMWViOThiZjQ3YmEwNTFhNzg3YzA1M2Q3ZTRhMDM.
CSeq: 1 REGISTER
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
User-Agent: X-Lite release 1011s stamp 41150
Content-Length: 0

handle_request_do 函数接下来调用parse_request（）函数正式解析数据包为rfc3261规定的sip格式，同时根据rfc3261定义做sip 包的额外检查，parse_request（） 即解析进来的数据包也解析系统发出的数据包。

parse_request（） 函数内部按CRLF 解析数据包(res->data),rfc3261规定SIP消息头与消息体（一般为sdp,presens或im时 为xml数据）之间要用一个空行来分隔，对于一个PUBLISH请求具体形式 如下：

<--- SIP read from UDP:10.10.10.84:51126 --->
PUBLISH sip:15011599734@10.10.10.182 SIP/2.0
Via: SIP/2.0/UDP 10.10.10.84:51126;branch=z9hG4bK-d87543-3d691e75b7321d47-1--d87543-;rport
Max-Forwards: 70
Contact: <sip:15011599734@10.10.10.84:51126>
To: "15011599734"<sip:15011599734@10.10.10.182>
From: "15011599734"<sip:15011599734@10.10.10.182>;tag=20557655
Call-ID: YWQ1OTg4ZDg2MGFiMGUwMDk5YjI1NTYzMzQwNTc4Y2I.
CSeq: 1 PUBLISH
Expires: 3600
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, NOTIFY, MESSAGE, SUBSCRIBE, INFO
Content-Type: application/pidf+xml
User-Agent: X-Lite release 1011s stamp 41150
Event: presence
Content-Length: 463

<?xml version='1.0' encoding='UTF-8'?><presence xmlns='urn:ietf:params:xml:ns:pidf' xmlns:dm='urn:ietf:params:xml:ns:pidf:data-model' xmlns:rpid='urn:ietf:params:xml:ns:pidf:rpid' xmlns:c='urn:ietf:params:xml:ns:pidf:cipid' entity='sip:15011599734@10.10.10.182'><tuple id='t733b0f62'><status><basic>open</basic></status></tuple><dm:person id='p0725b86e'><rpid:activities><rpid:on-the-phone/></rpid:activities><dm:note>On the Phone</dm:note></dm:person></presence>
<------------->

加黑部分为消息头，下面为消息体，此处为软电话的presence 携带状态消息，<status><basic>open</basic></status> ，表示当前在线。可以看到消息头与消息体有一行空格分隔。parse_request（）函数接下来会计算消息头数量以及消息体行数，然后保存到sip_request结构的 req->headers属性及req->req->lines属性上，最后parse_request（）调用determine_firstline_parts（）从sip 消息的第一个头域解析出  方法名、协议版本、及请求地址赋值给req->rlPart1及req->rlPart2属性，同时还会对sip消息的态码验证是否为三位，协议版本是否为SIP/2.0，不符合协议要求则返回错误。

现在返回到 handle_request_do()函数，调用parse_request返回后，调用find_sip_method 解析sip_request的rlpart1属性找出方法名字，解析包结束后从debug消息可以输出消息头及消息体的行数

if (req->debug)
  ast_verbose("--- (%d headers %d lines)%s ---\n", req->headers, req->lines, (req->headers + req->lines == 0) ? " Nat keepalive" : "");

--- (14 headers 1 lines) ---

正常的sip消息头至少两行，所以这里同样做了验证，接下来调用find_call （），此函数的作用为查找此请求的 CALL-ID，如果没找到则创建之，我们知道sip协议里有两个重要概念 会话及事务，会话是一路通话的唯一标识，会话用CALL-ID及from，to tag标示，事务是会话过程中某一请求及与此请求对应的效应的标识，可以认为会话包含事务，因为一路通话可能包含很多请求。

下面我们来看find_call（），对于第一次进入系统则call-ID不存在，所以find_call会创建此会话，如果请求的CALL-ID在系统中存在，则将此请求与存在的会话对接。

首先 find_call 从此次请求的sip包中解析出call-ID, From, to,Cseq 头域，实际上rfc3261要求每个sip包至少还要包含Max-forwoards及VIa 头域，但 chan_sip似乎没对上面两项验证，这里如果验证不通过则发 400 bad request 响应。

 原则上讲 CALL-ID 唯一标识一路通话，但是在一些代理服务器fork 时候 由于CAll-ID相同，所以要用to,from tag 唯一标识，如果有这种情况我们应该在sip。conf文件中打开pedanticsipchecking 选项 为 yes时 find_call只是根据 CALL-ID查找是否存在，为no时根据call-id,to,from tog 查找 会话是否存在，协议要求所有sip消息一定有from tag, 同时，ACK, BYE消息一定要有to tag, 否则 sip 消息会被丢弃。对于from。to, tag 的解释 有一点很重要，即在响应消息中，响应者不会将 from 及to 调换，因为to,from头域用来提示请求的方向而不是消息的流向，比如 bob 发请求给tom，那么所有响应中的from为bob,to域为tom.

find_call 找到会话后会直接返回此会话的channle, 否则创建sip_pvt 结构并返回。1.4 版本中查找会话方式是用过遍历会话链表，而1.6及1.8中已经替换为 hash方式，性能应该提高很多。

如果没找到会话则创建 channle, 创建时会 考虑 哪些方法支持 创建channel,这里 ACK，PRACK,BYE，INFO,CANCEL,update方法是不可创建channle的，我们知道这些方法都是在会话已经存在时可用。如果方法不能创建会话则会响应协议本身不支持方法，返回 501 Mothed not implement, 500 server internal error.

这里创建sip channel 结构 sip_pvt，此结构对应一路会话的所有信息，包括 注册，协商，呼叫。

通过 sip_alloc（）创建sip_pvt结构，并将其 添加进全局会话链表 dialloglist。

下面 来分析 sip_alloc ： 此函数的参数为 call-id, 前面初始化的sip_request结构，以及方法，

首先调用ao2_t_alloc 申请 对象sip_pvt内存，同时指定 垃圾回收回调函数（1.6,1.8 新增），

 这里1.8增加了 CCSS Call complete supplementary services ，所以分配 ccss结构。

如果此回话为请求会话，则存储 请求的参数到sip_pvt属性中。包括Cseq,及branch,这里sip协议要求所有branch要以.z9hG4bK 开始，

接下来给sip_pvt 属性赋值，包括 transport type, 此会话的默认 编码（全局配置），max_forwords 最大跳数(全局默认)，

sip  事务 定时器（全局 timer_t1），sip 消息转发定时器(全局配置 timer_b), 此消息客户端 ip地址（），如果轻轻地客户端地址为 空则拷贝默认地址（全局配置），否则将客户端地址赋值给p->ourip, 如果sip 方法支持 rtp则设置 比特率（一般码率越高质量越高，录音文件越大），这里sip_alloc有个参数 useglobal_nat，传进来时为1，涉及到nat穿透问题，表示 强迫 rport，即使请求中没有 rport （via 头域），接下来调用do_setnat（p）rtp, vrtp,udpl 的nat 模式是否开启，设置 关于nat 穿透及rport解释 参考另一篇文章 SIP通过NAT的实例解析，接下来设置 FROm 头域中的 域名（全局默认），然后调用built_via 构造via头域p->via，

接下来设置默认等待音乐，是否支持转移(allowtransfer)，编码转换（capability），context,，默认的parklot, 最后 sip_alloc 函数调用工具函数ao2_t_link 把创建的会话插入 全局会话容器（1.4为链表）dialogs。同时把此请求放到请求队列中。

 find_call 结束，返回handle_request_do, 在find_call中将请求放入请求队列，返回后此处调用process_request_queue处理此会上上的所有请求，下面来看process_request_queue内部做了什么，此函数不断遍历sip_pvt 属性 request_queue链表，从链表头取出一个请求，然后调用 Handle_incoming 处理 请求,开开sip debug,

ast_debug(4, "**** Received %s (%d) - Command in SIP %s\n", sip_methods[p->method].text, sip_methods[p->method].id, cmd);

对于 注册请求输出如下：

Dec 16 14:06:58] DEBUG[17316]: chan_sip.c:23539 handle_incoming: **** Received REGISTER (2) - Command in SIP REGISTER

Handle_incoming 是所有sip 请求的毕经入口，下面看看内部做了什么，首先检查sequence 是否正确，从请求头中找出User-Agent 保存客户端，接下来 分析 此次请求的 方法， 根据不同的方法调用Handle_request_方法名 具体处理请求, 包含如下一些 方法的处理函数。

 
 switch (p->method) {
 case SIP_OPTIONS:
  res = handle_request_options(p, req, addr, e);
  break;
 case SIP_INVITE:
  res = handle_request_invite(p, req, debug, seqno, addr, recount, e, nounlock);
  break;
 case SIP_REFER:
  res = handle_request_refer(p, req, debug, seqno, nounlock);
  break;
 case SIP_CANCEL:
  res = handle_request_cancel(p, req);
  break;
 case SIP_BYE:
  res = handle_request_bye(p, req);
  break;
 case SIP_MESSAGE:
  res = handle_request_message(p, req);
  break;
 case SIP_PUBLISH:
  res = handle_request_publish(p, req, addr, seqno, e);
  break;
 case SIP_SUBSCRIBE:
  res = handle_request_subscribe(p, req, addr, seqno, e);
  break;
 case SIP_REGISTER:
  res = handle_request_register(p, req, addr, e);
  break;
 case SIP_INFO:
  if (req->debug)
   ast_verbose("Receiving INFO!\n");
  if (!req->ignore)
   handle_request_info(p, req);
  else 
   transmit_response(p, "200 OK", req);
  break;
 case SIP_NOTIFY:
  res = handle_request_notify(p, req, addr, seqno, e);
  break;
 case SIP_UPDATE:
  res = handle_request_update(p, req);
  break;
 case SIP_ACK:
 
  if (seqno == p->pendinginvite) {
   p->invitestate = INV_TERMINATED;
   p->pendinginvite = 0;
   acked = __sip_ack(p, seqno, 1 , 0);
   if (find_sdp(req)) {
    if (process_sdp(p, req, SDP_T38_NONE))
     return -1;
   }
   check_pendings(p);
  } else if (p->glareinvite == seqno) {
  
   p->glareinvite = 0;
   acked = __sip_ack(p, seqno, 1, 0);
  }
  if (!acked) {
  
   p->method = oldmethod;
  }
  if (!p->lastinvite && ast_strlen_zero(p->randdata)) {
   pvt_set_needdestroy(p, "unmatched ACK");
  }
  break;
 default:
  transmit_response_with_allow(p, "501 Method Not Implemented", req, 0);
  ast_log(LOG_NOTICE, "Unknown SIP command '%s' from '%s'\n",
   cmd, ast_sockaddr_stringify(&p->sa));
 
  if (!p->initreq.headers) {
   pvt_set_needdestroy(p, "unimplemented method");
  }
  break;
 }

 下面分析  当请求方法为 register时handle_request_register做了什么。。。

路线：

handle_request_register-->register_verify->find_peer()->check_auth()->parse_register_contact()->transmit_response_with_date().

 首先，调用copy_request 复制此请求到p->inireq中，此属性表明此次请求为一个已经存在的对话的请求，而不是新创建的会话的请求，

 主要用来做 未来的响应消息 调用（p->inireq），接下来handle_request_register 调用 register_verify

 
static enum check_auth_result register_verify(struct sip_pvt *p, struct ast_sockaddr *addr,
           struct sip_request *req, const char *uri)

 调用parse_uri从请求头中取出 To 头域，解析 To头域的请求 URI，分解出域名，用户名，然后设置分机号码 为用户名，

调用build_contact 构造 constact 域，然后根据分机号码调用 find_peer ，查看是否已存在，find_peer可以根据ip地址及分机号码查找peer，此处注册时根据分机号码查找，比我我想注册号码 1234到 服务器10.10.10.134，则查找1234，需要注意的是此函数可能查数据库(用 realtime时)，当然了，第一次注册肯定找不到，所以为了简化我们不过多讨论。

根据 find_peer返回结果 会做不同处理：

1：找到peer ，但没有设置为 host=dynamic 则返回AUTH_PEER_NOT_DYNAMIC，如果设置host=dynamic ，则接下来会调用

 check_auth做验证，如果transport 错误则返回403 forbidden,  验证成功则 根据此次注册请求更新peer（因为找到peer所以已经认证，此时只更新peer）,调用parse_register_contact 解析 contact头域做更新动作 根据不同结果 调用transmit_response_with_date 做响应,这里，当响应是200ok时把contact域的地址换成了received地址，同时，当不指定强制使用rport 端口时会根据contact uri中的域名解析ip地址及端口号，如果在 请求的uri中有端口号则不会做域名解析，同时根据transport 类型指定 端口，当为uri时端口为5060，uris时5061，

在不用请求的uri中的端口时 直接将rport端口指定到contact uri的端口上，这一点对于sip nat穿透很重要。

接下来parse_register函数验证此peer的IP地址是否为sip.conf里面配置的禁止注册ip地址，这点可以防止注册攻击，

接下来把此peer的ip地址放入peers_by_ip全局链表中，以便以后通过ip地址查找此peer, 接下来处理此peer的存活时间，如果是realtime peer且开启 catche 功能(sip.conf配置)，则增加此peer的存活时间。

peer->expire = ast_sched_add(sched, (expire + 10) * 1000, expire_register,
    ref_peer(peer, "add registration ref"));

同时指定 回调函数 expire_register，当peer存活时间到期时调用它来销毁peer,这里（expire_register）又调用destroy_association 从数据库或ast_db中删除 peer注册信息，首先，destroy_association  调用int realtimeregs = ast_check_realtime("sipregs"); 返回是否存在sipregs表，不存在则指定为sippeers表，接下来又有一个特殊情况，即当sip。conf中配置了 ignor_regexpire（即不考虑peer存活时间）时，此函数不会删除peer注册信息，同时，如果开启了 rtupdate(sip.conf)选项，则只是用peer的注册信息更新数据库内容。除了以上情况，则调用 ast_db_del("SIP/Registry", peer->name);
   ast_db_del("SIP/PeerMethods", peer->name); 删除peer信息。

同时peer信息会从内存中被删除，包括realtime peer.

下面返回注册成功信息，

注册成功则将peer信息放到ast_db中，。parse_register_contact函数接下来调用sip_poke_peer 判断peer的可达性，保持nat开启，然后调用register_peer_exten 把peer分机号加入dialplan中。

最后返回到 register_verify函数调用 transmit_response_with_date对此次请求做响应。

2：没找到peer且sip.conf文件中autocreatpeer选项开启（如果没找到peer ，则自动创建peer,默认配置为 no），

  

根据 分机号码 （exten）创建peer结构，连接到 全局链表peers中，

 注意 此处如果是注册更新则会触发ami 事件 PeerStatus

manager_event(EVENT_FLAG_SYSTEM, "PeerStatus", "ChannelType: SIP\r\nPeer: SIP/%s\r\nPeerStatus: Registered\r\nAddress: %s\r\n", peer->name, ast_sockaddr_stringify(addr));

3： 没找到peer,sip.conf中 alwaysauthreject 开启(请求失败发 401 未认证响应)

 

 

 

 

从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
 
 
  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; 
   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啦。。。。

  if (find_sdp(req)) {

if (process_sdp(p, req, SDP_T38_INITIATE)) {
   
    if (!ast_strlen_zero(get_header(req, "Content-Encoding"))) {
     transmit_response_reliable(p, "415 Unsupported Media type", req);
    } else {
    
     transmit_response_reliable(p, "488 Not acceptable here", req);
    }

。。。。

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

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

static int find_sdp(struct sip_request *req)

此处当然是找到了。。

调用 process_sdp 处理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()

  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 (!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个。

 ast_channel_set_fd(tmp, AST_ALERT_FD, tmp->alertpipe[0]);
 
 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.......至此 一次呼入系统的请求 基本完成