7960 & Sipgate

[Wildi]

Hallo Gemeinde,

ich verwende schon eine ganze Weile ein Cisco 7960 (FW 7.5) mit zwei SipGate Accounts. Eigentlich funktioniert das ganz prima, wenn dann nicht ein paar Zuverlässigkeitsprobleme wären.

Auf meiner Firewall sind die Ports 5060UDP und 16384-16398UDP auf das Phone geforwardet.

Wenn ich das Phone ausstecke und wieder anstecke (warten auf Boot), gehen alle Accounts wunderbar. Ich erreiche alles/ich werde erreicht. Steht das Phone aber einfach so rum ... Stunden ... Tage ... Wochen, dann geht nicht mehr wirklich viel.

Anrufer kommen direkt auf meine Voicebox, oder es klingelt - wenn ich abhebe hör ich keinen, oder wenn ich jemanden anrufe krieg ich zwar den Freiton - wenn dann aber einer abhebt hör ich nix mehr (der andere hört mich auch nicht) usw. usw.

An was könnte das denn liegen? Die tägliche Zwangstrennung von DSL mit neuer öffentlicher IP? Zuverlässigkeit von SipGate? Fehler in der Konfig der cnf-Dateien?

So ist das VoIP'en eigentlich ne super Sache. Es hilft blos nichts wenn es so unzuverlässig ist

 

[cobra]

Hallo!

War bei mir genauso, nach jeder 24h-Trennung war das Problem wieder akut. Man musste immer einen Anruf durchfuehren, der dann nicht ging, und dann gingen komischerweise die naechsten meisstens besser.
Erst als ich einen DynDNS-Account eingerichtet hatte lief die Sache.

 

[Wildi]

Danke für die Info, aber ich frage mich was das mit dem DynDNS Account zu tun hat.

Mein Netzwerk ist ein Domänennetzwerk. Die Firewall ist ein ISA 2004. Davor hängt ein Router zum DSL. Dieser hat zwar einen aktiven DynDNS, jedoch ist der für Erreichbarkeitszwecken meines IIS, OWA, Sharepoint usw. auf die betreffenden Ports geforwardet (443, 80, usw.). Auch ja, dieser Router ist komplett geDMZ'et auf die externe NIC des ISA.

OK zugegeben, durch die Serververöffentlichungen auf das Telefon (Port 5060 und 16384-16398 ) sind die zwar auch über xxx.dyndns.orgort zu erreichen, jedoch im Fall von SipGate, wenn ich Deiner Aussage folgen kann, müsste ich den DynDNS Account ja auf der WebGUI von www.sipgate.de hinterlegen. Das geht meines Wissens aber nicht.

Nichts desto trotz wäre selbst wenn das Spielchen doppelt gemoppelt und hätte dennoch diese Störungen zur Folge (bei Zwangstrennung). Denn irgendwann wird halt mal getrennt. Ob sich nun der DNS bei DynDNS aktualisiert oder die IP bei SipGate dürfte eigentlich egal sein. Deiner Aussage zu Folge würde das Problem dann immer und vor allem bei ALLEN SIP-Usern, gleichgültig welchen Providers mit einer A-DSL immer bestehen.

Außerdem passiert der Fehler ganz sporadisch. Also nicht, heute gehts - nach der Nacht nimma. Es ist auh manchmal so, vormittag gehts - Nachmittag die Fehler, neuer Boot am Tel. - geht wieder.

 

[cobra]

Dein Problem muss ja nicht unbedingt damit zu tun haben, war bei mir aber zeitlich mit dem DynDNS-Account behoben. Natuerlich habe ich auch noch andere Experimente zeitgleich durchgefuehrt.

Bei mir steht der Eintrage bei ' nat_address: "name.dyndns.org" '.
Auf diese Art weiss das Phone wenigstens seine eigene Adresse.

Allerdings ist auch die Frage auf was bei Dir die Gueltigkeit der Registrierung steht.
timer_register_expires: 180

Deiner Aussage zu Folge würde das Problem dann immer und vor allem bei ALLEN SIP-Usern, gleichgültig welchen Providers mit einer A-DSL immer bestehen.

Richtig, geht auch vielen Usern so. Deshalb empfehle ich immer DynDNS - ob es hilft muss sich dann im Einzelfalle zeigen. Nicht jeder User meldet sich wenn es zwar grundsaetzlich geht, aber nicht immer - leider. Sonst haetten wir evtl. inzwischen etwas mehr Input zu diesem Problem.

Ich weiss nicht woran es genau liegt, aber bei einigen Usern hat es etwas gebracht mit den NAT_Einstellungen zu spielen:
nat_enable: 1 / 0
nat_received_processing: 1 / 0

Schlimmstenfalls musst Du saemtliche Configs posten, die des Phones, die des Routers und der Firewall, und dann hoffen jemanden zu finden, der auch den Router und die F/W kennt.

 

[Wildi]

OK, herzlichen Dank für die Erklärung. Damit lässt sich arbeiten.

Wenn ich das von Dir so raus höre schiebst Du das Problem ziemlich auf die Trennung und die daraus resultierende 'Trägheit' der IP/DNS Registrierung.
Ist eine Möglichkeit, wirkt mit Sicherheit mit rein bzw. verstärkt das Problem, aber da es z.B. bei mir auch mitten unterm Tag passiert glaube ich jetzt nicht das es das ausschlaggebende Prob ist - aber ich werde mal an Deinen vorgeschlagenen Einträgen basteln

Persönlich dachte ich eher an einen Fehler der Portvergabe. Da habe ich scheinbar ein kleines (großes) Verständnisproblem. Vielleicht könntest Du mich da etwas aufklären.

Ich hatte vor dem Cisco zwei Grandstream Phones. Das mit den Ports war mir da einleuchtend. Außerdem habe ich 4 SipGate Accounts

Grandstream-Konfig (Phone 1):
Port 5004 und für Account 1 Port 5060 und für Account 2 Port 5062

Grandstream-Konfig (Phone 2):
Port 5005 und für Account 1 Port 5064 und für Account 2 Port 5066

Ich bin davon ausgegangen, das jedes Gerät (Phone) einen Port brauchte und jeder Account. Das ging zumindest auch so tadellos.

--------------------------------------------------------

Jetzt bei dem Cisco bin ich mit den Ports etwas verwirrt (1x CISCO 7960 und alle Accounts drauf)

Hier soll man für alle Accounts unter proxy(x)_port, voip_control_port, proxy_emergency_port und proxy_backup_port den 5060 verwenden. (Ich nehme mal an, wenn ich ein 2. hätte, dann sollte da wohl Port 5061 oder 5062 usw. rein?

Und für start_media_port und end_media_port sollte 16384-32744 rein. Wobei ich die erheblich gekürzt habe, weil ca. 15000 Ports will ich dann auch nicht einfach so auf machen. Es würde ja reichen wenn ich für die 4 Accounts theoretisch nur 4 Media Ports auf mache, oder?

Danke

 

[cobra]

Hier soll man für alle Accounts unter proxy(x)_port, voip_control_port, proxy_emergency_port und proxy_backup_port den 5060 verwenden.

Ja, so laeuft es bei mir. Allerdings habe ich nicht mehrere Accounts des selben Providers installiert. Kannst ja gerne mal testen was passiert, wenn Du die Proxy-ports aenderst.
proxy1_port: 5060
proxy2_port: 5062
...
Normalerweise sollte m.E. schon die Registrierung nicht funktionieren.
Angeblich benoetigt Sipgate auch den Port 5004 - keine Ahnung wozu, auch nur gelesen.

(Ich nehme mal an, wenn ich ein 2. hätte, dann sollte da wohl Port 5061 oder 5062 usw. rein?

Also das einzige was ich geaendert habe um mehrere 7960 zu betreiben ist:
voip_control_port: 5061 gesetzt und eins hoeher fuer jedes weitere Phone
start_media_port: 30010 end_media_port: 30019 und zehn hoeher fuer jedes weitere Phone.

Wenn ich das von Dir so raus höre schiebst Du das Problem ziemlich auf die Trennung [...] aber da es z.B. bei mir auch mitten unterm Tag passiert glaube ich jetzt nicht das es das ausschlaggebende Prob ist

Ich schiebe es nicht auf die 24h-Trennung, ich hoffe es nur, weil es das Einfachste ist.
Aber die verwendeten Ports aendern sich ja auch nicht waerend des Tages, daher ist das genauso merkwuerdig...
Ich glaube stark, dass die Art der verwendeten NAT eine Rolle spielt, da ich darueber schon des oefteren gelesen habe, allerdings habe ich keinen Schimmer, was es da an Unterschieden gibt.

 

[Wildi]

Ja, so laeuft es bei mir. Allerdings habe ich nicht mehrere Accounts des selben Providers installiert. Kannst ja gerne mal testen was passiert, wenn Du die Proxy-ports aenderst.
proxy1_port: 5060
proxy2_port: 5062
...

So hatte ich das vorher. Irgendwo habe ich gelesen, dass die proxy(x)_port immer auf 5060 sein sollte, bei jedem Account, auch wenn unterschiedliche Provider. Seit dem ich bei allen Accounts auf 5060 gestellt habe, hab ich den Eindruck es geht besser.

Angeblich benoetigt Sipgate auch den Port 5004 - keine Ahnung wozu, auch nur gelesen.

5004 lese ich sehr oft in Verbindung mit STUN. Nun, ich bin Netzwerkler, kein Telekomiker. Soweit ich das aus dem Lesen interpretiere hat der Port was mit einer Vereinfachten Konfiguration über Firewalls zu tun. Bei SIP ist ja der Nachteil, dass man zwingend Ports zum Phone öffnen muss. Zu Hause hast Du das in der Hand. Aber was ist im Hotel? Hier soll das STUN offensichtlich dafür sorgen, dass ein virtueller 'STUN'-Tunnel über wohl http (???) aufgemacht wird und alles darüber ohne Portforwarding geschieht. So interpretiere ich zumindest STUN aus den eher sperlichen Informationen, die ich darüber habe.

Die Aussage beißt sich allerdings mit meinen Grandstream Phones. Hier war z.B. 5004 grundeingestellt für nen Mediaport. Allerdings war die Grundeinstellung dort auch, das 5004 der STUN ist.

Also das einzige was ich geaendert habe um mehrere 7960 zu betreiben ist:
voip_control_port: 5061 gesetzt und eins hoeher fuer jedes weitere Phone
start_media_port: 30010 end_media_port: 30019 und zehn hoeher fuer jedes weitere Phone.

OK, das jedes Phone seine eigenen Media Ports besitzt leuchtet mir ein. Das voip_control_port auch um 5060+x je Phone gesetzt wird auch. Aber müsste ich dann nicht auch die proxy(x)_port z.B. auf 5061 setzen?

Ich wüßte sonst nicht, wie ich ein anderes Phone in der Firewall forwarde.
Für das Phone 1 hätte ich ja in der Firewall die Ports 5060UDP und 16384-16398UDP geforwardet (Ausgehend davon, dass ich so wie bei mir alle Accounts auf 5060 habe)

Für das Phone 2 würde ich dann z.B. Port 5061UDP und 16484-16498UDP forwarden. Wären für die proxy(x)_port dann 5060 gesetzt, könnte ich ja diesen nimma forwarden, weil der schon für Phone 1 wäre.

Ich schiebe es nicht auf die 24h-Trennung, ich hoffe es nur, weil es das Einfachste ist.
Aber die verwendeten Ports aendern sich ja auch nicht waerend des Tages, daher ist das genauso merkwuerdig...

OK, ein Argument
Nein, die Ports ändern sich natürlich nicht. Aber wie ich schon weiter oben geschrieben habe, dachte ich eher an eine grundsätzliche Problematik bei mir an falsch gesetzten Ports.

Ich glaube stark, dass die Art der verwendeten NAT eine Rolle spielt, da ich darueber schon des oefteren gelesen habe, allerdings habe ich keinen Schimmer, was es da an Unterschieden gibt.

Also unterschiede bei NAT: Speziell bei NAT gibt es keine Unterschiede. Es gibt aber sehr wohl unterschiede beim Routing, also RIP-1 und RIP-2. Wobei das mit uns nichts zu tun hat, da geht es nur um die Metric (Hops). Ich wüsste jetzt auch nicht dass man das einstellen könnte an den Phones.

Alles was mit NAT beim Cisco zu tun hat ist:

nat_enable: 0/1 --> Geht das Phone über NAT (1= JA, 0=NEIN)
nat_address: "" --> Ok, ein guter Tipp von Dir. Hier kommt die WAN IP rein oder eben der DynDNS Host-FQDN
nat_received_processing: 0/1 --> Den Eintrag verstehe ich nicht so recht. Ich denke da geht es darum, ob der eingehende Verkehr auch über das NAT kommt (1=JA, 0=NEIN)

-----------------------------------------------------------
Ich habe mal meine beiden cnf's beigefügt. Wenn Du Lust hast kannst Du ja mal nen Blick drauf werfen.

 

[chaos2000]

also ich damals mein 7940 mit sipgate betrieben habe musste dich den 5004 UDP öffnen, da ich sonst nichts gehört habe - scheint so als ob sipgate die mediaports nicht beachtet.
unter nat_address babe ich den stun-server von sipgate eingetragen und alles funktionierte, auch nach 24h
Firmware war die 7.3

OK, das jedes Phone seine eigenen Media Ports besitzt leuchtet mir ein. Das voip_control_port auch um 5060+x je Phone gesetzt wird auch. Aber müsste ich dann nicht auch die proxy(x)_port z.B. auf 5061 setzen?

Ich wüßte sonst nicht, wie ich ein anderes Phone in der Firewall forwarde.
Für das Phone 1 hätte ich ja in der Firewall die Ports 5060UDP und 16384-16398UDP geforwardet (Ausgehend davon, dass ich so wie bei mir alle Accounts auf 5060 habe)

Für das Phone 2 würde ich dann z.B. Port 5061UDP und 16484-16498UDP forwarden. Wären für die proxy(x)_port dann 5060 gesetzt, könnte ich ja diesen nimma forwarden, weil der schon für Phone 1 wäre.

nein, die proxy_ports sind die ports beim provider, und diese sind "immer" 5060
Die zu forwarden Ports legst du mit voip_control_port fest

 

[Wildi]

@chaos2000

Hm, dann ist der Port 5060 bei proxy(x)_port ein Outgoing Port und kein Incomming?

Könntest Du mir vielleicht bitte mal zur Referenz Deine beiden cnf's posten?

 

[chaos2000]

ja;

die sipgateconf habe ich nicht mehr, da ich jetzt mit localen asterisk arbeite;

Ich versuche es mal zu rekonstruieren:
Sipdefault:

# SIP Default Generic Configuration File

# Image Version
image_version: P0S3-07-5-00

# Proxy Server
proxy1_address: "sipgate.de"		; Can be dotted IP or FQDN
proxy2_address: ""			; Can be dotted IP or FQDN
#proxy2_address: ""		; Can be dotted IP or FQDN
#proxy3_address: ""		; Can be dotted IP or FQDN
#proxy4_address: ""		; Can be dotted IP or FQDN
#proxy5_address: ""		; Can be dotted IP or FQDN
#proxy6_address: ""		; Can be dotted IP or FQDN

# Proxy Server Port (default - 5060)
proxy1_port: 5060
#proxy2_port: 5060
#proxy3_port: 5060
#proxy4_port: 5060
#proxy5_port: 5060
#proxy6_port: 5060

# Proxy Registration (0-disable (default), 1-enable)
proxy_register: 1

# Phone Registration Expiration [1-3932100 sec] (Default - 3600)
timer_register_expires: 3600

# Codec for media stream (g711ulaw (default), g711alaw, g729a)
preferred_codec: g711ulaw

# TOS bits in media stream [0-5] (Default - 5)
tos_media: 5

# Inband DTMF Settings (0-disable, 1-enable (default))
dtmf_inband: 1

# Out of band DTMF Settings (none-disable, avt-avt enable (default), avt_always - always avt )
dtmf_outofband: avt_always

# DTMF dB Level Settings (1-6dB down, 2-3db down, 3-nominal (default), 4-3db up, 5-6dB up)
dtmf_db_level: 3

# SIP Timers
timer_t1: 500 			; Default 500 msec
timer_t2: 4000 			; Default 4 sec
sip_retx: 10			; Default 10
sip_invite_retx: 6 		; Default 6
timer_invite_expires: 180 	; Default 180 sec

####### New Parameters added in Release 2.0 #######

# Dialplan template (.xml format file relative to the TFTP root directory)
dial_template: "dialplan"

# TFTP Phone Specific Configuration File Directory
tftp_cfg_dir: "./cisco_voipphones/"		; Example:  ./sip_phone/

# Time Server (There are multiple values and configurations refer to Admin Guide for Specifics)
#sntp_server: "217.10.79.4"			; SNTP Server IP Address
sntp_server: "192.53.103.103"			; SNTP Server IP Address ptbtime1.ptb.de
;sntp_mode: directedbroadcast	; unicast, multicast, anycast, or directedbroadcast (default)
sntp_mode: unicast		; unicast, multicast, anycast, or directedbroadcast (default)
time_zone: CET			; Time Zone Phone is in
dst_offset: 1			; Offset from Phone's time when DST is in effect
dst_start_month: March		; Month in which DST starts
dst_start_day: ""		; Day of month in which DST starts
dst_start_day_of_week: Sunday	; Day of week in which DST starts
dst_start_week_of_month: 8	; Week of month in which DST starts
dst_start_time: 02		; Time of day in which DST starts
dst_stop_month: Oct		; Month in which DST stops
dst_stop_day: ""		; Day of month in which DST stops
dst_stop_day_of_week: Sunday	; Day of week in which DST stops
dst_stop_week_of_month: 8	; Week of month in which DST stops 8=last week of month
dst_stop_time: 2		; Time of day in which DST stops
dst_auto_adjust: 1		; Enable(1-Default)/Disable(0) DST automatic adjustment
time_format_24hr: 1		; Enable(1 - 24Hr Default)/Disable(0 - 12Hr)


# Do Not Disturb Control (0-off, 1-on, 2-off with no user control, 3-on with no user control)
dnd_control: 1			; Default 0 (Do Not Disturb feature is off)

# Caller ID Blocking (0-disbaled, 1-enabled, 2-disabled no user control, 3-enabled no user control)
callerid_blocking: 0		; Default 0 (Disable sending all calls as anonymous)

# Anonymous Call Blocking (0-disabled, 1-enabled, 2-disabled no user control, 3-enabled no user control)
anonymous_call_block: 0		; Default 0 (Disable blocking of anonymous calls)

# DTMF AVT Payload (Dynamic payload range for AVT tones - 96-127)
dtmf_avt_payload: 101		; Default 101

# Sync value of the phone used for remote reset
sync: 1				; Default 1

####### New Parameters added in Release 2.1 #######

# Backup Proxy Support
proxy_backup: "UNPROVISIONED"		; Dotted IP of Backup Proxy
proxy_backup_port: 5060		; Backup Proxy port (default is 5060)

# Emergency Proxy Support
proxy_emergency: "UNPROVISIONED" 		; Dotted IP of Emergency Proxy
proxy_emergency_port: 5060	; Emergency Proxy port (default is 5060)

# Configurable VAD option
enable_vad: 0			; VAD setting 0-disable (Default), 1-enable

####### New Parameters added in Release 2.2 ######

# NAT/Firewall Traversal
nat_enable: 1                   ; 0-Disabled (default), 1-Enabled
nat_address: stun.sipgate.net:10000    ; WAN IP address of NAT box (dotted IP or DNS A record only)
voip_control_port: 5060      	; UDP port used for SIP messages (default - 5060)
start_media_port: 30000 	; Start RTP range for media (default - 16384)
end_media_port: 30010   	; End RTP range for media (default - 32766)
nat_received_processing: 1	; 0-Disabled (default), 1-Enabled

# Outbound Proxy Support
outbound_proxy: ""	 	; restricted to dotted IP or DNS A record only
outbound_proxy_port: 5060       ; default is 5060

####### New Parameter added in Release 3.0 #######

# Allow for the bridge on a 3way call to join remaining parties upon hangup
cnf_join_enable : 1		; 0-Disabled, 1-Enabled (default)

####### New Parameters added in Release 3.1 #######

# Allow Transfer to be completed while target phone is still ringing
semi_attended_transfer: 1	; 0-Disabled, 1-Enabled (default)

# Telnet Level (enable or disable the ability to telnet into the phone)
telnet_level: 2			; 0-Disabled (default), 1-Enabled, 2-Privileged

####### New Parameters added in Release 4.0 #######

# XML URLs
#services_url: http://flame.tiefighter.org/fwd/xml/			; URL for external Phone Services
#services_url: http://phone-xml.berbee.com/menu.xml			; URL for external Phone Services
#services_url: http://172.17.1.2/voip/am-web/				; URL for external Phone Services
services_url: http://www.voip-info.de/feed/cisco7960/index.xml		; URL for News-feed



directory_url: "http://webserver/voip/directory.xml"		; URL for external Directory location
logo_url: "http://webserver/voip/asterisk-tux.bmp"			; URL for branding logo to be used on phone display

# HTTP Proxy Support
http_proxy_addr: "" 		; Address of HTTP Proxy server
http_proxy_port: 80		; Port of HTTP Proxy Server (80-default)

# Dynamic DNS/TFTP Support
dyn_dns_addr_1: ""              ; restricted to dotted IP
dyn_dns_addr_2: ""              ; restricted to dotted IP
dyn_tftp_addr: ""               ; restricted to dotted IP

# Remote Party ID
remote_party_id: 0		; 0-Disabled (default), 1-Enabled

####### New Parameters added in Release 4.4 #######

# Call Hold Ringback (0-off, 1-on, 2-off with no user control, 3-on with no user control)
call_hold_ringback: 0		; Default 0 (Call Hold Ringback feature is off)

####### New Parameters added in Release 6.0 #######

# Dialtone Stutter for MWI
stutter_msg_waiting: 1		; 0-Disabled (default), 1-Enabled

# RTP Call Statistics (SIP BYE/200 OK message exchange)
call_stats: 1			; 0-Disabled (default), 1-Enabled

ACHTUNG - auf Zeilenumbrüche achten

 

[Wildi]

Vielen Dank für Deine Bemühungen. Eigentlich sieht die cnf ziemlich identisch mit meiner aus.

Ausnahme:
nat_address: stun.sipgate.net:10000

Dazu ne doofe Frage. Wenn ich diesen Eintrag in die SIPDefault oder SIP<mac>.cnf eintrage, gilt es für alle Phones bzw. mindestens für DAS Phone gesamt. Hätte ich jetzt weitere Accounts von anderen Providern, hätte ich doch das Problem, das die nicht gehen, weil zentral auf --> stun.sipgate.de:10000. Oder mach ich da jetzt nen Gedankenfehler?

Außerdem wäre es mal interessant zu wissen, welche Befehle für Ports als Eingehend oder Ausgehend definiert sind.

nat_address: stun.sipgate.net:10000
(Ausgehend?)

http_proxy_addr: ""
http_proxy_port: 80
(Ausgehend?)

proxy_backup: "UNPROVISIONED"
proxy_backup_port: 5060
(Ausgehend?)

proxy_emergency: "UNPROVISIONED"
proxy_emergency_port: 5060
(Ausgehend?)

voip_control_port: 5060
start_media_port: 30000
end_media_port: 30010
(Eingehend?)

outbound_proxy: ""
outbound_proxy_port: 5060
(Ausgehend?)

proxy(x)_port: 5060
(Ausgehend?)

 

[chaos2000]

nat_address: user.dyndns.org
(Ausgehend?) - jein, es sagt dem registrar welche ip das phone hat

http_proxy_addr: ""
http_proxy_port: 80
(Ausgehend?) - für die services

proxy_backup: "UNPROVISIONED"
proxy_backup_port: 5060
(Ausgehend?) - ja

proxy_emergency: "UNPROVISIONED"
proxy_emergency_port: 5060
(Ausgehend?) - ja

voip_control_port: 5060
start_media_port: 30000
end_media_port: 30010
(Eingehend?) - ja

outbound_proxy: ""
outbound_proxy_port: 5060
(Ausgehend?) - ja

proxy(x)_port: 5060
(Ausgehend?)

 

[Wildi]

Danke

Hmmm, ich habe heute mal ein UTStarcom F1000 W-LAN Phone getestet. Alles wech - F1000 ran. Account eingerichtet. Auf der Firewall 5060 und 10010 zum F1000 freigegben und wie ein Bl.öder hin und her telefoniert.

Bisher hat es keine Zicken gemacht.

Dann das F1000 wech und ein Grandstream GXP-2000 dran. Hier Port 5060 und 5004 geforwardet und es ging auch. Als ich aber dann einen 2. SipGate Account an dem Phone eingerichtet habe, fingen die Probleme wieder an.

Um heute Nacht mal das Verhalten wegen der Zwangstrennung zu beobachten, hängt wieder das F1000 dran. Das läuft nach meinem Eindruck bisher am stabilsten. Jetzt warte ich mal bis morgen früh, ob es ohne neuen Boot noch geht.

Und wenn, dann konfigurier ich das CISCO auf mal auf nur einen Account. Hab die Phones bisher immer mit mindestens zwei Accounts betrieben.

Ich bin diesbezüglich auch mit der SipGate Hotline per eMail in Kontakt.
Zumindest habe ich deshalb jetzt auch ein bisschen Licht ins Dunkel wegen STUN gebracht:

SIP arbeitet auf Layer 7/6. Daher gibt es keine Routinginformatinen zurück. Ohne STUN wird also immer nur das letzte Netz preis gegeben. Das ist allerdings in der Regel das private Netz. STUN liefert jedoch die Informatinen VOR dem letzten Router zurück. Das ist zu Hause in der Regel die öffentliche IP. Funktioniert also ähnlich wie DynDNS.
Die Aufgabe von STUN erklärt jetzt auch, wieso es bei mir nicht geht und weshalb ich es um einigermaßen Erfolg haben zu können, deaktivieren muss.

Ich habe ja:

DSL ---- Router ---- ISA-Server ---- lok. Netz (Server, Clients, Phones)

Der ISA ist auch als Router zu betrachten. Das Netz zwischen Router und ISA ist ebenfalls ein privates Netz. Da STUN die IP des letzten Netzes vor dem letzten Router zurückliefert, kommt bei mir das Transfernetz zurück, dass SipGate oder anderen Providern nicht hilft.

Habe heute den Port 10000 auch mal gesnift. Ist tatsächlich so. Ich müsste also die Phones noch vor den ISA hängen, damit ich STUN einsetzen könnte, oder ich muss mich mal in die STUN-Geschichte tiefer reinarbeiten. Vielleicht gibt es ja so was ähnliches wie nen STUN Relay Agent, damit ich ihm sage er soll nicht die IP des letzten, sondern des vorletzten Routers übermitteln.

 

[chaos2000]

oder du richtest einen dyndns-accout ein mit der öffentlichen ip und sendest diese. Funktioniert mit meinem Asterisk ohne probleme