VoIP Verbindung schläft ein - bin nicht erreichbar

Bin per UMTS Stick an der Fritzbox unterwegs. Surfen funktioniert, Telefonieren raus geht auch. Aber ich bin nicht erreichbar.
Interessanterweise kann ich angerufen werden, kurz nachdem ich nach draussen telefoniert hab. Aber schon nach kurzer Zeit (weniger als 10min) kommt kein Anruf mehr rein - der Anrufer bekommt kein Rufzeichen und ich höre kein Klingeln.
Als wenn die Verbindung in Standby ginge - was zumindest nur halb stimmt, denn ich kann weiter ganz normal surfen.

Das klingt logisch, half aber nicht. Ich habs noch mal geprüft und auch rebootet, es bleibt dabei.
Ich kann bspw voipcfgchanged aufrufen, danach kann ich innerhalb von ca 45s angerufen werden. Danach ist Schicht.
Ich hab das mit einem anderen UMTS Stick probiert - gleiches Ergebnis.
Mit einer anderen Karte (O2/Netzclub) probiert - da hab ich das Problem nicht.

Es wäre natürlich einfach zu sagen, Vodafone unterstützt das nicht, blockt oder was weiss ich - aber vom PC aus (Phonerlite) gehts doch auch.
Was ist da denn anders - übers Netz sollten doch die gleichen Daten gehen? Sendet der PC irgendwie einen "keep alive", den die FB nicht sendet?

Einfach nur Surfen nebenbei hilft auch nicht (damit die Verbindung aktiv am Leben bleibt), also es muss schon etwas anderes sein..

---

Edit:

wenn man auf andere Anbieter geht, statt dem voreingestelltem Sipgate, findet man noch diese Einstellung:

Anmeldung immer über eine Internetverbindung
Falls Ihr Internetanbieter die separate Internettelefonie-Verbindung für eigene Rufnummern reserviert, aktivieren Sie diese Option, wenn es sich um eine Rufnummer eines anderen Anbieters handelt.

So ganz klar ist mir das nicht, und ich habe es schon mal mit und ohne Haken da probiert. Hilft auch nicht.

Hallo Michl, dake für den Tip:
Hier mal die voip.cfg:
Der Reregistration timer - sendet der dauernd eine Anmeldung an den Sipgate-Server?
Welcher Eintrag ist das denn? Das hier "sipping_interval = 280s" ?

Könnte ich das per Wireshark am PC Softphone mitbekommen, wie oft der sendet? Wie heist das Protokoll?

Wie bekomme ich eigentlich nach ein paar Rekonfigurationen wieder eine Original-Datei? Wird die, einmal gelöscht wieder neu erstellt?


voipcfg {
dnsport = 7077;
rtpport_start = 7078;
sip_srcport = 5060;
ua1 {
enabled = yes;
username = "xxxxx";
authname = "";
passwd = "xxxx";
registrar = "sipgate.de";
ttl = 30m;
sipping_enabled = no;
sipping_interval = 280s;
name = "xxxxx";
providername = "";
ims_client = no;
with_displayname = no;
dtmfcfg = dtmfcfg_info_or_rtp_or_inband;
rtpevent_keep_packetrate = no;
register_failwait = 0w;
register_failwaitmax = 30m;
stunserver = "";
stunserverport = 3478;
use_internat_calling_numb = no;
is_nat_aware = yes;
localip = 0.0.0.0;
protocolprefer = protocolprefer_ipv4only;
ignore_received_header = no;
always_clir = no;
clirtype = clir_displayname;
colptype = colp_none;
clipnstype = clipns_off;
vad_enabled = no;
only_one_dialog = no;
presence_supported = no;
mwi_supported = yes;
mwi_inmemoria = no;
ccbs_supported = no;
reg_support = regsupport_auto;
packetization = packetization_fixed;
tx_packetsize_in_ms = 20;
xrtp_periodic = 0;
reject_refer = yes;
no_register_fetch = no;
do_not_register = no;
only_call_from_registrar = no;
invite_without_register_allowed = no;
outboundproxy = "sipgate.de";
outboundproxy_without_route_header = no;
factory_3pty_uri = "";
no_hold_speech = no;
dditype = ddi_none;
ddireception = "";
alias_head_number = "";
cfxsignaling = cfx_standard;
backup_wanted = no;
use_session_timer = no;
use_rport = yes;
add_rtpmap_for_all_codecs = no;
answer_only_one_codec = no;
without_annexb_no = no;
srtp_supported = no;
use_488_for_no_t38 = no;
g726_via_rfc3551 = no;
no_g726_32_offer_with_pt2 = no;
g726_fixed_ptime30 = yes;
dtmf_inband_on_g711g722 = yes;
enable_3xx = yes;
t38_reinvite_from_remote = no;
use_t38version0 = no;
rtcp_xr_media_attribute = no;
ptime_a_attribute = yes;
tones_and_announcements_for_service = no;
read_p_asserted_identity_header = no;
route_always_over_internet = yes;
gui_readonly = no;
convertstate = 1;
snmp_instance = 0;
}
register_sequence_timer = 0;
use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32";
verbose = no;
capi_blocksize_in_ms = 30;
sip_prio = 0;
rtp_prio = 0;
rtcp_prio = 0;
dyn_codecs = yes;
prio_low_codec = no;
send_ringtone = no;
t38_support_enabled = yes;
enum_support_enabled = no;
bandwidth_to_leave_KBits = 0;
dialoglimit = 0;
enumdomains = "e164.arpa", "e164.org", "openenum.eu";
rtpstream {
voice_activity_detection {
vad_enabled = vadenabled_no;
vad_threshold = 10000;
}
plc {
in_the_stack = yes;
}
jitter {
auto_on = yes;
in_ms = 50;
in_packets = 0;
}
rtcp_enabled = yes;
silence_detection = no;
}
voip_assi_enabled = yes;
voip_over_mobile = yes;
gui_readonly = no;
voipcfg_version = 8;
}

Scheinbar geht es jetzt. Also noch mal Danke an euch zwei.

Ich hab geändert
- stunserver = "stun.sipgate.net";
- stunserverport = 10000;
- is_nat_aware = yes;
- sipping_enable=yes
- sipping_interval=30s

Was davon es gebracht hat untersuche ich später mal. Nach ca 3 Tagen Dauerexperimenten ist bei mir der Riemen runter.
Leider findet man nix zu der Bedeutung z.B. von sipping_enable.

Warum meinst du ist der Stun-Server ohne Bedeutung?

Wäre jetzt noch schick rauszufinden, warum meine Fritzbox von aussen nicht erreichbar ist. DynDNS geht und wird auch richtig übersetzt.
Hängt bestimmt wieder damit zusammen, dass der Zugang über UMTS ist, solche Probleme hatte ich vorher (DSL) nicht.

--

Gerade nochmal bei Sipgate gesehen:

http://www.sipgate.com/faq/article/397/How_do_I_set_up_my_VoIP_device

Da steht ein anderer STUN Port. Das wundert mich, weil irgendwo hab ich die 10000 auch schon mal gefunden. Naja.

Dast stimmt, die Verkürzung auf 30s bringts. Gestern lief es den ganzen Tag, aber heute irgendwann war Schluss.
Wenn das stimmt was du schreibst - und ich habe keinen Zweifel - dann reicht ein kurzer Ausfall von 45..60s und die Verbindung ist dauerhaft tot.
Kann man irgendwas machen, dass so ab und an die Verbindung richtig neu startet? Sowas wie ein Cronjob. Keine Ahnung wie das geht ... aber wäre das eine Lösung? Nebenwirkungen?

Noch besser wäre die NAT zu umgehen, dann wäre meine FB auch wieder von aussen zugreifbar. Nehme an das dies nicht geht hängt auch damit zusammen?

So, da hast du meine schöne Theorie zerstört.

Also das der SIP Server die Zeitspanne (30s) als zu kurz betrachtet hat kann eigentlich nicht sein. Das sollte ja schliesslich kein dynamisches Verhalten sein.

Ich hab mal ein log vom Phonerlite auf den Notebook gemacht. An das Interface komme ich gut mit wireshark ran. Es ist wie du sagts, das Phone handelt etwas aus, und dannach meldet sich der Server (ich nehme an der von Sipgate) alle 14s bei meinem Softphone. Ich hätte gedacht es läuft umgekehrt. Aber so wie ich das sehe (mir fehlen ein bisschen die Tricks mit den Filter bei Wireshark) ist das ganze eine Einbahnstraße. Frage mich gerade, wie die Anzeige bei Sipgates Webseite (online) Zustande kommt. Kann ja dann nur sein dass die Anmeldeprozedur lief und keine Abmeldung erfolgte. Nach irgendeiner Zeit muss aber auch Sipgate ja mal feststellen - da ist nix mehr das antwortet, aber das scheint definitiv ein längerer Zeitraum zu sein. Keine Ahnung wie das passiert...

Ich hab daraufhin noch mal meine voip.cfg angepasst. Stun-Server und Port 10000 waren diesmal schon eingetragen. Nun die Zeit verkürzt auf 15s und sipping_enabled=yes und is_nat_aware=yes. Man muss aufpassen - ändert man danach irgendein Setting via Webinterface (z.B. einen anderen VoiP eintrag rausnehmen) dann werden die Werte wieder auf default gesetzt. Da muss ich mehr aufpassen, was ich da eigentlich teste ....

Dann ein Reboot und um sicherzugehen hab ich noch den Stecker gezogen.
Heute morgen bekam ich zwar ein Rufzeichen beim Anrufen, auch die Fritzbox signalisierte mit einer LED den Anruf - jedoch klingelte das Mobilteil (DECT) nicht. Mhhh. Naja, das ist ein anderes Problem - wenns erst mal bis zur Box kommt, kann der Rest nicht mehr so wild sein...

Weil du danach fragst, das Fritzlog zeigt nichts bemerkenswertes - die einzigen Zeilen betrafen eine fehlgeschlagene Anmeldung von Vortagsexperimenten.
Wenn die NAT (ich gehen mal davon aus dass ich hinter so einer sitze) aber ne Weile dicht macht oder die Verbindung dahin, dann finden die Pakete des Servers ihr Ziel nicht mehr. Dann wäre die Verbindung auch irreversibel unterbrochen, oder nicht. Daher müßte die fritzbox einen Watchdog haben, der bei fehlenden UDP Sip-Server Paketen eine Neuanmeldung macht.

Es gibt, was ich bisher nicht wusste die Möglichkeit, dass die Fritzbox selbst ihre Protokolle mitloggt, da ist Recorder eingebaut - geil! Die Fritzen sind doch die besten. Da müßte das Notebook zum Abspeichern allerdings den ganzen Tag dran bleiben.

Zur Erreichbarkeit der Box aus dem Netz: Woran erkenne ich denn ob die IP öffentlich ? Was man alles wissen muss nur um zu telefonieren. Schöne neue Welt.

Hallo Michl,

da kann man leicht die Übersicht verlieren:

Vodafone Datenvertrag -> UMTS-Stick via USB an Fritzbox, Fritzbox als Router mit Telefon-Anlage.
Daran hatte ich früher ein Schnurlos-Telefon per Draht angebunden (klingt widersinning, also Basis am Draht, Mobilteil schnurlos an Basis).
Das habe ich inzwischen nicht mehr und gehe mit dem DECT Mobilteil direkt an die Fritzbox, die ja eine DECT-Basis hat.

a) die SIP Daten sind in der Fritzbox hinterlegt, das DECT-Telefon ist dumm und weiß nichts von SIP
b) als Testalternative habe ich ein Softphone, das selbst die Zugangsdaten hat (der ist der Sip-Client in der Fritzbox egal).

Ich hab a), b) und a+b) probiert.
Die meisten Probleme habe ich mit a) - mit entsprechenden Modifikation funktioniert das auch mal Stunden.
b) hat bisher immer funktioniert, weil PC dafür immer an sein muss hab ich keinen Dauertest mit gemacht (über Stunden geht es).
a+b): Manchmal klingelt nur das Softphone, manchmal beide. Warum wieso keine Ahnung. Aber das ist nicht der Normalfall und mir daher nicht so wichtig. War nur zum Testen.

Die Nacht über hat das Setting jetzt durchgehalten. Übrigens hatte ich nicht ttl kürzer gemacht, sondern sipping_interval. Das kann ich auch mal probieren.
Mal sehen, ob das jetzt auch noch bis heute abend durchhält. Dann mache ich noch ein Log. Ich hab gestern abend nur noch kurz Zeit gehabt. Also in kurzen Worten meldet sich die FB alle 300s bei dem Server. Und scheinbar wird auch nicht jede Anrage mit ok beantwortet. Wie gesagt, heute abend mal im Detail.

Ein Problem ist noch die Sprachqualität. Scheinbar aber nur der Anrufende hat Probleme mich zu verstehen (ausgehende Sprache)- in die andere Richtung (einkommend) geht es besser.
Wenn ich mit einer anderen Sipgatenr telefoniere waren keine Auffälligkeiten. Was für Möglichkeiten hab ich das zu verbessern?

Warum gestern das DECT Phone nicht geklingel hat, hab ich nicht verstanden. Verbindung zwischen Basis und Mobilteil war da. Wenn ich den DECT Knopf an der FB drücke klingelte es auch. Nachtschaltung usw war nicht an, und das Phone auf die Nummer registriert. Schluckauf in der Box?

Jetzt ausführlicher Test gemacht. Zurück auf Standard und von dort geändert. Es gibt zwei Wege erreichbar zu bleiben.

a) ttl von 30m auf 30s
Wenn ich mir Wireshark ansehe, dann bedeutet das, dass jedesmal eine komplette Anmeldung gemacht wird. Das scheint mir ziemlich heftig, aber auf Nr sicher. Frage ist, wie sich das auf die Gesprächsqualität auswirkt.
(Edit: Das funktioniert erstaunlicherweise gut.)

b) sipping_enable=y && sipping_interval=30
Damit meldet sich der Server alle 30s und hält die Verbindung aufrecht.
Ich glaube, dass das Interval keine Rolle spielt, wenn sipping_enable=no ist. Aber 100% siche bin ich nicht.
Die Gesprächsqualität eingehend (für den, der mich anruft) war bescheiden.

Das setting is_nat_aware muss nicht von no auf yes

Die Anmeldeprozedur für a) besteht aus insgesamt 3 Requests und Anworten.
1) Request: Register sip:sipgate.de (fetch binding)
1a) Status 200 ok (1 binding)
2) Request: Register sip:sipgate.de
2a) Status 200 ok (1 binding)
3) Request: Subscribe sip: [email protected]
3a) Status 501 not implemented

so geht das jetzt alle 30s.

Leider sehe ich nicht, was die Meldung 501 hervorruft. Verbindung ist ja da...
Also, ich danke für den Tip, ttl war die Lösung des Problems.