> # SIP-Server: Konfiguration: Allgemein

> Konfigurationsoptionen

> Auf dieser Seite können Sie Features und Standardverhalten für den SIP-Servlet-Container konfigurieren.

> #### Konfigurationsoptionen

> Name | Beschreibung
> --- | ---
> Standard-Servlet-Name | Der Name des Standard-SIP-Servlets, das aufgerufen werden soll, wenn der Server eingehende erste Anforderungen an ein Servlet mit verfügbaren Servlet-Zuordnungsregeln nicht zuordnen kann. Der für die Option "Standard-Servlet-Name" angegebene Name muss mit dem Wert des Servlet-Namens eines bereitgestellten SIP-Servlets übereinstimmen. Wenn der hier definierte Name keinem bereitgestellten Servlet entspricht oder kein Wert bereitgestellt ist (Standardkonfiguration), registriert WebLogic Communications Server den Namen com.bea.wcp.sip.engine.BlankServlet als Standard-Servlet. Der Name BlankServlet wird auch verwendet, wenn das Deployment eines als Standardname registrierten Servlets im Container rückgängig gemacht wird. Das Verhalten von BlankServlet wird mit dem Standardverhaltenselement konfiguriert. Standardmäßig werden alle Anforderungen, die nicht übereinstimmen, vom Servlet über einen Proxy geleitet. Wenn das Standardverhaltenselement jedoch auf den Modus "ua" eingestellt ist, kann BlankServlet für CANCEL- und BYE-Anforderungen 481 Antworten und in allen anderen Fällen 500/416 Antworten zurückgeben. BlankServlet antwortet nicht auf ACK und invalidiert immer die Anwendungssession. MBean-Attribut: `SipServerBean.DefaultServletName` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> T1-Timeoutintervall | Die Dauer des SIP-Protokoll-T1-Timers, in Millisekunden Timer T1 gibt auch die ersten Werte der Timer A, E und G an, die das Neuübertragungsintervall für INVITE-Anforderungen und -Antworten über UDP steuern. T1 wirkt sich auf die Werte der Timer F, H und J aus, die Neuübertragungsintervalle für INVITE-Anforderungen und -Antworten steuern. Diese Timer werden auf einen Wert von 64*T1 Millisekunden eingestellt. Weitere Informationen über SIP-Timer finden Sie unter SIP-Spezifikation. Siehe auch "Configuring NTP for Accurate SIP Timers" im Konfigurationshandbuch. Wenn der T1-Timeoutwert nicht konfiguriert ist, verwendet WebLogic Communications Server den Standardwert des SIP-Protokolls von 500 Millisekunden. MBean-Attribut: `SipServerBean.T1TimeoutInterval` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> T2-Timeoutintervall | Die Dauer des SIP-Protokoll-T2-Timers, in Millisekunden Timer T2 definiert das Neuübertragungsintervall für INVITE-Antworten und Nicht-INVITE-Anforderungen. Weitere Informationen zu SIP-Timern finden Sie unter SIP-Spezifikation. Siehe auch "NTP für präzise SIP-Timer konfigurieren" in der Konfiguration. Wenn der T2-Timeoutwert nicht konfiguriert ist, verwendet WebLogic Communications Server den Standardwert des SIP-Protokolls von 4 Millisekunden. MBean-Attribut: `SipServerBean.T2TimeoutInterval` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> T4-Timeoutintervall | Die Dauer des SIP-Protokoll-T4-Timers, in Millisekunden Der T4-Timer gibt an, wie lange eine Nachricht maximal im Netzwerk verbleibt. Der Timer gibt darüber hinaus die ersten Werte der Timer I und K an, die die Wartezeit für die Neuübertragung von ACKs und Antworten über UDP steuern. Weitere Informationen zu den SIP-Timern finden Sie unter SIP-Spezifikation. Siehe auch "Configuring NTP for Accurate SIP Timers" im Konfigurationshandbuch. Wenn der T4-Timeoutwert nicht konfiguriert ist, verwendet WebLogic Communications Server den Standardwert des SIP-Protokolls von 5 Millisekunden. MBean-Attribut: `SipServerBean.T4TimeoutInterval` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Timeoutintervall von Timer B | Die Dauer des SIP-Protokoll-Timers B, in Millisekunden Timer B gibt an, wie lange eine Clienttransaktion versuchen kann, eine Anforderung zu senden. Weitere Informationen zu den SIP-Timern finden Sie unter SIP-Spezifikation. Siehe auch "NTP für präzise SIP-Timer konfigurieren". Wenn der Wert für Timer B nicht konfiguriert ist, ruft der Server einen Wert aus Timer T1 ab (standardmäßig 64*T1 oder 32000 Millisekunden). MBean-Attribut: `SipServerBean.TimerBTimeoutInterval` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Timeoutintervall von Timer F | Die Dauer des SIP-Protokoll-Timers F, in Millisekunden Der Timer F gibt das Timeoutintervall für die Neuübertragung von Anforderungen an, die keine INVITE-Antworten sind. Weitere Informationen zu den SIP-Timern finden Sie unter SIP-Spezifikation. Siehe auch "Configuring NTP for Accurate SIP Timers" im Konfigurationshandbuch. Wenn der Wert für Timer F nicht konfiguriert ist, ruft der Server einen Wert aus Timer T1 ab (standardmäßig 64*T1 oder 32000 Millisekunden). MBean-Attribut: `SipServerBean.TimerFTimeoutInterval` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Maximale Gültigkeitsdauer der Anwendungssession | Die maximale Zeitdauer in Minuten, die eine SIP-Anwendungssession aktiv sein darf, bevor sie vom WebLogic Communications Server ungültig erklärt wird. Dieser Wert muss größer oder gleich der Standardsessionlänge jeder einzelnen bereitgestellten Anwendung sein. A -1 (Standardwert): Die Dauer der SIP-Session ist unbegrenzt. MBean-Attribut: `SipServerBean.MaxApplicationSessionLifetime` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Lokales Dispatch aktivieren | Die aktivierte Serveroptimierung verhindert unnötigen Netzwerkverkehr beim Senden und Weiterleiten von Nachrichten. Wenn eine Serverinstanz Nachrichten an die Cluster-Adresse einer Engine Tier oder an die lokale Serveradresse senden und weiterleiten muss, wird die Nachricht nicht über das Netzwerk, sondern intern an den lokalen Server geroutet. MBean-Attribut: `SipServerBean.EnableLocalDispatch` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Standardverhalten des SIP-Servers | Das Standardverhalten der WebLogic Communications Server-Instanz, wenn der Server die eingehende SIP-Anforderung keinem bereitgestellten SIP-Servlet zuordnen kann oder das übereinstimmende Servlet invalidiert oder aufgrund von Zeitüberschreitung deaktiviert wurde. Gültige Werte: proxy: agiert als zustandsloser Proxyserver ua: agiert als User Agent "proxy" wird als Standard verwendet, wenn Sie keinen Wert angeben. Als User Agent (UA) ist das Antwortverhalten bei SIP-Anforderungen von WebLogic Communications Server wie folgt: ACK-Anforderungen werden ohne weitere Benachrichtigung verworfen. CANCEL- oder BYE-Anforderungen erhalten den Antwortcode 481 - Transaktion ist nicht vorhanden. Alle anderen Anforderungen erhalten den Antwortcode 500 - Interner Serverfehler Agiert der Server als zustandsloser Proxy, werden die Anforderungen automatisch an einen Outbound-Proxy weitergeleitet (falls konfiguriert). Wurde kein Proxy definiert, leitet WebLogic Communications Server nur dann an einen angegebenen Anforderungs-URI weiter, wenn der Anforderungs-URI nicht mit IP und Portnummer einer bekannten lokalen Adresse für einen SIP Servlet-Container oder eine Load Balancer-Adresse übereinstimmt, die für den Server konfiguriert wurde. So wird sichergestellt, dass die Anforderung nicht kontinuierlich zu denselben Servern geleitet wird. Wenn der Anforderungs-URI einer lokalen Container-Adresse oder Load Balancer-Adresse entspricht, agiert WebLogic Communications Server stattdessen als UA. MBean-Attribut: `SipServerBean.DefaultBehavior` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Einfügen von Server-Header | Gibt die Bedingungen für das Einfügen von Server-Headern in SIP-Nachrichten an. Mit diesem Attribut können Sie Server-Header beschränken oder ganz weglassen, um so die Nachrichtengröße für mobile Netzwerke zu reduzieren oder die Sicherheit zu erhöhen. Wählen Sie einen der folgenden Zeichenfolgenwerte aus, um das Verhalten zu konfigurieren: none (Standard): Es wird kein Server-Header eingefügt request: Der Server-Header wird nur für SIP-Anforderungen eingefügt, die vom Server generiert werden. response: Der Server-Header wird nur für SIP-Antworten eingefügt, die vom Server generiert werden. all: Der Server-Header wird für alle SIP-Anforderungen und -Antworten eingefügt. Gemäß der Standardeinstellung fügt WebLogic Communications Server keine Server-Header in SIP-Nachrichten ein. MBean-Attribut: `SipServerBean.ServerHeader`
> Server-Header-Wert | Der Wert der in SIP-Nachrichten eingefügten Server-Header. Mit WebLogic Communications Server können Sie den Text steuern, der in die Server-Header generierter Nachrichten eingefügt wird. Sie haben so zusätzliche Kontrolle über die Größe der SIP-Nachrichten. Darüber hinaus können Sie die Serverinstanz zur Sicherheit maskieren. Um den Inhalt des Headers zu konfigurieren, geben Sie einen Zeichenfolgenwert ein. Standardmäßig fügt WebLogic Communications Server keine Server-Header in generierte SIP-Nachrichten ein. Wenn die Option "Einfügen von Server-Header" aktiviert, jedoch kein Wert für einen Server-Header angegeben ist, fügt WebLogic Communications Server den Wert "WebLogic SIP Server" ein. MBean-Attribut: `SipServerBean.ServerHeaderValue`
> Standardform für Einfügen von Header | Gibt an, wie der Server Regeln für die Komprimierung von SIP-Nachrichten-Headern anwendet Mit dieser Option wird das serverweite Standardverhalten bezüglich der Verwendung oder Beibehaltung kompakter Header in SIP-Nachrichten konfiguriert. Sie können diese Option auf einen der folgenden Werte einstellen: compact: WebLogic Communications Server komprimiert alle systemgenerierten Header. Bei Headern, die von der ursprünglichen Nachricht kopiert (also nicht generiert) werden, wird das ursprüngliche Format übernommen. force compact: WebLogic Communications Server komprimiert alle Header. Lange Header aus bestehenden Nachrichten werden gegebenenfalls in komprimierte Header umgewandelt. long: WebLogic Communications Server verwendet das lange Format für alle systemgenerierten Header. Bei Headern, die von der ursprünglichen Nachricht kopiert (also nicht generiert) werden, wird das ursprüngliche Format übernommen. force long: WebLogic Communications Server verwendet das lange Format für alle Header. Komprimierte Header aus bestehenden Nachrichten werden gegebenenfalls in lange Header umgewandelt. MBean-Attribut: `SipServerBean.UseHeaderForm`
> DNS-Serversuche aktivieren | Gibt an, ob der Server eine DNS-Suche durchführt. Wenn Sie für dieses Attribut "true" einstellen, kann der Server mit DNS die folgenden Aufgaben ausführen: Informationen zu Transport, IP-Adresse und Port-Nummer eines Proxy-Servers ermitteln, wenn eine Anforderung an einen SIP-URI gesendet wird. IP-Adresse und/oder Port-Nummer während des Antwort-Routings auflösen, je nach Inhalt im Feld "Gesendet von". Bei der Proxy-Ermittlung verwendet WebLogic Communications Server die DNS-Auflösung nur ein Mal pro SIP-Transaktion, um Transport-, IP- und Port-Nummerinformationen zu bestimmen. Alle Neuübertragungen, ACKs oder CANCEL-Anforderungen werden über dieselbe Transportmethode an dieselbe Adresse und denselben Port geliefert. Informationen zur DNS-Auflösung finden Sie unter RFC 3263: Session Initiation Protocol (SIP): SIP-Server suchen. Wenn ein Proxy eine Antwortnachricht senden muss, ermittelt WebLogic Communications Server mit der DNS-Suchfunktion die IP-Adresse und Port-Nummer des Zieles, je nachdem, welche Informationen im Feld "Gesendet von" und über den Header bereitgestellt werden. Standardmäßig wird keine DNS-Auflösung verwendet ("false"). Hinweis: Da die DNS-Auflösung innerhalb des Kontextes der SIP-Nachrichtenverarbeitung ausgeführt wird, führen alle DNS-Performanceprobleme zu einer Performance mit erhöhter Latenz. Oracle empfiehlt die Verwendung eines DNS-Servers in einer Production-Umgebung, um potenziellen Performanceproblemen vorzubeugen. MBean-Attribut: `SipServerBean.EnableDnsSrvLookup`
> Aufrufstatuscache aktivieren | Gibt an, ob die Engines einen Teil der Aufrufstatusdaten lokal cachen. MBean-Attribut: `SipServerBean.EngineCallStateCacheEnabled` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Contact Header für Non-Reliable Provisional (1xx) Response aktivieren | Gibt an, ob der Server Contact Header in nicht zuverlässige provisorische (1xx) Antworten mit dem Tag "An" aufnimmt. Dies ist für 100 nicht relevant. Mögliche Werte sind "true" und "false". Wenn Sie dieses Attribut auf "true" einstellen, werden Contact Header aufgenommen, bei "false" werden sie nicht aufgenommen. MBean-Attribut: `SipServerBean.EnableContactProvisionalResponse`
> Global routbarer URI | Ein global routbarer Benutzeragent-URI (GRUU), den WebLogic Communications Server automatisch in Contact Header und Route-Set Header einfügt, wenn mit Netzwerkelementen kommuniziert wird. Der in diesem Element angegebene URI sollte der GRUU für das gesamte WebLogic Communications Server-Cluster sein. Geben Sie in einer Domain mit einem Server ein GRUU für den Server selbst an. Beachten Sie, dass User Agents (UAs), die auf WebLogic Communications Server bereitgestellt werden, die GRUUs in der Regel über eine Registrierungsanforderung abfragen. In diesem Fall ist der Anwendungscode sowohl für die Anforderung als auch die anschließende Bearbeitung des GRUU zuständig. Um einen GRUU anzufordern, fügt der UA den Feldparameter "+sip.instance" des Contact Headers in alle Kontakte ein, für die GRUU erforderlich ist. Der UA verwendet den GRUU nach seinem Eingang bei der Generierung neuer Anforderungen als URI für das Contact Header-Feld. MBean-Attribut: `SipServerBean.GloballyRoutableUri` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Timer-Affinität aktivieren | Gibt an, ob die einzelnen Timer in der Engine verarbeitet werden, in der sie festgelegt wurden. Wenn dieses Attribut auf "true" eingestellt ist, werden die Timer in der Engine verarbeitet, in der sie erstellt wurden. Für einige Anwendungen ist dieser Aspekt wichtig. Bei "false" können Timer auch in beliebigen Engines verarbeitet werden. MBean-Attribut: `SipServerBean.EnableTimerAffinity`
> Retry After-Wert | Gibt an, wie viele Sekunden im Retry After-Header für 5xx Antworten angegeben werden. Dieser Wert kann auch einen Parameter oder einen Grund beinhalten, beispielsweise "Retry-After: 18000;duration=3600" oder "Retry-After: 120 (Ich bin in einer Besprechung)." Ist dieser Wert nicht konfiguriert, verwendet WebLogic Communications Server den Standardwert von 180 Sekunden. MBean-Attribut: `SipServerBean.RetryAfterValue` Änderungen werden wirksam, nachdem Sie das Modul erneut bereitgestellt oder den Server neu gestartet haben.
> Domainaliasnamen | Die Liste der Domains, für die der Server verantwortlich ist. Nachrichten an Domains in dieser Liste werden lokal verarbeitet und nicht weitergeleitet. Sie können vollständig qualifizierte Namen in die Liste aufnehmen oder Namen, die mit einem Platzhalterzeichen beginnen, wie etwa *.mycompany.com. MBean-Attribut: `SipServerBean.DomainAliasNames`
> Symmetrisches Response Routing | Gibt an, ob das symmetrische Response Routing (über den Parameter "rport") für Anforderungen angefordert wird, die von WebLogic Communications Server generiert werden. Bei Aktivierung dieser Option tritt das symmetrische Response Routing in Kraft, wie in RFC3581 definiert. MBean-Attribut: `SipServerBean.EnableRport`
> Dumpebene für Diagnosebild | Gibt die Detailebene an, die in Diagnosebilddateien aufgezeichnet werden soll. "basic" zeichnet alle möglichen Daten außer Aufrufstatusdaten auf. "full" zeichnet alle Daten einschließlich Aufrufstatusdaten auf. MBean-Attribut: `SipServerBean.ImageDumpLevel`
> Veraltete Sessionverarbeitung | Die Maßnahme, die ausgeführt werden muss, wenn eine eingehende Nachricht fehlerhafte Session-IDs enthält. WebLogic Communications Server codiert die IDs für Session und Aufrufstatus in ausgehende URLs. So kann in Rückgabenachrichten die korrekte Session erkannt werden. Die folgenden Werte geben an, welche Maßnahme ausgeführt werden soll, wenn eine eingehende Nachricht fehlerhafte Session-IDs enthält. error: Mit dem Fehler 481 oder 404 antworten. continue: Der codierte Bezeichner wird ignoriert und die Nachricht wird weiterverarbeitet. drop: Die Nachricht wird ohne Rückfrage gelöscht. Die Standardaktion ist "error". MBean-Attribut: `SipServerBean.StaleSessionHandling`