<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/New+SIP+Channel+Driver+Architecture">New SIP Channel Driver Architecture</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mmichelson">Mark Michelson</a>
</h4>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" > <br>{gliffy:name=new_chan_sip_design|version=3} <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;"> <br>h1. Transport <br> <br>This is straightforward. Each transport will be treated separately. The necessary transports when the new channel driver is created will be TCP, TLS, UDP, and Websocket. The transports may or may not be handled by the SIP stack itself. <br> <br>h1. Protocol conversion <br> <br>This is where Asterisk's main interaction with the third-party SIP stack will occur. A {{res_sip}} module will be defined in order to provide APIs for the upper layers of the architecture to use. The SIP operations will be application-agnostic. Concepts such as "media sessions" and "registrations" have no business here. <br> <br>h1. Message Interception <br> <br>This is an interesting piece. Before doing any application-specific parsing of SIP messages, there are some things that can be accomplished. For instance, logging the SIP message can be done here. In addition, transport-related security framework items can be placed at this layer. Authentication can also happen here since authentication is a global concept that does not pertain to individual SIP applications. <br> <br>h1. Application <br> <br>This is where specific SIP applications would find their home, as well as application-specific APIs. Each application should live separately from others as much as possible. There should be no need for the registrar to need to use any logic provided by the channel driver, for instance. <br> <br>An explanation for servants: servants are essentially the workhorses for specific operations. In the diagram, they live directly below an API definition. So for instance, the channel driver implementation would provide the necessary channel technology callbacks but would immediately send the work off to a channel driver servant to perform the work. Doing this allows for quick dispatching of work into an appropriate thread. <br> <br>h1. Asterisk Integration <br> <br>This is the Asterisk core. Parts of the core already exist, such as the messaging core and the channel core. A new piece is the data access layer. The data access layer is a layer where persistent information can be stored and retrieved. This allows for different configuration backends to be able to store data into a common layer, and it allows for the SIP modules to access the data without having to know where the data originated from. <br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>This page is under construction. Please refrain from adding comments until a draft has been completed</td></tr></table></div>
<p>A proposed architecture for the new SIP channel driver architecture is below.</p>
<table width="100%">
<tr>
<td >
<table>
<caption align="bottom">
</caption>
<tr>
<td>
<img style="border: none; width: 800px;"
usemap="#gliffy-map-21758067-3165"
src="/wiki/download/attachments/21464468/new_chan_sip_design.png?version=3&modificationDate=1353020914898"
alt=""/>
</td>
</tr>
</table>
</td>
</tr>
</table>
<h1><a name="NewSIPChannelDriverArchitecture-Transport"></a>Transport</h1>
<p>This is straightforward. Each transport will be treated separately. The necessary transports when the new channel driver is created will be TCP, TLS, UDP, and Websocket. The transports may or may not be handled by the SIP stack itself.</p>
<h1><a name="NewSIPChannelDriverArchitecture-Protocolconversion"></a>Protocol conversion</h1>
<p>This is where Asterisk's main interaction with the third-party SIP stack will occur. A <tt>res_sip</tt> module will be defined in order to provide APIs for the upper layers of the architecture to use. The SIP operations will be application-agnostic. Concepts such as "media sessions" and "registrations" have no business here.</p>
<h1><a name="NewSIPChannelDriverArchitecture-MessageInterception"></a>Message Interception</h1>
<p>This is an interesting piece. Before doing any application-specific parsing of SIP messages, there are some things that can be accomplished. For instance, logging the SIP message can be done here. In addition, transport-related security framework items can be placed at this layer. Authentication can also happen here since authentication is a global concept that does not pertain to individual SIP applications.</p>
<h1><a name="NewSIPChannelDriverArchitecture-Application"></a>Application</h1>
<p>This is where specific SIP applications would find their home, as well as application-specific APIs. Each application should live separately from others as much as possible. There should be no need for the registrar to need to use any logic provided by the channel driver, for instance.</p>
<p>An explanation for servants: servants are essentially the workhorses for specific operations. In the diagram, they live directly below an API definition. So for instance, the channel driver implementation would provide the necessary channel technology callbacks but would immediately send the work off to a channel driver servant to perform the work. Doing this allows for quick dispatching of work into an appropriate thread.</p>
<h1><a name="NewSIPChannelDriverArchitecture-AsteriskIntegration"></a>Asterisk Integration</h1>
<p>This is the Asterisk core. Parts of the core already exist, such as the messaging core and the channel core. A new piece is the data access layer. The data access layer is a layer where persistent information can be stored and retrieved. This allows for different configuration backends to be able to store data into a common layer, and it allows for the SIP modules to access the data without having to know where the data originated from.</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/New+SIP+Channel+Driver+Architecture">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=21464468&revisedVersion=6&originalVersion=5">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/New+SIP+Channel+Driver+Architecture?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>