Snom Service Hub

Space shortcuts

Content

Page tree

Versions Compared

Old Version 6

changes.mady.by.user Snom Wiki

Saved on

compared with

New Version Current

changes.mady.by.user Snom Wiki

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Sv translation
languageen

Snom Deskphones support SIP Failover and Load balancing via DNS (SRV+NAPTR).

  • When the phone needs to send a SIP request, it gets a list of servers from DNS.
  • Then, the phone chooses a server in the list depending on the NAPTR and SRV priority and weight (see here for a deeper explanation of NAPTR and SRV configurations: https://en.wikipedia.org/wiki/NAPTR_record and  https://en.wikipedia.org/wiki/SRV_record).
  • If the chosen server refuses the connection or does not reply within 32 seconds, the request is sent to the next server and so on.
  • The 32 seconds time can be reduced by reducing parameter sip_retry_t1.


Below is a simplified example on how this works.
For our registrar snom.rocks we would like to use 2 SIP servers in load balancing:

  • sipserver52.snom.rocks
  • sipserver114.snom.rocks


The identity on the Snom phone is configured with Registrar: snom.rocks.
I have the following DNS entries for it. Below is the DNS (bind9) configuration:

  • the NAPTR entry: (note that you can configure TCP and TLS here as well, we used only UDP for simplification purposes)

    Code Block
    snom.rocks. IN NAPTR 1 60 "s" "SIP+D2U" "" _sip._udp.snom.rocks.


  • the SRV entries:

    Code Block
    _sip._udp.snom.rocks. IN SRV 1 50 5060 sipserver52.snom.rocks.

_sip._udp.snom.rocks. IN SRV 1 50 5060 sipserver114.snom.rocks.

           

Here is a summary of a potential failover scenario:

  • Initially, the phone sends the REGISTER request, choosing randomly sipserver52. Now the phone is registered.
  • Let's say after 5 minutes sipserver52 crashes or doesn't answer anymore
  • Later, the user wants to make a call. The phone sends the INVITE request randomly to sipserver52 or sipserver114.
    If the INVITE gets sent to sipserver114, the call is successful and there is no problem. Otherwise, if sipserver52 is chosen the phone does not get an answer. For this example, let's assume sipserver52 is chosen
  • The phone does not receive an answer so it stays in calling state for 32 seconds
  • After 32 seconds, the phone automatically sends the INVITE to sipserver114. The sipserver114 server works and the call is successful.


A few important aspects:

  • The server that is selected first for INVITE is not necessarily the same as the server that was originally selected for REGISTER. This has to do with the NAPTR and SRV priority and weight, which you can configure on the DNS server. In the above example, there was only one NAPTR entry and for the two SRV entries both priority and weight were the same so the phone chooses the two servers alternately
  • If the 32 seconds are too much, you can reduce them by reducing sip_retry_t1.
  • It is recommended to enable the dirty host mechanism as well so that sipserver52 is not tried again for a while: dirty_host_ttl (this mechanism is not active by default)


Include Page
Howto Footer - uni-en
Howto Footer - uni-en

Content by Label
showLabelsfalse
max20
spacesPW
showSpacefalse
sorttitle
typepage
cqllabel = "deskphone" and label in ("feature","sip") and type = "page"
labelsdect dect-multicell


Sv translation
languagede

Snom Deskphones unterstützen SIP Failover und Load Balancing über DNS (SRV+NAPTR).

  • Wenn das Telefon eine SIP-Anfrage senden muss, erhält es eine Liste der Server vom DNS.
  • Anschließend wählt das Telefon je nach NAPTR- und SRV-Priorität und Gewichtung einen Server in der Liste aus (siehe hier für eine genauere Erläuterung der NAPTR- und SRV-Konfigurationen: https://en.wikipedia.org/wiki/NAPTR_record and  https://en.wikipedia.org/wiki/SRV_record).
  • Wenn der gewählte Server die Verbindung ablehnt oder nicht innerhalb von 32 Sekunden antwortet, wird die Anfrage an den nächsten Server gesendet und so weiter.
  • Der 32 Sekunden lange Zeitraum kann durch Reduzieren des Parameters sip_retry_t1 reduziert werden.


Nachfolgend finden Sie ein vereinfachtes Beispiel, wie dies funktioniert.
Für unseren Registrar snom.rocks möchten wir 2 SIP-Server im Load Balancing einsetzen:

  • sipserver52.snom.rocks
  • sipserver114.snom.rocks


Die Identität auf dem Snom-Telefon wird mit Registrar: snom.rocks konfiguriert.
Wir haben die folgenden DNS-Einträge dafür. Unten ist die DNS (bind9) Konfiguration:

  • der NAPTR-Eintrag: (beachten Sie, dass Sie TCP und TLS auch hier konfigurieren können, wir haben zur Vereinfachung nur UDP verwendet).

    Code Block
    snom.rocks. IN NAPTR 1 60 "s" "SIP+D2U" "" _sip._udp.snom.rocks.



  • die SRV-Einträge:

    Code Block
    _sip._udp.snom.rocks. IN SRV 1 50 5060 sipserver52.snom.rocks.

_sip._udp.snom.rocks. IN SRV 1 50 5060 sipserver114.snom.rocks.

           

Hier ist eine Zusammenfassung eines möglichen Failover-Szenarios:

  • Zunächst sendet das Telefon die REGISTER-Anfrage und wählt dabei zufällig sipserver52. Jetzt ist das Telefon registriert.
  • Angenommen, sipserver52 stürzt nach 5 Minuten ab oder antwortet nicht mehr.
  • Später möchte der Benutzer einen Anruf tätigen. Das Telefon sendet die INVITE-Anfrage zufällig an sipserver52 oder sipserver114.
  • Wenn das INVITE an sipserver114 gesendet wird, ist der Aufruf erfolgreich und es gibt kein Problem. Andernfalls, wenn sipserver52 gewählt wird, erhält das Telefon keine Antwort. Für dieses Beispiel nehmen wir an, dass sipserver52 ausgewählt ist.
  • Das Telefon erhält keine Antwort, so dass es 32 Sekunden lang im Anrufzustand bleibt.
  • Nach 32 Sekunden sendet das Telefon automatisch das INVITE an sipserver114. Der sipserver114-Server funktioniert und der Aufruf ist erfolgreich.


Einige wichtige Aspekte:

  • Der Server, der zuerst für INVITE ausgewählt wird, ist nicht unbedingt derselbe wie der Server, der ursprünglich für REGISTER ausgewählt wurde. Dies hat mit der NAPTR- und SRV-Priorität und -Gewichtung zu tun, die Sie auf dem DNS-Server konfigurieren können. Im obigen Beispiel gab es nur einen NAPTR-Eintrag und für die beiden SRV-Einträge waren sowohl Priorität als auch Gewichtung gleich, so dass das Telefon abwechselnd die beiden Server wählt.
  • Wenn die 32 Sekunden zu viel sind, können Sie sie reduzieren, indem Sie sip_retry_t1 reduzieren.
  • Es wird empfohlen, auch den Dirty-Host-Mechanismus zu aktivieren, damit sipserver52 eine Weile nicht erneut versucht wird: dirty_host_ttl (dieser Mechanismus ist standardmäßig nicht aktiv). 


Include Page
Howto Footer - de
Howto Footer - de

Content by Label
showLabelsfalse
max20
spacesPW
showSpacefalse
sorttitle
typepage
cqllabel = "deskphone" and label in ("feature","sip") and type = "page"
labelsdect dect-multicell