GXP2000 nach ~30 Sek Schluß

FRiP

Neuer User
Mitglied seit
25 Dez 2005
Beiträge
177
Punkte für Reaktionen
0
Punkte
16
Hallo,

also ich habe ein relativ schwerwiegendes Problem mit meinem GXP2000 (Program 1.1.2.25 Bootloader 1.1.1.5).
Ich habs bisher fast nur zum Raustelefonieren genutzt, weswegen ich das Problem bisher nicht festgestellt habe - jetzt nutze ich es jedoch auch für reinkommende Gespräche.

Das Problem ist, dass bei einkommenden Gesprächen nach ca. 30-40 Sekunden die Leitung "gekappt" wird. Die Anrufer sagen nachher immer, dass es sich anhören würde, als hätte ich einfach aufgelegt.

Also ich habe im Router folgende Ports geforwarded:
Code:
  	RTP for GXP  	TCP  	5004  	192.168.178.25
	GXP for Acc 1 	TCP 	5060 	192.168.178.25
	GXP for Acc 2 	TCP 	5062 	192.168.178.25
	GXP for Acc 3 	TCP 	5064 	192.168.178.25
	GXP for Acc 4 	TCP 	5066 	192.168.178.25

Es handelt sich bei dem Provider der incoming Nummer um sipgate - die Konfiguration im GXP sieht wie folgt aus:
Code:
SIP Server: sipgate.de
Outbound Proxy: sipgate.de
SIP User ID: meine Sipgate Nr ohne Vorwahl
Authenticate ID:  siehe SIP User ID
Use DNS SRV: No
User ID is phone number: No
SIP Registration: Yes
Unregister On Reboot: No
Register Expiration: 60
local SIP port: 5062
SIP T1 Timeout:  1 sec	 
SIP T2 Interval: 4 sec 
SIP Transport: UDP
Use RFC3581 Symmetric Routing: No
NAT Traversal (STUN): No
SUBSCRIBE for MWI: No
PUBLISH for Presence: No
Proxy-Require: sipgate.de
Voice Mail UserID: 50000
Send DTMF: via SIP INFO
Early Dial: No
Dial Plan Prefix: 
Delayed Call Forward Wait Time: 20
Enable Call Features: Yes (Call Forwarding/Call-Waiting-Disable supported locally)
Call Log: 	  Log All Calls
Session Expiration: 180
Min-SE: 90
Caller Request Timer: No
Callee Request Timer: No
Force Timer: No
UAC Specify Refresher: Omit (Recommended)
UAS Specify Refresher: UAC
Force INVITE: No
Enable 100rel: No
Send Anonymous: No
Anonymous Method: Use From Header
Anonymous Call Rejection: No
Auto Answer: 	  No 
Allow Auto Answer by Call-Info: No
Turn off speaker on remote disconnect: No  
Check SIP User ID for incoming INVITE: No
Refer-To Use Target Contact: No
Preferred Vocoder:
(in listed order) 	
choice 1:  G.722
choice 2:  PCMU
choice 3:  G723.1
SRTP Mode: Disabled
Special Feature: Standard

Ich bin ziemlich ratlos, zumal meine Telefon angeschlossen an der FritzBox funktionieren. Daher gehe ich auch davon aus, dass es an dem GXP liegt und nicht an Sipgate...

Würde mich sehr über Hilfe freuen!


MfG
 
Code:
   RTP for GXP  	TCP  	5004  	192.168.178.25
	GXP for Acc 1 	TCP 	5060 	192.168.178.25
	GXP for Acc 2 	TCP 	5062 	192.168.178.25
	GXP for Acc 3 	TCP 	5064 	192.168.178.25
	GXP for Acc 4 	TCP 	5066 	192.168.178.25

Mach mal aus TCP UDP.

Gruss hotroot
 
hotroot schrieb:
Code:
   RTP for GXP  	TCP  	5004  	192.168.178.25
	GXP for Acc 1 	TCP 	5060 	192.168.178.25
	GXP for Acc 2 	TCP 	5062 	192.168.178.25
	GXP for Acc 3 	TCP 	5064 	192.168.178.25
	GXP for Acc 4 	TCP 	5066 	192.168.178.25

Mach mal aus TCP UDP.

Gruss hotroot

Das mal auf jeden Fall, da SIP ausschließlich UDP verwendet.
Des Weiteren bin ich mir nicht ganz sicher, ob es ausreicht, nur den Port 5004, 5060, usw. freizugeben. Zumindest beim RTP-Port werden ja oftmals mehrere simultane Verbindungen aufgebaut. Von daher würde ich eher mit Portranges arbeiten, und so z.B. UDP 5004-5009 und 5060-5069 freigeben. Wenn du den RTP-Port deines Telefons auf 5051 legst, kannst du das ganze auch mit einer Regel abdecken, indem du die UDP-Range 5051-5069 an dein Telefon weiterleitest.
Als nächstest würde ich noch den Gebrauch von STUN in Erwägung ziehen (außer du sitzt hinter einer symmetrischen Firewall, wo STUN nicht funktioniert). Dazu STUN aktivieren und als Server stun.sipgate.net:10000 eintragen.
Und als letzten Tipp (hat aber mit deinem Problem nichts zu tun) würde ich PCMa anstelle von PCMu verwendet, da wir uns hier in Europa befinden.
Und bist du dir sicher, dass ein Registry-Timeout von nur 60 Sekunden passt? Ich persönlich fände es etwas unnötig, wenn sich das Telefon alle 60 Sekunden frisch beim SIP-Server registriert. Normalerweise sollten da 600 Sekunden ausreichen.

Vielleicht ist da ja ein heißer Tipp dabei, der bei dir funktioniert.
 
Angebot: http://www.ip-phone-forum.de/showpost.php?p=834142&postcount=1

PS:
Das mal auf jeden Fall, da SIP ausschließlich UDP verwendet.

Stimmt so nicht. SIP funktioniert ebensogut über TCP.

PPS:
Und bist du dir sicher, dass ein Registry-Timeout von nur 60 Sekunden passt? Ich persönlich fände es etwas unnötig, wenn sich das Telefon alle 60 Sekunden frisch beim SIP-Server registriert. Normalerweise sollten da 600 Sekunden ausreichen.

Die WLAN Phones sind i.d.R. so vorkonfiguriert. Wg. der Beweglichkeit...

Grüsse

 
Stimmt so nicht. SIP funktioniert ebensogut über TCP.
Naja, hast ja Recht. Dann korrigiere ich meine Aussage folgendermaßen:
SIP verwendet per Default ausschließlich UDP. Möchte man für das Signalling TCP verwenden, so muss man dies im Gerät explizit einstellen. Der Voice-Datenstrom läuft aber selbst dann noch über UDP.
Passt's so? ;)

Die WLAN Phones sind i.d.R. so vorkonfiguriert. Wg. der Beweglichkeit.
Nunja, so kann man auf bequeme Art das NAT-Loch in der Firewall aufrecht erhalten. Ich persönlich finde dies aber nur unnötigen Traffic, da ich genauso gut auch einfach nur den dafür benötigten Port weiterleiten kann.
Eine solche Option hat das GXP aber auch, so dass man trotzdem den Registry-Timeout auf 600 belassen kann, dass GXP aber dennoch alle n Sekunden ein Idle-Paket an den SIP-Server schickt (als Ersatz für STUN).
 
danke euch für die Antworten!

Es scheint so, als hätte die einfache Umstellung von TCP auf UDP schon den gewünschten Effekt gebracht - hab aber nicht so intensiv testen können bisher.


Vielen Dank nochmal!!!
 
FRiP schrieb:
danke euch für die Antworten!
Es scheint so, als hätte die einfache Umstellung von TCP auf UDP schon den gewünschten Effekt gebracht - hab aber nicht so intensiv testen können bisher.
Vielen Dank nochmal!!!
Hallo,
ist doch schön zu hören, wenn's funktioniert.
Das wird wohl ganz schlicht und einfach darin liegen, dass die Ports nun freigeschaltet und von außen erreichbar sind. Wenn UDP gebraucht aber TCP geschaltet ist, bringt das genau so viel wie gar keine Portregel. :)
Ist aber beim ersten Mal vielleicht einfach deshalb etwas verwirrend, da man von "normalen" Diensten immer TCP gewohnt ist, was auf Grund der Fehlerkorrektur soweit auch Sinn macht. Beim Signalling könnte man sich nun um TCP oder UDP streiten, aber spätestens bei RTP scheidet TCP wegen des hier unnötigen Overheads einfach aus.
 
hmm, na ja um ehrlich zu sein hat sich die Situation etwas verschlimmbessert.

Ich telefonier nicht so oft, als dass ich es sofort merken würde - aber heute war es doch signifikant ;-)

also, ich glaube, dass meine incoming Gespräche jetzt länger als 30sec halten. Allerdings bin ich nach ein paar Sekunden immer auf "Stumm"... was meine gegenüber nicht sehr vergnüngt. Ich höre sie, sie aber mich nicht.

auch nicht so klasse. glaub ich mach bald dmz auf das scheiss telefon. dürfte einiges sparen
 
Interpretiere ich deine Signatur richtig?
Hardware: FritzBox 5012 mit 2 angeschlossenen ISDN Telefonen und einem Grandstream GXP-2000
Du hast das GXP hinter der Fritzbox hängen? Falls ja versuche mal den SIP-Port zu verändern und damit auch das Protforwarding. Es scheint mir nämlich so, dass sich die Fritzbox und das GXP um den Port 5060 streiten und immer wenn die FritzBox sich erneut registriert hat das GXP wieder verloren.

Gruss hotroot
 
hmm, was genau meinst du mit SIP Port?

Also ich hab aus "weise" Voraussicht im Grandstream den local SIP port vom ersten Account auf 5068 gesetzt, die anderen Accounts auf 5062, 64 und 66.
Aber ich hab das Problem bei jedem Account... könnte es sonst ggf. der local RTP port auf 5004 sein, der die Probleme birgt?
 
In deinen Portforwardings leitest du den Port 5060 auf dein GXP weiter. Wenn du den ersten Account auf 5068 liegen hast, musst du auch den Port weiterleiten. Der RTP Port sollte, wenn ich mich noch richtig entsinne, nicht das Problem. Allerdings könntest du ihn testweise mal auf irgendwas > 10000 ändern, vielleicht hilft das.

Gruss hotroot
 

Statistik des Forums

Themen
246,733
Beiträge
2,256,559
Mitglieder
374,746
Neuestes Mitglied
hsv25a
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.