<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/Registrar">Registrar</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>/** <br></td></tr>
            <tr><td class="diff-added-lines" style="background-color: #dfd;"> * A dictionary mapping <br> * AoRs to their bound contacts <br> */ <br>dictionary&lt;string, Ice::StringSeq&gt; ContactDict; <br> <br>/** <br></td></tr>
            <tr><td class="diff-unchanged" > * A RegistrarListener is updated when a binding changes. <br> * Typical RegistrarListeners will be SIP services that <br></td></tr>
            <tr><td class="diff-snipped" >...<br></td></tr>
    
            </table>
    </div>                            <h4>Full Content</h4>
                    <div class="notificationGreySide">
        <h1><a name="Registrar-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 this mapping. The registrar populates this mapping based on incoming SIP REGISTER requests it receives.</p>

<h1><a name="Registrar-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.</p>

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

<p>A binding in Asterisk SCF is a single contact URI that is bound to an AoR. A single AoR may have multiple bindings associated with it, and a single REGISTER message may create multiple bindings in Asterisk SCF.</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>Binding</tt> object represents all the state data that needs to be replicated between registrars. Individual registrars will be responsible for scheduling destruction of their local <tt>Bindings</tt> based on the binding's expiration.</p>

<h1><a name="Registrar-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 contacts from all bindings for this AoR
     */
    StringSeq contacts;
}

/**
 * A dictionary mapping
 * AoRs to their bound contacts
 */
dictionary&lt;string, Ice::StringSeq&gt; ContactDict;

/**
 * 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.
     * The AoR may be new or it may have previous
     * bindings.
     */
    void contactsAdded(BindingUpdate contacts);
    /**
     * 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
     * method has been called, listeners should take
     * appropriate action if the AoR has no bound contacts.
     */
    void contactsRemoved(BindingUpdate contacts);
};

interface Registrar
{
    /**
     * Add a new listener to the registrar.
     * The return value is the map of all AoRs and their
     * bindings.
     */
    ContactDict addListener(RegistrarListener *listener);
    /**
     * Remove a listener.
     */
    void removeListener(RegistrarLister *listener);
    /**
     * Get the mapping of all active registrations.
     */
    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 a <tt>BindingUpdate</tt> instead of a <tt>Binding</tt> because information besides the contact in a <tt>Binding</tt> is not useful outside the registrar service. If a component wishes to get a full <tt>Binding</tt> it may use a variant of <tt>getBindings</tt> to do so.</p>

<h1><a name="Registrar-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="Registrar-Otherideas"></a>Other ideas</h1>

<ul>
        <li>The registrar specification does not currently authorize third party registrations. By this, I mean that an endpoint can only be configured to update bindings for his own AoRs, not bindings for AoRs associated with other endpoints. This could be allowed, but the configuration would become more complex for a feature that is not widely used.</li>
</ul>


<ul>
        <li>Once SIP configuration interfaces and objects have stabilized, the section about <tt>RegistrarListeners</tt> may change. If it becomes practical, there may not be a need for <tt>RegistrationListeners</tt> if the registrar is able to push configuration updates to endpoints directly.</li>
</ul>


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