Bei wem funktioniert die registrarlose SIP-IP?

[NAPALM]

Direct-IP-Calling / 100% registrarloses VoIP mit der Fritzbox 7170 per SIP-URI

Nachdem ich hier und da ein wenig rumgelesen habe, ließ meine Verblüffung über die Möglichkeit der Telefonie Pseudo-Account «--» Pseudo-Account mit der FRITZ!Box dann doch etwas nach - das scheint früher wirklich ohne größere Probleme funktioniert zu haben. Es war also total normal. Zumal: Das ist eigentliches SIP, oder? Dann ärgert es einen aber um so mehr, wenn es nun auf einmal nicht mehr geht bzw. gehen soll...

Daher habe ich noch mal ein wenig rumgefriemelt - und siehe da - direkte Anrufe zwischen 2 FRITZ!Boxen funktionieren immer noch - und zwar entgegen meiner obigen Aussage auch OHNE irgendeinen ECHTEN ACCOUNT auf der Box, "der einen ins Netz bringt" !!! Also muß ich mich jetzt selbst hauen... Um das zu vermeiden, reiche ich die Vorgehensweise wie gefordert nach...

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

Bislang hatte ich mich bei allen meinen Versuchen nicht am "Zumüllen" meines Ereignis-Logs gestört; insofern hatte ich die hier im Forum viel zitierte Änderung do_not_register = no; --» do_not_register = yes; in der voip.cfg konsequent ignoriert (was ein Fehler ist...). Da die Box aber nun kurz vor dem Kollaps war (evtl. auch durch ein paar Spielereien per SSH), entschied ich mich dazu, das doch zu ändern.

Doch leichter gesagt als getan - es rächte sich wieder einmal, daß ich sowohl in Linux als auch in "Frittux" noch ein ziemlicher DAU bin.

Der Befehl nvi var/flash/voip.cfg führte mich trotz der sicherheitshalber zur Rate gezogenen Anleitung nicht zum gewünschten Ergebnis.

Folgendes dachte ich mir mal so - mit der debug.cfg geht es ja schließlich auch: Für die Variante cat ~/var/flash/voip.cfg > ~/var/tmp/voip.cfg (mit anschließernder Bearbeitung mittels Midnight Commanders) und mit darauf folgendem Zurückbeamen per cp ~/var/tmp/voip.cfg ~/var/flash/voip.cfg erwies ich mich auch irgendwie als "zu blond". Vielleicht habe ich auch einen Reboot zuviel oder zuwenig gemacht - jedenfalls kam die Box irgendwie aus dem Tritt; und aus irgendeinem Grund konnte ich auch die von mir gemachten Änderungen einfach nicht wiederfinden...

Was blieb noch?

Die einfachste Variante: FRITZ!Box Export Editor bzw. FBEditor in der Version 0.5.1 !!!

Dort habe ich mir also die voip.cfg bzw. den entsprechenden Bereich vorgeknöpft und meinen zuvor angelegten Pseudo-Account "gepimpt":


uaX {
enabled = yes;
username = "$$$$...Schnatter...Blablabla";
authname = "";
passwd = "$$$$...Laber...Sülz";
registrar = "S I E H E * U N T E N";
ttl = 30m;
sipping_enabled = no;
sipping_interval = 280s;
name = "81379";
dtmfcfg = dtmfcfg_automatic;
register_failwaitmax = 30m;
stunserver = "";
stunserverport = 3478;
use_internat_calling_numb = no;
is_nat_aware = no;
localip = 0.0.0.0;
ignore_received_header = no;
clirtype = clir_none;
colptype = colp_none;
only_one_dialog = no;
presence_supported = no;
mwi_supported = no;
reg_support = regsupport_auto;
tx_packetsize_in_ms = 30;
reject_refer = yes;
no_register_fetch = no;
do_not_register = yes;
only_call_from_registrar = no;
outboundproxy = "";
outboundproxy_without_route_header = no;
dditype = ddi_none;
ddireception = "";
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;
}

- X - Nummer des betreffenden Sip-Accounts und letzte Stelle bei *12X# (ua10: X=10 --» X=0)
- username - ergibt sich aus den eingetragenen individuellen Daten
- passwd - ergibt sich aus eingetragenen individuellen Daten, sofern vorhanden
- clirtype - ist hier so eingestellt, weil ich meinen ersten Dummy-Accounts per Webinterface unter Rufnummernunterdrückung (CLIR) "deaktiviert" verpaßt habe - ich habe es so gelassen; keine Ahnung, ob es irgendeinen Einfluß hat
- mwi_supported - macht hier keinen Sinn
- do_not_register - so bleibt das Log sauber (und eigentlich ist das der ausschlaggebende Punkt, damit das Ganze funzt!)

So - es fehlt eigentlich nur noch der Registrar. Ich testete alle möglichen (mir bekannten) Registar-Varianten, da das bisher festgestellte Verhalten ja unterschiedlich war. Dazu habe mir meine Testumgebung etwas ausgebaut. Vier Dummy-/Pseudo-/Fake-Accounts auf einer ansonsten von VoIP-Accounts freien Box. Angeschlossen daran diverse analoge Telefone, ein ISDN-Telefon und eine ISDN-Anlage. So ziemlich jedem Gerät alles zugewiesen.

Zusätzlich zu meinen eigenen SIP-URIs legte ich im Telefonbuch unter 4 weiteren Kurzwahlen folgende externen Testziele an:

[email protected] (Echotest)
[email protected] (Nachrichten)
[email protected] (Londoner Testnummer)
[email protected] (Affengeschrei)

Meine Pseudo-Account-Nummern sind, wie bereits erwähnt, meinen zahlreichen Telefonen zugewiesen. Obwohl ich mich selbst über meine DynDNS-Domain anrufe, nenne ich sie mal interne Testziele.

Dann konnte die VoIP-Orgie beginnen...

Ergebnis (OK/NOK bezieht sich auf die Audioübertragung):

fritz.box - INT/EXT: alles OK
localhost - INT/EXT: alles OK
127.0.0.1 - INT/EXT: alles OK
169.254.1.1 - INT/EXT: alles OK
192.168.178.10 - INT/EXT: alles OK
(Meine Fritte hat die 10 am Ende - so kann ich Kunden-Boxen problemlos im LAN anstöpseln.)

Einziges Manko bei diesen "Registraren": Habe ich einen anderen meiner Pseudo-Accounts angewählt (INT), kam es vor, daß ich manchmal in beiden Richtungen nichts hören konnte. Ich stellte aber fest, daß es 2 x klingeln mußte. Dann war Audio immer ok. (Zufall? Warum auch immer das so ist... Vielleicht hat es was damit zu tun, daß Sender und Empfänger die gleiche öffentliche IP haben? Keine Ahnung... )
Verbindungen zu EXT waren hingegen IMMER sofort i.O.

ACCOUNT.dyndns.org - INT/EXT generell: 1. SIP-URI-Anwahl: NOK; jeder 2. Anruf OK

Kurisoserweise entpuppt sich nun der von mir weiter oben ja ach so viel gepriesene Registrar ACCOUNT.dyndns.org als scheinbar ungeeignet.

Aber man muß unterscheiden: Nutzt man Dummy-/Pseudo-/Fake-Accounts im Sinne meines ersten Posts (also zusätzlich zu einem echten, registrierten VoIP-Account), ist ACCOUNT.dyndns.org durchaus empfehlenswert und zuverlässig.

Spielt man aber (z.B. mit dem FBEditor) an der voip.cfg rum und trägt dort für wirklich 100%ig registrarloses SIP-URInieren do_not_register = yes; ein, sollte man scheinbar fritz.box, localhost oder 127.0.0.1 oder die FRITZ!Box-IP-Adresse als Registrar eintragen.

Mit diesen Einstellungen konnte ich jedenfalls per *12X#**7YZ von einer Box ohne registrierte VoIP-Accounts per SIP-URI telefonieren, wobei X die Sip-Account-Nummer ist (X=10 --» X=0) und YZ samt vorangestelltem **7 für die im Telefonbuch vergebene Kurzwahl steht. Handelt es sich bei einem dieser Pseudo-Accounts um den Default-SIP-Account oder um die Sende-Nummer eines angeschlossenen Telefons, sollte es auch ohne *12X# funktionieren.

Für die Erreichbarkeit eines solchen Accounts ist natürlich nach wie vor eine Adresse wie [email protected] oder [email protected] (siehe 1. Post von mir; je nach Haken bei "Internetrufnummer für die Anmeldung verwenden" im Webinterface bzw. vorhandenem authname = "$$$$...usw...etc...pp..." bei uaX in der voip.cfg) nötig.

FRITZ!Box: 7170 V2
Firmware: 29.04.57

PS: Vielleicht interessiert das alles ja noch den einen oder anderen... Für meine FRITZ!Box freut es mich: 1 Bug weniger - (m)ein ohnehin "geiles" Fritzdingens ist nun noch "geiler"...

PPS: Und Anrufe mit 0190666666 zu tätigen, ist schon irgendwie witzig. So kann man mit einem stundenlangen Gespräch mit dem Herrn des Hauses die Beziehung dieses Bekannten etwas auffrischen; zumindest, wenn sein Weibchen in der FRITZ!Box rumschnökert und noch nichts von 0190--»0900 weiß... (Achtung Joke! Keinen Unsinn machen!)

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

Aufgrund des nachfolgenden Posts habe ich unwichtige Angaben zum STUN-Server erntfernt, die ich fälschlicherweise für wichtig erachtete.

 

[gandalf94305]

Der Eintrag eines STUN-Servers ist überflüssig, da er gar nicht genutzt wird in dieser Konfiguration.

Der Eintrag von do_not_register = yes ist dagegen essentiell, da ein Account, der registriert werden soll, dies jedoch aus offensichtlichen Gründen niemals erreichen wird, in der Box auch nicht als Ziel verwendet werden kann. do_not_register sorgt nicht nur dafür, daß keine Registrierungsversuche erfolgen, sondern daß der Account ohne weiteres Aufheben auch als korrekt akzeptiert wird. Damit ist er natürlich valides Ziel eines Anrufs von draußen.

Diese Konfiguration verwende ich seit langer Zeit, um von extern VoIP-Anrufe auf meine Tk-Anlage zu tunneln, wenn ich mit einem VoIP-Telefon/Softphone unterwegs bin.

--gandalf.

 

[NAPALM]

Vielen Dank für die Aufklärung bzw. Richtigstellung. Ich habe meinen Post dahingehend korrigiert. :groesste:

Das Problem war, daß ich tatsächlich Direct-IP-Calls mit PhonerLite testete und im Forum des Programmierers auf einen (für den Betrieb der Software) wichtigen Fakt stieß: Eintragung eines STUN-Servers...

Gelesen, gemacht, probiert - ok. Ran an die FRITZ!Box, eingetragen (und wenn man schon mal dabei ist, gleich noch do_not_register = yes; zur Reinhaltung des Logs gesetzt). Funzt. Da lag nahe, daß es am STUN-Server liegt.

Aber:

Session Traversal Utilities for NAT (STUN, dt. „Werkzeuge zum durchqueren von NATs“) ist ein einfaches Netzwerkprotokoll, um das Vorhandensein und die Art von Firewalls und NAT-Routern zu erkennen und letztere zu durchdringen. Es soll den unkomplizierten Einsatz von Geräten (z. B. SIP-Telefone) und Computer-Programmen in Heimnetzwerken ermöglichen, welche Daten aus dem Internet empfangen möchten.
Mit Hilfe von STUN lässt sich die derzeit öffentliche IP-Adresse des Anschlusses ermitteln. So kann z. B. ein SIP-Telefon seine derzeit gültige IP-Adresse ermitteln und mitteilen. Dies ist nötig, damit die Gegenstelle ihre Gesprächsdaten korrekt adressieren kann. Derzeit wird STUN wohl am meisten im VoIP-Bereich, im Zusammenhang mit SIP eingesetzt. (Quelle)

Bei der Software macht das natürlich Sinn, da sich die auf einem PC mit privater IP im LAN befindet. Bei einer FRITZ!Box, die schon mit öffentlicher IP im Internetz eingeklinkt ist, dürfte das dann aber relativ überflüssig sein.

Insofern wieder was gelernt.


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


Das "Doofe" ist nur, wenn man hier im Forum mal nach den Suchbegriffen

- Direct IP Call / Calling
- Fritzbox / FRITZ!Box
- SIP-URI / SIP-Adresse
- registrarloses Telefonieren

in verschiedenen Kombinationen sucht, stößt man nur auf solche Problem-Einträge:


- Klingeln und anschließend Stille
- neue Firmware --» geht nicht mehr
- läuft über "echten" Anbieter / Caller-ID eines vorhandenen Accounts wird gesendet
- nicht ereichbar


Dann werden beispielsweise für Anrufe auf Sipgate-Accounts die SIP-URIs [email protected] (was von außerhalb des Netzes seit geraumer Zeit nicht mehr geht) und [email protected] durcheinandergewürfelt, was auch noch zur allgemeinen Verwirrung beiträgt.

Oft wird zwar das do_not_register = yes; erwähnt - aber soweit ich gelesen habe, immer nur im Zusammenhang mit dem "Zumüllen" des Logs. Selbst bei WeHaveMorFun liest sich die Info für mich nur so als Maßnahme zur Sauberhaltung des Logs.

Daß gerade das aber den Ausschlag gibt, konnte ich nirgend herauslesen!

Der Eintrag von do_not_register = yes ist dagegen essentiell, da ein Account, der registriert werden soll, dies jedoch aus offensichtlichen Gründen niemals erreichen wird, in der Box auch nicht als Ziel verwendet werden kann. do_not_register sorgt nicht nur dafür, daß keine Registrierungsversuche erfolgen, sondern daß der Account ohne weiteres Aufheben auch als korrekt akzeptiert wird. Damit ist er natürlich valides Ziel eines Anrufs von draußen.

Dazu muß ich allerdings anmerken, daß ich keine Probleme mit der Erreichbarkeit eines Accounts hatte, der (als ZIEL) auf do_not_register = no; stand. Mein Problem war vielmehr, daß ich mit einem solchen Account nicht rausrufen kann!

Letzendlich ist aber wohl der Tenor Deiner Aussage, daß ein Account, der sich vergeblich irgendwo anzumelden versucht, nicht richtig "arbeiten" kann. Und dem kann ich (jetzt) nur zustimmen.

Wie gesagt - wieder was gelernt. Zumindest hat die Rumprobiererei jetzt ein Ende.

100% registrarloses VoIPen/Sippen funzt mit der Fritte. Fertich!


PS: Hätte ich auch einfacher haben können: Gerade diesen Thread gefunden, indem ich nur nach "registrarloses" gesucht habe. Da hätte auch ich begriffen, daß "do_not_register" der eigentliche Knackpunkt ist... Na ja - wie man es macht, macht man es ja bekanntlich falsch...

 

[henry90]

Na endlich, jetzt funktioniert der registrarlose Betrieb auch bei mir , also über dummy-account auf Fritzbox A am Standort A zum dummy-account auf Fritzbox B am 60km entfernten Standort B. Das Gesspräch kann auf beiden Seiten eingeleitet werden.
Das Erfolgsgeheimnis: Im dummy-account der einen Fritzbox , die an einem Kabelmodem hängt, muss ein STUN-Server eingetragen werden. Ja ja, wirklich! Ohne STUN gehts nicht, d.h. kein Ton.

Edit:
Die Welt ist wieder in Ordnung: es geht auch ohne STUN-Server-Eintrag. Wäre auch gar zu komisch gewesen.
Ich nehme alles zurück und behaupte das Gegenteil.

Manchmal bleibt nach wie vor der Ton weg. Warum ? :noidea:
Mit STUN hat es jedenfalls nix zu tun.

 

[SeGeGa]

@ henry90

@ henry90
Habe auch mit dem Tema gefast leider habe ich aufgegeben, Könnten sie vielleicht bischen genauer schildern wie das gehen soll. Mit welche FW habe Sie hinbekommen danke im Voraus

 

[henry90]

@SeGeGa
Habe eben die Ausführungen von NAPALM noch einmal überflogen. Besser könnte ich es auch nicht machen. Man muss halt ein bisschen experimentieren. Meine Firmware ist die aktuelle 29.04 70, 7170.
Eventuelle Fragen bitte hier im Forum, nicht per PN oder Telefon.

 

[saltarte]

2.PVC bei 1und1

Neuerdings (in 29.04.76) ist in den Firmware der 7170 (und aufwärts?), gebrandet von 1und1, die Möglichkeit vorgesehen, eine zweite DSL-Verbindung nur für SIP-Telefonie einzutragen.
Bzw. wird das durch den Instant-Setup-Code anfangs eingestellt, und man kann (wenn man darauf kommen sollte) es abschalten.

Telefonie -> Internettelefonie -> Erweiterte Einstellungen -> weitere Verbindung (...)(PVC)

Dadurch verbindet sich die FB mit dem einen Set von Zugangsdaten ins www, mit dem 2. Set für SIP. Die FB bekommt (im Ereignis-Log vermerkt) eine 2. abweichende IP aus dem Pool für SIP.

Folgen:
- direktes Anrufen auf [email protected] geht nicht mehr, da dyndns die 1.IP einstellt (bislang hat man m.E. die 2.IP nicht automatisch ins dyndns einspeisen können) Ich nehme an, an der 1. IP hört dann die FB nicht mehr nach SIP-Paketen.
Auf diese Idee brachten mich Obicom und Nimrod mit:

Ich habe noch keinen Weg gefunden, wie ich die 2. PVC auslesen kann, denn dann könnte man es bestimmt auch mit dem 2. dyn DNS Account in der ar7.cfg bewerkstelligen. Also sehe ich nur zwei gangbare Wege, 1. ich komm an die 2. IP ran (wie auch immer) oder schalte die Vergabe einer 2. PVC ganz ab.

Wichtig: Die 2. PVC muss abgeschaltet sein damit das ganze hier überhaupt geht. Oder man verwendet die direkte IP der 2. PVC oder verbindet die per dyndns. Kann man abschalten unter Internettelefonie, Erweiterte Einstellungen.

Weitere Folgen:
- direktes Anrufen auf ID@<2. PVC-IP> geht.
- laut Pfeffer ein besseres QoS für SIP des Anbieters, da jetzt eindeutig, welche Pakete VoIP sind und schnell ankommen sollen.
- Kundenbindung (hätte ich nicht gewußt, wie/wo/wozu ich die 2.PVC wieder abschalten kann...)
- Außerdem könnte 1und1 im nächsten Schritt die Verbindungen über die 2.PVC filtern, damit alle Fremden/unregistrierten SIP-Anrufe ausgesperrt sind.
- Belauschen durch sniffer wird auch einfacher. Obwohl, bei SIP ist ja eh alles im Klartext geschickt.

Die ältere FB 7050 hat die 2. PVC nicht, weshalb da bei mir ID@dyndns ohne Umstellungen geht.

 

[rucola]

Ich bekomme das einfach nicht hin und die Anleitungen sind mir irgendwie unverständlich. Also nochmal zum mitschreiben:

FB1: 7270 ist eine 54.04.80
FB2: 7270 ist eine 74.04.80

Ich richte ein:

FB1:
Anderer SIP-Anbieter
Internetrufnummer: 1234
Benutzername: ABC
Registrar: fb1.dyndns.org

FB2:
Anderer SIP-Anbieter
Internetrufnummer: 2345
Benutzername: CDE
Registrar: fb2.dyndns.org

Dennoch kann ich die FB1 nicht mittels Kurzwahl auf [email protected] erreichen. Es kommt ein Besetzt-Ton und im Log der FB2 steht :

Internettelefonie mit 1234 über fb1.dyndns.org war nicht erfolgreich. Ursache: Not Found (404)

Was habe ich falsch gemacht? Zu beachte gilt, dass ich keine Vorwahl bei der Nummer 1234 verwende. Irgendwie stehe ich auf dem Schlauch... Die Log-Einträge stören mich nicht weiter, daher habe ich nicht per Telnet do_not_register = yes; gesetzt.

(Ob Anrufen von FB1 -> FB2 gehen, kann ich nicht sagen, da ich die FB1 nur über VPN erreiche und konfiguriere.)

 

[henry90]

Hallo,

do_not_register = yes ist zwingend notwendig, nicht nur wegen der Logeinträge.

FB1 ist nicht per [email protected], zu erreichen, sondern durch [email protected].

Empfehlung:
Fake-Accounts sind heutzutage nicht mehr nötig, um VoIP-Provider außen vor zu lassen, seitdem es die Möglichkeit gibt, die entfernte Box am Sip-Server der Box vor Ort zu registrieren und umgekehrt.
Zu beachten: reg_from_outside = yes.
Man telefoniert sich dann gegenseitig an z.B.: per [email protected].
Das Forum ist voll mit Anweisungen

 

[rucola]

Danke für die Antwort!

...
Man telefoniert sich dann gegenseitig an z.B.: per [email protected].

Wo kommt die 620 her und ist sie nicht nur bei WLAN/LAN-Telefonen konfiguriert?
NACHTRAG: OK das mit der 620 habe ich gefunden.

Das Forum ist voll mit Anweisungen

Genau das ist ja das Problem. Es gibt zu viele Anweisungen, Anleitungen etc. und es ist daher nicht ganz klar, was nun genau gemacht werden muss.

 

[rucola]

Ok, danke für den Hinweis. Jetzt habe ich was neues probiert:

Auf FB1 habe ich ein neues Telefongerät hinzugefügt (WLAN/IP-Telefon). Auf FB2 habe ich einen neuen Internettelefonanbieter angelgt, wobei als Benutzername die 620 und als Registrar "fritz.box" gewählt wurde. Als Proxy habe ich "fb1.dyndns.org" gewählt.

Die FB1 hat die FB2 als IP-Telefon akzeptiert und ich konnte dem Gerät eine der Festnetznummern zuweisen. Auch die FB2 zeigt, dass sie sich erfolgreich registriert hat.

Wähle ich jetzt eine Nummer *121#12345, dann höre ich einen sich wiederholenden Piepton (Kein Anschluss unter dieser Nummer) und im Log der FB2 sehe ich wieder "Internettelefonie mit 12345 über fritz.box war nicht erfolgreich. Ursache: Not Found (404)".

Wie kann ich jetzt Telefone im FB1-Verbund anrufen oder gar ins Festnetz rauswählen?

 

[henry90]

Hallo,

es klappt ja schon das Wichtigste.

Jetzt noch vor allen Dingen: Hast du auf FB2 für den account 620 "reg_from_outside=yes" eingestellt?

Wenn nein, bitte Suchfunktion (auch wenn's schwer fällt)

Wenn ja, solltest du von FB1 bzw von überall die Telefone an der FB2 mit [email protected] anrufen können. reg_... ist nötig, damit's nicht nur klingelt, sondern auch Ton über die Leitung kommt.

 

[rucola]

Nach langer Konfigurationsorgie funktioniert jetzt alles. FB2 ist über das Internet (dyndns) mit bei der FB1 als IP-Telefon eingetragen. Auf FB1 ist für den 620er SIP-Anschluss "reg_from_outside=yes" gesetzt. Auf FB2 sind die Wahlregeln für Ortsgespräch und Ferngespräch auf die 620er Leitung gelegt.

Damit verhält es sich so, als wären Telefon an der FB2 im FB1 Netz und man kann perfekt heraus telefonieren. Unglaublich, was die Fritz!Box alles kann. Sie ist jeden Cent wert!

Danke für die Hinweise. Fest steht: Zukünftig werde ich keine Festnetz-Flatrates mehr buchen und locker 10¤ im Monat sparen.

 

[henry90]

Hallo rucola,

Zitat: Nach langer Konfigurationsorgie funktioniert jetzt alles.

Bin sehr erleichtert und erfreut. Weiterhin viel Spaß mit der Fritz

 

[nophone]

Der Eintrag von do_not_register = yes ist dagegen essentiell, da ein Account, der registriert werden soll, dies jedoch aus offensichtlichen Gründen niemals erreichen wird, in der Box auch nicht als Ziel verwendet werden kann. do_not_register sorgt nicht nur dafür, daß keine Registrierungsversuche erfolgen, sondern daß der Account ohne weiteres Aufheben auch als korrekt akzeptiert wird. Damit ist er natürlich valides Ziel eines Anrufs von draußen.

Das stimmt nicht! Einen Account mit einem Dummy Registrar, bei dem die Registrierung immer fehlschlägt, kann man sehr wohl anrufen. Getestet mit Firmware-Version 29.04.88.

 

[Hans Juergen]

Auch dieser Thread ist 4 Jahre alt... :gruebel:

 

[gandalf94305]

@nophone: könnte es Dir in den Sinn gekommen sein, daß zum Zeitpunkt des Schreibens meines Postings nicht die Firmware 29.04.88 verfügbar war, sondern eine etwas ältere, da es sich immerhin um einen Beitrag aus grauen Vorzeiten handelt?

--gandalf.

 

[leseratte10]

Sorry fürs Ausgraben, habe aber eine Frage zur SIP-Telefonie:

Diese Vorgehensweise (Dummy-SIP-Account anlegen) funktioniert perfekt, wenn ich SIP-Adressen anrufen will.

Ich will aber, dass die Fritte SIP-Accounts über SIP anwählt und normale Nummern über meinen VoIP-Anbieter.

Lege ich einen Dummy an und stelle ihn als Standard ein, kann ich keine Festnetznummer erreichen.
Lege ich den VoIP-Account als Standard fest, kann ich ins Festnetz anrufen und SIP-Adressen erreichen.

Das Problem dabei: Als "Absender" des SIP-INVITE wird "[email protected]" übermittelt. Die Nummer kann der Angerufene natürlich nicht zurückrufen.
Wie bekomme ich die Fritte dazu, "[email protected]" im "From"-Header zu setzen?

 

[nophone]

Bei mir wird "[email protected]" übemittelt.

Du kannst in den Wahlregeln einstellen, mit welchem Account das Festnetz angerufen wird.