<html>
<head>
    <base href="https://wiki.asterisk.org/wiki">
            <link rel="stylesheet" href="/wiki/s/2033/1/7/_/styles/combined.css?spaceKey=AST&amp;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/chan_sip+Transaction+Support+Proprosal">chan_sip Transaction Support Proprosal</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://wiki.asterisk.org/wiki/display/~twilson@digium.com">Terry Wilson</a>
    </h4>
        <br/>
                         <h4>Changes (2)</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" >** Connection-oriented protocols (TCP/TLS) <br>** Connectionless protocols (UDP) <br></td></tr>
            <tr><td class="diff-changed-lines" ><span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">*</span> <span class="diff-added-words"style="background-color: #dfd;">**</span> Handle transport layer errors <br></td></tr>
            <tr><td class="diff-unchanged" >* Code should be as self-contained as possible to minimize bug introduction <br>* Possibly should be optional for backward compatibility <br> <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;">h1. What is a transaction layer? <br>SIP is a transactional protocol. A transaction is basically a single request and all of the responses to that request. Essentially, the SIP transaction layer sits between the User Agent core code and the transmission layer. The purpose of the transaction layer is to handle sending retransmissions of messages that have not received a timely response (with some exceptions) and to filter out (most) retransmissions and invalid messages instead of having the UA core code handle them. <br> <br>h1. What does chan_sip currently do instead of using a transaction layer? <br> <br>chan_sip, instead of maintaining a full transaction layer, tries to identify incoming retransmissions and marks them with an &quot;ignore&quot; flag. Then, in every request/response handling function where we think it might be important, we try to handle falling through the code to &quot;do the right thing.&quot; This has led to many, many bugs. Many times we end up trying to reconstruct the same response to a request based on some state that isn&#39;t guaranteed not to have changed. The core code, in most circumstances should not even be aware that a retransmission has been received. <br> <br>For retransmitting messages that chan_sip&#39;s UA code sends, chan_sip relies on the retrans_pkt function which is scheduled to run from sip_reliable_xmit. The retransmission behavior should be dependant upon whether or not the underlying protocol is connection-oriented or not. chan_sip retransmits packets even for TCP. <br> <br>h1. Proposed solution <br> <br>If transaction support is enabled (either by having it be the only option, or by a config option), the &quot;ignore&quot; flag should never be set. The transaction layer code itself can absorb the retransmissions and the legacy code will only receive the &quot;non-ignored&quot; requests and responses. The existing code checking for &quot;ignore&quot; can be cleaned up at leisure without worrying about it causing a problem. <br></td></tr>
            <tr><td class="diff-unchanged" >{numberedheadings} <br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        

<h1><a name="chan_sipTransactionSupportProprosal-Introduction"></a>1. Introduction</h1>
<p>SIP is a transactional protocol. Asterisk's chan_sip has no transaction concept of a transaction layer. Developers have spent countless hours providing workarounds for bugs caused by this situation. In fact, more hours have been spent trying to work around the issue than it would take to actually implement a transaction layer for chan_sip. This document outlines how a transaction layer can be added to chan_sip with a relatively minimal amount of change to existing code.</p>

<h1><a name="chan_sipTransactionSupportProprosal-TableofContents"></a>2. Table of Contents</h1>

<style type='text/css'>/*<![CDATA[*/
div.rbtoc1293996224932 {margin-left: 1.5em;padding: 0px;}
div.rbtoc1293996224932 ul {list-style: disc;margin-left: 0px;padding-left: 20px;}
div.rbtoc1293996224932 li {margin-left: 0px;padding-left: 0px;}

/*]]>*/</style><div class='rbtoc1293996224932'>
<ul>
    <li><a href='#chan_sipTransactionSupportProprosal-Introduction'>1. Introduction</a></li>
    <li><a href='#chan_sipTransactionSupportProprosal-TableofContents'>2. Table of Contents</a></li>
    <li><a href='#chan_sipTransactionSupportProprosal-ProjectRequirements'>3. Project Requirements</a></li>
    <li><a href='#chan_sipTransactionSupportProprosal-Whatisatransactionlayer%3F'>4. What is a transaction layer?</a></li>
    <li><a href='#chan_sipTransactionSupportProprosal-Whatdoeschansipcurrentlydoinsteadofusingatransactionlayer%3F'>5. What does chan_sip currently do instead of using a transaction layer?</a></li>
    <li><a href='#chan_sipTransactionSupportProprosal-Proposedsolution'>6. Proposed solution</a></li>
</ul></div>

<h1><a name="chan_sipTransactionSupportProprosal-ProjectRequirements"></a>3. Project Requirements</h1>

<ul>
        <li>RFC 3261-compliant transactions
        <ul>
                <li>Client/Server INVITE/Non-INVITE transactions</li>
                <li>Connection-oriented protocols (TCP/TLS)</li>
                <li>Connectionless protocols (UDP)</li>
                <li>Handle transport layer errors</li>
        </ul>
        </li>
        <li>Code should be as self-contained as possible to minimize bug introduction</li>
        <li>Possibly should be optional for backward compatibility</li>
</ul>


<h1><a name="chan_sipTransactionSupportProprosal-Whatisatransactionlayer%3F"></a>4. What is a transaction layer?</h1>
<p>SIP is a transactional protocol. A transaction is basically a single request and all of the responses to that request. Essentially, the SIP transaction layer sits between the User Agent core code and the transmission layer. The purpose of the transaction layer is to handle sending retransmissions of messages that have not received a timely response (with some exceptions) and to filter out (most) retransmissions and invalid messages instead of having the UA core code handle them.</p>

<h1><a name="chan_sipTransactionSupportProprosal-Whatdoeschansipcurrentlydoinsteadofusingatransactionlayer%3F"></a>5. What does chan_sip currently do instead of using a transaction layer?</h1>

<p>chan_sip, instead of maintaining a full transaction layer, tries to identify incoming retransmissions and marks them with an "ignore" flag. Then, in every request/response handling function where we think it might be important, we try to handle falling through the code to "do the right thing." This has led to many, many bugs. Many times we end up trying to reconstruct the same response to a request based on some state that isn't guaranteed not to have changed. The core code, in most circumstances should not even be aware that a retransmission has been received.</p>

<p>For retransmitting messages that chan_sip's UA code sends, chan_sip relies on the retrans_pkt function which is scheduled to run from sip_reliable_xmit. The retransmission behavior should be dependant upon whether or not the underlying protocol is connection-oriented or not. chan_sip retransmits packets even for TCP.</p>

<h1><a name="chan_sipTransactionSupportProprosal-Proposedsolution"></a>6. Proposed solution</h1>

<p>If transaction support is enabled (either by having it be the only option, or by a config option), the "ignore" flag should never be set. The transaction layer code itself can absorb the retransmissions and the legacy code will only receive the "non-ignored" requests and responses. The existing code checking for "ignore" can be cleaned up at leisure without worrying about it causing a problem.</p>


    </div>
        <div id="commentsSection" class="wiki-content pageSection">
        <div style="float: right;">
            <a href="https://wiki.asterisk.org/wiki/users/viewnotifications.action" class="grey">Change Notification Preferences</a>
        </div>
        <a href="https://wiki.asterisk.org/wiki/display/AST/chan_sip+Transaction+Support+Proprosal">View Online</a>
        |
        <a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=10649861&revisedVersion=3&originalVersion=2">View Changes</a>
                |
        <a href="https://wiki.asterisk.org/wiki/display/AST/chan_sip+Transaction+Support+Proprosal?showComments=true&amp;showCommentArea=true#addcomment">Add Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>