Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: updated @ 2023-08-09T11:38:25.185554
HTML
headtrue
encodingUTF-8
<!DOCTYPE html
  SYSTEM "about:legacy-compat">
<html lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8"><meta charset="UTF-8"><meta name="copyright" content="(C) Copyright 2023"><meta name="DC.rights.owner" content="(C) Copyright 2023"><meta name="DC.type" content="concept"><meta name="prodname" content="All Mediatrix Units"><meta name="version" content="DGW 49.12.28842941"><meta name="platform" content="All"><meta name="DC.date.modified" content="2023-0308-2809"><meta name="DC.date.issued" content="2023-0308-2809"><meta name="DC.date.available" content="2023-0308-2809"><meta name="ChapterNumbering" content="no"><meta name="DC.format" content="HTML5"><meta name="DC.identifier" content="concept_srv_redundancy"><link href="https://fonts.googleapis.com/css?family=Open+Sans" rel="stylesheet"><link rel="stylesheet" type="text/css" href="https://documentation.media5corp.com/download/attachments/45482024/commonltr.css"><link rel="stylesheet" type="text/css" href="https://documentation.media5corp.com/download/attachments/45482024/custom.css"><title>DNS SRV and Redundancy</title></head><body><header role="banner"><div class="topicmeta title">DNS SRV and Redundancy</div><div class="topicmeta date">2023-0308-28<09</div><div class="topicmeta product">All Mediatrix Units</div><div class="topicmeta version">DGW 49.12.2884<2941</div><div class="topicmeta pdf"><a href="https://documentation.media5corp.com/download/attachments/45482024/DNS%20SRV%20Usage.pdf" rel="nofollow">Download PDF Document</a></div><hr><span style="float: inline-end;"></span></header><nav role="toc"><ul><li><a href="#concept_srv_redundancy">DNS SRV Redundancy</a></li><li><a href="#concept_irn_qnb_5s">DNS SRV Usage</a></li><li><a href="#concept_eq3_nkb_5s">DNS SRV (RFC 2782)</a></li><li><a href="#concept_ojw_rxb_5s">Type A Query</a></li><li><a href="#concept_qbw_3bc_5s">Type A Query to a SRV Record</a></li><li><a href="#concept_u2m_tdc_5s">Type SRV Query</a></li><li><a href="#concept_fq5_ssb_5s">The Effects of Priority and Weight</a></li><li><a href="#reference_jly_1rb_5s">Additional Interop Parameters</a></li><li><a href="#reference_ur5_yx3_ps">Available Documentation</a></li><li><a href="#concept_fqm_rv4_k4">Copyright Notice</a></li></ul></nav><main role="main"><article role="article" aria-labelledby="ariaid-title1"><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="nested0" aria-labelledby="ariaid-title1" id="concept_srv_redundancy">
  <h1 class="title topictitle1" id="ariaid-title1">DNS SRV Redundancy</h1>
  <div class="body conbody">
    <p class="p">This configuration note will help you use DNS queries to configure a Mediatrix gateway for:</p>
    <ul class="ul">
      <li class="li">Redundancy Failover, or</li>
      <li class="li">Load Balancing</li>
    </ul>
    <p class="p">Note that DNS SRV type is not mandatory for Redundancy Failover, 
       as it can be achieved with DNS A or AAAA types where multiple IP addresses 
       are received in a single A or AAAA response.
    </p>
  </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title2" id="concept_irn_qnb_5s">
  <h1 class="title topictitle1" id="ariaid-title2">DNS SRV Usage</h1>
  <div class="body conbody">
    <br><img class="image" id="concept_irn_qnb_5s__image_qmv_1hd_d1b" src="https://documentation.media5corp.com/download/attachments/45482024/DNSSRVusage.png" width="800"><br>
    <div class="p">
      <div class="note note note_note"><span class="note__title">Note:</span> The Mediatrix unit will keep the DNS responses it has received in cache for the
        remainder of the TTL field specified in the DNS response. If you make modifications to your
        DNS server configuration and want the Mediatrix unit to reissue DNS requests before the end
        of the TTL, you will need to enter the following command in the CLI or SNMP:
          <span class="keyword parmname">Hoc.ClearDnsCache</span></div>If any of the SIP server parameters
      corresponds to a FQDN that is bound to a SRV record, the corresponding port must be set to
        <strong class="ph b">0</strong> for the unit to perform DNS requests of type SRV (as per RFC 3263). Otherwise, the
      unit will not use DNS SRV requests, but will rather use type A requests because it does not
      need to have a specified port. We now look at the two types of DNS queries.</div>
  </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title3" id="concept_eq3_nkb_5s">
 <h1 class="title topictitle1" id="ariaid-title3">DNS SRV (RFC 2782)</h1>
 <div class="body conbody">
  <p class="p">DNS SRV is an extension of the standard DNS server specification (independent from SIP, as per
   RFC 2782). SRV (Service Record) is a type of entry a network administrator may put into the DNS
   server. A DNS SRV request is used to get one or more IP addresses of servers, each one having its
   own weight, priority and possible port.</p>
  <p class="p">Each entry received when using DNS SRV, depending on its weight and priority, can be used as a
   primary or backup server or can be part of a load balancing system.</p>
  <p class="p">For instance, the client requests the SRV for SIP servers in some domain. The DNS server may
   return the A, B, and C addresses, which are all SIP servers. Each address has a weight and the
   client must choose one of those three addresses by using an algorithm that considers the
   weight.</p>
  <p class="p">To use DNS SRV, an administrator must set a service records (SRV) into the DNS servers
   available on the network.</p>
 </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title4" id="concept_ojw_rxb_5s">
 <h1 class="title topictitle1" id="ariaid-title4">Type A Query</h1>
 <div class="body conbody">
  <p class="p">If you specify a SIP port for the registrar and proxy, the Mediatrix unit will issue a type A
   query. In this example the requests are sent to server1.media5berlin.com for both the Registrar
   and Proxy, with the SIP port being 5060 for both.</p>
  <br><img class="image" id="concept_ojw_rxb_5s__image_k4l_tzb_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery.png" width="800"><br>
  <br><img class="image" id="concept_ojw_rxb_5s__image_qnw_tzb_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_2.png" width="800"><br>
  <br><img class="image" id="concept_ojw_rxb_5s__image_rx3_5zb_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_3.png" width="800"><br>
  <p class="p">Wireshark displays the answer to the query as a “type A” answer, which contains the IP address
   for server1.media5berlin.com. The Mediatrix unit then attempts to register itself to that IP
   address.</p>
  <br><img class="image" id="concept_ojw_rxb_5s__image_qrl_yzb_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_4.png" width="800"><br>
 </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title5" id="concept_qbw_3bc_5s">
 <h1 class="title topictitle1" id="ariaid-title5">Type A Query to a SRV Record</h1>
 <div class="body conbody">
  <p class="p">In the following example, the Mediatrix unit administrator is told to use “media5berlin.com” as
   FQDN for his registrar and proxy, but is unaware that he should use SRV for his DNS queries.
   Consequently he does not configure his registrar and proxy ports to 0.</p>
  <br><img class="image" id="concept_qbw_3bc_5s__image_j5l_fdc_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_SRVRecord_1.png" width="800"><br>
  <br><img class="image" id="concept_qbw_3bc_5s__image_j4w_fdc_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_SRVRecord_2.png" width="800"><br>
  <p class="p">The Wireshark capture shows no additional SRV query and no registration, why? </p>
  <p class="p">By specifying the SIP port to 5060, the unit makes a standard A query, and since
   media5berlin.com is configured as a SRV record, no address is returned. The symptom will be a
   failed registration with the message “Registrar Unreachable”.</p>
  <br><img class="image" id="concept_qbw_3bc_5s__image_acv_3dc_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeAQuery_SRVRecord_3.png" width="800"><br>
 </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title6" id="concept_u2m_tdc_5s">
 <h1 class="title topictitle1" id="ariaid-title6">Type SRV Query</h1>
 <div class="body conbody">
  <p class="p">As previously stated, setting proxy and registrar ports to 0 will make the Mediatrix unit issue
   a DNS request of type SRV.</p>
  <br><img class="image" id="concept_u2m_tdc_5s__image_icb_wfc_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeSRVQuery.png" width="800"><br>
  <br><img class="image" id="concept_u2m_tdc_5s__image_scl_wfc_5s" src="https://documentation.media5corp.com/download/attachments/45482024/TypeSRVQuery_2.png" width="800"><br>
  <p class="p">The response contains 2 available SIP servers with the FQDN, IP addresses, priorities, weight
   (for equal priority) and SIP ports.</p>
  <p class="p">At the bottom of the window you can see “Additional records” with server1.media5berlin.com and
   server2.media5berlin.com. Those are 2 valid type A FQDNs which are offered in the SRV response.
   If you wished to do so, you could also explicitly enter those FQDNs directly into your Mediatrix
   proxy configuration field (as done in Scenario #1).</p>
  <p class="p">Please note that a NAPTR query is done before the SRV query. NAPTR is used to find Transport
   method, UPD – TCP – TLS. The establishment of persistent (TLS) connections will not send NAPTR
   since the transport is already known. </p>
  <div class="p">A NAPTR query is made if:<ul class="ul" id="concept_u2m_tdc_5s__ul_nbc_bgc_5s">
    <li class="li">The host is not an IP address</li>
    <li class="li">And, the port is not explicity specified in the SIP URI (the port is not present or equal to
     0)</li>
    <li class="li">And, the SIP URI does not contain a "maddr" with an IP address</li>
    <li class="li">And, the SIP URI does not specify explicity the transport (transport parameter)</li>
   </ul>
  </div>
 </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title7" id="concept_fq5_ssb_5s">
 <h1 class="title topictitle1" id="ariaid-title7">The Effects of Priority and Weight</h1>
 <div class="body conbody">
  <p class="p">In some rare cases you may have a SRV response where some servers are configured with equal
   priority. In that case, the clients will use the weight values to determine which host to use. If
   the weights are also identical, then 50% of the packets will go to host 1 and the rest to host 2
   (in a 2 server scenario). In this example, both proxy1 and proxy2 have the same priority, but
   different weights. 51% of the packets will go to proxy1 and 49% to proxy2.</p>
  <p class="p">This may cause an issue where the unit REGISTER is sent to host1 and, after the authentication
   challenge is sent by the registrar, the answer is sent to host 2 as shown in these screenshots.
   The initial REGISTER is sent to 192.168.120.11, and the response to the challenge sent to
   192.168.120.10. If your hosts are not synchronized, you will get REGISTER or INVITE failures.</p>
  <br><img class="image" id="concept_fq5_ssb_5s__image_ljz_btb_5s" src="https://documentation.media5corp.com/download/attachments/45482024/EffectsofPriorityandWeight_1.png" width="800"><br>
  <br><img class="image" id="concept_fq5_ssb_5s__image_ay5_33d_d1b" src="https://documentation.media5corp.com/download/attachments/45482024/EffectsofPriorityandWeight_2.png" width="800"><br>
 </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic reference nested0" aria-labelledby="ariaid-title8" id="reference_jly_1rb_5s">
  <h1 class="title topictitle1" id="ariaid-title8">Additional Interop Parameters</h1>
  <div class="body refbody">
    <section class="section"><h2 class="title sectiontitle">SipEp.InteropLockDnsSrvRecordPerCallEnable</h2>
      
        <div class="p"><ul class="ul">
          <li class="li">DNS SRV implementation should imply a shared database between servers since a Register
            and an INVITE can be sent to any server, not necessarily the same one;</li>
          <li class="li">For those who do not share their database, this must be enabled, allowing INVITEs to
            be sent to the same Registrar host, thus use the same SRV record</li>
        </ul></div>
        <p class="p">This parameter can be used to get around the above-mentioned issue. Setting this
        parameter to “enable” makes the Mediatrix unit “stick” to the IP address associated with the
        initial Call-Id of the REGISTER or INVITE.</p>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.InteropLockDnsSrvRecordForRegister</h2>
      
        <p class="p">
        This parameter can be used to control the registration refresh failback behavior; 
        whether it “sticks” to the current target, or try to failback to a higher priority target.
        </p>
        <p class="p">Note: This parameter is ignored if <strong class="ph b">SipEp.InteropLockDnsSrvRecordPerCallEnable</strong> is disabled.</p>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.InteropLockDnsSrvRecordWithInviteBoundToRegisterEnable</h2>
      
        <p class="p">
         This parameter can be used to define the behavior of INVITEs; 
         whether they lock or not to the same target than their associated REGISTER.
        </p>
        <p class="p">Note: This parameter is ignored if <strong class="ph b">SipEp.InteropLockDnsSrvRecordPerCallEnable</strong> is disabled.</p>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.InteropTransmissionTimeout</h2>
      
      <p class="p">If using DNS SRV and multiple entries are present, this value is the time spent waiting for
        answers from each entry when one server is unreachable or unresponsive. The default value of
        this parameter is 32 seconds. It has a dramatic effect should a server time out, since a
        default 32 seconds delay would be introduced at every call.</p>
      <p class="p">A maximum value of 2-3 seconds is recommended when using DNS SRV.</p>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.PenaltyBoxEnable</h2>
      
      <div class="p">
        <ul class="ul">
          <li class="li">The penalty box feature is used when a given host address times out. When the address
            times out, it is put into the penalty box for a given amount of time. During that time,
            the address in question is considered as 'non-responding' for all requests.</li>
        </ul>
      </div>
      <p class="p">Note: This parameter only applies to "Trunk Gateway" type, and not for the "Endpoint Gateway" type. 
         Refer to the SipEp.Gateway[].Type parameter.</p>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.PenaltyBoxtime</h2>
      
      <div class="p">
        <ul class="ul">
          <li class="li">A “timed out” server is considered “not responding” for this amount of time;</li>
          <li class="li">Can be seen as the time it will take to retry a server that failed to respond.</li>
        </ul>
      </div>
    </section>
    <section class="section"><h2 class="title sectiontitle">SipEp.DnsIpVersion</h2>
      
      <p class="p">This parameter can be used to disable AAAA requests, so only A requests are issued.</p>
    </section>
  </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic reference nested0" aria-labelledby="ariaid-title9" id="reference_ur5_yx3_ps">
  <h1 class="title topictitle1" id="ariaid-title9">Available Documentation</h1>

  <div class="body refbody">

    <section class="section">For more details, refer to the <a class="xref" href="https://documentation.media5corp.com/display/DGWLATEST/Latest+DGW" target="_blank">Mediatrix Documentation</a> published on the <a class="xref" href="https://documentation.media5corp.com/" target="_blank">Media5 Documentation Portal</a>.</section>

  </div>
</article><hr><span style="float: inline-end;"><a href="#">Top</a></span><article class="topic concept nested0" aria-labelledby="ariaid-title10" id="concept_fqm_rv4_k4">
 <h1 class="title topictitle1" id="ariaid-title10">Copyright Notice</h1>
 

 <div class="body conbody"><p class="shortdesc">Copyright © 2023 Media5 Corporation.</p>
  <p class="p">This document contains information that is proprietary to Media5 Corporation.</p>
  <p class="p">Media5 Corporation reserves all rights to this document as well as to the Intellectual Property
   of the document and the technology and know-how that it includes and represents.</p>
  <p class="p">This publication cannot be reproduced, neither in whole nor in part, in any form whatsoever,
   without written prior approval by Media5 Corporation.</p>
  <p class="p">Media5 Corporation reserves the right to revise this publication and make changes at any time
   and without the obligation to notify any person and/or entity of such revisions and/or
   changes.</p>
 </div>
</article></article></main></body></html>