<html>
<head>
    <base href="https://wiki.asterisk.org/wiki">
            <link rel="stylesheet" href="/wiki/s/2042/1/7/_/styles/combined.css?spaceKey=TOP&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/TOP/SIP+Registrar">SIP Registrar</a></h2>
    <h4>Page <b>edited</b> by             <a href="https://wiki.asterisk.org/wiki/display/~khunt">Ken Hunt</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>     * Add a new listener to the registrar. The listener will <br></td></tr>
            <tr><td class="diff-changed-lines" >* <span class="diff-deleted-words"style="color:#999;background-color:#fdd;text-decoration:line-through;">will</span> receive all known AoRs and their bindings through <br></td></tr>
            <tr><td class="diff-unchanged" >     * its &#39;contactsAdded&#39; operation. <br>     */ <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="SIPRegistrar-Registrar%27sDuties"></a>Registrar's Duties</h1>

<p>The SIP registrar's job is to maintain a mapping of addresses-of-record (AoRs) to contact URIs. The registrar is responsible for letting other SIP services within a cluster know of updates to these mappings. The registrar populates these mappings by processing and responding to SIP REGISTER requests it receives.</p>

<h1><a name="SIPRegistrar-Endpoints"></a>Endpoints</h1>

<p>SIP endpoints will be configured to determine which AoRs they are associated with. For instance, if a SIP endpoint named "Bob" were to be configured to be associated with the AoR "sip:bob@example.com" then this would imply the following things:</p>

<ol>
        <li>REGISTER requests from Bob would be permitted to add and remove bindings for the AoR sip:bob@example.com</li>
        <li>SIP Requests targeted at sip:bob@example.com would be targeted for Bob.</li>
</ol>


<p>An endpoint may be associated with multiple AoRs and multiple endpoints may be associated with the same AoR. The association between endpoints and AoRs, however, is not known to the Registrar; this association exists only in the SIP components that use the Registrar's services. As a result, decisions about whether an incoming REGISTER request should be permitted to modify the mappings or not (authorization), or even whether an incoming REGISTER request must be authenticated, will fall to components outside the Registrar. The Registrar will offer Extension Points where Hooks can be attached to implement these policies as needed.</p>

<h1><a name="SIPRegistrar-Registrationdata"></a>Registration data</h1>

<p>A binding in the Registrar is a single contact URI that is bound to an AoR. An AoR may have multiple bindings associated with it, and a single REGISTER message may create multiple bindings for a single AoR.</p>

<p>The <tt>Binding</tt> object is defined in Slice since the registrar's state will need to be replicated.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<script type="syntaxhighlighter" class="toolbar: false; theme: Confluence; brush: java; gutter: false"><![CDATA[
class Binding
{
    /**
     * The contact URI associated with this particular Binding.
     */
    string contact;
    /**
     * The Call-ID from the latest successful Binding.
     */
    string callid;
    /**
     * The CSeq from the latest successful Binding.
     */
    int cseq;
    /**
     * A UNIX timestamp indicating when the Binding is set
     * to expire
     */
    int expiration;
};

sequence&lt;Binding&gt; BindingSeq;

dictionary&lt;string, BindingSeq&gt; BindingDict;

]]></script>
</div></div>

<p>The <tt>BindingDict</tt> object represents all the state data that needs to be replicated between registrar instances. Individual registrars will be responsible for scheduling destruction of their local <tt>Bindings</tt> based on the binding's expiration.</p>

<p>The <tt>BindingDict</tt> is the set of all bindings currently known to the Registrar; the <tt>string</tt> key is the AoR, and the <tt>BindingSeq</tt> is the list of Contact URIs currently bound to that AoR.</p>

<h1><a name="SIPRegistrar-Interfaces"></a>Interfaces</h1>

<p>The registrar will not have much in the way of public interfaces since the data it makes available is pushed out to the other SIP services.</p>

<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<script type="syntaxhighlighter" class="toolbar: false; theme: Confluence; brush: java; gutter: false"><![CDATA[
struct BindingUpdate
{
    /**
     * The AoR for which bindings have been updated
     */
    string aor;
    /**
     * The Contact URIs bound to this AoR
     */
    StringSeq contacts;
}

sequence&lt;BindingUpdate&gt; BindingUpdateSeq;

/**
 * A RegistrarListener is updated when a binding changes.
 * Typical RegistrarListeners will be SIP services that
 * require up-to-date information.
 */
interface RegistrarListener
{
    /**
     * Alerts the listener that contacts have been added
     * to one or more AoRs. The AoRs may be new or they
     * may have already had bindings.
     */
    void contactsAdded(BindingUpdateSeq updates);
    /**
     * Alerts the listener that contacts have been removed.
     * There is no specific call for indicating that an AoR
     * no longer has contacts associated with it. After this
     * operation has been invoked, listeners should take
     * appropriate action if an AoR no longer has bindings.
     */
    void contactsRemoved(BindingUpdateSeq updates);
};

interface Registrar
{
    /**
     * Add a new listener to the registrar. The listener will
     * receive all known AoRs and their bindings through
     * its 'contactsAdded' operation.
     */
    void addListener(RegistrarListener *listener);
    /**
     * Remove a listener.
     */
    void removeListener(RegistrarLister *listener);
    /**
     * Get the mapping of all known AoRs and their bindings.
     */
    BindingDict getAllBindings();
    /**
     * Get all bindings associated with a particular AoR.
     */
    BindingSeq getAORBindings(string aor);
};
]]></script>
</div></div>

<p>A <tt>RegistrarListener</tt> registers itself with the <tt>Registrar</tt> in order to receive updates about the <tt>Registrar</tt>'s bindings. Most <tt>RegistrarListeners</tt> will be other SIP services that need to use the registrar's data. A <tt>RegistrarListener</tt> is always provided with <tt>BindingUpdate</tt> objects instead of <tt>Binding</tt> objects because the <tt>Binding</tt> contains information that is not useful outside the registrar service. If a component wishes to get a full <tt>Binding</tt> object it may use a variant of <tt>getBindings</tt> to do so.</p>

<h1><a name="SIPRegistrar-Operation"></a>Operation</h1>

<p><span class="image-wrap" style=""><img src="/wiki/download/attachments/12550396/Registration.png?version=1&amp;modificationDate=1299018543697" style="border: 0px solid black" /></span></p>

<p>The diagram shows that when contacts are added or removed from the registrar, the <tt>RegistrarListener</tt> is notified. The third REGISTER transaction does not notify the listener. This is because the REGISTER was refreshing the expiration period for a previously established contact. While this results in internal changes to the registrar and its replicas, <tt>RegistrarListeners</tt> do not need to be updated.</p>

<h1><a name="SIPRegistrar-Otherideas"></a>Other ideas</h1>

<ul>
        <li>Providing a mechanism for default AoRs may be desirable. For instance, if there is an endpoint named "Bob" and his endpoint belongs to the domains "example1.com" and "example2.com" then it may be reasonable to automatically associate Bob with the AoRs "sip:bob@example1.com" and "sip:bob@example2.com." Implicit behavior is typically discouraged in Asterisk SCF, which is why default AoRs are not currently defined.</li>
</ul>

    </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/TOP/SIP+Registrar">View Online</a>
        |
        <a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=12550396&revisedVersion=14&originalVersion=13">View Changes</a>
                |
        <a href="https://wiki.asterisk.org/wiki/display/TOP/SIP+Registrar?showComments=true&amp;showCommentArea=true#addcomment">Add Comment</a>
            </div>
</div>
</div>
</div>
</div>
</body>
</html>