[Gelöst] Ausgehende Verbindung zu Fairytel schlägt fehl

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

Arrow768

Neuer User
Mitglied seit
28 Jan 2015
Beiträge
5
Punkte für Reaktionen
0
Punkte
0
Hallo IP-Phone Community,

ich bin derzeit etwas am verzweifeln mit der Konfiguration von Fairytel.

Sobald ich hinauswähle erhalte ich folgende Fehlermeldung: (eingehende Anrufe funktionieren Einwandfrei)
Code: 
chan_sip.c:23225 handle_response_invite: Received response: "Forbidden" from '"Werner XXXX" <sip:[email protected]>;tag=as7fe83c48'
Gewählte Nummer: 9106991822XXXX


Ein- und Ausgehende Anrufe über sipgate funktionieren

Ich bin für jede Idee dankbar.

Vielan Dank im Voraus,
Werner


sip.conf:
Code: 
[fairytel]
type=peer
host=sip.fairytel.at
;outboundproxy=sip.fairytel.at
port=5060
username=4372034XXXX
fromuser=4372034XXXX
fromdomain=sip.fairytel.at
secret=SIP-PW
;dtmfmode = rfc2833
insecure=port,invite
canreinvite=no
registertimeout=600
nat=yes
disallow=all
allow=ulaw
context=von-voip

[sipgate]
type = peer
host = sipconnect.sipgate.de
outboundproxy=sipconnect.sipgate.de
port = 5060
username = XXXXX
fromuser = XXXXX
fromdomain = sipconnect.sipgate.de
secret = XXXXX
dtmfmode = rfc2833
insecure = port,invite
canreinvite = no
registertimeout = 600
disallow=all
allow=alaw
allow=ulaw
context=von-voip

extensions.conf: (Ausgehende Verb.)
Code: 
; 9X - Dial to extern

;91 Use Fairytel to dial to external
exten => _91X.,1,SET(RUFNUMMER=${EXTEN:2})
exten => _91X.,2,noop(Using Fairytel to dial: ${RUFNUMMER})
exten => _91X.,3,Dial(SIP/${RUFNUMMER}@fairytel)

;92 User Sipgate to dial to external
exten => _92X.,1,SET(RUFNUMMER=${EXTEN:2})
exten => _92X.,2,noop(Using Sipgate to dial: ${RUFNUMMER})
exten => _92X.,3,Dial(SIP/${RUFNUMMER}@sipgate)

;Rauswählen - depr.
;exten => _0X.,1,Dial(SIP/${EXTEN}@fairytel)

Log von einem ausgehenden Anruf mit sip debug on:
Code: 
<--- SIP read from UDP:192.168.1.4:5060 --->
INVITE sip:[email protected] SIP/2.0
Max-Forwards: 20
Via: SIP/2.0/UDP 192.168.1.4:5060;rport;branch=z9hG4bK1513583366
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 57 INVITE
User-Agent: YATE/5.4.0
Contact: <sip:[email protected]:5060>
Allow: ACK, INVITE, BYE, CANCEL, OPTIONS, INFO
Content-Type: application/sdp
Content-Length: 502

v=0
o=yate 1422473577 1422473577 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 192.168.1.4
t=0 0
m=audio 23730 RTP/AVP 0 8 3 11 98 97 102 103 104 105 106 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:11 L16/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:102 SPEEX/8000
a=rtpmap:103 SPEEX/16000
a=rtpmap:104 SPEEX/32000
a=rtpmap:105 iSAC/16000
a=rtpmap:106 iSAC/32000
a=rtpmap:101 telephone-event/8000
a=ptime:30
<------------->
--- (12 headers 21 lines) ---
Sending to 192.168.1.4:5060 (no NAT)
Sending to 192.168.1.4:5060 (no NAT)
Using INVITE request as basis request - [email protected]
Found peer '3101' for '3101' from 192.168.1.4:5060

<--- Reliably Transmitting (no NAT) to 192.168.1.4:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 192.168.1.4:5060;branch=z9hG4bK1513583366;received=192.168.1.4;rport=5060
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>;tag=as354ddea2
Call-ID: [email protected]
CSeq: 57 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
WWW-Authenticate: Digest algorithm=MD5, realm="asterisk", nonce="31ff1661"
Content-Length: 0


<------------>
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: INVITE)

<--- SIP read from UDP:192.168.1.4:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.4:5060;rport;branch=z9hG4bK1513583366
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>;tag=as354ddea2
Call-ID: [email protected]
CSeq: 57 ACK
Max-Forwards: 20
Contact: <sip:[email protected]:5060>
User-Agent: YATE/5.4.0
Content-Length: 0

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

<--- SIP read from UDP:192.168.1.4:5060 --->
INVITE sip:[email protected] SIP/2.0
Max-Forwards: 20
Via: SIP/2.0/UDP 192.168.1.4:5060;rport;branch=z9hG4bK302029695
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>
Call-ID: [email protected]
User-Agent: YATE/5.4.0
Contact: <sip:[email protected]:5060>
Allow: ACK, INVITE, BYE, CANCEL, OPTIONS, INFO
CSeq: 58 INVITE
Authorization: Digest username="3101", realm="asterisk", nonce="31ff1661", uri="sip:[email protected]", response="f7a13a***011a752", algorithm=MD5
Content-Type: application/sdp
Content-Length: 502

v=0
o=yate 1422473577 1422473577 IN IP4 192.168.1.4
s=SIP Call
c=IN IP4 192.168.1.4
t=0 0
m=audio 23730 RTP/AVP 0 8 3 11 98 97 102 103 104 105 106 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:11 L16/8000
a=rtpmap:98 iLBC/8000
a=fmtp:98 mode=20
a=rtpmap:97 iLBC/8000
a=fmtp:97 mode=30
a=rtpmap:102 SPEEX/8000
a=rtpmap:103 SPEEX/16000
a=rtpmap:104 SPEEX/32000
a=rtpmap:105 iSAC/16000
a=rtpmap:106 iSAC/32000
a=rtpmap:101 telephone-event/8000
a=ptime:30
<------------->
--- (13 headers 21 lines) ---
Sending to 192.168.1.4:5060 (no NAT)
Using INVITE request as basis request - [email protected]
Found peer '3101' for '3101' from 192.168.1.4:5060
  == Using SIP RTP CoS mark 5
Found RTP audio format 0
Found RTP audio format 8
Found RTP audio format 3
Found RTP audio format 11
Found RTP audio format 98
Found RTP audio format 97
Found RTP audio format 102
Found RTP audio format 103
Found RTP audio format 104
Found RTP audio format 105
Found RTP audio format 106
Found RTP audio format 101
Found audio description format PCMU for ID 0
Found audio description format PCMA for ID 8
Found audio description format GSM for ID 3
Found audio description format L16 for ID 11
Found audio description format iLBC for ID 98
Found audio description format iLBC for ID 97
Found audio description format SPEEX for ID 102
Found audio description format SPEEX for ID 103
Found audio description format SPEEX for ID 104
Found unknown media description format iSAC for ID 105
Found unknown media description format iSAC for ID 106
Found audio description format telephone-event for ID 101
Capabilities: us - (ulaw|alaw|gsm|h263), peer - audio=(ulaw|gsm|alaw|slin|ilbc|speex|speex16|speex32)/video=(nothing)/text=(nothing), combined - (ulaw|alaw|gsm)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event|), peer - 0x1 (telephone-event|), combined - 0x1 (telephone-event|)
Peer audio RTP is at port 192.168.1.4:23730
Looking for 9106991822XXXX in intern (domain 192.168.1.103)
sip_route_dump: route/path hop: <sip:[email protected]:5060>

<--- Transmitting (no NAT) to 192.168.1.4:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 192.168.1.4:5060;branch=z9hG4bK302029695;received=192.168.1.4;rport=5060
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 58 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


<------------>
    -- Executing [9106991822XXXX@intern:1] Set("SIP/3101-00000002", "RUFNUMMER=06991822XXXX") in new stack
    -- Executing [9106991822XXXX@intern:2] NoOp("SIP/3101-00000002", "Using Fairytel to dial: 06991822XXXX") in new stack
    -- Executing [9106991822XXXX@intern:3] Dial("SIP/3101-00000002", "SIP/06991822XXXX@fairytel") in new stack
  == Using SIP RTP CoS mark 5
Audio is at 10732
Adding codec ulaw to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 213.185.165.114:5060:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.103:5060;branch=z9hG4bK68dae5bf;rport
Max-Forwards: 70
From: "Werner XXXX" <sip:[email protected]>;tag=as41979518
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 13.1.0
Date: Wed, 28 Jan 2015 19:37:10 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 241

v=0
o=root 1399985572 1399985572 IN IP4 192.168.1.103
s=Asterisk PBX 13.1.0
c=IN IP4 192.168.1.103
t=0 0
m=audio 10732 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=maxptime:150
a=sendrecv

---
    -- Called SIP/06991822XXXX@fairytel

<--- SIP read from UDP:213.185.165.114:5060 --->
SIP/2.0 403 Forbidden
Via: SIP/2.0/UDP 192.168.1.103:5060;branch=z9hG4bK68dae5bf;rport=5060;received=83.215.XXX.XXX
From: "Werner XXXX" <sip:[email protected]>;tag=as41979518
To: <sip:[email protected]:5060>;tag=c6f834bd5392a69e0ed298424be1ffc7.4a2f
Call-ID: [email protected]
CSeq: 102 INVITE
Server: kamailio (4.1.4 (x86_64/linux))
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
Transmitting (NAT) to 213.185.165.114:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.1.103:5060;branch=z9hG4bK68dae5bf;rport
Max-Forwards: 70
From: "Werner XXXX" <sip:[email protected]>;tag=as41979518
To: <sip:[email protected]:5060>;tag=c6f834bd5392a69e0ed298424be1ffc7.4a2f
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX 13.1.0
Content-Length: 0


---
[Jan 28 20:37:10] WARNING[14152][C-00000001]: chan_sip.c:23225 handle_response_invite: Received response: "Forbidden" from '"Werner XXXX" <sip:[email protected]>;tag=as41979518'
Scheduling destruction of SIP dialog '[email protected]' in 32000 ms (Method: INVITE)
  == Everyone is busy/congested at this time (1:0/0/1)
    -- Auto fallthrough, channel 'SIP/3101-00000002' status is 'CHANUNAVAIL'

<--- Reliably Transmitting (no NAT) to 192.168.1.4:5060 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 192.168.1.4:5060;branch=z9hG4bK302029695;received=192.168.1.4;rport=5060
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>;tag=as481023b7
Call-ID: [email protected]
CSeq: 58 INVITE
Server: Asterisk PBX 13.1.0
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH, MESSAGE
Supported: replaces, timer
X-Asterisk-HangupCause: Call Rejected
X-Asterisk-HangupCauseCode: 21
Content-Length: 0


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

<--- SIP read from UDP:192.168.1.4:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 192.168.1.4:5060;rport;branch=z9hG4bK302029695
From: <sip:[email protected]>;tag=714922787
To: <sip:[email protected]>;tag=as481023b7
Call-ID: [email protected]
CSeq: 58 ACK
Max-Forwards: 20
Contact: <sip:[email protected]:5060>
Authorization: Digest username="3101", realm="asterisk", nonce="31ff1661", uri="sip:[email protected]", response="f7a13a***11a752", algorithm=MD5
User-Agent: YATE/5.4.0
Content-Length: 0

<------------->
--- (11 headers 0 lines) ---
Really destroying SIP dialog '[email protected]' Method: ACK

<--- SIP read from UDP:217.10.68.150:5060 --->

<------------->
sip set debug off
SIP Debugging Disabled
 
Zuletzt bearbeitet:
Ich kann auf Deiner Seite keinen Fehler entdecken. Würde schon fast in die Richtung tendieren, dass der Account providerseitig nicht für ausgehende Gespräche freigeschaltet ist oder etwas in der Art. Interessant ist, dass gleich ein "Forbidden" zurück kommt, anstatt zb. eines "Proxy Authentication Required". Hast Du auch eine Register Zeile für den Account?

Funktioniert der Account, wenn Du ihn direkt am Softphone betreibst?
 
Es könnte sein, dass sich der Provider am
From: "Werner XXXX" <sip:[email protected]>
stört. Vielleicht hilft Set(CALLERID(name)= bzw. Set(CALLERID(name)=4372034XXXX

Da eingehende Anrufe funktionieren, ist die Registrierung wohl in Ordnung.

Haben die einen brauchbaren Support, die sich das mal ansehen können, bzw. sagen können welche Felder wie gesetzt sein müssen?

Seit 1.6 gibt es das Feld username übrigens nicht mehr, das heißt jetzt defaultuser. Ist im Normalfall aber sowieso überflüssig. Außerdem ist directmedia das neue canreinvite.
 
Das wär aber der erste Provider der mir unterkommt, der auf den Displaynamen schaut. Meiner Auffassung nach, sollte da drin von "Susi" bis "Adventkalender" alles drin stehen dürfen.
 
Hab schon länger keine Asterisk-Experimente gemacht, aber eines ist mir in deinem log aufgefallen. Dein "from" enthält lokale Adressen. Verwende z.B. externhost um deine WAN-Adresse im from header zu übertragen. Alles andere ist Käse. Es würde mich nicht wundern, wenn der Dialog nicht zustande kommt, weil das invite nicht "zugestellt" werden kann. Versuch macht kluch! :)

VG R.
 
rmh schrieb:
Hab schon länger keine Asterisk-Experimente gemacht, aber eines ist mir in deinem log aufgefallen. Dein "from" enthält lokale Adressen.
Zum Vergrößern anklicken....

Das dachte ich bei der ersten Sichtung auch, aber das betrifft IMHO nur die Pakete zwischen Telefon und Asterisk. Die Pakete zum Provider hin sind ok, mit korrektem Username und Domain im FROM.
 
Zuletzt bearbeitet:
Contact: <sip:[email protected]:5060>
Zum Vergrößern anklicken....
aber der Provider korrigiert das (rport, received). Es kommt ja schließlich auch das Forbidden zurück, also sollte das nicht das Problem sein. Außerdem funktionieren ankommende Anrufe.

Michael, es wäre ungewöhnlich, aber das einzige was mir aufgefallen ist. Einen Versuch wäre es wert. Persönlich bekannt ist mir zumindest ein Provider, der mich keine Callerid übertragen lies, weil er Svenja als Displaynamen nicht wollte, Adventkalender hab ich nicht probiert, das war im Sommer :cool:

Da noch nicht mal ein 401 kommt, kann es außer am fromuser ja eigentlich an nichts anderem fehlen. Bei einem regionalen Anbieter wäre es genau so ungewöhnlich, dass in e.164 gewählt werden muss.
 
Vielen Dank für die vielen Tips.

IEEE schrieb:
Hast Du auch eine Register Zeile für den Account?
Funktioniert der Account, wenn Du ihn direkt am Softphone betreibst?
Zum Vergrößern anklicken....

  • Ja, register ist gesetzt
  • Habe nicht daran gedacht den Account direkt mit dem Softphone zu betrieben (Manchmal sieht man den Wald vor lauter Bäumen nicht) --> Funktioniert auch nicht

rentier-s schrieb:
Vielleicht hilft Set(CALLERID(name)= bzw. Set(CALLERID(name)=4372034XXXX
[...]
Haben die einen brauchbaren Support, die sich das mal ansehen können
Zum Vergrößern anklicken....

  • Habe die Callerid geändert --> Hat leider nicht geholfen
  • Support hat zwar schnell auf die erste Anfrage reagiert, jedoch hat mir die antwort nicht weitergeholfen (ist register gesetzt ?; evtl nat=force setzen) --> habe nachgehackt und warte dzt. auf eine antwort
  • Danke für die Infos bzgl. der Config Items --> Habe sie aktualisiert

rmh schrieb:
Dein "from" enthält lokale Adressen. Verwende z.B. externhost um deine WAN-Adresse im from header zu übertragen.
Zum Vergrößern anklicken....

Hat mich auch zuerst gewundert wie ich das das erste mal gesehen habe, aber sipgate.de funktioniert ja (ein und ausgehend; Muss nur schauen ob es möglich ist ne DE nummer zu bekommen wenn man in AT ist und der Test-Zeitraum vorbei ist)

Was ich inzwischen noch versucht habe:
  • externip im gernal Bereich ist auf meine externe ip gesetzt --> erfolglos
  • Zusätzlich versucht ob ein DNAT und/oder ein SNAT auf der Firewall hilft --> erfolglos (zusammen mit externip)
  • Mit dem einem Andorid SIP Client versucht extern anzurufen --> fehlgeschlagen (könnte aber auch am Mobilfunk Provider liegen --> werde es in den nächsten Tagen mit dem Firmen-WLAN versuchen)

Was mir aufgefallen ist:
  • Auf der fairytel Website ist zusätzlich noch ein STUN Server angegeben.
    (STUN-Server stun.fairytel.at STUN-Port 3478)
    Muss dieser in Asterisk konfiguriert werden ? - Wenn ja, wo ?
  • Der Asterisk läuft erst seit ~ 1er Woche und schon habe ich die ersten Hacking-Versuche (aus Amerika von einem bekannten Malware Hoster)

Vielen Dank,
Werner
 
Zuletzt bearbeitet von einem Moderator:
Solange Du den Account nicht mal auf einem simplen Softphone zum Laufen bringst, würde ich die Fehlersuche auf Deiner Seite einstellen. An Firewall/NAT Probleme glaube ich in Deinem Fall nicht, weil Du ja die SIP Nachrichten bekommst. NAT Probleme sehen üblicherweise anders aus, bei groben Problemen kriegst nicht mal eine SIP Nachricht retour, bei weniger groben Problemen bemerkst Du es eher an Audio Problemen (zb. der Angerufene hört Dich, Du aber ihn nicht).

Daher würde ich mich von deren Support nicht mit Netzwerkblabla abspeisen lassen, sie sollen Dir klar sagen, warum da ein "Forbidden" retour kommt.

Ein STUN Server dient eher dazu, dass der Client mit dessen Hilfe feststellen kann, welche öffentliche IP er hat und hinter welcher Art NAT er sitzt, damit er entsprechend darauf reagieren kann. Wenn Du eine fixe IP hast, und diese auch noch als externip eingetragen hast, brauchst Du das nicht. Aber auch ohne habe ich schon ewig keinen STUN Server mehr gebraucht, in der Regel funktioniert alles auch so, dank der mitterweile relativ braven NAT Implementierung der heutigen Router und den ganz guten providerseitigen NAT Erkennungsmechanismen.

Was Angriffe angeht: Diese gehören mittlerweile zum Grundrauschen im Internet. Ich kann Dir dazu mal folgende Tipps geben:

- Prüfe, ob Du Deinen SIP Port überhaupt ins Internet aufmachen musst. Sofern Du nur mit Peers über das Internet quatschst, bei denen Du Dich registrierst (und sich niemand bei Dir über das Internet registriert), ist das oft gar nicht nötig. Wenn Du dafür sorgst, dass die Registrierung (zb. maxexpiry Parameter) oft genug aufgefrischt wird (zb. 60 - 180 Sekunden), bleibt die Connection in der NAT Tabelle Deiner Firewall immer brav offen und Du kannst eingehende Anrufe empfangen, auch ohne den Port komplett aufzumachen

- Nimm trotzdem, egal wie offen Du ins Internet bist, sicherheitshalber immer starke Kennwörter für Deine SIP Clients. Das kann nie schaden. Ich nehm meistens > 15 Zeichen mit Groß/Kleinbuchstaben, Ziffern und Sonderzeichen

- Wenn Du doch darauf angewiesen bist, dass der Port offen ist, benutze eventuell einen alternativen SIP Port (musst Du dann auch auf Deinen Clients nachziehen) und schau Dir fail2ban an.

- Setze Deinen Peers in der sip.conf soweit möglich eine deny/permit Maske. Clients, die sich ohnehin nur aus dem lokalen LAN registrieren, kann man ruhig auf diesen Netzbereich einschränken.

- Schau Dir die üblichen Tips hier an, speziell allowguest, alwaysauthreject

Übrigens - auch wenns schon etwas OT ist - weise ich auch immer recht gern auf nicht technische Lücken hin. Der letzte fette Fraud Fall mit dem ich konfrontiert war, hatte nichts mit Asterisk zu tun. Hier wurden schlicht die Zugangsdaten zum Provider entwendet und vom nahen Osten aus direkt verwendet. Weil üblicherweise läuft es ja so, dass der Accountinhaber die Zugangsdaten vom Provider per Mail bekommt. Dann beauftragt er seinen Dienstleister mit der Implementierung oder führt diese selbst durch, und das Zugangsdatenmail bleibt in seiner Inbox liegen, weil er so wie viele sein Mailprogramm gleichzeitig auch als chaotische Dokumentenarchivierung nutzt. In dem Fall war es dann so, dass sein Mailkonto durch einen Phishing Angriff gehackt wurde und sich der Angreifer die Zugangsdaten einfach von dort geholt hat. Da kannst dann Deinen Asterisk absichern so viel Du willst.
Das war so ein Moment wo ich generell über diese Problematik nachgedacht habe. Wer garantiert mir zum Beispiel, dass meine Zugangsdaten nicht direkt beim Provider abgegriffen werden?
Daher erwarte ich mir von einem VoIP Provider auch, speziell wenn er Postpaid anbietet, dass er entsprechende Mechanismen zur Erkennung hat, und den Account nicht erst dann sperrt, wen eine ruinöse Summe zusammengekommen ist.
 
Zuletzt bearbeitet:
Konnte das Problem vor einiger Zeit lösen (Habe nur vergessen die Lösung zu posten)

Es war ein ganz primitives Problem:

Bei der Fairytel Webconfiguration war eingestellt, dass für die Amtsleitung die 0 Vorgewählt werden muss.
Habe die Einstellung geändert (auf direkt erreichbar und jetzt funktionierts)
Amtsholung.PNG
 
Dann ändere doch bitte auch noch das Titel-Prefix in "gelöst", den 1. Beitrag Bearbeiten -> Erweitert.
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 819 (Mitglieder: 60, Gäste: 759)

Neueste Beiträge

Statistik des Forums

Themen
246,216
Beiträge
2,248,288
Mitglieder
373,786
Neuestes Mitglied
horscht187
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