<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">New SIP channel driver</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~mmichelson">Mark Michelson</a>
</h4>
<br/>
<h4>Changes (2)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-changed-lines" ><span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">stub</span> <span class="diff-added-words"style="background-color: #dfd;">{warning}</span> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">This page is currently under construction. <br>{warning} <br> <br>{toc:maxlevel=3} <br> <br>h1. Project Overview <br> <br>This project's aim is to create a new SIP channel driver to be included in Asterisk 12. <br> <br>Asterisk's current SIP channel driver (hereon referred to as "chan_sip") basically has the flaw of being poorly architected. <br> <br>* The code is not arranged in a stack. Attempting to add elements such as a new transport or other new feature means touching the code in places you would never expect to have to touch. <br>* chan_sip is monolithic; all aspects of SIP reside in the channel driver. Attempting to have a SIP registrar that does not accept calls is not easy. <br>* Fixing bugs in chan_sip is rarely straightforward. Changing code in order to fix one bug usually leads to new faults being discovered as a result. <br>* Many limitations are deeply-ingrained in chan_sip. For instance, trying to change chan_sip to support binding to multiple addresses would require huge changes. <br> <br>As of 1 November, 2012, chan_sip issues occupy 24% of the issue tracker <br>{note} <br>GET STATS FROM JIRA ABOUT ISSUE COUNT, ETC. <br>{note} <br> <br>The issue count in JIRA should go a long way in showing the difficulty Asterisk developers have in maintaining chan_sip. <br> <br>Asterisk developers have on several occasions attempted projects to give chan_sip a transaction layer, or to give it some semblance of a refactor. In every case, they've reported that the effort that it would take in order to do whatever task they were doing would be better spent in rewriting chan_sip altogether. <br> <br>h1. Requirements and Specification <br> <br>h3. SIP stack <br> <br>The new chan_sip will use a third-party SIP stack. Research is currently being done into various offerings. SIP stack research can be found at <br>{note} <br>Insert SIP stack research link here <br>{note} <br> <br>h3. Configuration <br> <br>Configuration for the new chan_sip will be redesigned entirely. Configuration will be more modular, allowing easier control over aspects than previously allowed. At the same time, the new chan_sip MUST be backwards-compatible with the old chan_sip's configuration to ease upgrade. The tentative plan for this is to parse old configuration and translate the options into their new equivalents where possible. <br> <br>h3. Features <br> <br>h3. Testing <br> <br>h3. Documentation <br> <br>The purpose of this section is to provide the minimum requirements the project must fulfill. This can take several forms depending on the project; project developers should choose the schemes that best fit the project they are developing. This section should also provide details about the project from an end-user perspective. This can include dialplan configuration, sample configuration files, API descriptions, etc. <br> <br>If needed, break this section up into multiple subsections. Several subsection examples are provided below; feel free to use/remove these as your project dictates. <br> <br>{info} <br>If sufficiently complex, subpages should be used to provide reference information. In particular, sufficiently large configuration schemas and detailed API descriptions may benefit from their own subpage. <br>{info} <br> <br>h2. Use Cases <br> <br>Assuming a use case approach is used, the following can be used as a model. <br> <br>h3. Use Case: Bob calls Alice <br> <br>Actor: Alice <br>Actor: Bob <br> <br>Scenario: <br>* Bob picks up his phone. He dials Alice's extension. <br>* Bob hears a ringing indication. <br>* Alice's phone rings. <br>* Alice picks up her phone. <br>* Both Bob and Alice's phones stop ringing. <br>* Both Bob and Alice can talk to each other and hear the other person. <br> <br>h2. User Stories <br> <br>Assuming a user story approach is used, the following can be used as a model. <br> <br>* As a user of a SIP phone, I want to be able to pick up my SIP phone, dial an extension, and hear a ringing indication while I wait for the other phone to be picked up. <br>* As a user of a SIP phone, I want to be able to speak with another user using a SIP phone if they answer when I call them. <br> <br>h2. Configuration <br> <br>h3. project.conf <br> <br>h4. \[general\] <br> <br>|| Parameter || Description || Type || Default Value || <br>| foo | Turns feature foo on or off | Boolean | True | <br>| bar | A comma delineated list of bar items (pun intended?) | String | | <br> <br>h3. RealTime schemas <br> <br>h2. APIs <br> <br>Add an entry for each Application, Function, AMI command, AMI event, AGI command, CLI command, or other external way of interacting with the features provided by the project. Different APIs require different sets of documentation; in general, sufficient documentation should be provided to create the standard XML documentation for that particular item. <br> <br>h1. Design <br> <br>For sufficiently complex projects, a high level design may be needed to illustrate how the project plugs into the overall Asterisk architecture. Sufficiently detailed design of the project should be provided such that newcomers to the Asterisk project are provided a conceptual view of the construction of the implementation. <br> <br>Note that the design should be independent of the implementation, i.e., if the code is not drastically changed, it should not require updates to this section. <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 currently under construction.</td></tr></table></div>
<div>
<ul>
<li><a href='#NewSIPchanneldriver-ProjectOverview'>Project Overview</a></li>
<li><a href='#NewSIPchanneldriver-RequirementsandSpecification'>Requirements and Specification</a></li>
<ul>
<ul>
<li><a href='#NewSIPchanneldriver-SIPstack'>SIP stack</a></li>
<li><a href='#NewSIPchanneldriver-Configuration'>Configuration</a></li>
<li><a href='#NewSIPchanneldriver-Features'>Features</a></li>
<li><a href='#NewSIPchanneldriver-Testing'>Testing</a></li>
<li><a href='#NewSIPchanneldriver-Documentation'>Documentation</a></li>
</ul>
<li><a href='#NewSIPchanneldriver-UseCases'>Use Cases</a></li>
<ul>
<li><a href='#NewSIPchanneldriver-UseCase%3ABobcallsAlice'>Use Case: Bob calls Alice</a></li>
</ul>
<li><a href='#NewSIPchanneldriver-UserStories'>User Stories</a></li>
<li><a href='#NewSIPchanneldriver-Configuration'>Configuration</a></li>
<ul>
<li><a href='#NewSIPchanneldriver-project.conf'>project.conf</a></li>
<li><a href='#NewSIPchanneldriver-RealTimeschemas'>RealTime schemas</a></li>
</ul>
<li><a href='#NewSIPchanneldriver-APIs'>APIs</a></li>
</ul>
<li><a href='#NewSIPchanneldriver-Design'>Design</a></li>
</ul></div>
<h1><a name="NewSIPchanneldriver-ProjectOverview"></a>Project Overview</h1>
<p>This project's aim is to create a new SIP channel driver to be included in Asterisk 12.</p>
<p>Asterisk's current SIP channel driver (hereon referred to as "chan_sip") basically has the flaw of being poorly architected.</p>
<ul>
<li>The code is not arranged in a stack. Attempting to add elements such as a new transport or other new feature means touching the code in places you would never expect to have to touch.</li>
<li>chan_sip is monolithic; all aspects of SIP reside in the channel driver. Attempting to have a SIP registrar that does not accept calls is not easy.</li>
<li>Fixing bugs in chan_sip is rarely straightforward. Changing code in order to fix one bug usually leads to new faults being discovered as a result.</li>
<li>Many limitations are deeply-ingrained in chan_sip. For instance, trying to change chan_sip to support binding to multiple addresses would require huge changes.</li>
</ul>
<p>As of 1 November, 2012, chan_sip issues occupy 24% of the issue tracker</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>GET STATS FROM JIRA ABOUT ISSUE COUNT, ETC.</td></tr></table></div>
<p>The issue count in JIRA should go a long way in showing the difficulty Asterisk developers have in maintaining chan_sip.</p>
<p>Asterisk developers have on several occasions attempted projects to give chan_sip a transaction layer, or to give it some semblance of a refactor. In every case, they've reported that the effort that it would take in order to do whatever task they were doing would be better spent in rewriting chan_sip altogether.</p>
<h1><a name="NewSIPchanneldriver-RequirementsandSpecification"></a>Requirements and Specification</h1>
<h3><a name="NewSIPchanneldriver-SIPstack"></a>SIP stack</h3>
<p>The new chan_sip will use a third-party SIP stack. Research is currently being done into various offerings. SIP stack research can be found at</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Insert SIP stack research link here</td></tr></table></div>
<h3><a name="NewSIPchanneldriver-Configuration"></a>Configuration</h3>
<p>Configuration for the new chan_sip will be redesigned entirely. Configuration will be more modular, allowing easier control over aspects than previously allowed. At the same time, the new chan_sip MUST be backwards-compatible with the old chan_sip's configuration to ease upgrade. The tentative plan for this is to parse old configuration and translate the options into their new equivalents where possible.</p>
<h3><a name="NewSIPchanneldriver-Features"></a>Features</h3>
<h3><a name="NewSIPchanneldriver-Testing"></a>Testing</h3>
<h3><a name="NewSIPchanneldriver-Documentation"></a>Documentation</h3>
<p>The purpose of this section is to provide the minimum requirements the project must fulfill. This can take several forms depending on the project; project developers should choose the schemes that best fit the project they are developing. This section should also provide details about the project from an end-user perspective. This can include dialplan configuration, sample configuration files, API descriptions, etc.</p>
<p>If needed, break this section up into multiple subsections. Several subsection examples are provided below; feel free to use/remove these as your project dictates.</p>
<div class='panelMacro'><table class='infoMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/information.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>If sufficiently complex, subpages should be used to provide reference information. In particular, sufficiently large configuration schemas and detailed API descriptions may benefit from their own subpage.</td></tr></table></div>
<h2><a name="NewSIPchanneldriver-UseCases"></a>Use Cases</h2>
<p>Assuming a use case approach is used, the following can be used as a model.</p>
<h3><a name="NewSIPchanneldriver-UseCase%3ABobcallsAlice"></a>Use Case: Bob calls Alice</h3>
<p>Actor: Alice<br/>
Actor: Bob</p>
<p>Scenario:</p>
<ul>
<li>Bob picks up his phone. He dials Alice's extension.</li>
<li>Bob hears a ringing indication.</li>
<li>Alice's phone rings.</li>
<li>Alice picks up her phone.</li>
<li>Both Bob and Alice's phones stop ringing.</li>
<li>Both Bob and Alice can talk to each other and hear the other person.</li>
</ul>
<h2><a name="NewSIPchanneldriver-UserStories"></a>User Stories</h2>
<p>Assuming a user story approach is used, the following can be used as a model.</p>
<ul>
<li>As a user of a SIP phone, I want to be able to pick up my SIP phone, dial an extension, and hear a ringing indication while I wait for the other phone to be picked up.</li>
<li>As a user of a SIP phone, I want to be able to speak with another user using a SIP phone if they answer when I call them.</li>
</ul>
<h2><a name="NewSIPchanneldriver-Configuration"></a>Configuration</h2>
<h3><a name="NewSIPchanneldriver-project.conf"></a>project.conf</h3>
<h4><a name="NewSIPchanneldriver-%5Cgeneral%5C"></a>[general]</h4>
<div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Parameter </th>
<th class='confluenceTh'> Description </th>
<th class='confluenceTh'> Type </th>
<th class='confluenceTh'> Default Value </th>
</tr>
<tr>
<td class='confluenceTd'> foo </td>
<td class='confluenceTd'> Turns feature foo on or off </td>
<td class='confluenceTd'> Boolean </td>
<td class='confluenceTd'> True </td>
</tr>
<tr>
<td class='confluenceTd'> bar </td>
<td class='confluenceTd'> A comma delineated list of bar items (pun intended?) </td>
<td class='confluenceTd'> String </td>
<td class='confluenceTd'> </td>
</tr>
</tbody></table>
</div>
<h3><a name="NewSIPchanneldriver-RealTimeschemas"></a>RealTime schemas</h3>
<h2><a name="NewSIPchanneldriver-APIs"></a>APIs</h2>
<p>Add an entry for each Application, Function, AMI command, AMI event, AGI command, CLI command, or other external way of interacting with the features provided by the project. Different APIs require different sets of documentation; in general, sufficient documentation should be provided to create the standard XML documentation for that particular item.</p>
<h1><a name="NewSIPchanneldriver-Design"></a>Design</h1>
<p>For sufficiently complex projects, a high level design may be needed to illustrate how the project plugs into the overall Asterisk architecture. Sufficiently detailed design of the project should be provided such that newcomers to the Asterisk project are provided a conceptual view of the construction of the implementation.</p>
<p>Note that the design should be independent of the implementation, i.e., if the code is not drastically changed, it should not require updates to this section.</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">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=21464232&revisedVersion=2&originalVersion=1">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/New+SIP+channel+driver?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>