HOWTO

Konfiguration und Anpassung von SIP-Providern über Providerprofile (kb3436)

Die Information in diesem Artikel betrifft die folgenden Produkte:

  • SwyxWare 11.10.1.0
  • SwyxWare 11.00.1.0
  • SwyxWare 11.00
  • SwyxWare 11
  • SwyxWare 2015 R40.3.0
  • SwyxWare 2015 R40.2.0
  • SwyxWare 2015 R40.1.0
  • SwyxWare 2015 R40.0.0
  • SwyxWare 2015 R30.5.0
  • SwyxWare 2015 R30.4.0
  • SwyxWare 2015 R3.2.2
  • SwyxWare 2015 R3.2
  • SwyxWare 2015 R3.1
  • SwyxWare 2015 R3
  • SwyxWare 2015 R2
  • SwyxWare 2015
  • SwyxWare 2013
  • SwyxWare 2011 R2

[ Zusammenfassung | Information ]


Zusammenfassung

Dieser Artikel beschreibt, wie ein Profil für einen neuen SIP Provider zur SwyxWare hinzugefügt wird, so dass es beim Anlegen einer SIP-Trunkgruppe in der Liste der Providerprofile zur Verfügung steht.


Information

Zum Anlegen der SIP Trunk Gruppe in der SwyxWare existieren vordefinierte Profile für eine große Anzahl von SIP Providern. In diesen Profilen sind Konfigurationsparameter festgelegt, die für einen störungsfreien Betrieb mit dem ausgewählten Provider notwendig sind. Diese Profile sind in der XML Datei ProviderProfiles.config hinterlegt, die im Installationsverzeichnis der SwyxWare liegt, üblicherweise C:\Program Files (x86)\SwyxWare. Die meisten der Parameter zu einem Profil lassen sich bei Bedarf über das AdminTool ändern, andere können ausschließlich in der ProviderProfiles.config konfiguriert werden. Da diese Datei bei einem Update überschrieben wird, wird strengstens davon abgeraten, diese Datei zu modifizieren.

Wenn ein neues Profil für einen noch nicht unterstützten Provider angelegt werden soll, so kann dies zwar als CustomProvider mit dem Admin-Tool erfolgen, allerdings wird auch hiervon abgeraten, da sich nicht alle Parameter konfigurieren lassen. Stattdessen sollte eine zweite XML Datei CustomProviderProfiles.config im Installationsverzeichnis der SwyxWare angelegt werden.

WICHTIG:

Vor dem Anlegen und Editieren der CustomProviderProfiles.config ist zwingend die SwyxWare Administration zu schließen, da anderenfalls die Einträge nicht übernommen werden.

Die XML Struktur dieser Datei ist identisch mit der ProviderProfiles.config und muss ebenfalls UTF8-kodiert sein, da anderenfalls Umlaute und Sonderzeichen nicht korrekt übernommen werden.

Wenn Sie die XML-Datei ändern, muss der LinkManager die Änderungen übernehmen. Sie können das erreichen, indem Sie den LinkManager einfach neu starten.

Um ein neues Profil in der XML-Datei zu hinterlegen, muss ein neues XML-Element "SIPProviderProfile" mit den im Folgenden erklärten Attributen hinzugefügt werden. Die fett markierten Attribute sind hierbei Pflichtfelder, die weiteren sind optional. Zu diesen sind die Standardwerte angegeben, die verwendet werden, wenn das Attribut nicht verwendet wird.

 

Attribut Typ Voreinstellung
id String ohne Leerzeichen -
name String -
numberformats Typ (siehe unten) -
proxy String -
stun String "" (kein STUN Server)
registrar String Wert von proxy
realm domainname Wert von registrar
reRegistrationTimeout integer "120"
DtmfMode enum (siehe unten) "None"
UseDisplayInfo boolean "true"
CallingPartyNumberPosition enum (siehe unten) "FromHeaderSIPURI"
IncomingFaxMethod FaxMethods (siehe unten) "T38"
OutgoingFaxMethod FaxMethods (siehe unten) "G711"
TransportType enum (siehe unten) "NotSpecified"
UseRegistration boolean "true"
UseOverlapDialing boolean "false"
UseSIPConnectV1_1 boolean "false"
UsePAssertedIdentity boolean "true"
UseInviteAuth boolean "false"
FilterSipMessages boolean "false"
UseSipInstanceId boolean "false"
UseSipRfc3262 boolean "false"
RecvCalledPartyNumberPosition enum CalledPartyNumberPositions (siehe unten) "ToHeaderSIPURI"
ReuseMediaPorts boolean "false"

 

id - Id, die alle Providerprofile unterscheidet. Jedes Profil aus der ProviderProfiles.config und aus der CustomProviderProfiles.config benötigt einen eindeutige Id.

name - Name des Providers, so wie er in der Profilliste beim Anlegen einer SIP Trunkgruppe erscheint.

numberformats - das Nummernformat für die Zielnummer (called party) und die Absendernummer (calling party), das für ein- und ausgehende Rufe vom/zum SIP-Provider in SIP-Nachrichten (z.B. Invite) verwendet wird. Folgenden Attributen müssen Werte zugewiesen werden:

  • inbound_called:  Called Party für eingehende Rufe
  • inbound_calling:  Calling Party für eingehende Rufe
  • outbound_called:  Called Party für ausgehende Rufe
  • outbound_calling:  Calling Party für ausgehende Rufe

Mögliche Werte:

  • CanonicalWithPlus:  benutze kanonische Nummern mit führendem + (z.B. +4923147770)
  • CanonicalWithoutPlus:  benutze kanonische Nummern ohne führendem + (z.B. 4923147770)
  • National:  das nationale Nummernformat. Die Konvertierung wird auf der Basis der im SwyxServer konfigurierten Daten wie Landeskennzahl und Ferngesprächsvorwahl durchgeführt (z.B. 023147770) 

proxy - der SIP-Proxy für ausgehende Rufe.

stun - der zu benutzende STUN-Server. Falls leer, ist STUN für alle Trunks mit diesem Provider deaktiviert. Wenn STUN verwendet werden muss, aber der Provider selber keinen STUN Server betreibt, ist unter http://www.voip-info.org/wiki/view/STUN eine Liste mit öffentlichen STUN Servern verfügbar. Sofern nicht der Standard Port für STUN 3478 verwendet werden soll, kann dieser durch Doppelpunkt getrennt nach dem STUN-Server angegeben werden (Bsp.: stun.example.org:12345).

registrar - Name oder IP Adresse des SIP-Registrar, an den die REGISTER Nachrichten gesendet werden. Sofern nicht der Standard Port für SIP 5060 verwendet werden soll, kann dieser durch Doppelpunkt getrennt nach dem Server angegeben werden.

realm - definiert den SIP-Realm. Dieser wird in den SIP-URIs der entsprechenden Header als Host-Part verwendet. Die SIP-URI wird folgendermaßen gebildet: <12345>@<realm>.

reRegistrationTimeout - legt Registrierungsintervall fest. Ein kleiner Wert lässt den Verlust der SIP-Verbindung zum Provider schnell erkennen. Ein hoher Wert führt zu geringerer Netzwerklast. Der SIP-Provider kann mittels des "expires"-Headers in der SIP OK-Antwort auf das REGISTER einen anderen Wert für das Registrierungsintervall setzen, auf den sich die SwyxWare adaptiert.

DtmfMode - der Modus der DTMF-Signalisierung, die mit diesem Provider benutzt wird. Mögliche Werte:

  • None:  Keine DTMF-Signalisierung
  • Rfc2833_Event:  DTMF-Signalisierung basierend auf dem im RFC2833 beschriebenen Eventmechanismus
  • InfoMethod_DtmfRelay:  DTMF-Signalisierung über SIP INFO Requests wie von Cisco vorgeschlagen (applicationtype DtmfRelay)

UseDisplayInfo - definiert, ob bei ausgehenden Rufen die URI im From-header ein Display-Feld enthalten soll. Das Display-Feld signalisiert die alphanumerischen Benutzernamen, z.B. "Anton Mustermann"

CallingPartyNumberPosition - definiert für ausgehende Rufe die Signalisierung der Anrufernummer. Mögliche Werte:

  • None:  Signalisierung der anrufenden Nummer ist deaktiviert
  • FromHeaderSIPURI:  im User-Feld der URI im From-Header
  • FromHeaderDisplayName:  im Display-Info-Feld des From-Headers
  • RFC3325:  Rufnummernsignalisierung wie im RFC3325 beschrieben ("P-Preferred-Identity" und "Privacy" Header)
Hinweis: Ab der Version SwyxWare 2013 R3 wird unabhängig vom eingestellten Wert bei einem ausgehenden Ruf immer der P-Asserted-Identity Header mitgeschickt. Dieser beinhaltet üblicherweise die öffentliche Rufnummer des Anrufers falls der Anrufer eine hat, ansonsten die erste öffentliche zugewiesene Rufnummer des SIP Trunks.

CalledPartyNumberPosition - definiert für eingehende Rufe die Position der Zielrufnummer. Mögliche Werte:

  • ToHeaderSIPURI:  im User-Feld der URI im To-Header
  • RequestURI:  im User-Feld der Request URI

FaxMethods - definiert die bevorzugte Faxmethode. Mögliche Werte:

  • T38:  verwende Faxmethode T.38 für ein- oder ausgehende Rufe (IncomingFaxMethod, OutgoingFaxMethod)
  • G711:  verwende Faxmethode G.711 für ein- oder ausgehende Rufe (IncomingFaxMethod, OutgoingFaxMethod)
  • G711+T38:  verwende G.711 und T.38 als Faxmethode für ausgehende Rufe (nur OutgoingFaxMethod)

TransportType - definiert das bevorzugte Transportprotokoll. Mögliche Werte:

  • NotSpecified  (in der Regel wird dann UDP verwendet)
  • UDP
  • TCP
  • TLS

UseRegistration - legt fest, ob sich der SIP-Trunk aktiv mit einem SIP REGISTER beim Provider anmelden muss.

UseOverlapDialing - hiermit kann "overlapped dialing" aktiviert werden, wie es aus dem PSTN bekannt ist. Die Wahl einer Zielrufnummer kann damit ziffernweise in Richtung Provider signalisiert werden. D.h. es gehen mehrere Invites für denselben Ruf unter Aufsummierung der Ziffern an den Provider. Der Provider muss jedes Invite mit einer SIP 484 Nachricht beantworten, sofern der Ruf noch nicht zugestellt werden kann. Der Vorteil liegt darin, dass der Ruf direkt signalisiert werden kann und kein Timeout für das Ziffernsammeln abgewartet werden muss.

Ab SwyxWare 2013 R3:
UseSIPConnectV1_1 - aktiviert die Unterstützung aller praxisrelevanten Teile der technischen Empfehlung "SIPconnect Ver. 1.1". Weitere Informationen entnehmen Sie bitte der Website: http://www.sipforum.org/sipconnect

Hier ist zu beachten:

  1. Alle "numberformats" sind auf den Wert "CanonicalWithPlus" zu setzen.
  2. "DtmfMode" ist auf den Wert "Rfc2833_Event" zu setzen.
  3. "CallingPartyNumberPosition" ist automatisch "FromHeaderSIPURI", unabhängig von dem eingetragenen Wert.

Ab SwyxWare 2013 R4:

  • UsePAssertedIdentity - definiert, ob bei ausgehenden Rufen der P-Asserted-Identity Header mitgeschickt wird.
    Hinweis: Nicht deaktivierbar, wenn 'UseSIPConnectV1_1' als True konfiguriert ist.
  • UseInviteAuth - legt fest, ob bei eingehenden Rufen der SIP INVITE Request authentisiert werden soll.

Ab SwyxWare 2015 R40.0.0:

  • FilterSipMessages - legt fest, ob SIP Messages auf die entfernte Quell-IP-Adresse des SIP-Provider-Trunks gefiltert werden sollen.
  • UseSipInstanceId - legt fest, ob SIP REGISTER Requests eine SIP instance UUID nach RFC 5626 verwenden.
  • UseSipRfc3262 - legt fest, ob SIP PRACK Messages nach RFC 3262 verwendet werden sollen.
  • RecvCalledPartyNumberPosition - legt fest, aus welchem SIP Header die Zielrufnummer extrahiert wird.

Ab SwyxWare 11.00:
ReuseMediaPorts - legt fest, ob die RTP/RTCP Media Ports innerhalb eines Rufes wiederverwendet werden sollen.

Die häufigsten in der Praxis auftretenden Probleme bei der Anbindung von SIP-Trunks an SIP-Provider sind in den folgenden Bereichen zu finden, die mit eigenen KB-Artikeln behandelt werden:

 

Hier ein Beispiel für eine CustomProviderProfiles.config-Datei, in der ein SIP Provider mit dem Namen "Sample Provider" konfiguriert wurde. Dieser steht in der Trunk-Gruppen-Konfiguration zur Verfügung, nachdem die Datei im SwyxWare-Installationsverzeichnis abgelegt wurde:

<?xml version="1.0" encoding="utf-8"?>
<sp:ProviderProfiles xmlns:sp="http://www.lanphone.de/ProviderProfiles" allowcustom="false">
  <sp:SIPProviderProfile id="smplprv" name="Sample Provider" stun="stun.example.org" proxy="proxy.example.org" DtmfMode="Rfc2833_Event" >
    <sp:NumberFormats outbound_called="CanonicalWithPlus" outbound_calling="CanonicalWithPlus" inbound_called="CanonicalWithPlus" inbound_calling="CanonicalWithPlus" />
  </sp:SIPProviderProfile>
</sp:ProviderProfiles>


Kommentar

Hat Ihnen dieser Artikel weitergeholfen? Kommentieren Sie diesen Artikel



Sollten sich Fragen aus Ihrem Kommentar ergeben, wie können wir Sie erreichen?

E-Mail Adresse (optional)


Hinweis

Dieses Kommentar-Feld steht Ihnen nicht für Support-Anfragen zur Verfügung. Diese richten Sie bitte ausschliesslich an Ihren Swyx Händler bzw. Distributor.