AutoProvisioning meldet falschen Port

shenke · Mar 3rd 2015

Hallo zusammen,
wir mussten bei unserer STARFACE den SIP Port ändern. Dies hat auch mit Hilfe der Anleitung im Wiki (https://wiki.starface.de/index.php/STARFACEhinterFritzbox) ganz unproblematisch geklappt.

Allerdings meldet der Provisioning-Server unserer Anlage immer noch den Standard-SIP-Port 5060 an alle Geräte, anstatt des neuen Ports. Resultiert am Ende darin, dass sich die Geräte auf dem "toten" Port versuchen anzumelden.

Gibt es noch eine andere Stelle die abzuändern wäre oder wo bezieht der Provisioning-Server seine Werte für die Configdateien ?

Anbei ein Auszug aus einem tcpdump.

HTTP

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Pragma: No-cache
Cache-Control: no-cache
Expires: Thu, 01 Jan 1970 01:00:00 CET
Content-Type: text
Content-Length: 5878
Date: Fri, 27 Feb 2015 17:32:48 GMT


#!version:1.0.0.1


##File header "#!version:1.0.0.1" can not be edited or deleted.##


#####Basic Settings file for Yealink T42 #####
...
account.1.sip_server.1.port = 5060
...
account.1.outbound_port = 5060

Display More

Sebastian

fwolf · Mar 3rd 2015

Persönlich würde ich davon absehen, den SIP-Port zu ändern. Stattdessen könnte man auf der STARFACE mit iptables den neuen UDP-Zielport auf UDP 5060 umschreiben. Damit wäre die Anlage unter beiden Ports für SIP erreichbar.

Philipp · Mar 3rd 2015

Hallo,

Änderungen am asterisk wirken sich nicht auf die STARFACE Autoprovisionierung aus, d.h. in den Telefonen muss der Port manuell geändert werden.
Daher auch die großen Ausrufezeichen im wiki-Artikel.

Gruß
Philipp

shenke · Mar 4th 2015

Fabian: Die Variante hatten wir schon getestet, allerdings wechselten die meisten Clients automatisch nach einiger Zeit selbstständig den SIP Port.
Bsp.: externer Client baut Verbindung über neuen Port auf, bekommt von der STARFACE die Kontaktdaten geschickt (welche den Standardport beinhaltet) und wechselt nach kurzer Zeit automatisch vom neuen auf den alten Port (der aber nur intern verfügbar ist).

Einzige Ausnahme war hier der SIP Client QuteCom.

Philipp: Danke für die Info. Ich bin davon ausgegangen, dass wenn STARFACE zur Generation der sip.conf den Datenbankeintrag heran zieht, dass auch die STARFACE Autoprovisionierung ihre Daten daraus bildet. Wäre für mich logisch gewesen.

Gruß
Sebastian

fwolf · Mar 4th 2015

Das Wechseln der SIP-Ports wird vermutlich dadurch verursacht, dass die SIP-Ports nicht nur im UDP-Header stehen, sondern zusätzlich in den SIP-Headern. Unter Umständen ist das Verhalten der Clients davon abhängig, ob diese von einem NAT-Szenario ausgehen oder nicht. Bitte den Clients mitteilen, dass NAT verwendet wird, dann sollten die Ziel-Ports aus dem UDP-Header extrahiert werden.

shenke · Jun 5th 2015

Hat jetzt (dank Probleme mit dem neuen Update) etwas länger gedauert.

Ich habe inzwischen das Problem lösen können. Es lag am Client (Jitsi), der alle gemachten Einstellungen ignoriert und mit dem gesonderten Port nicht klar kommt. Alle anderen Clients funktionieren jetzt problemlos.

Bin aber am überlegen ob die Variante über iptables nicht sinnvoller ist. Allerdings habe ich die Befürchtung, dass die Einstellungen nach einen Neustart/Update wieder verworfen werden. STARFACE holt sich die iptables-Info ja aus der Datenbank von STARFACE und generiert die Dateien unter /etc/sysconfig/ neu. Die allerdings enthält keine Einträge für die Tabelle PREROUTING.

Als Übergangslösung würde mir gerade nur ein Cronjob einfallen, der beim Systemstart die entsprechenden Einträge hinzufügt.

Grüße Sebastian

Participate now!