SIP-Registrar nutzen über Dyndns oder VPN Fernzugang

SIP-Registrar über Dyndns, keine Sprachübetragung

Hallo zusammen;

ich kann, mit meiner Dyndns Adresse:xyz.homeip.net) als Proxi über UMTS
eine Wahlverbindung herstellen.

Jedoch können weder ich, noch der angerufene einander hören.


Stelle ich die selbe Telefonverbindung im heimuschen Wlan her, funktioniert das Gespräch, zumindet wenn ich anrufe, tadellos.

Woran kann das liegen, das eine Sprachübertragung bei der UMTS verbindung nicht funktioniert?


PS: Mein Dus.net Voip Account, und andere, sind über UMTS problemlos nutzbar.


Wer kann mir (idealerweise für Nokia Voip Client) mitteilen, wie eine funktionierenden Konfiguration für die esterne Verwendung des Fritzbox sip-regitrar auszusehen hätte ?


Vielen Dank im Voraus.


Gruß

Marc
 
Geht mir genauso. Es gibt hier einige Vorschläge, wie man mit einem TC 300 von aussen auf die Fritzbox sip zugreifen kann. Habe auch versuche mit einem Kumpel gemacht, der auch eine FB hat. Aber Sprachverbindung ging nie! Wer kann eine funktionierende Anleitung liefern?

Wenn ich mit dem TC 300 (Pirelli FW) in einem externen WLAN bin, kann ich zwar surfen, der SIP-Status geht aber nach einiger Zeit auf "DNS resolved failed". Ein ping (Lapi) auf mein ***.dyndns.org bringt aber die richtige IP.
 
Zuletzt bearbeitet:
"Woran kann das liegen, das eine Sprachübertragung bei der UMTS verbindung nicht funktioniert?"
Genau das gleiche bei mir auch.
Novize hat "uns" ja nach Schliessung des Threads SIP registrar hier hin verwiesen.
Leider gibt es immer noch nicht die Erklärung warum es bei dem einen anscheinend funzt und bei der Mehrzahl der anderen genau dieser Effekt ( Im Wlan ja, UMTS nein ) auftritt.
Bin für jeden Hinweis dankbar:
FB 7270 mit Nokia E71 , dyndns eingerichtet ,Voip tool Nokia geladen, stun Server bestimmt.
Leider nur Erfolg im Wlan.

Z.
 
Bei UMTS kommt das Problem hinzu, dass einige Mobilfunk Betreiber VoIP in den Bedingungen verbieten. Ich weiss nicht ob der eine oder andere Anbieter evtl. sogar filtert. Bitte auch beachten dass manche Mobile Anbieter public IPs vergeben und andere private IPs.

Die Vorgehensweise zu der ich raten würde ist:
aktuelle Labor Version und dies auch nach den Vorgaben von AVM installiert oder zumindest auf Werkseintellungen setzen (bei Speedports mit clear mtd3/mtd4 flashen) und Zugangsdaten neu eingeben.

Softclient im heimischen WLAN versuchen - wenn ok dann
Softclient von einem WLAN/LAN welches ausserhalb ist - wenn ok dann
kann man ja UMTS mal versuchen (bitte die Bedingungen des Operators beachten)

Erst jetzt würde ich mich mit den SIP Clients die in Handys integriert sind oder Box - Box Verbindungen befassen.

Bei Fragen bitte angeben:
Welche Fritzbox / Firmware ?
Welcher externe Zugang (Lan/Wlan/hinter Router - UMTS/Operator/pub. oder priv. IP)?
Welche SIP clients wurden versucht?
Konfiguration: Stun/Proxy/Registrar
 
Zuletzt bearbeitet:
Gleiches Problem wie oben

Ich habe das gleiche Problem wie oben beschrieben. Aus dem eigenen Netz funktioniert alles prima. Von außerhalb kann ich sip anmelden, auch rufnummer wählen und anrufe tätigen. jedoch höre ich nichts und die gegenstelle hört nix...
 
ok, ich habe das gleiche Problem, wie die meisten hier.
(Keine Sprachübertragung und keine Registrierung via dyndns).
Anmeldung per realer IP geht.
Aber ich werde gleich mal los und die "Serverbox" auf Werkseinstellungen resetten.
Halte euch auf dem laufenden...
 
Dito, gleiche Problem. (Push)

/OT on
Da ja nun der Fred zum Thema festgelegt ist, hoffe ich hier auf eine Lösung
/OT off

Gruß
BDW
 
also, Werksreset hat nichts gebracht.
Nach wie vor werden die Anrufe signalisiert, aber keine Sprachübertragung.
Dyndns funktioniert nicht, auch nachdem ich Phoner auf TCP umgestellt habe.

//Sarkasmus an //naja, zumindest kann man phoner nun als Anrufmonitor benutzen...//Sarkasmus aus
EDIT: ich habe weiterhin festgestellt, das ohne Stun Server Eintrag, daß Softphone nicht klingelt (bei eingehenden Anrufen)
Ich habe momentan "stun.xten.com" eingetragen
EDIT2: mit diesen Einstellungen klappt zumindest schon mal eine Registrierung über dyndns!

http://img3.imageshack.us/img3/9048/zoiper.jpg

EDIT3: Habe mit meinem Handy jetzt mal die externe Box angerufen.
Das log von Zoiper gibt folgendes aus.
Interessant erscheint mir die rotmarkierte Zeile
Code:
15:30:02 DEBUG PhoneLine - 0 : creating current call
15:30:02 DEBUG Call - 14605 : created LineID = 0
15:30:02 DEBUG Call - 14605 : change state old state = 0;new state = 2
[COLOR=Red]15:30:02 Leitung 1 : codec negotiated : a-law[/COLOR]
15:30:24 Leitung 1 : anrufen '0176xxxxxxx'
15:30:24 Leitung 1 : beantwortet
15:30:24 DEBUG Call - 14605 : change state old state = 2;new state = 4
15:30:42 DEBUG Call - 14605 : change state old state = 4;new state = 0
15:30:42 Leitung 1 : beendet
15:30:42 DEBUG PhoneLine - 0 : destroying call
15:30:42 DEBUG PhoneLine - 0 : destroying call
15:30:42 DEBUG Call - 14605 : destroyed
 
Zuletzt bearbeitet:
Interessant erscheint mir die rotmarkierte Zeile

15:30:02 Leitung 1 : codec negotiated : a-law

Was hältst Du daran für aussergewöhnlich? Ich weiß zwar auswendig nicht ob die Box a-law oder u-law unterstützt, aber ich kann mir kaum vorstellen, dass ein Codec der intern (LAN) funktionierend ausgehandelt wird, extern Probleme machen sollte.

Oder anders: Wenn die Box intern a-law aushandelt, und damit funktioniert, muß a-law prinzipiell auch extern funktionieren. Und a-law oder eben u-law ist definitiv der Standard der Box wenn Breitband zur Verfügung steht.

Gruß

Tabs
 
SIP macht über Port 5060 den Verbindungsaufbau und handelt dann den Codec aus den beide Geräte können. In dem Fall wurde einfach a-law ausgehandelt.
Danach wird über RTP der "Sprachkanal" geführt. Die Frage ist wieso die RTP Verbindung nicht aufgebaut wird.
Jemand bei dem der Verbindungsaufbau funktioniert aber keine Sprachverbindung bekommt müsste mal ein Capture, sowohl auf Client Seite als auf der Fritzbox, machen und dies dann mit wireshark anschauen.
 
ich habe auf Client Seite mal Wireshark mitlaufen lassen.....allerdings fang ich damit wenig, bis gar nix an.:confused:
 
Nur mal so als Zwischenfrage, kann es nicht einfach sein, dass die RTP-Ports von außen einfach nicht freigegeben sind? Eventuell fehlt schlicht die entsprechende Weiterleitung im Binding 0.0.0.0 in der ar7.cfg.

Eine weitere Besonderheit trifft bei den 1und1 Komplettusern zu, denn diese habe zwei IPs im Internet mit unterschiedlichen Porteinstellungen von außen!
 
Code:
voip_forwardrules = "udp 0.0.0.0:5060 0.0.0.0:5060", 
                    "tcp 0.0.0.0:5060 0.0.0.0:5060", 
                    "udp 0.0.0.0:7078+32 0.0.0.0:7078";

Bei mir funktioiniert es ja auch und ich verwende nur das was bereits von AVM freigegeben ist

Das Thema 1und1 Komplettuser ist natürlich interessant (kann ich nicht überprüfen weil ich kein 1und1 Komplett habe) und könnte zu Problemen führen, da muss man dann die Portfreigaben auf der dyndns Adr. überprüfen.
 
Zuletzt bearbeitet:
ich habe jetzt mal testweise die komplette udp-range auf der Server-Box freigegeben mit:
"udp 0.0.0.0:0 0.0.0.0:0 0",

bringt auch nix...möglicherweise überschneidet sich das aber auch mit bereits vorhandenen Regeln?
ich glaube ich warte auf die nächste Beta von AVM :mad:
 
Zuletzt bearbeitet:
bringt auch nix...ich glaube ich warte auf die nächste Beta von AVM :mad:


die Frage die sich hier stellt ist die, ob es sich um einen Bug handelt, dessen Behebung im nächsten Release möglich erscheint, oder um eine (zum momentanen Zeitpunkt) von AVM nicht gewollte Funktion.

Für letzteres spricht die Bezeichnung die AVM bei der Einrichtung des SIP- Anschlusses gewählt hat: "LAN/WLAN"- per Definition ist damit nur "intern" gemeint.

@muenchner: Um der Sache näher zu kommen, könntest Du mir ggf. noch folgende Infos zu Deiner Konfiguration geben:

- Wie sehen denn Deine eigenen Freigaben auf die Box aus (also die, die nach "tcp 0.0.0.0:443 0.0.0.0:443 0 # HTTPS-UI" genannt werden?
- Welche IP hat Deine Box intern (Standard oder ein anderes PV Netz)


Gruß
Tabs
 
Zuletzt bearbeitet:
meine Box läuft in einem 192.168.1.0/24 Netz
Freigaben habe ich natürlich für andere Dienste aber keine die für VoIP zuständig sind.
 
192.168.0.0/24
ich denke nicht, das das von AVM so gewollt ist, ansonsten hätten Sie doch schon die Registrierung unterbinden können. (spekulativ)
 
@PsychoMantis: Nach Durchlesen des gesamten Threads erst einmal danke für die Idee. Habe jetzt 620 des FBF-Sipservers im Asterisk eingetragen und kann somit übers Festnetz der FBF raus. Super Idee. Danke Dir. :)
 
Hallo,

für das scheitern einer VoIP Verbindung über UMTS gibt es zig mögliche Ursachen. Einige, die mir adhoc einfallen:
  • Eine Mobilfunk-Netzbetreiber sperren VoIP definitiv schon
  • Viele Mobilfunkanbieter bieten nur noch Verbindungen über NAT Router an. VoIP über NAT ist immer kritisch
  • Viele VoIP Endgeräte haben eine maximale Paketlaufzet, nach der sie RTP Pakete verwerfen. Das Delay ist bei UMTS Verbindungen schnell mal überschritten
  • Viele WLAN Handys unterstützen kein VoIP über WCDMA. Das muss man evtl. extra über Einstellungen aktivieren.

Ich würde empfehlen, zunächst mal eine funktionierende Konfiguration mit einer direkten öffentlichen IP und nicht über Mobilfunk zu identifizieren (z.B. mit einem Softphone auf einem PC, der eine direkte DFÜ Verbindung über DSL aufbaut oder direkt an einem Kabelmodem hängt). Wenn das zuverlässig funktioniert, kann man die gleiche Konstellation über einen NAT-Router in Angriff nehmen, um die erforderlichen Parameter für STUN, NAT-Keep-Alive und Portweiterleitungen zu identifizieren. Und wenn das geht, dann kann man es mit Mobilfunk probieren. Und diese Erfahrungen kann man dann sukzessive auf weitere VoIP Clients adaptieren.
 

Neueste Beiträge

Statistik des Forums

Themen
245,002
Beiträge
2,222,484
Mitglieder
371,776
Neuestes Mitglied
ChristopherReichel
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.

IPPF im Überblick

Neueste Beiträge