[Gelöst] Bei abgehenden Anrufen kein eingehender Ton

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
J

jonofe

Neuer User
Mitglied seit
26 Aug 2007
Beiträge
29
Punkte für Reaktionen
0
Punkte
1
Hallo zusammen,

nach dem Umbau meines Heimnetzes aufgrund Umstellung von ADSL auf VDSL habe ich das Problem, dass ich bei ausgehenden Anrufen ins ISDN Netz keinen eingehendes Audio mehr habe, d.h. der Angerufene mich zwar hört, aber ich ihn nicht. Ruft derselbe Anschluss hingegen mich an, kommt eine korrekte Verbindung in beide Richtungen zustanden. Interne Anrufe funktionieren auch. Rufe ich mich allerdings selbst über externe MSNs an, tritt dasselbe Problem auf.

Hier die Änderung meines Netzes:

alt: (funktioniert)

Internet <--> Alice IAD WLAN 3232 (PPPoE Passthrough) <--> WAN: 85.182.220.x - Router - LAN: 192.168.0.1 <--> LAN <--> Asterisk (192.168.0.10)

neu: (funktioniert nicht)

Internet <--> WAN: 85.182.220.x - O2 Homebox 6641 - DMZ: 192.168.1.1 <--> DMZ: 192.168.1.2 - Router - LAN: 192.168.0.1 <--> LAN <--> Asterisk (192.168.0.10)

In der neuen Konfiguration habe ich o.g. Problem, d.h. kein eigehendes Audio bei ausgehenden Anrufen.

Ändere ich die Config nun wie folgt:

Internet <--> WAN: 85.182.220.x - O2 Homebox 6641 - LAN: 192.168.0.1 <--> Asterisk (192.168.0.10)

dann funktioniert es wieder, allerdings möchte ich dies so nicht haben, da ich den Router dazwischen brauche um dynmisch Firewallregeln setzen zu können und außerdem mein E-Mail Server in einer DMZ stehen soll und nicht im internen LAN.

Der Asterisk Server ist übrigens mit einer hfc Karte ausgestattet und hängt damit direkt am S0 der O2 Homebox. Daher war mein Verständnis, dass die Netzänderung davor eigentlich gar kein Einfluss haben sollte, denn ich spreche hier nur von SIP Telefonen die im internen Netz 192.168.0.x hängen, d.h. über gar keinen Router müssen, sondern nur im internen Netz zum asterisk (192.168.0.10) kommunizieren und dieser per ISDN ins PSTN.

Hier meine sip.conf:

Code: 
[general]
context = default
alwaysauthreject=yes
allowguest=no
bindport = 5060
bindaddr = 0.0.0.0
srvlookup = yes
language = de
register => 1234567:[email protected]/1234567
buggymwi = yes
buggyciscomwi = yes
domain=192.168.0.10
domain = anrath.net
disallow=all
allow=alaw
allow=ulaw
allow=gsm
nat=no
transport=udp
externip=85.182.220.xxx
localnet=192.168.0.0/255.255.255.0


[s685ip]
callerid = s685ip <11>
call-limit=2
context=sip
contactdeny=0.0.0.0/0.0.0.0
contactpermit=192.168.0.0/255.255.255.0
allowguest=no
host=dynamic
domain = 192.168.0.10
user = s685ip
secret = <password>
type = friend
mailbox = 497809@VOICEMAIL
canreinvite = no

Ich hoffe ihr habt einen Tip für mich, wo ich ansetzen kann.

Danke im Voraus.

Viele Grüße

André
 
Zuletzt bearbeitet:
Ohne IP geht nicht, da ich keine ISDN Telefone habe, d.h. ich brauche IP um überhaupt telefonieren zu können.
ISDN ist quasi nur meine PSTN Anbindung, aber ich habe keinen internen S0 Bus an dem noch ISDN Geräte hängen.

Oder hab ich deine Frage nicht richtig verstanden? :-?
 
Doch, alles klar ich habe das vergessen, dann hänge doch nur die Verbindung für ein SIP-Fon dran
 
Ich nehme mal an - Signatur hast Du ja leider nicht - dass die Asterisk-Version > 1.4 ist.
Falls dem so sein sollte, ändere bitte mal
Code: 
canreinvite = no
in
Code: 
directmedia = no
.

Ansonsten ist Dein SIP-Telefon auch noch ein wenig "krude" konfiguriert:

Code: 
allowguest=no
gehört, wenn dann denn dann in den general-Abschnitt.
Code: 
call-limit=2
gibt es bei Asterisk > 1.4 nicht mehr.

Was zusätzlich irritiert: Wenn nach außen ISDN genutzt wird, weshalb gibt es dann eine SIPGATE-Registrierung ?

Ansonsten kannst Du im Szenario "Einseitiges Audio" auch mal
Code: 
rtp set debug on
einschalten, dann siehst Du nämlich, von/an welche IP-Adressen der Ton gesendet wird.
 
abw1oim schrieb:
Ich nehme mal an - Signatur hast Du ja leider nicht - dass die Asterisk-Version > 1.4 ist.
Zum Vergrößern anklicken....

Ja, es ist Asterisk 1.8.20.0

abw1oim schrieb:
Ansonsten ist Dein SIP-Telefon auch noch ein wenig "krude" konfiguriert:
Zum Vergrößern anklicken....

Ist dann wohl noch ein Relikt von früheren Asterisk, bzw. das allowguest von einem Zwischenfall, bei dem mein Asterisk gehackt wurde und für 500€ nach Kuba telefoniert wurde. :-(
Habe ich jetzt geändert.

abw1oim schrieb:
Was zusätzlich irritiert: Wenn nach außen ISDN genutzt wird, weshalb gibt es dann eine SIPGATE-Registrierung ?
Zum Vergrößern anklicken....

sipgate nutze ich, wenn ich eingehende Anrufe nach extern weiterleiten möchte, da sipgate ermöglicht die Absenderrufnummer zu ersetzen. Somit kann ich die Anrufernummer erhalten und ich sehe am Handy immer noch, wer da anruft. Ansonsten würde ich ja meine asterisk Nummer sehen.

abw1oim schrieb:
rtp set debug on
Zum Vergrößern anklicken....

Okay, das mache ich dann als nächstes. Melde mich gleich, ob es erfolgreich war.
Wo muss ich das rtp set debug on denn angeben? sip.conf?
bis gleich

André
 
okay, habs mir schon selbst beantwortet, es war ein console Befehl:

und es erzeugt nach Verbindungsaufbau fortlaufenden einen Output wie folgt: (Eigene MSN auf eigene MSN => funktioniert nicht)

Code: 
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040046, ts 086880, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044857, ts 084480, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000586, ts 35036160, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024011, ts 116955816, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040047, ts 087040, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044858, ts 084640, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000587, ts 35036320, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024012, ts 116955976, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040048, ts 087200, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044859, ts 084800, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000588, ts 35036480, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024013, ts 116956136, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040049, ts 087360, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044860, ts 084960, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000589, ts 35036640, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024014, ts 116956296, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040050, ts 087520, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044861, ts 085120, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000590, ts 35036800, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024015, ts 116956456, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040051, ts 087680, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044862, ts 085280, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000591, ts 35036960, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024016, ts 116956616, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040052, ts 087840, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044863, ts 085440, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000592, ts 35037120, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024017, ts 116956776, len 000160)
Sent RTP packet to      192.168.0.60:30428 (type 08, seq 040053, ts 088000, len 000160)
Sent RTP packet to      192.168.0.63:5008 (type 08, seq 044864, ts 085600, len 000160)
Got  RTP packet from    192.168.0.63:5008 (type 08, seq 000593, ts 35037280, len 000160)
Got  RTP packet from    192.168.0.60:30428 (type 08, seq 024018, ts 116956936, len 000160)

Das sind die beiden SIP Endgeräte. Und ich habe die Anwahl über die ISDN MSN gemacht.

Mache ich es hingegen über die interne Asterisknummer, dann funktioniert die Verbindung wie gewünscht und das RTP Log sieht wie folgt aus: (Anruf von 10 auf 11 => funktioniert)

Code: 
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.60:31358 (type 08, len 000160)
Sent RTP P2P packet to 192.168.0.63:5010 (type 08, len 000160)

Und als Ergänzung: Wenn ich eine komplett externe Nummer anrufe bekomme ich: (SIP Telefon => Handy => funktioniert nicht)

Code: 
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027868, ts 000160, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027869, ts 000320, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027870, ts 000480, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027871, ts 000640, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027872, ts 000800, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000072, ts 35104640, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027873, ts 000960, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000073, ts 35104800, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027874, ts 001120, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000074, ts 35104960, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027875, ts 001280, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000075, ts 35105120, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027876, ts 001440, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000076, ts 35105280, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027877, ts 001600, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000077, ts 35105440, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027878, ts 001760, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000078, ts 35105600, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027879, ts 001920, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000079, ts 35105760, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027880, ts 002080, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000080, ts 35105920, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027881, ts 002240, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000081, ts 35106080, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027882, ts 002400, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000082, ts 35106240, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027883, ts 002560, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000083, ts 35106400, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027884, ts 002720, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000084, ts 35106560, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027885, ts 002880, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000085, ts 35106720, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027886, ts 003040, len 000160)
Got  RTP packet from    192.168.0.63:5012 (type 08, seq 000086, ts 35106880, len 000160)
Sent RTP packet to      192.168.0.63:5012 (type 08, seq 027887, ts 003200, len 000160)

Und beim Anruf von extern, welcher dann korrekt funktioniert, erscheint etwa: (Handy => eigene MSN am asterisk => funktioniert)

Code: 
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048069, ts 000960, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024399, ts 117078144, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048070, ts 001120, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024400, ts 117078304, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048071, ts 001280, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024401, ts 117078464, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048072, ts 001440, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024402, ts 117078624, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048073, ts 001600, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024403, ts 117078784, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048074, ts 001760, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024404, ts 117078944, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048075, ts 001920, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024405, ts 117079104, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048076, ts 002080, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024406, ts 117079264, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048077, ts 002240, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024407, ts 117079424, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048078, ts 002400, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024408, ts 117079584, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048079, ts 002560, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024409, ts 117079744, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048080, ts 002720, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024410, ts 117079904, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048081, ts 002880, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024411, ts 117080064, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048082, ts 003040, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024412, ts 117080224, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048083, ts 003200, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024413, ts 117080384, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048084, ts 003360, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024414, ts 117080544, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048085, ts 003520, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024415, ts 117080704, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048086, ts 003680, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024416, ts 117080864, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048087, ts 003840, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024417, ts 117081024, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048088, ts 004000, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024418, ts 117081184, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048089, ts 004160, len 000160)
Got  RTP packet from    192.168.0.60:28518 (type 08, seq 024419, ts 117081344, len 000160)
Sent RTP packet to      192.168.0.60:28518 (type 08, seq 048090, ts 004320, len 000160)
Seltsam!!!

Noch weitere Ideen?
 
Zuletzt bearbeitet:
Aber da liegt ja auch der Hund begraben: Wenn ich es richtig verstanden habe, gehst Du über die hfc-Karte (per DAHDI oder etwas anderem) and den internen S0 von der O2 Homebox und von da über ISDN weiter ...
Wenn das so ist, darf in diesem Szenario kein Datenstrom zwischen den Endgeräten fließen. Vielmehr müsste Asterisk, also 192.168.0.10 hier als Mediengateway zwischen ISDN und SIP auftauchen.
Wer ist eigentlich in dem Szenario Anrufer und wer Angerufener ? Da wäre in wenig Konsolenoutput nett, um sehen zu können, wer eigentlich wohin anruft.

Eines hatte ich aber in der Tat auch noch übersehen:
Code: 
localnet=192.168.0.0/255.255.255.0
passt im neuen Setup nicht mehr und müsste entweder einfach so
Code: 
localnet=192.168.0.0/255.255.0.0
oder etwas komplizierter so
Code: 
localnet=192.168.0.0/255.255.255.0
localnet=192.168.1.0/255.255.255.0
sein. Das sollte zwar das beschriebene Szenario eigentlich nicht betreffen, aber zur Korrektheit gehörts halt dazu ...

Hattest Du nach den vorgeschlagenen Änderungen einen sip reload (oder einen Asterisk reload bzw. Neustart) gemacht ?
 
Die 192.168.0.63 ist Anrufer, die .60 wird angerufen. Außer im vierten Fall, da habe ich per Handy auf die 192.168.0.60 angerufen, aber dieser Fall funktioniert ja auch. Bei beidem Problemfällen war 192.168.0.63 der Anrufer.

Hier nochmal der Consolen Output, allerdings passiert da noch etwas mehr, aber ich hoffe du kannst die relevanten Zeilen identifizieren:

Code: 
  == Using SIP RTP CoS mark 5
    -- Executing [016090717xxx@sip:1] System("SIP/s685ip-00000010", "/usr/bin/php /home/eib/homeserver/prowl/send_prowl.php 'Outgoing Call' 'Call from: s685ip (11) \nCall to    : 016090717xxx' ASTERISK 2") in new stack
       > doing dnsmgr_lookup for 'sipgate.de'
       > ast_get_srv: SRV lookup for '_sip._udp.sipgate.de' mapped to host sipgate.de, port 5060
    -- Executing [016090717xxx@sip:2] System("SIP/s685ip-00000010", "/usr/bin/php /home/eib/homeserver/server/send_cmd.php OUTGOING_CALL _11 016090717xxx") in new stack
    -- Executing [016090717xxx@sip:3] Goto("SIP/s685ip-00000010", "outgoing,,1") in new stack
    -- Goto (outgoing,016090717xxx,1)
    -- Executing [016090717xxx@outgoing:1] ExecIf("SIP/s685ip-00000010", "0?Set(CALLERID(num-pres)=prohib_not_screened)") in new stack
    -- Executing [016090717xxx@outgoing:2] ExecIf("SIP/s685ip-00000010", "0?Set(CALLERID(num-pres)=prohib_not_screened)") in new stack
    -- Executing [016090717xxx@outgoing:3] NoOp("SIP/s685ip-00000010", "") in new stack
    -- Executing [016090717xxx@outgoing:4] Dial("SIP/s685ip-00000010", "dahdi/g1/016090717xxx,60,r") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called dahdi/g1/016090717xxx
    -- DAHDI/i1/016090717xxx-f is proceeding passing it to SIP/s685ip-00000010
    -- DAHDI/i1/016090717xxx-f is ringing
    -- DAHDI/i1/016090717xxx-f is making progress passing it to SIP/s685ip-00000010
    -- DAHDI/i1/016090717xxx-f answered SIP/s685ip-00000010
    -- Executing [h@outgoing:1] NoOp("SIP/s685ip-00000010", "ANSWER") in new stack
    -- Executing [h@outgoing:2] System("SIP/s685ip-00000010", "/usr/bin/php /home/eib/homeserver/server/send_cmd.php CALL_FINISHED ANSWER 021xx497xxx 10") in new stack
    -- Hungup 'DAHDI/i1/016090717xxx-f'
  == Spawn extension (outgoing, 016090717xxx, 4) exited non-zero on 'SIP/s685ip-00000010'
david*CLI>

abw1oim schrieb:
localnet=192.168.0.0/255.255.255.0 passt im neuen Setup nicht mehr
Zum Vergrößern anklicken....

Ursprünglich hatte ich das so und hatte es während der Fehlersuche geändert. Habs jetzt wieder wie von die beschrieben umgestellt.

abw1oim schrieb:
Hattest Du nach den vorgeschlagenen Änderungen einen sip reload (oder einen Asterisk reload bzw. Neustart) gemacht ?
Zum Vergrößern anklicken....

Ja, jeweils ein asterisk Neustart.
 
Laut dem Konsolen-Log rufst Du aber ein Handy an (das auch abnimmt: DAHDI/i1/016090717xxx-f answered SIP/s685ip-00000010).
Das führt uns jedenfalls nicht zu dem Problem mit "Auf eigene MSN herausrufen und dann nur einseitiger Ton".
In diesem speziellen Handy-Fall müsste in jedem Fall beidseitiger Ton da sein (auch wenn ich das r im Dial hier weglassen würde, aber das ist für das Problem nicht relevant), da ja auch nur eine einzige IP-Komponente beteiligt ist (gut: streng genommen zwei, nämlich ein telefon und der Asterisk, aber da kommt ja RTP an) und der Rest DAHDI ist.
 
Aber wie eingangs gesagt, ich habe das Problem immer wenn ich ins ISDN Netz (PSTN) anrufe, also auch bei diesem Anruf auf das Handy. Ich habe dann keinen eingehenden Ton.
Wenn das handy hingegen anruft, dann funktioniert es. Ist genauso wie zwischen den public MSNs.
 
hast du mal versucht mit 'dahdi_monitor' die Audio Levels fuer Sende und Empfangsseite in Echtzeit am DAHDI Interface abzugreifen? Waere insbesondere der Vergleich von Gut- und Schlechtfall interessant.
Man kann damit auch RX / TX streams kombiniert/getrennt aufzeichnen etc.

Mir ist aus den Angaben immer noch nicht klar ob das Problem ISDN oder IP seitig auftritt. Ergibt es einen Unterschied, wenn die beiden IP Telefone getauscht werden? Wenn nicht gerade intern telefoniert wird, scheint es immer dann nicht zu gehen wenn die 192.168.0.63 massgeblich beteiligt ist.
 
Dann wird's langsam esotherisch :mad:

Wenn in diesem Szenario kein eingehender Ton (am SIP-Telefon) ankommt, bridgt Asterisk die DAHDI-Pakete nicht an das SIP-Endgerät durch. Das verstehe, wer will. Das Einzige, was noch schräg ist, ist das nat=no, das ein diesem Szenario eigentlich nat=yes wäre, aber das sollte eigentlich nicht stören.

Du kannst jetzt höchstens noch einmal einen sip-Debug auf das Call-Szenario machen (also auf der Asterisk-Console: sip set debug peer s685ip) und dann den Anruf wie zuletzt wiederholen. Theoretisch könnte beim Verhandeln des Gesprächsaufbaus (INVITE / ACK) noch irgendetwas komisches im SDP passieren, repektive irgendwelche IP-Adressen fürs RTP nicht passen, wobei ich noch keinen Grund sehe, warum das passieren sollte ...

@sparkie: Denkbar sind immer noch alle möglichen Sachen, aber nach den Schilderungen des OP liegt der Hund immer noch irgendwo in der IP-Welt begraben ... Ich tippe immer noch auf irgendein Problem in der RTP-Adressierung zwischen Endgerät und Asterisk.
 
Wieso nat=yes? Alle Endgeräte liegen doch im gleichen LAN und das ISDN hängt doch mit der hfc Karte auch direkt am asterisk.

Hier mal das sip-debug log:

Code: 
<--- SIP read from UDP:192.168.0.63:5060 --->
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bKfc14948e83ca4614bb8ae9976eedc0f2;rport
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>
Call-ID: 152872904@192_168_0_63
CSeq: 2 INVITE
Contact: <sip:[email protected]:5060>
Max-Forwards: 70
User-Agent: S685 IP/022270000000
Supported: replaces
Allow-Events: message-summary, refer
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 346

v=0
o=s685ip 5012 5 IN IP4 192.168.0.63
s=Mapping
c=IN IP4 192.168.0.63
t=0 0
m=audio 5012 RTP/AVP 9 96 97 2 18 8 101
a=rtpmap:9 G722/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AAL2-G726-32/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
<------------->
--- (14 headers 15 lines) ---
Sending to 192.168.0.63:5060 (no NAT)
Using INVITE request as basis request - 152872904@192_168_0_63
Found peer 's685ip' for 's685ip' from 192.168.0.63:5060

<--- Reliably Transmitting (no NAT) to 192.168.0.63:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bKfc14948e83ca4614bb8ae9976eedc0f2;received=192.168.0.63;rport=5060
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as0a63feca
Call-ID: 152872904@192_168_0_63
CSeq: 2 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="2dc05f29"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '152872904@192_168_0_63' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:192.168.0.63:5060 --->
ACK sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bKfc14948e83ca4614bb8ae9976eedc0f2;rport
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as0a63feca
Call-ID: 152872904@192_168_0_63
CSeq: 2 ACK
Contact: <sip:[email protected]:5060>
Max-Forwards: 70
User-Agent: S685 IP/022270000000
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---

<--- SIP read from UDP:192.168.0.63:5060 --->
INVITE sip:[email protected];user=phone SIP/2.0
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK1c6d0c7a64c478da476d6d83eb7ab9cd;rport
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>
Call-ID: 152872904@192_168_0_63
CSeq: 3 INVITE
Contact: <sip:[email protected]:5060>
Authorization: Digest username="s685ip", realm="asterisk", algorithm=MD5, uri="sip:[email protected];user=phone", nonce="2d***29", response="b0fd65**********2dc8d2b"
Max-Forwards: 70
User-Agent: S685 IP/022270000000
Supported: replaces
Allow-Events: message-summary, refer
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Type: application/sdp
Content-Length: 346

v=0
o=s685ip 5012 5 IN IP4 192.168.0.63
s=Mapping
c=IN IP4 192.168.0.63
t=0 0
m=audio 5012 RTP/AVP 9 96 97 2 18 8 101
a=rtpmap:9 G722/8000
a=rtpmap:96 G726-32/8000
a=rtpmap:97 AAL2-G726-32/8000
a=rtpmap:2 G726-32/8000
a=rtpmap:18 G729/8000
a=fmtp:18 annexb=no
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
<------------->
--- (15 headers 15 lines) ---
Sending to 192.168.0.63:5060 (no NAT)
Using INVITE request as basis request - 152872904@192_168_0_63
Found peer 's685ip' for 's685ip' from 192.168.0.63:5060
  == Using SIP RTP CoS mark 5
Found RTP audio format 9
Found RTP audio format 96
Found RTP audio format 97
Found RTP audio format 2
Found RTP audio format 18
Found RTP audio format 8
Found RTP audio format 101
Found audio description format G722 for ID 9
Found audio description format G726-32 for ID 96
Found audio description format AAL2-G726-32 for ID 97
Found audio description format G726-32 for ID 2
Found audio description format G729 for ID 18
Found audio description format PCMA for ID 8
Found audio description format telephone-event for ID 101
Capabilities: us - 0xe (gsm|ulaw|alaw), peer - audio=0x1918 (alaw|g726|g729|g726aal2|g722)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x8 (alaw)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.0.63:5012
Looking for 016090XXXXXX in sip (domain 192.168.0.10)
list_route: hop: <sip:[email protected]:5060>

<--- Transmitting (no NAT) to 192.168.0.63:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK1c6d0c7a64c478da476d6d83eb7ab9cd;received=192.168.0.63;rport=5060
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>
Call-ID: 152872904@192_168_0_63
CSeq: 3 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


<------------>
    -- Executing [016090XXXXXX@sip:1] System("SIP/s685ip-00000015", "/usr/bin/php /home/eib/homeserver/prowl/send_prowl.php 'Outgoing Call' 'Call from: s685ip (11) \nCall to    : 016090XXXXXX' ASTERISK 2") in new stack
    -- Executing [016090XXXXXX@sip:2] System("SIP/s685ip-00000015", "/usr/bin/php /home/eib/homeserver/server/send_cmd.php OUTGOING_CALL _11 016090XXXXXX") in new stack
    -- Executing [016090XXXXXX@sip:3] Goto("SIP/s685ip-00000015", "outgoing,,1") in new stack
    -- Goto (outgoing,016090XXXXXX,1)
    -- Executing [016090XXXXXX@outgoing:1] ExecIf("SIP/s685ip-00000015", "0?Set(CALLERID(num-pres)=prohib_not_screened)") in new stack
    -- Executing [016090XXXXXX@outgoing:2] ExecIf("SIP/s685ip-00000015", "0?Set(CALLERID(num-pres)=prohib_not_screened)") in new stack
    -- Executing [016090XXXXXX@outgoing:3] NoOp("SIP/s685ip-00000015", "") in new stack
    -- Executing [016090XXXXXX@outgoing:4] Dial("SIP/s685ip-00000015", "dahdi/g1/016090XXXXXX,60,r") in new stack
    -- Requested transfer capability: 0x00 - SPEECH
    -- Called dahdi/g1/016090XXXXXX

<--- Transmitting (no NAT) to 192.168.0.63:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK1c6d0c7a64c478da476d6d83eb7ab9cd;received=192.168.0.63;rport=5060
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as703fd62a
Call-ID: 152872904@192_168_0_63
CSeq: 3 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


<------------>
    -- DAHDI/i1/016090XXXXXX-e is proceeding passing it to SIP/s685ip-00000015
    -- DAHDI/i1/016090XXXXXX-e is ringing

<--- Transmitting (no NAT) to 192.168.0.63:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK1c6d0c7a64c478da476d6d83eb7ab9cd;received=192.168.0.63;rport=5060
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as703fd62a
Call-ID: 152872904@192_168_0_63
CSeq: 3 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


<------------>
    -- DAHDI/i1/016090XXXXXX-e is making progress passing it to SIP/s685ip-00000015
    -- DAHDI/i1/016090XXXXXX-e answered SIP/s685ip-00000015
Audio is at 10040
Adding codec 0x8 (alaw) to SDP
Adding non-codec 0x1 (telephone-event) to SDP

<--- Reliably Transmitting (no NAT) to 192.168.0.63:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK1c6d0c7a64c478da476d6d83eb7ab9cd;received=192.168.0.63;rport=5060
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as703fd62a
Call-ID: 152872904@192_168_0_63
CSeq: 3 INVITE
Server: Asterisk PBX 1.8.20.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Type: application/sdp
Content-Length: 235

v=0
o=root 382415707 382415707 IN IP4 192.168.0.10
s=Asterisk PBX 1.8.20.0
c=IN IP4 192.168.0.10
t=0 0
m=audio 10040 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

<------------>

<--- SIP read from UDP:192.168.0.63:5060 --->
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.63:5060;branch=z9hG4bK7a75179ae0d78f1789f9301ea8ecb2c0;rport
From: "S685IP" <sip:[email protected]>;tag=3195968463
To: <sip:[email protected];user=phone>;tag=as703fd62a
Call-ID: 152872904@192_168_0_63
CSeq: 3 ACK
Contact: <sip:[email protected]:5060>
Authorization: Digest username="s685ip", realm="asterisk", algorithm=MD5, uri="sip:[email protected];user=phone", nonce="2d***29", response="b0fd6*********dc8d2b"
Max-Forwards: 70
User-Agent: S685 IP/022270000000
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---
Really destroying SIP dialog '547814886@192_168_0_63' Method: REGISTER
    -- Span 1: Channel 0/1 got hangup request, cause 16
    -- Executing [h@outgoing:1] NoOp("SIP/s685ip-00000015", "ANSWER") in new stack
    -- Executing [h@outgoing:2] System("SIP/s685ip-00000015", "/usr/bin/php /home/eib/homeserver/server/send_cmd.php CALL_FINISHED ANSWER ANONYM 11") in new stack
    -- Hungup 'DAHDI/i1/016090XXXXXX-e'
  == Spawn extension (outgoing, 016090XXXXXX, 4) exited non-zero on 'SIP/s685ip-00000015'
Scheduling destruction of SIP dialog '152872904@192_168_0_63' in 32000 ms (Method: ACK)
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 192.168.0.63:5060
Reliably Transmitting (no NAT) to 192.168.0.63:5060:
BYE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK19590b33;rport
Max-Forwards: 70
From: <sip:[email protected];user=phone>;tag=as703fd62a
To: "S685IP" <sip:[email protected]>;tag=3195968463
Call-ID: 152872904@192_168_0_63
CSeq: 102 BYE
User-Agent: Asterisk PBX 1.8.20.0
Proxy-Authorization: Digest username="s685ip", realm="asterisk", algorithm=MD5, uri="sip:192.168.0.10", nonce="", response="edf169*****a70909"
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
Content-Length: 0


---

<--- SIP read from UDP:192.168.0.63:5060 --->
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK19590b33;rport=5060
From: <sip:[email protected];user=phone>;tag=as703fd62a
To: "S685IP" <sip:[email protected]>;tag=3195968463
Call-ID: 152872904@192_168_0_63
CSeq: 102 BYE
Contact: <sip:[email protected]:5060>
Supported: replaces
Allow: INVITE, ACK, CANCEL, BYE, OPTIONS, INFO, REFER, SUBSCRIBE, NOTIFY
Content-Length: 0

<------------->
--- (10 headers 0 lines) ---
SIP Response message for INCOMING dialog BYE arrived
Really destroying SIP dialog '152872904@192_168_0_63' Method: ACK
david*CLI>

sparkie schrieb:
hast du mal versucht mit 'dahdi_monitor' die Audio Levels fuer Sende und Empfangsseite in Echtzeit am DAHDI Interface abzugreifen?
Zum Vergrößern anklicken....

Wie mache ich das denn genau? D.h. wie sind die Aufrufparameter von dahdi_monitor?
Muss ich dass vor Call-Aufbau aufrufen oder erst nach Aufbau?
 
das kann man jederzeit aufrufen (ab Zeitpunkt wenn die Treiber geladen sind). Aufruf z.B.

dahdi_monitor 10 -vv

wenn du channel 10 ansehen willst. Die channels bekommt man am CLI mit z.B.

asterisk -nrx "pri show channels"

da bei dir nur 2(?) channels in Frage kommen (welche HFC Karte?) und mindestens eine Sprachrichtung funzt kannst du die richtige channel-Wahl schnell verifizieren
 
Zuletzt bearbeitet:
Okay, hab ich gemacht.
Habe beide Kanäle mit dahdi_monitor überwacht.
Wenn man in das anrufende Gerät spricht, dann ist ein TX Ausschlag und beim Angerufenen ein RX Ausschlag zu sehen.
Wenn man in das angerufene Gerät spricht ist nur ein TX Ausschlag zu sehen aber *KEIN* RX Ausschlag beim Anrufer.

Was sagt uns das?
 
Wieso nat=yes?
Zum Vergrößern anklicken....
Yep, aber nicht aus Sicht von SIPGATE - aber das nur nebenbei.

Das Verrückte ist: Nach meinem bescheidenen Kenntnisstand sieht der sip debug gut aus, auf die Schnelle sehe ich keinen Grund, warum da One-Way-Audio auftauchen sollte. Insoweit solltest Du in der Tat mal mit dem Tipp von sparkie weitermachen ...
 
Was kann ich denn nun aus der Erkenntnis ableiten, dass basierend auf dahdi_monitor auf der Seite des Anrufers kein RX Stream ankommt?
 
die dahdi_monitor Ergebnisse spiegeln die bereits bekannten Fehler Symptome. Was wohl eher auf irgendwelche Probleme am ISDN hinweist. Warum das Problem aber verschwindet wenn der Router weggenommen wird ist mir voellig schleierhaft. Was hat der Router mit ISDN zu tun?

Insgesamt waere es besser mit einer ganz einfachen Konfiguration zu beginnen. Zunaechst alles weglassen was nicht unbedingt benoetigt wird. Mir ist der ganze Aufbau im Moment zu undurchsichtig.

Was fuer Software lauft eigentlich auf dem Asterisk?
 
Das wird schwierig. Das läuft ungefähr alles drauf, mein Haus/Hof-Server: Webserver, DNS, Mailserver, DHCP, Homeautomation, Webmin, Logitech Mediaserver, Twonky, mysql, u.v.m.

eigentlich ist doch ISDN das einzige was sich in beiden Konfigurationen nicht ändert. Ich dachte jetzt eher, dass da etwas mit dem IP Routing schief läuft und der Anrufer RTP Stream ins Nirwana geht. Denn dann kann ja auch nichts auf den ISDN Bus geschickt werden, wenn der asterisk nichts bekommt. Hmmm, aber ne gute Idee dazu hab ich trotzdem nicht. Mist!

Ich nochmal ... also ich denke es ist irgendwas im IP Bereich. Ich habe gerade festgestellt, dass wenn ich einen solchen internen MSN Call bestehen lasse und nicht auflege, dann geht mein Internet total in die Knie und insbesondere die Last auf dem internen Router steigt ganz schnell auf 100%. Jetzt weiss ich nur nicht genau wie ich feststellen kann, was da genau passiert. Aber es ist natürlich genau der Router den ich bei der funktionierenden Konfiguration überbrücke.
 
Zuletzt bearbeitet von einem Moderator:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 687 (Mitglieder: 14, Gäste: 673)

Neueste Beiträge

Statistik des Forums

Themen
244,878
Beiträge
2,220,023
Mitglieder
371,604
Neuestes Mitglied
broekar
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück