[Problem] GXV3275 - wie telefonieren? Sip, ID, Mail.. Wust an Einstellungen...

[andiling]

... und das noch für analoge.

Drayteks haben keinen Sip Registrar. An solchen Geraten, die das können, könntest Du eigene IP Telefone anmelden.

TKs können das (z.B. Asterisk als Softwarelösung, Auerswald als professionelle), FB als AIO Gerät.

Aber: nicht der Vigor ist das vermeintliche Problem sondern das GXV.

 

[o0Julia0o]

Aber: nicht der Vigor ist das vermeintliche Problem sondern das GXV.

...weil es nicht mit DNS-Namen umgehen kann?

Faszinierend....und so viele Nummern können da registriert werden, für zwei Telefone.

das macht mich gerade stutzig. Muss ich dort - neben den Einstellungen im IP-Telefon auch nochmal alles eingeben? Der Draytek-Support meinte, das Menü sei ausschliesslich für Analoge Telefone zuständig, also nicht für IP-Telefone.

 

[andiling]

Weil wohl andere Endgeräte kein Problem haben.

Der Support hat recht, für Dich ist die Telefoniefunktion des Routers uninteressant.

 

[o0Julia0o]

jo - genau ->

Faszinierend....und so viele Nummern können da registriert werden, für zwei Telefone.

Der Support sagte mir dazu gerade folgendes:
Um auf ein IP-Telefon(also kein analoges Telefon) mit dem Draytek nutzen zu können sind dazu auf dem Router keine Anpassungen nötig. Einzig muss er sich ins Internet einwählen können. Die SIP Accounts sind nur für die analogen Ports gedacht. Man kann mehrere SIP Accounts für eingehende Gespräche einem Phone Port zuweisen. Über „VoIP -> Dial Plan -> Digit Map“ kann man Regeln festlegen, wann welcher Account zum Rauswählen verwendet werden soll.

 

[Andre]

Das GXV bekommt insofern seine Verantwortung, da man dort beim Outbound-Proxy keinen DSN-Namen eintragen kann, sondern nur die IP funktioniert. Da der IP-Phone-Hersteller aber davon ausgehen kann, dass sich diese ändern - und das tut er auch, liegt diesr Teil des Problems in deren Garten.

Njein. Wie das Thema Extension-Module - und der Preis der Telefone - schon zeigt, zielen die Geräte in das Buisiness-Umfeld. Im Heimbereich sind stationäre Telefone ja schon als exotisch zu bezeichnen. 99% der Grandtreamtelefone dürften an einer eigenen PBX betrieben werden. Damit stellt sich das Problem nicht, die IP des Outbound-Proxys ist immer fix - oder wird bei professionelleren Anlagen ggf. durch Autoprovisionierung angepasst. Greandstream muss also nicht davon ausgehen - und tut dies auch nicht - dass sich der Outbound-Proxy ständig ändert.
Selbst unter den Hobyisten bist Du hier ein ziemlicher Exot, wenn Du das Telefon direkt bei der Telekom registrierst. Die meisten dürften ihre Telefone an einer PBX betreiben - sei es extern (pbxes, sipgate team) oder intern (asterisk, OpenSips). Die direkte Anmeldung bei einem externen Provider wie DTAG oder UI käme mir gar nicht in den Sinn. Ich glaube also nicht, dass Grandstream wirklich Anlass hat, da was zu ändern.

Im Prinzip gilt der Grundsatz Business-Geräte / Buisnessumfeld, Consumer-Geräte / Consumer-Umfeld. Die hier praktizierte Kombi Business-Gerät/Consumerumfeld wird schlicht nicht supported.
Mal ehrlich, wie oft bist Du schon angesprochen worden, wieso Du Dir ein Bildtelefon gekauft hast, wo man das alles doch mit kostenlosen Apps auf dem Smartphone kann? Mich hat man jedenfalls oft genug für verrückt erklärt...
Ein nennenswerter Consumer-Markt ist schlicht nicht da. Der scheinbar verspielte und auf "Consumer" hindeutende Aspekt "Multimediaphone"/"Android" erklärt sich schlicht daraus, dass Consumer - also Kunden - natürlich auch beim "Buisiness" anrufen und erwarten, dass dies auf allen Wegen (Skype, Voiper...) funktioniert.

Das GXV trägt also keine "Verantwortung" - wie immer ist es der Mensch, der sich dann auch noch wundert, wieso etwas nicht auf Anhieb funktioniert, nachdem man es aus seinem angestammten Biotop gerissen hat ;-)

Die beste Variante dürfte sein, schlicht eine eigene PBX aufzusetzen. Kann ich eh empfehlen, da Funktionen wie spottbillige RUL mit Übermittlung der original Anrufernummer als Parallelruf, extrem billiges Callback usw. eh kaum anders zu erreichen sind.

Alternativ wären natürlich echte vergleichbare Consumer-Geräte zu begüßen...

 

[o0Julia0o]

Das ist generell ein Problem bei den "ganz großen" wie DTAG und 1&1. Die machen zwangsläufig ein Load-Balancing, wodurch sich die jeweils gültigen Outbound-Proxys häufig ändern.

Wie ist das die Häufigkeit so? Passiert das Load-Balancing live - also immer? Oder führen die das jedes halbe Jahr aus? Warum funktioniert der alte Outbound-Proxy nicht mehr - aktiv ist er ja dann noch, nehme ich an - nur für andere Regionen?

Die Lösung Sipgate/Dellmont und DTAG nur zusätzlich über FBF ist natürlich unbefriedigend

Dann muss ich ja jedes Mal, wenn ich die Telefon-Flat der deutschen Telekom nutzen möchte, den Router umklemmen, also den FBF anklemmen? Und die IP-Adressen im Telefon anpassen.. puh! Dann laufe ich lieber zum Gesprächspartner ´rüber

Ich glaube also nicht, dass Grandstream wirklich Anlass hat, da was zu ändern.

Und die nötige Änderung wäre: DNS-Support im Feld Outbound-Proxy?

Die hier praktizierte Kombi Business-Gerät/Consumerumfeld wird schlicht nicht supported.

Wobei der Grandstream-Support sich echt noch Mühe gibt(die haben schon viele Stunden per Teamspeak auf meinem PC & Telefonen rumgehackt) im Gegensatz zum Telekom-Support. Die sagen stets nur: "Fremdhardware? Dafür gilt ihr Vertrag nicht".

Mal ehrlich, wie oft bist Du schon angesprochen worden, wieso Du Dir ein Bildtelefon gekauft hast, wo man das alles doch mit kostenlosen Apps auf dem Smartphone kann?

jetzt zum 1. Mal - und auch nur indirekt durch Dich Aber vielleicht liegt es auch daran, dass ich kein Smartphone habe & das Telefon ja nicht nutzen konnte bislang. Jetzt ja schon, wobei ich noch viel sicher, anpasse, und mit dem Support arbeite, also es bis jetzt noch nicht zum anrufen genutzt habe. Und praktisch ist es schon. Es ist leise(lautlos), und man sieht seine e-mails, kann sich benachritigen lassen. Und auch per FB chatten. Und hängt am Strom, also Handy ist ja auch oft unterwegs. Auch das Display ist größer als beim Handy - nicht nur für ältere Menschen angenehm. Mal eben schnell bei Wikipedia nachschlagen was PBX heisst - und das noch zu 2t gut erkennen können(ohne jetzt den PC dafür anschalten zu müssen).

Die beste Variante dürfte sein, schlicht eine eigene PBX aufzusetzen.

Ich dachte eine Telefonanlage wäre mit IP-Telefonen überflüssig. Hast du vielleicht einen Link, wie ich so etwas hinbekomme? Was kostet das ca.? Mir reicht meine Funktionalität wie ich sie jetzt habe, einzig einen DNS-Outbount-Proxy möchte ich nutzen können.

@Outbound-Proxy
Der Grandstream Support meinte, dass das Problem daher kommt, dass die mein Provider "seems like this service provider use multiple IP's". Ist damit gemeint, dass für unterschiedliche Regionen verschiedene IP´s parallel existieren & daher das GXV3275 nicht damit klar kommt, weil wenn ich ins Feld Outboundproxy eine DNS eingebe er dann 40 Stück zur Vergügung hat & nicht checkt, welchen er nehmen soll für meine Region? Oder ist damit gemeint, dass die IP´s schlicht gewechselt werden(und dazu dann der DNS-Name eigentlich sinnig ist)?

Der Support meinte, ich sollte die Telekom mal fragen welche DNS-Einstellung ist nötig, damit man für den Outboundproxy die richtige IP des SIP-Providers erhält? So habe ich das jedenfalls verstanden. Die sprechen halt englisch.

 

[andiling]

Das ist der feine Unterschied zwischen Consumer und Business... die Argumentation von Andre leuchtet ein.

 

[Andre]

Wie ist das die Häufigkeit so?...Warum funktioniert der alte Outbound-Proxy nicht mehr

Das hängt davon ab, wie oft die DTAG Änderungen vornimmt und ist nicht vorher zu sagen. Der alte Outbound-Proxy funktioniert dann nicht mehr für Dich, weil er die Verbindung zum "falschen Gateway" (vereinfacht ausgedrückt) weiterleitet.

"...ja jedes Mal... den FBF anklemmen ... IP-Adressen im Telefon anpassen..."

Nö. Eine FBF wird als IP-Client eingerichtet. Ist dann ganz normales Gerät im internen Netzwerk. Die FBF ist bei den DTAG-Nummern angemeldet, je Nummer stellt es einen Account zur Anmeldung eines IP-Telefons bereit. Alle ein- und ausgehenden Anrufe über die DTAG gehen dann logisch über die FBF. Das IP-Telefon ist an die IP-Telefon-Accounts der FBF angemeldet, zusätzlich z.B. an Sipgate Basic, CheepVoIP und IPVideoTalk. Man kann in den GXV ja 6 Accounts einstellen. Wenn man den Hörer abnimmt oder die Telefonapp startet, kann man die abgehende Line duch Antippen aussuchen. Eingehend reagiert das GXV auf alle Nummern.

...Und praktisch ist es schon.

Mich musst Du nicht überzeugen, ich habe ja 3140 und 3240 Daneben liegt dann mein Nexus 10 - damit kann ich dann mit mir selbst Bildtelefonieren.
Weil ich das Nexus 10 eh habe, ich richtige Tasten bevorzuge und es etwas billiger ist, habe ich mich für das 3240 entschieden. Ist etwas problematisch mit dem kleinem Display, wenn ich drauf fernsehe und viper geht nicht, weil der Rufannahmebutton unterhalb des Anzeigebereichs liegt, aber ansonsten gehts.

Ich dachte eine Telefonanlage wäre mit IP-Telefonen überflüssig

Nein, man kann sie nur auslagern. Wenn man quasi keine internen Funktionen einer PBX nutzt, reicht die Anmeldung an einem VoIP-Provider, der ja ebenfalls eine PBX ist. Problematisch sind aber eben Dinge wie Loadbalancing, weil sowas bei lokalen PBX - und auch bei kleineren VoIP-Providern - nicht existiert.
Aber die Grandstreams sind halt eigentlich nicht darauf ausgelegt, weil in Firmenumgebungen immer eine PBX zum Einsatz kommt - wer will denn die internen Gespräche alle nach außen geben?
Zumal alle großen VoIP-Anbieter gezwungen sind, Abhörmöglichkeiten zu schaffen, und dazu auch die eigentlichen Medienströme relayen müssen (ganz im Gegensatz zum Grundgedanken des SIP, dass die eigentlichen Mediendaten zwischen den Endgeräten direkt laufen)

@Outbound-Proxy
"seems like this service provider use multiple IP's"

Wie es technisch genau realisiert wird, weis ich auch nicht. Ich vermute mal, dass der DTAG-DNS dir die passende IP-Adresse zu tel.t-online.de in Abhängigkeit Deiner eigenen externen IP zuweist. Wäre jedenfalls der logischste Weg, denn so bekommen verschiedene Kunden verschiedene IPs zurück geliefert. Das Problem wäre also nicht der gewählte DNS, sondern die Dir gerade extern zugewiesene IP...


Die einfachste Lösung wäre also eine FBF als lokaler "Proxy". Eine 7170 mit defektem DSL-Modem wäre zu weniger als 20€ zu haben. Eine richtige PBX (Asterisk) kostet rund 45€ (RaspberryPI, SD-Karte, Gehäuse, Netzteil), ist aber kniffelig zu installieren, vor allem, wenn es das DTAG-Problem lösen soll.

 

[GottSeth]

Wie es technisch genau realisiert wird, weis ich auch nicht. Ich vermute mal, dass der DTAG-DNS dir die passende IP-Adresse zu tel.t-online.de in Abhängigkeit Deiner eigenen externen IP zuweist. Wäre jedenfalls der logischste Weg, denn so bekommen verschiedene Kunden verschiedene IPs zurück geliefert. Das Problem wäre also nicht der gewählte DNS, sondern die Dir gerade extern zugewiesene IP..

Stimmt soweit ich weiß :ziggi:

Der einfachste Lösung, ist aber ne Puplic-DNS zu nutzen - die waren noch nie längere Zeit down, und werden eigentlich immer gut "gepflegt"

 

[andiling]

Fast. Die DNS Serveradressen unterscheiden sich von Anschluss zu Anschluss und die lösen dann den zuständigen SIP Server auf. Wenn der DNS Server erstmal die richtige Antwort suchen muss dauert das viel zu lange. Diese regionalen DNS Server kann man auch nur vom passenden Anschluss aus erreichen.

Außerhalb dieser Welt löst tel.t-online.de zu 217.0.16.42 auf.

 

[Andre]

Worüber man sich aber gar nicht mehr anmelden kann. DTAG-VoIP und abweichende Einträge für den DNS-Server im Router schließen sich demnach zwingend aus.

Da Android ja ein offenes System ist und sich die Einstellungen des GXV über die Webadminseite ändern lassen, wäre ein Workarround ein kleines Skript, das z.B. alle 10 Minuten tel.t-online.de auflöst und prüft, ob sich die IP geändert hat. Wenn ja, muss sich das Skript ins admin-interface einloggen, die Outbound-Proxy-IP ändern und die neuen Einstellungen übernehmen.

Da müsste sich dann aber jemand mit befassen, der sich damit auskennt...

 

[andiling]

Hmm... ich habe die 7390 als IP-Client und einen eigenen DNS Server konfiguriert, der nicht auf T-DNS zurückgreift. Im Gegensatz zum Router kann der Client die T-DNS-Adressen nicht kennen und muss sich m.E. mit der allgemein aufgelösten Adresse von tel.t-online.de zufrieden geben. Funktionieren tut das aber einwandfrei.

Ich gehe dem mal morgen im Detail nach.

 

[Andre]

Wäre interessant. Meldest Du Dich anonym an oder mit Nutzername/Password?
Eventuell ginge es ja, im GXV mit Nutzername/Password anzumelden und durchgehend 217.0.16.42 statt tel.t-online.de zu verwenden oder (falls IPs nicht überall zulässig sind) in der host-Datei des GXV tel.t-online.de zwingend zu 217.0.16.42 aufzulösen...

 

[andiling]

Inzwischen scheint die Art der Anmeldung am eigenen Anschluss komplett egal zu sein.

Ich kann mich anonym, mit meinen Zugangsdaten oder jedem beliebigen Namen/Passwort anmelden, geht alles, egal ob mit oder ohne MyLogin.

Die Registrierung an 217.0.16.42 scheint wohl ohne Probleme möglich zu sein.

SIP log
----------
2014-10-31 13:10:57.728 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bKE99AA4423E800E2F
From: <sip:[email protected]>;tag=2346639760
To: <sip:[email protected]>;tag=5c7a4be0
Call-ID: [email protected]
CSeq: 4590 REGISTER
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>;expires=287
P-Associated-URI: <sip:[email protected];user=phone>
Content-Length: 0

2014-10-31 13:10:57.731 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bK08B42B79499986D3
From: <sip:[email protected]>;tag=2346639760
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 4591 REGISTER
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>
Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="240f72fc240f72fc705c005a60be2cf09976ddc4c837825615d7bd36e5ff6774", uri="sip:tel.t-online.de", response="becb9551ea25c860b2d4364076a41c48", algorithm=MD5
Max-Forwards: 70
Expires: 0
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

2014-10-31 13:10:57.848 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bK08B42B79499986D3
From: <sip:[email protected]>;tag=2346639760
To: <sip:[email protected]>;tag=44fe0b1f
Call-ID: [email protected]
CSeq: 4591 REGISTER
P-Associated-URI: <sip:[email protected];user=phone>
Content-Length: 0

2014-10-31 13:11:16.865 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
(null)

2014-10-31 13:11:16.865 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.234 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
(null)

2014-10-31 13:11:16.997 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bK3A0D644DE13D2962
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 1 REGISTER
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

2014-10-31 13:11:17.092 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bK3A0D644DE13D2962
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>;tag=d5a7e8db
Call-ID: [email protected]
CSeq: 1 REGISTER
WWW-Authenticate: Digest realm="tel.t-online.de", nonce="d49942a7d49942a780ca3ec29056254060127e99ee9ae27ad5baa3b87380c472", algorithm=MD5
Content-Length: 0

2014-10-31 13:11:17.095 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bKB41DCB08BF534B1E
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 2 REGISTER
Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="d49942a7d49942a780ca3ec29056254060127e99ee9ae27ad5baa3b87380c472", uri="sip:tel.t-online.de", response="310c83d93755e8a49635d2f6ed35e6b8", algorithm=MD5
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

2014-10-31 13:11:17.228 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bKB41DCB08BF534B1E
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>;tag=7fd8bf1c
Call-ID: [email protected]
CSeq: 2 REGISTER
P-Associated-URI: <sip:[email protected];user=phone>
Content-Length: 0

2014-10-31 13:11:17.231 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
REGISTER sip:tel.t-online.de SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bK32DC35CD5A769078
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 3 REGISTER
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>
Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="d49942a7d49942a780ca3ec29056254060127e99ee9ae27ad5baa3b87380c472", uri="sip:tel.t-online.de", response="310c83d93755e8a49635d2f6ed35e6b8", algorithm=MD5
Max-Forwards: 70
Expires: 600
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Supported: 100rel,replaces
Allow-Events: telephone-event,refer,reg
Allow: INVITE,ACK,OPTIONS,CANCEL,BYE,UPDATE,PRACK,INFO,SUBSCRIBE,NOTIFY,REFER,MESSAGE,PUBLISH
Accept: application/sdp, multipart/mixed
Accept-Encoding: identity
Content-Length: 0

2014-10-31 13:11:17.353 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 200 OK
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bK32DC35CD5A769078
From: <sip:[email protected]>;tag=3344267770
To: <sip:[email protected]>;tag=fe45b35a
Call-ID: [email protected]
CSeq: 3 REGISTER
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>;expires=600
P-Associated-URI: <sip:[email protected];user=phone>
Content-Length: 0

2014-10-31 13:11:17.355 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
(null)

2014-10-31 13:11:17.356 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.234 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
(null)

2014-10-31 13:11:17.358 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bKF1782D5CC2B8BFB3
From: <sip:[email protected]>;tag=1024924709
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 4 SUBSCRIBE
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>
Event: message-summary
Expires: 3600
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Allow: NOTIFY
Accept: application/simple-message-summary
Content-Length: 0

2014-10-31 13:11:17.451 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bKF1782D5CC2B8BFB3
From: <sip:[email protected]>;tag=1024924709
To: <sip:[email protected]>;tag=300296c6
Call-ID: [email protected]
CSeq: 4 SUBSCRIBE
WWW-Authenticate: Digest realm="tel.t-online.de", nonce="12bf614e12bf614e46ec1d2b5670084a5a46d84c0f7344fcd0b2740564b4e899", algorithm=MD5
Content-Length: 0

2014-10-31 13:11:17.455 - OUT: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=internet tcclass=sip_internet, netmark=0:
SUBSCRIBE sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 1.2.3.4:5060;rport;branch=z9hG4bKDD411B4061389D1C
From: <sip:[email protected]>;tag=4091039175
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 5 SUBSCRIBE
Contact: <sip:[email protected];uniq=5C9B610D88607CED7CCB8C2471038>
Authorization: Digest username="[email protected]", realm="tel.t-online.de", nonce="12bf614e12bf614e46ec1d2b5670084a5a46d84c0f7344fcd0b2740564b4e899", uri="sip:[email protected]", response="6038b4cfeff4f23443ac37df481c651f", algorithm=MD5
Event: message-summary
Expires: 3600
Max-Forwards: 70
User-Agent: AVM FRITZ!Box Fon WLAN 7390 84.06.20 (Aug 21 2014)
Allow: NOTIFY
Accept: application/simple-message-summary
Content-Length: 0

2014-10-31 13:11:17.561 - IN: my=10.0.0.18%6:5060 peer=217.0.16.42 port=5060 UDP, sipiface=none:
SIP/2.0 404 Zielrufnummer nicht bekannt oder nicht unterstützt. (23)
Via: SIP/2.0/UDP 1.2.3.4:5060;rport=5060;branch=z9hG4bKDD411B4061389D1C
From: <sip:[email protected]>;tag=4091039175
To: <sip:[email protected]>;tag=47abd557
Call-ID: [email protected]
CSeq: 5 SUBSCRIBE
Contact: <sip:[email protected]:5060>
Content-Length: 0

 

[o0Julia0o]

Da Android ja ein offenes System ist und sich die Einstellungen des GXV über die Webadminseite ändern lassen, wäre ein Workarround ein kleines Skript, das z.B. alle 10 Minuten tel.t-online.de auflöst und prüft, ob sich die IP geändert hat. Wenn ja, muss sich das Skript ins admin-interface einloggen, die Outbound-Proxy-IP ändern und die neuen Einstellungen übernehmen.

aber die IP-Adresse von tel.t-online.de nützt mir ja nix - die funktioniert nicht. Auch wenn das auf der Telekom-Seite so steht. Regional ist ja der Outbound-Proxy verschieden & für meine Region funktioniert nur: 217.0.20.236

Und kann ich das Script einfach so ausführen lassen beim Start vom Telefon oder müsste ich es rooten?

Ich wäre ja schon froh, wenn ich den irgendwie nachgucken könnte & wenn das Telefon bei der nächsten Outbound-Proxy-Änderung ausfällt ich dann nachgucken kann, welcher der neue Outbound-Proxy für meine Region ist.

Eine FBF wird als IP-Client eingerichtet. Ist dann ganz normales Gerät im internen Netzwerk. Die FBF ist bei den DTAG-Nummern angemeldet, je Nummer stellt es einen Account zur Anmeldung eines IP-Telefons bereit. Alle ein- und ausgehenden Anrufe über die DTAG gehen dann logisch über die FBF. Das IP-Telefon ist an die IP-Telefon-Accounts der FBF angemeldet, zusätzlich z.B. an Sipgate Basic, CheepVoIP und IPVideoTalk. Man kann in den GXV ja 6 Accounts einstellen. Wenn man den Hörer abnimmt oder die Telefonapp startet, kann man die abgehende Line duch Antippen aussuchen. Eingehend reagiert das GXV auf alle Nummern.

Hört sich doch gut an - bis auf den Account-Slot-Verbrauch. Und ich kann die FBF dann einach in einen Slot vom Routerswitch stecken - so wäre sie ja im Netz anpingbar von den IP-Telefonen? Und dann vergebe ich der FBF eine IP-Adresse. Und was nun?

Eine 7170 mit defektem DSL-Modem wäre zu weniger als 20€ zu haben.

jo, auch mit funktionierendem. Welche FBF sind denn alle tauglich dazu? Gibt ja immer mal wieder gebrauchte oder defekte angeboten, dann wüsste ich wo ich zuschlagen könnte. Als Backup-Lösung für die Himbeere. Kann ich mir dort im Package-Manager einfach Asterisk, DAHDI, and libpri herunterladen und installieren? asterisk-11-current.tar.gz findet man ja so auch überall, aber DAHDI & libpri nicht.

 

[Andre]

Der Account-Slot-Verbrauch ist an sich kein Problem - letzlich kann man sogar die Zahl der Slots reduzieren, indem man in der FBF mehrere Rufnummern auf einen IP-Telefonaccount routet und ausgehende Wahlregeln in der FBF definiert.

Es gehen definitiv die 7170 (Achtung: ein bestimmter Seriennummernbereich geht nicht, bei wehavemorefun nachschauen), 7240, 7270, 7390, 7490. Welche von den anderen, verkrüppelten Modellen interne IP-Telefonieaccounts unterstützen, kann ich nicht aus dem Kopf sagen. Ab 7240 haben die Boxen auch internen DECT, was sehr praktisch ist, schließlich will man nicht ausschließlich das stationäre Telefon nurtzen. Ich rate daher meist zur 7240.

Ein Vorteil, wenn man DECT und IP-Telefone über die FBF betreibt, ist die Liste verpassten Anrufe. Hast Du z.B. am Draytek eine DECT-Basis am analogen Anschluss, würde das DECT-Telefon einen verpassten Anruf anzeigen, wenn Du am GXV annimmst. Anders bei Betrieb über die FBF, hier verwaltet diese die verpassten Anrufe, ergo weis sie, dass der Anruf nicht verpasst war...

DAHDI auf dem Raspi hat mich einige Nächte gekostet. Da dies Kernelmodule benötigt, braucht man die passenden Kernel-Header. Komischerweise sind die kaum zu bekommen (wobei es von der Ditribution abhängt, die man verwendet). Man muss die ganze Umgebung zum Kompillieren des Kernels laden, die Kernel-Sourcen und dann die Kompillierung eines neuen Kernels mit gleicher Versionsnummer vorbereiten (glücklicherweise nicht komplett kompillieren), dann hat man die Header...
Dahdi geht entsprechend auch nicht als Paket, sondern muss auch passend zum Kernel kompilliert werden ...
Auch muss man den Asterisk selbst kompillieren, um DAHDI einzubinden.

Der Vorteil beim RasPi ist natürlich die genau definierte Hardware. Hat man ein funktionierendes Basissystem, kann man einfach die SD-Karte klonen.
Leider sind die fertigen Systeme (Incredible Pi) derart mit Funktionen überladen, die man als Heimanwender gar nicht braucht und es fehlen genau die Funktionen im Webinterface, die man händisch in überladenen Konfigdateien nachrüsten muss, dass ich nicht empfehlen kann, sie zu nutzen.

Ich arbeite gerade an einem Image, das Asterisk 13.0.0 mit DAHDI, chan_mobile, IMAP-Unterstützung und noch einigem weiteren enthält. etc/asterisk in Samba freigegeben, also bequem aus dem Windows-Netzwerk zu editieren.
Ich arbeite noch an Musterkonfiguration und Anleitung - aber erstmal versuche ich noch, bluetooth zum Laufen zu bekommen. Das Image ist aber ziemlich groß, weil ich ja die ganze Entwicklungsumgebung mit drin habe (fürs updaten aber nicht verkehrt...)

 

[andiling]

Also ehrlich gesagt, Draytek, Grandstream und dann eine (olle) FBF, das passt doch nicht?!?

Das mit den entgangenen Anrufen kann ich nicht bestätigen, ich habe es nicht geschafft, meine Gigasets (SL400H) wie auch mein damaliges GS dazu zu bringen abgehobene Anrufe als nicht verpasst anzuzeigen (mit AVM Handsets wirds zumindest für die wohl gehen).

Ich habe den 217.0.16.42 an drei verschiedenen Anschlüssen in DE getestet und zumindest mit der FB und dem SP gab es kein Problem. Dass das nicht mit dem GS geht muss einen anderen Hintergrund haben.

 

[Andre]

... Draytek, Grandstream und dann eine (olle) FBF, das passt doch nicht ...

Sicher. Jedes Gerät hat seine Nische. Da gibt es kein Entweder-Oder. Ich setze in meinem Netzwerk sogar noch FBF Classics ein - die haben die zuverlässigste Impulswahlerkennung. Das Problem der FBFs ist bloß deren Überladung mit Funktionen. Als ATA/ITA ist sie nicht verkehrt.
Die FBF (gerade die 7170) sind auch eine gute Lösung, das delmont-Problem zu lösen, dass pro Endgerät nur ein Gespräch gleichzeitig möglich ist (wobei ein Asterisk halt auch als ein Endgerät zählt). Setzt man die FBF als Mediagateway (in diesem Fall als SIP- und RDP-Proxy) ein, hat man dies Problemeinfach und elegant umgangen.

 

[o0Julia0o]

Der Account-Slot-Verbrauch ist an sich kein Problem - letzlich kann man sogar die Zahl der Slots reduzieren, indem man in der FBF mehrere Rufnummern auf einen IP-Telefonaccount routet und ausgehende Wahlregeln in der FBF definiert.

Aber manchmal möchte man das wählen auch flexibel handhaben. Und es gibt auch Apps welche einen Account verknüpft haben müssen - dazu brauche ich dann schonmal einen Extraaccount, wenn ich nicht eine echte Telefonnummer nutzen möchte. Also schön ist es jedenfalls nicht, dass die freie Accout-Menge weniger wird.

Es gehen definitiv die 7170 (Achtung: ein bestimmter Seriennummernbereich geht nicht, bei wehavemorefun nachschauen).Ab 7240 haben die Boxen auch internen DECT, was sehr praktisch ist, schließlich will man nicht ausschließlich das stationäre Telefon nurtzen.

Also hier steht davon zunächst einmal nichts: http://www.wehavemorefun.de/fritzbox/7140. Oder wonach muss ich genau suchen? Nach support for internal telefone-accounts? Bei mir ist es so, dass ich ausschliesslich das stationäre Telefon nutzen möchte. Dect-Funktion möchte ich sogar komplett abschaltbar haben. Aber danke für den Tipp!

Ein Vorteil, wenn man DECT und IP-Telefone über die FBF betreibt, ist die Liste verpassten Anrufe. Hast Du z.B. am Draytek eine DECT-Basis am analogen Anschluss, würde das DECT-Telefon einen verpassten Anruf anzeigen, wenn Du am GXV annimmst. Anders bei Betrieb über die FBF, hier verwaltet diese die verpassten Anrufe, ergo weis sie, dass der Anruf nicht verpasst war...

hatte über so etwas noch nie nachgedacht - interessant zu wissen, auch wenn es für mich ja nicht in Frage kommt, da ich kein DECT-Gerät habe.

Der Vorteil beim RasPi ist natürlich die genau definierte Hardware. Hat man ein funktionierendes Basissystem, kann man einfach die SD-Karte klonen.
Leider sind die fertigen Systeme (Incredible Pi) derart mit Funktionen überladen, die man als Heimanwender gar nicht braucht und es fehlen genau die Funktionen im Webinterface, die man händisch in überladenen Konfigdateien nachrüsten muss, dass ich nicht empfehlen kann, sie zu nutzen.

Das Incredible Pi hat aber dann Incredible PBX anstelle von ASterisk installiert, richtig? Es gibt ja auch AsteriskNOW, da ist eine Linux-Distribution bereits mit drin - installiert sich also leicht. Aber wie kann ich die ISO überhaupt installieren ohne DVD-Laufwerk? Und der Nachteil ist, dass ich dann keinen Einfluss auf die Linux-Version habe, die dann vielleicht andere Projekte nicht so gut supportet. Denn wenn ich schon ein Raspberry Pi betreibe, dann möchte ich es parallel auch noch mit anderen Aufgaben betreuen - sollte ja genug Leistung über haben, neben der PBX-Aufgabe.

Ich arbeite gerade an einem Image, das Asterisk 13.0.0 mit DAHDI, chan_mobile, IMAP-Unterstützung und noch einigem weiteren enthält. etc/asterisk in Samba freigegeben, also bequem aus dem Windows-Netzwerk zu editieren.
Ich arbeite noch an Musterkonfiguration und Anleitung - aber erstmal versuche ich noch, bluetooth zum Laufen zu bekommen. Das Image ist aber ziemlich groß, weil ich ja die ganze Entwicklungsumgebung mit drin habe (fürs updaten aber nicht verkehrt...)

-das mit den Portabilität hatte ich gar nicht so auf dem Plan, das ist ja echt super
-libpri ist aber ohnehin nur für ISDN notwendig, oder?
-größe spielt ja keine Rolle eigentlich, solange es passende SD-Karten gibt.. so viel Strom zieht es wohl nicht
-ich wäre natürlich interessiert

Die FBF (gerade die 7170) sind auch eine gute Lösung, das delmont-Problem zu lösen, dass pro Endgerät nur ein Gespräch gleichzeitig möglich ist (wobei ein Asterisk halt auch als ein Endgerät zählt).

2 Leitungen habe ich laut Telekom-Vertrag. Wenn ich also Asteriks einsetze, dann kann ich nur an einem Telefon telefonieren & nicht mehr an 2 Telefonen gleichzeitig?

und dem SP gab es kein Problem. Dass das nicht mit dem GS geht muss einen anderen Hintergrund haben.

Was ist denn SP?

 

[andiling]

Sp wie Speedport