[Problem] Telekom: keine ausgehenden Anrufe / SIP/2.0 403 Zugriff nicht erlaubt (seit heute)

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

vwittich

Neuer User
Mitglied seit
31 Okt 2004
Beiträge
90
Punkte für Reaktionen
0
Punkte
6
Hallo zusammen,

bei uns ist heute plötzlich keine ausgehende Verbindung über die Telekom mehr möglich. Es kommt die Meldung:

Code: 
WARNING[3716]: chan_sip.c:20245 handle_response_invite: Received response: "Forbidden" from '"0699999999" <sip:[email protected]>;tag=as628bfe42'

Ein Blick in die SIP DEBUG zeigt die Meldung SIP/2.0 403 Zugriff nicht erlaubt (45). Das bedeutet doch das der Telekom-Server den Asterisk aussperrt, oder verstehe ich das falsch?

Hier mal der komplette SIP DEBUG Output:
Code: 
<--- Transmitting (NAT) to 10.0.2.125:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP 10.0.2.125:5060;branch=z9hG4bK767839053;received=10.0.2.125;rport=5060
From: "Telefon Intern" <sip:[email protected]>;tag=90340890
To: <sip:[email protected]>
Call-ID: [email protected]
CSeq: 301 INVITE
Server: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


<------------>
    -- Executing [0693333333@telefon:1] Goto("SIP/125-00000017", "0049693333333,1") in new stack
    -- Goto (telefon,0049693333333,1)
    -- Executing [0049693333333@telefon:1] NoOp("SIP/125-00000017", "Abgehende Verbindung (festnetz) via Telekom") in new stack
    -- Executing [0049693333333@telefon:2] Set("SIP/125-00000017", "CALLERID(name)=0699999999") in new stack
    -- Executing [0049693333333@telefon:3] Set("SIP/125-00000017", "CALLERID(num)=0699999999") in new stack
    -- Executing [0049693333333@telefon:4] Dial("SIP/125-00000017", "SIP/0049693333333@telekom,60,trg") in new stack
  == Using SIP RTP CoS mark 5
Audio is at 17028
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x40 (slin) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 217.0.19.166:5060:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.5:5060;branch=z9hG4bK44585e11;rport
Max-Forwards: 70
From: "0699999999" <sip:[email protected]>;tag=as628bfe42
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 INVITE
User-Agent: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Date: Tue, 10 Feb 2015 09:57:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 315

v=0
o=root 1203295267 1203295267 IN IP4 10.0.2.5
s=Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
c=IN IP4 10.0.2.5
t=0 0
m=audio 17028 RTP/AVP 8 0 3 10 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:10 L16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv

---
    -- Called SIP/0049693333333@telekom

<--- Transmitting (NAT) to 10.0.2.125:5060 --->
SIP/2.0 180 Ringing
Via: SIP/2.0/UDP 10.0.2.125:5060;branch=z9hG4bK767839053;received=10.0.2.125;rport=5060
From: "Telefon Intern" <sip:[email protected]>;tag=90340890
To: <sip:[email protected]>;tag=as0aadacd0
Call-ID: [email protected]
CSeq: 301 INVITE
Server: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Contact: <sip:[email protected]:5060>
Content-Length: 0


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

<--- SIP read from UDP:217.0.19.166:5060 --->
SIP/2.0 401 Unauthorized
Via: SIP/2.0/UDP 10.0.2.5:5060;rport=5060;branch=z9hG4bK44585e11
To: <sip:[email protected]:5060>;tag=26d28772
From: 0699999999 <sip:[email protected]>;tag=as628bfe42
Call-ID: [email protected]
CSeq: 102 INVITE
WWW-Authenticate: Digest algorithm=MD5, nonce="c014f7****5892c6", realm="tel.t-online.de"
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 217.0.19.166:5060
Transmitting (NAT) to 217.0.19.166:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.5:5060;branch=z9hG4bK44585e11;rport
Max-Forwards: 70
From: "0699999999" <sip:[email protected]>;tag=as628bfe42
To: <sip:[email protected]:5060>;tag=26d28772
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 102 ACK
User-Agent: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Content-Length: 0


---
Audio is at 17028
Adding codec 0x8 (alaw) to SDP
Adding codec 0x4 (ulaw) to SDP
Adding codec 0x2 (gsm) to SDP
Adding codec 0x40 (slin) to SDP
Adding non-codec 0x1 (telephone-event) to SDP
Reliably Transmitting (NAT) to 217.0.19.166:5060:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.5:5060;branch=K508e6c2fz9hG4b;rport
Max-Forwards: 70
From: "0699999999" <sip:[email protected]>;tag=as628bfe42
To: <sip:[email protected]:5060>
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 INVITE
User-Agent: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Authorization: Digest username="loginmail", realm="tel.t-online.de", algorithm=MD5, uri="sip:[email protected]:5060", nonce="c014f7c8*****f5892c6", response="e301****2457b"
Date: Tue, 10 Feb 2015 09:57:27 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 315

v=0
o=root 1203295267 1203295268 IN IP4 10.0.2.5
s=Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
c=IN IP4 10.0.2.5
t=0 0
m=audio 17028 RTP/AVP 8 0 3 10 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:3 GSM/8000
a=rtpmap:10 L16/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-
a=ptime:20
a=sendrecv

---

<--- SIP read from UDP:217.0.19.166:5060 --->
SIP/2.0 100 Rufaufbau
Via: SIP/2.0/UDP 10.0.2.5:5060;rport=5060;branch=K508e6c2fz9hG4b
To: <sip:[email protected]:5060>
From: 0699999999 <sip:[email protected]>;tag=as628bfe42
Call-ID: [email protected]
CSeq: 103 INVITE
Content-Length: 0

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

<--- SIP read from UDP:217.0.19.166:5060 --->
SIP/2.0 403 Zugriff nicht erlaubt (45)
Via: SIP/2.0/UDP 10.0.2.5:5060;rport=5060;branch=K508e6c2fz9hG4b
To: <sip:[email protected]:5060>;tag=234252b3
From: 0699999999 <sip:[email protected]>;tag=as628bfe42
Call-ID: [email protected]
Contact: <sip:[email protected]:5060>
CSeq: 103 INVITE
Content-Length: 0

<------------->
--- (8 headers 0 lines) ---
set_destination: Parsing <sip:[email protected]:5060> for address/port to send to
set_destination: set destination to 217.0.19.166:5060
Transmitting (NAT) to 217.0.19.166:5060:
ACK sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/UDP 10.0.2.5:5060;branch=K508e6c2fz9hG4b;rport
Max-Forwards: 70
From: "0699999999" <sip:[email protected]>;tag=as628bfe42
To: <sip:[email protected]:5060>;tag=234252b3
Contact: <sip:[email protected]:5060>
Call-ID: [email protected]
CSeq: 103 ACK
User-Agent: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Content-Length: 0


---
[Feb 10 10:57:27] WARNING[3716]: chan_sip.c:20245 handle_response_invite: Received response: "Forbidden" from '"0699999999" <sip:[email protected]>;tag=as628bfe42'
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: INVITE)
  == Everyone is busy/congested at this time (1:0/1/0)
    -- Executing [0049693333333@telefon:5] NoOp("SIP/125-00000017", "Status: 34") in new stack
    -- Executing [0049693333333@telefon:6] Hangup("SIP/125-00000017", "") in new stack
  == Spawn extension (telefon, 0049693333333, 6) exited non-zero on 'SIP/125-00000017'
Scheduling destruction of SIP dialog '[email protected]' in 6400 ms (Method: INVITE)

<--- Reliably Transmitting (NAT) to 10.0.2.125:5060 --->
SIP/2.0 503 Service Unavailable
Via: SIP/2.0/UDP 10.0.2.125:5060;branch=z9hG4bK767839053;received=10.0.2.125;rport=5060
From: "Telefon Intern" <sip:[email protected]>;tag=90340890
To: <sip:[email protected]>;tag=as0aadacd0
Call-ID: [email protected]
CSeq: 301 INVITE
Server: Asterisk PBX 1.8.10.1~dfsg-1ubuntu1
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Length: 0


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

<--- SIP read from UDP:10.0.2.125:5060 --->
ACK sip:[email protected] SIP/2.0
Via: SIP/2.0/UDP 10.0.2.125:5060;branch=z9hG4bK767839053;rport
From: "Telefon Intern" <sip:[email protected]>;tag=90340890
To: <sip:[email protected]>;tag=as0aadacd0
Call-ID: [email protected]
CSeq: 301 ACK
Content-Length: 0

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

Meine sip.conf orientiert sich übrigens weitgehend an den Empfehlungen aus dem Forum. Bis heute hat das auch zu 95% gut funktioniert.
Code: 
[general]
context=xxx
allowguest=no
allowoverlap=no           
udpbindaddr=0.0.0.0:5060
tcpenable=no 
tcpbindaddr=0.0.0.0
srvlookup=yes
disallow=all
allow=alaw
allow=ulaw
allow=g729
allow=gsm
allow=slinear
language=de
allowsubscribe=yes
notifyringing = yes
notifyhold = yes
defaultexpirey=480
directmedia=no
directrtpsetup=no
localnet=10.0.2.0/255.255.255.0
externalhost=office.ddns.net
externrefresh=10 
alwaysauthreject=yes
allowguest=no

register => 0699999999:xxxxxx:[email protected]/0699999999

[...]

[telekom]
type=peer
context=from_telekom
username=loginmail
secret=xxxxxx
host=tel.t-online.de
fromdomain=tel.t-online.de
qualify=yes  
port=5060
insecure=port,invite
usereqphone=no
nat=yes
call-limit=5
canreinvite=no

[telekom_ip](!)
type=peer
context=from_telekom
username=loginmail
secret=xxxxxx
qualify=no            
port=5060
insecure=port,invite
usereqphone=no
nat=yes
call-limit=5
canreinvite=no

[DTAG-IP_IN16_026](telekom_ip)
host=217.0.16.26
trustrpid=no
[DTAG-IP_IN16_035](telekom_ip)
host=217.0.16.35
trustrpid=no
[DTAG-IP_IN16_039](telekom_ip)
host=217.0.16.39
trustrpid=no
[...]

Hoffe ihr hab einen weiterführenden Tipp für mich?!

Gruß Valentin
 
Zuletzt bearbeitet:
Ich kann auf Deiner Seite keinen Fehler erkennen. Via Google hab ich Leute gefunden, die meinen, dass es zu diesem "403 Zugriff nicht erlaubt (45)" dann kommt, wenn Du eine abgehende Nummer sendest, die nicht erkannt wird. Das wird aber vermutlich bei Dir nicht der Fall sein, da Du in Deinem Beispiel hier ohnehin konsequent ausgehend die Nummer aus Deinem register string sendest. Ich würde den Support bemühen, sofern nicht noch jemand anderem hier etwas auffällt.
 
Habe heute wegen eines Fehlerberichts meiner Frau auch mal verifiziert: In der Tat ging es bei mir auch (In- und Outbound) mit gleichem Fehlerbild nicht. Zum Glück sind das schon lange nicht mehr die Rufnummern, auf die ich mich verlasse :mad:

Zur Problemlösung: Bei mir hat ein sip reload Abhilfe geschaffen.
 
Sehr merkwürdig. Bei mir hat weder sip reload noch der Neustart des Asterisk geholfen. Erst nach der endgültige Neustart des Server nach ein bis zwei Stunden ging es wieder.

Gleichzeitig hatte ich den Telekom Support darauf angesetzt. Das Ticket ist nach wie vor offen, obwohl der "spezial Techniker" meinte, dass wäre kein Problem und sie würden das in 5 Minuten wieder hingekommen... ;-)
 
Hallo in die Runde!

@vwittich: Hast du mittlerweile ein Feedback vom technischen Service erhalten? Ich bin auch gespannt, was da los war.

Viele Grüße
Natalie P. von Telekom hilft
 
@Telekom hilft Team, Status der Störung: "Ihre Störung wird von einem Spezialisten bearbeiten", seit 24 Stunden!

Heute ist jetzt wieder das gleiche Phänomen aufgetreten. Da irgendwie alle Anrufe bei mir über die 217.0.19.166 geroutet wurden, habe ich jetzt mal anstelle des Host tel.telekom.de eine andere bouncer IP eingetragen. Dreimal raten ob es wieder geht... natürlich! Also scheint mich nur der Server mit der besagten IP abzuweisen. Ich habe jetzt zusätzlich mal qualify=no eingestellt, sodass die IP nicht ständig angepingt wird. Evtl. werde ich also einfach nur gesperrt obgleich dagegen spricht, dass auch mehrere vorheriger IP-Wechsel (also Trennen des Routers) nichts geholfen hatten.

Soweit zum Stand der Dinge. Ich warte gerade mal wieder auf eine T-Kundenberater! ;-)

Gruß Valentin
 
@vwittich: Das ist wirklich ein sehr interessanter Fehler. Habe ich so noch gar nicht gehört. Ich hoffe, dass der "Spezialist" dort schnell eine Lösung findet. Für den Fall der Fälle stehe ich aber auch gerne parat und informiere mich.

Viele Grüße
Natalie P. von Telekom hilft
 
Hallo zusammen,

danke für diesen Thread. Dann weiß ich wenigstens, dass ich nicht allein betroffen bin.

Bei mir treten genau die gleichen Probleme auf. Ich setze einen Asterisk 11.6-cert5 ein, der über ein Management-Interface (MobyDick) konfiguriert wird. Ich habe meine drei Telefonnummern registriert und Telefonie klappt ein- und ausgehend. Sobald ich aber per Zwangstrennung eine neue IP zugewiesen bekomme, meldet Asterisk das Folgende:
Code: 
[Feb 15 09:49:30] WARNING[22688][C-0000000c] chan_sip.c: Received response: "Forbidden" from '"Ulf Kosack" <sip:[email protected]>;tag=as20e0e956'

Das Ironische daran ist, dass die Telekom mir eingehehende Anruf bis zum Asterisk durchstellt und ich dann beim Bestätigen des Verbindungsaufbaus auch wieder abgelehnt werden :confused::confused::confused:

Aber gut. Ich kann das Verhalten jederzeit reproduzieren. Ein "sip reload" hat bei mir jetzt jedes Mal geholfen. Also werde ich als Übergangslösung nach der Zwangstrennung noch einen Cronjob auf dem Asterisk einrichten:
Code: 
/usr/sbin/asterisk -rx 'sip reload'

Hat eigentlich schon jemand beobachtet, ob der Fehler auch auftritt, wenn man per IPv6 seine Internet-Verbindung aufgebaut hat? Dann ändert sich die Adresse doch nicht mehr, oder?

Ich hoffe die Telekom findet den Fehler oder besser eine Lösung.

Danke
Ulf
 
Bei einer festen IP (bzw. fehlender Zwangstrennung) besteht das gleiche Problem.
Was bei Dir allerdings hinzukommen könnte: "Kennt" Deine Moby Dick ihre jeweilige externe IP-Adresse, respektive hast Du ihr einen "externhost" angegeben oder aber den STUN-Service in Betrieb?

Denn: Nach der Zwangstrennung sollte der Re-Synch der Verbindung zur Telekom-Telefonie eigentlich nach einem Registrieungsintervall (also im Bereich 3-5 Minuten) wieder funktionieren.

Wenn der sip reload erst einmal hilft, ok, aber: Sauber ist das nicht.
 
Hallo abw1oim,

danke für den Hinweis mit dem externhost. Da ich mit Asterisk selber noch nicht so viele Erfahrungen habe, hatte ich bisher nur die externip gefunden und gesetzt. Diese aber als Hostnamen. Dementsprechend habe ich immer ein Warning bekommen:
Code: 
[Feb 15 12:17:01] WARNING[22688] chan_sip.c: Invalid address for externaddr keyword: dyndns.domain.tld
Nach der Änderung auf externhost ist das Warning schon einmal weg. Die dyndns-Subdomain wird bei jedem Verbindungsaufbau neu gesetzt. Danke.

Die Resynchronisierung innerhalb 3-5 Minuten funktioniert leider trotzdem nicht. Ich habe jetzt auf meinem Router noch einmal die DSL-Verbindung getrennt und 20 Minuten gewartet. In dieser Zeit war keine ausgehenden Telefonate möglich, da ich die hier behandelte Fehlermeldung bekommen habe. Eingehend hatte ich jetzt nicht getestet.

Erst nach einem sip reload funktioniert die Telefonie wieder.

Ich habe es jetzt erst einmal so eingerichtet, dass der Lancom-Router die TK-Anlage bei einem Neuaufbau der VDSL-Verbindung informiert und diese dann ein "sip reload" durchführt.

Danke
Ulf
 
Worauf steht bei Dir externrefresh ?. Das ist nämlich das Intervall in Sekunden, innerhalb dessen Asterisk die IP-Adresse zu externhost neu ermittelt. Idealerweise stellst Du das auf 60s, damit sollte das Trennungsproblem jedenfalls kein relevantes mehr sein (zumindest, wenn die Zwangstrennung in der Nacht liegt).
 
Hallo zusammen,

also die Option externrefresh hat leider auch keine Besserung gebracht. Auf der Konsole habe ich mit
Code: 
getent hosts dyndns.domain.tld
bereits die korrekte IP bekommen, aber auch nach 15 Minuten waren keine Gespräche möglich. erst nach einen sip reload.

@IEEE: Danke für den Hinweis. Ich habe den Cronjob für das Trennen der Verbindung jetzt mal ausgesetzt. Da meine DSLAM-Version erst bei v10.08.37 liegt, weiß ich nicht, ob ich schon in diesen Genuß komme. Nichtsdestotrotz lasse ich den Workaround, dass nach einem VDSL-Verbindungsaufbau ein "sip reload" durch geführt wird, mal aktiv.

Danke für die Hilfen. Vielleicht findet die Telekom ja auch noch eine Lösung.
 
vwittich schrieb:
Das gilt aber nur für die neuen IP Verträge.
Zum Vergrößern anklicken....
Was verstehst Du unter neuen IP Verträgen? Mein Anschluss ist jetzt IP. Ich habe ihn lediglich von einem ISDN umstellen lassen und habe keinen Neuvertrag.

Lange hat die Freude aber noch nicht gewährt :-(. Heute morgen waren nur noch ausgehende Verbindungen möglich. Eingehende Anrufe von T-Mobile oder Vodafone oder Telekom Festnetz sind nicht bei mir angekommen. Es gab kein Freizeichen, nichts. Nach ca. 1 - 2 Minuten wurde der Verbindungsversuch abgebrochen. Folgendes habe ich versucht:
  • sip reload: Kein Erfolg
  • Server-HW neugestartet: Kein Erfolg
  • DSL-Verbindung getrennt: Weder eingehende, noch ausgehende Anruf möglich
  • sip reload: Telefonie wieder möglich

Sowohl die eine Rufnummer, die in meiner Fritz!Box 7270 registriert ist, als auch die drei Rufnummern, die in der Asterisk-TK-Anlage konfiguriert sind, waren nicht erreichbar.
 
Kurze Update: Das Ticket der Telekom ist immer noch offen... der Spezialist arbeitet mit Hochdruck! Mit öfteren neustarten des Asterisk geht es meist für eine Weile... Ich hab jetzt mal ein Fallback-Option eingebaut, sodass im Notfall immer über einen anderen SIP Anbieter telefoniert wird.
Code: 
exten => _0049[2-9].,n,Dial(SIP/${EXTEN}@telekom,60,trg)
exten => _0049[2-9].,n,GotoIf($["${DIALSTATUS}" = "ANSWER"]?end)
exten => _0049[2-9].,n,Noop(alternative Verbindung (Festnetz))
exten => _0049[2-9].,n,Dial(SIP/${EXTEN}@alternativ,60,trg)
exten => _0049[2-9].,n(end),Hangup()


Heute kam dann zwischendurch mal die Meldung:
Code: 
-- Got SIP response 500 "Netzseitiger Fehler. Versuchen Sie es später noch einmal. (0)" back from 217.0.23.100:5060
- SIP/telekom-0000001b is circuit-busy
Wobei es 2 Minuten später auch ohne Neustart wieder funktionierte.

Es bleibt spannend.

Gruß Valentin
 
Der hier
Code: 
-- Got SIP response 500 "Netzseitiger Fehler. Versuchen Sie es später noch einmal. (0)" back from 217.0.23.100:5060
ist bei der Telekom sehr beliebt. Das ist die Ausgabe, die entsteht, wenn die Telekom selbst feststellt, dass ihre Infrastruktur gerade nicht funktioniert. Den Fehler hatte ich leider auch öfter und dann schon gerne mal eine ganzen Tag lang.

Insoweit ist - mindestens für abgehende Gespräche - ein Fallback auf einen anderen Anbieter immer eine gute Idee, leider :mad:
 
@vwittich: Die Hoffnung stirbt zuletzt. Noch ist der Spezialist ja am Werk, daher bin ich sicher, dass wir noch eine Lösung finden werden.

Viele Grüße
Natalie P. von Telekom hilft
 
Ich hänge mich mal mit dran: Seit einem Serverneustart gestern Abend bekomme ich auch die Meldung

Code: 
WARNING[27882]: chan_sip.c:13250 handle_response_register: Forbidden - wrong password on authentication for REGISTER for '064******' to 'tel.t-online.de'

und seitdem geht garnichts mehr.
Diese Meldung taucht beim Start von Asterisk auf (ich habe hier Asterisk 1.4).
Im gleichen Zug kurz danach erscheint auf der Konsole

Code: 
NOTICE[27882]: chan_sip.c:13394 handle_response_peerpoke: Peer 'DTAG-IP' is now Reachable. (11ms / 2000ms)

Habe auch schon die E-Mail-Adresse als Login versucht, gleiches Problem.

Hier meine sip.conf, die bis gestern Abend wunderbar funktionierte (ok, bis auf teilweise keine externe Gespräche, weil die Registrierung mal wieder verloren gegangen ist...nach 1-2 Minuten warten gehts dann wieder):

Code: 
; Generelle Konfiguration
;
[general]
allowguest=no
alwaysauthreject=yes
autocreatepeer=no
pedantic=no
context=default
bindport=5060
bindaddr=192.168.***.***
externhost=*****.ddns.net
externrefresh=10
localnet=192.168.***.0/255.255.255.0
srvlookup=no
nat=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
language=de
defaultexpirey=540 [B]<- War vorher 240, das lässt die T-Com aber seit gestern nichtmehr zu !!![/B]
maxexpirey=3600
allowoverlap=yes
;
; DTAG-IP -> Registrierung der Rufnummern
;
register => 064********:*****:****@tel.t-online.de/064********
register => 064********:*****:****@tel.t-online.de/064********
register => 064********:*****:****@tel.t-online.de/064********
;
;subscribecontext = default
;
;
; Ankommende Registrierung
;
[external-standard](!)
trustrpid=no
canreinvite=no
context=ankommend
type=peer
insecure=port,invite
usereqphone=no
t38pt_udptl=no
disallow=all
allow=ulaw
allow=alaw
allow=gsm
dtmfmode=rfc2833
;
; Abgehende Registrierung
;
[DTAG-IP](external-standard)
allow=alaw
allow=gsm
defaultuser=******@tel.t-online.de
authuser=******@tel.t-online.de
username=******
secret=*****
remotesecret=*****
host=tel.t-online.de
fromdomain=tel.t-online.de
qualify=yes
;qualifyfreq=200
canreinvite=no
call-limit=3
;
; Telekom Loadbalancer
;
[DTAG-IP_IN16_026](external-standard)
allow = alaw
allow = gsm
host = 217.0.16.26
trustrpid=no
;
[DTAG-IP_IN16_035](external-standard)
allow = alaw
allow = gsm
host = 217.0.16.35
trustrpid=no
;
[DTAG-IP_IN16_090](external-standard)
allow = alaw
allow = gsm
host = 217.0.16.90
trustrpid=no
;
[DTAG-IP_IN16_102](external-standard)
allow = alaw
allow = gsm
host = 217.0.16.102
trustrpid=no
;
[DTAG-IP_IN16_106](external-standard)
...
.....
.........

Wenn ich versuche z.B. die Sprachbox anzurufen bekomme ich folgende Meldung auf der Konsole:

Code: 
-- Called 08003302424@DTAG-IP
[Feb 21 11:01:24] WARNING[27882]: chan_sip.c:13062 handle_response_invite: Received response: "Forbidden" from '"064********" <sip:064********@tel.t-online.de>;tag=***'
    -- SIP/DTAG-IP-00000001 is circuit-busy
  == Everyone is busy/congested at this time (1:0/1/0)


Hoffentlich bekommt die Telekom das mal langsam in den Griff und macht nicht Ständig das System kaputt!
 
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 475 (Mitglieder: 19, Gäste: 456)

Neueste Beiträge

Statistik des Forums

Themen
244,826
Beiträge
2,219,010
Mitglieder
371,520
Neuestes Mitglied
Hipath3000
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