VoIP trennt nach 30 Minuten Gespräch !
- Ersteller uv61
- Erstellt am
seelenlos schrieb:
Nein!
T-Com TDSL Anschluss (also kein resale)
Flatrate: bis vor einigen Tagen bei Lycos, nun bei Congster.
Davon abgesehen erfolgt der Abruch auch bei VoIP Gesprächen über einen Openvpn-Tunnel (Ethernet-Tunnel zwischen 2 Fritzboxen - udp mit tap devices --> ein einziges "gemeinsames" Subnetz).
Da hier VoIP über einen verschlüsselten Openvpn-Tunnel stattfindet, werden aus der Providersicht keine VoIP Ports verwendet und es sind auch keine VoIP-Datenpakete öffentlich sichtbar
--> Provider sieht nichts ausser verschlüsselte Datenpakete an Port 1194.
Mein Tunnel steht stabil und es gehen keine Pakete verloren und es finden auch keine Verbindungsabrüche statt..
Daher gehe ich davon aus, dass hier kein Internet-Provider seine Finger im Spiel hat.
--> übrig bleibt nur noch die Fritzbox oder der VoIP-Provider (natürlich nicht beim Tunnel).
Hier verwende ich eigene Siprouter (mal Ondo und mal SER). Daher kann ich auch hier den VoIP-Provider ausschließen.
Im Ondo Log sind die abgebrochenen Gespräche immer mit einer Dauer von 44:59 gelistet (die Zeitangaben in der Fritzbox weichen hiervon bei mir immer etwas ab, k.A. ob die Fritzbox schon das Anwählen etc. mit in die Zeitmessung nimmt *g*)
--------------------------
Nachtrag:
in einer ruhigen Minute werde ich nochmals folgendes tun (kann auch jeder im Forum nachvollziehen)
(1. Windows Ondo Server runterladen + auf PC Installieren + 2 Accounts einrichten mit jeweils beliebig ausgedachten Telefonnummern A und B) <-- für die, die es noch nicht haben
2. In der eigenen Fritzbox die beiden angelegten VoIP-Accounts A und B registrieren, wobei Sip-Registrar = IP des PC's mit dem Ondo-Server.
3. Wählregeln einrichten, so dass z.B. ein Anruf auf Nummer A über den Account B rausgeht und umgekehrt
4. Nun kann man z.B. Rufnummer B über den Account A anrufen --> das zweite an der Fritzbox angeschlossene Telefon klingelt --> abnehmen und beide Hörer einfach hinlegen
5. Warten was passiert und die diversen Logmöglichkeiten auswerten.
Hierbei kann die Fritzbox auch vom DSL getrennt werden. Es findet alles innerhalb der Fritzbox und den im LAN angeschlossene PC-Sip-Server statt.
Zuletzt bearbeitet:
wie schon gesagt,
die bitte an euch einen mitschnitt anzufertigen:
http://fritz.box/html/capture.html
hatte bereits schon mit avm kontakt.
die aber zur weiteren analyse einen mitschnitt benötigen.
wir selbst haben nur eine 5050
und können daher derzeit nix dazu beitragen.
danke !
entweder mitschnitt direkt an avm
ich gebe euch dann per pm die ticket nr.
oder mitschnitt zu mir, dann sende ich ihn ein.
die bitte an euch einen mitschnitt anzufertigen:
http://fritz.box/html/capture.html
hatte bereits schon mit avm kontakt.
die aber zur weiteren analyse einen mitschnitt benötigen.
wir selbst haben nur eine 5050
und können daher derzeit nix dazu beitragen.
danke !
entweder mitschnitt direkt an avm
ich gebe euch dann per pm die ticket nr.
oder mitschnitt zu mir, dann sende ich ihn ein.
So, also bei mir ist der Fehler reproduzierbar, und zwar fritzboxintern ohne eine DSL/Internetverbindung. Konfiguration: 1 x Fritzbox 7170 mit 2 angeschlossenen Telefonen und einen PC am LAN-Port mit SIP-Server (192.168.178.201). Im SIP-Server sind 2 Accounts eingerichtet mit den Rufnummern 5555 und 8888. Diese beiden Accounts wurden in der Fritzbox registriert. Weiterhin wurde eine Wählregel definiert, dass ein Anruf auf die Nummer 5555 vom Account 8888 aufgebaut wird.
Nun hat die 8888 die 5555 angerufen und es wurde eine Verbindung aufgebaut. --> Bis auf die Anfrage beim Ondoserver läuft jegliche Kommunikation innerhalb der Fritzbox ab.
Auf die Sekunde genau 44:59 Minuten später an/von (???) der 5555 eine udp Request BYE.
Auffällig ist, dass im LOG unmittelbar vor dem Gesprächsabbruch ein Qos - Report gemacht wird. --> Ursache für den Abbruch ????
Gesprächslog Ondo SIP Server:
Timeout-Konfiguration:
Gesamter LOG:
LOG-Ausschnitt:
Nun hat die 8888 die 5555 angerufen und es wurde eine Verbindung aufgebaut. --> Bis auf die Anfrage beim Ondoserver läuft jegliche Kommunikation innerhalb der Fritzbox ab.
Auf die Sekunde genau 44:59 Minuten später an/von (???) der 5555 eine udp Request BYE.
Auffällig ist, dass im LOG unmittelbar vor dem Gesprächsabbruch ein Qos - Report gemacht wird. --> Ursache für den Abbruch ????
Gesprächslog Ondo SIP Server:
Timeout-Konfiguration:
Gesamter LOG:
Code:
Jun 12 11:17:15 voipd[686]: incoming(5:appl=5 plci=0xf05 ncci=0x0 incoming): 11
5555 <- 3
Jun 12 11:17:15 voipd[686]: telapp_incoming - running (voip=0)
Jun 12 11:17:15 voipd[686]: VoIP led value = 18
Jun 12 11:17:15 voipd[686]: allowed bandwidth 208000 for sip:[email protected]
1
Jun 12 11:17:15 voipd[686]: [email protected]: bandwidth left 208000
Jun 12 11:17:15 voipd[686]: >>>UDP Request: INVITE sip:[email protected]
Jun 12 11:17:15 voipd[686]: <<<UDP Status: 100 Trying
Jun 12 11:17:15 voipd[686]: <<<UDP Request: INVITE sip:[email protected]:5060
Jun 12 11:17:15 voipd[686]: <unknown>: refresh in 900 seconds
Jun 12 11:17:15 voipd[686]: <unknown>: expire in 1800 seconds
Jun 12 11:17:15 voipd[686]: [email protected]: bandwidth left 4294967295
Jun 12 11:17:15 voipd[686]: audio: 8 (<NORTPMAP>)
Jun 12 11:17:15 voipd[686]: audio: 8 (<NORTPMAP>) => (8 (PCMA/8000))
Jun 12 11:17:15 voipd[686]: audio: 0 (<NORTPMAP>)
Jun 12 11:17:15 voipd[686]: audio: 0 (<NORTPMAP>) => (0 (PCMU/8000))
Jun 12 11:17:15 voipd[686]: audio: 2 (2 G726-32/8000)
Jun 12 11:17:15 voipd[686]: audio: 2 (2 G726-32/8000) => (2 (2 G726-32/8000))
Jun 12 11:17:15 voipd[686]: audio: 102 (102 G726-32/8000)
Jun 12 11:17:15 voipd[686]: audio: 102 (102 G726-32/8000) => (102 (102 G726-32/8
000))
Jun 12 11:17:15 voipd[686]: audio: 100 (100 G726-40/8000)
Jun 12 11:17:15 voipd[686]: audio: 100 (100 G726-40/8000) => (100 (100 G726-40/8
000))
Jun 12 11:17:15 voipd[686]: audio: 99 (99 G726-24/8000)
Jun 12 11:17:15 voipd[686]: audio: 99 (99 G726-24/8000) => (99 (99 G726-24/8000)
)
Jun 12 11:17:15 voipd[686]: audio: 97 (97 iLBC/8000)
Jun 12 11:17:15 voipd[686]: audio: 97 (97 iLBC/8000) => (97 (97 iLBC/8000))
Jun 12 11:17:15 voipd[686]: audio: 101 (101 telephone-event/8000)
Jun 12 11:17:15 voipd[686]: audio: 101 (101 telephone-event/8000) => (101 (101 t
elephone-event/8000))
Jun 12 11:17:15 voipd[686]: call from sip:[email protected] to 4 (sip4:8888)
Jun 12 11:17:15 voipd[686]: >>>UDP Status: 100 Trying
Jun 12 11:17:15 voipd[686]: alerting(appl=5 plci=0x1005 ncci=0x0 outgoing)
Jun 12 11:17:15 voipd[686]: >>>UDP Status: 180 Ringing
telefon: SIGCHLD received!
Jun 12 11:17:15 voipd[686]: <<<UDP Status: 180 Ringing
Jun 12 11:17:15 voipd[686]: ringing appl=5 plci=0xf05 ncci=0x0 incoming sip:5555
@192.168.178.201
killall: wget: no process killed
Jun 12 11:17:19 voipd[686]: alerting(appl=5 plci=0x1005 ncci=0x0 outgoing)
Jun 12 11:17:19 voipd[686]: plci_connected(appl=5 plci=0x1005 ncci=0x0 outgoing)
Jun 12 11:17:19 voipd[686]: connected(appl=5 plci=0x1005 ncci=0x11005 outgoing)
NCPIlen=0
Jun 12 11:17:19 voipd[686]: allowed bandwidth 104000 for sip:[email protected]
1
Jun 12 11:17:19 voipd[686]: [email protected]: bandwidth left 104000
Jun 12 11:17:19 voipd[686]: audio: 8 (<NORTPMAP>)
Jun 12 11:17:19 voipd[686]: audio: 8 (<NORTPMAP>) => (8 (PCMA/8000))
Jun 12 11:17:19 voipd[686]: audio: 0 (<NORTPMAP>)
Jun 12 11:17:20 voipd[686]: audio: 0 (<NORTPMAP>) => (0 (PCMU/8000))
Jun 12 11:17:20 voipd[686]: audio: 2 (2 G726-32/8000)
Jun 12 11:17:20 voipd[686]: audio: 2 (2 G726-32/8000) => (2 (2 G726-32/8000))
Jun 12 11:17:20 voipd[686]: audio: 102 (102 G726-32/8000)
Jun 12 11:17:20 voipd[686]: audio: 102 (102 G726-32/8000) => (102 (102 G726-32/8
000))
Jun 12 11:17:20 voipd[686]: audio: 100 (100 G726-40/8000)
Jun 12 11:17:20 voipd[686]: audio: 100 (100 G726-40/8000) => (100 (100 G726-40/8
000))
Jun 12 11:17:20 voipd[686]: audio: 99 (99 G726-24/8000)
Jun 12 11:17:20 voipd[686]: audio: 99 (99 G726-24/8000) => (99 (99 G726-24/8000)
)
Jun 12 11:17:20 voipd[686]: audio: 97 (97 iLBC/8000)
Jun 12 11:17:20 voipd[686]: audio: 97 (97 iLBC/8000) => (97 (97 iLBC/8000))
Jun 12 11:17:20 voipd[686]: audio: 101 (101 telephone-event/8000)
Jun 12 11:17:20 voipd[686]: audio: 101 (101 telephone-event/8000) => (101 (101 t
elephone-event/8000))
Jun 12 11:17:20 voipd[686]: 192.168.178.200 7078 - 7082 audio 8(PCMA)
Jun 12 11:17:20 voipd[686]: capienabledrop 1
Jun 12 11:17:20 voipd[686]: Codec PCMA (8) - audio 98933 hold=none (none) (by re
mote)
Jun 12 11:17:20 voipd[686]: rtp_start_session(image): no session definition
Jun 12 11:17:20 voipd[686]: rtp_start_session(video): no session definition
Jun 12 11:17:20 voipd[686]: bridgelimit: nConnections=1
Jun 12 11:17:20 voipd[686]: number of bridge interfaces 1
Jun 12 11:17:20 voipd[686]: sip:[email protected]: refresh in 900 seconds
Jun 12 11:17:20 voipd[686]: sip:[email protected]: expire in 1800 seconds
Jun 12 11:17:20 voipd[686]: >>>UDP Status: 200 OK
Jun 12 11:17:20 voipd[686]: <<<UDP Status: 200 OK
Jun 12 11:17:20 voipd[686]: allowed bandwidth 109067 for sip:[email protected]
1
Jun 12 11:17:20 voipd[686]: [email protected]: bandwidth left 109067
Jun 12 11:17:20 voipd[686]: audio: 8 (8 PCMA/8000)
Jun 12 11:17:20 voipd[686]: audio: 8 (8 PCMA/8000) => (8 (8 PCMA/8000))
Jun 12 11:17:20 voipd[686]: audio: 0 (0 PCMU/8000)
Jun 12 11:17:20 voipd[686]: audio: 0 (0 PCMU/8000) => (0 (0 PCMU/8000))
Jun 12 11:17:20 voipd[686]: audio: 2 (2 G726-32/8000)
Jun 12 11:17:20 voipd[686]: audio: 2 (2 G726-32/8000) => (2 (2 G726-32/8000))
Jun 12 11:17:20 voipd[686]: audio: 102 (102 G726-32/8000)
Jun 12 11:17:20 voipd[686]: audio: 102 (102 G726-32/8000) => (102 (102 G726-32/8
000))
Jun 12 11:17:20 voipd[686]: audio: 100 (100 G726-40/8000)
Jun 12 11:17:20 voipd[686]: audio: 100 (100 G726-40/8000) => (100 (100 G726-40/8
000))
Jun 12 11:17:20 voipd[686]: audio: 99 (99 G726-24/8000)
Jun 12 11:17:20 voipd[686]: audio: 99 (99 G726-24/8000) => (99 (99 G726-24/8000)
)
Jun 12 11:17:20 voipd[686]: audio: 97 (97 iLBC/8000)
Jun 12 11:17:20 voipd[686]: audio: 97 (97 iLBC/8000) => (97 (97 iLBC/8000))
Jun 12 11:17:20 voipd[686]: audio: 101 (101 telephone-event/8000)
Jun 12 11:17:20 voipd[686]: audio: 101 (101 telephone-event/8000) => (101 (101 t
elephone-event/8000))
Jun 12 11:17:20 voipd[686]: 192.168.178.200 7082 - 7078 audio 8(PCMA)
Jun 12 11:17:20 voipd[686]: capienabledrop 1
Jun 12 11:17:20 voipd[686]: Codec PCMA (8) - audio 98933 hold=none (none) (by lo
cal)
Jun 12 11:17:20 voipd[686]: rtp_start_session(image): no session definition
Jun 12 11:17:20 voipd[686]: rtp_start_session(video): no session definition
Jun 12 11:17:20 voipd[686]: bridgelimit: nConnections=2
Jun 12 11:17:20 voipd[686]: number of bridge interfaces 1
[b][color=red]Jun 12 11:17:20 voipd[686]: call to sip:[email protected] established
...
Und auf die Sekunde genau 45 Minuten später:
...
Jun 12 12:02:19 voipd[686]: QoS-Report(> 5555 via 192.168.178.201): PS=89990;OS=
21597600;SP=0/0;SO=0;PR=89993;OR=21598320;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=PCMA;JI
=0
Jun 12 12:02:19 voipd[686]: Codec - (-) - audio 0
Jun 12 12:02:19 voipd[686]: bridgelimit: nConnections=1
Jun 12 12:02:20 voipd[686]: number of bridge interfaces 1
Jun 12 12:02:20 voipd[686]: >>>UDP Request: BYE sip:[email protected]:5060;un
iq=B9BB775A844026FAA13790FAA1B01[/color][/b]
Jun 12 12:02:20 voipd[686]: sent: 89990 (21597600) voice, 0 (0) CN, 0 silence
Jun 12 12:02:20 voipd[686]: jitter packets 89993 bytes 21598320 drop_toolate 0 d
rop_duplicates 0
Jun 12 12:02:20 voipd[686]: wrong_seq 0 packets lost 0 (max burst 0)
Jun 12 12:02:20 voipd[686]: rtpsession drop_nobuffer 0 drop_nonaudio 0 drop_toos
hort 0 decoder failed 0
Jun 12 12:02:20 voipd[686]: <<<UDP Request: BYE sip:[email protected]
Jun 12 12:02:20 voipd[686]: QoS-Report(< 8888 via 192.168.178.201): PS=89990;OS=
21597600;SP=0/0;SO=0;PR=89993;OR=21598320;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=PCMA;JI
=0
Jun 12 12:02:20 voipd[686]: QoS-Report(> 8888 via 192.168.178.201): PS=90004;OS=
21600960;SP=0/0;SO=0;PR=89990;OR=21597600;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=PCMA;JI
=0
Jun 12 12:02:20 voipd[686]: Codec - (-) - audio 0
Jun 12 12:02:20 voipd[686]: bridgelimit: nConnections=0
Jun 12 12:02:20 voipd[686]: number of bridge interfaces 1
Jun 12 12:02:20 voipd[686]: ocfree: fail 0 normal 0 small 22 large 89988
Jun 12 12:02:20 voipd[686]: underrun 0 max_ackqueuelen 6
Jun 12 12:02:20 voipd[686]: small packets merged 0, output 0 and consume
d from CNG 0
Jun 12 12:02:20 voipd[686]: ocmode: normal 90010 merged 0 delayed 0
Jun 12 12:02:20 voipd[686]: dropped 2 packets with 480 samples and one sample in
1246 packets
Jun 12 12:02:20 voipd[686]: generated noise: 22
Jun 12 12:02:20 voipd[686]: capiqueue[0]: 2 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[1]: 21 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[2]: 88739 ( 98.5%)
Jun 12 12:02:20 voipd[686]: capiqueue[3]: 791 ( 0.8%)
Jun 12 12:02:20 voipd[686]: capiqueue[4]: 434 ( 0.4%)
Jun 12 12:02:20 voipd[686]: capiqueue[5]: 23 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[6]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[7]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 0ms]: 2 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 10ms]: 5 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 20ms]: 5 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 30ms]: 16 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 40ms]: 14 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 50ms]: 165 ( 0.1%)
Jun 12 12:02:20 voipd[686]: txqueue[ 60ms]: 88557 ( 98.3%)
Jun 12 12:02:20 voipd[686]: txqueue[ 70ms]: 6 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 80ms]: 737 ( 0.8%)
Jun 12 12:02:20 voipd[686]: txqueue[ 90ms]: 47 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[100ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[110ms]: 433 ( 0.4%)
Jun 12 12:02:20 voipd[686]: txqueue[120ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[130ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[140ms]: 23 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[150ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[160ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[170ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[180ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[190ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[200ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[210ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[220ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[230ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: call from sip:[email protected] terminated (200)
Jun 12 12:02:20 voipd[686]: sent: 90004 (21600960) voice, 0 (0) CN, 0 silence
Jun 12 12:02:20 voipd[686]: jitter packets 89990 bytes 21597600 drop_toolate 0 d
rop_duplicates 0
Jun 12 12:02:20 voipd[686]: wrong_seq 0 packets lost 0 (max burst 0)
Jun 12 12:02:20 voipd[686]: rtpsession drop_nobuffer 0 drop_nonaudio 0 drop_toos
hort 0 decoder failed 0
Jun 12 12:02:20 voipd[686]: >>>UDP Status: 200 OK
Jun 12 12:02:20 voipd[686]: >>>UDP Request: BYE sip:[email protected]:5060;un
iq=B9BB775A844026FAA13790FAA1B01
Jun 12 12:02:20 voipd[686]: <<<UDP Status: 200 OK
Jun 12 12:02:20 voipd[686]: QoS-Report(< 5555 via 192.168.178.201): PS=90004;OS=
21600960;SP=0/0;SO=0;PR=89990;OR=21597600;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=PCMA;JI
=0
Jun 12 12:02:20 voipd[686]: 8888: BYE complete
Jun 12 12:02:20 voipd[686]: ocfree: fail 0 normal 0 small 53 large 89973
Jun 12 12:02:20 voipd[686]: underrun 0 max_ackqueuelen 4
Jun 12 12:02:20 voipd[686]: small packets merged 0, output 0 and consume
d from CNG 0
Jun 12 12:02:20 voipd[686]: ocmode: normal 90026 merged 0 delayed 0
Jun 12 12:02:20 voipd[686]: dropped 20 packets with 4800 samples and one sample
in 75 packets
Jun 12 12:02:20 voipd[686]: generated noise: 53
Jun 12 12:02:20 voipd[686]: capiqueue[0]: 1 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[1]: 54 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[2]: 89730 ( 99.6%)
Jun 12 12:02:20 voipd[686]: capiqueue[3]: 241 ( 0.2%)
Jun 12 12:02:20 voipd[686]: capiqueue[4]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[5]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[6]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: capiqueue[7]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 0ms]: 1 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 10ms]: 5 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 20ms]: 5 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 30ms]: 49 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 40ms]: 52 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 50ms]: 19 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 60ms]: 89655 ( 99.5%)
Jun 12 12:02:20 voipd[686]: txqueue[ 70ms]: 19 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 80ms]: 66 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[ 90ms]: 155 ( 0.1%)
Jun 12 12:02:20 voipd[686]: txqueue[100ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[110ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[120ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[130ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[140ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[150ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[160ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[170ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[180ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[190ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[200ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[210ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[220ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: txqueue[230ms]: 0 ( 0.0%)
Jun 12 12:02:20 voipd[686]: call to sip:[email protected] terminated (200)
Jun 12 12:02:50 voipd[686]: disconnected(appl=5 plci=0x1005 ncci=0x11005 outgoin
g): local: 0x3490 (0x3301) -
Jun 12 12:02:50 voipd[686]: disconnected(appl=5 plci=0xf05 ncci=0x20f05 incoming
): local: 0x3490 (0x3301) -LOG-Ausschnitt:
Code:
[b][color=red]Jun 12 11:17:20 voipd[686]: call to sip:[email protected] established
...
Und auf die Sekunde genau 45 Minuten später:
...
Jun 12 12:02:19 voipd[686]: QoS-Report(> 5555 via 192.168.178.201): PS=89990;OS=
21597600;SP=0/0;SO=0;PR=89993;OR=21598320;CR=0;SR=0;PL=0;BL=0;EN=PCMA;DE=PCMA;JI
=0
Jun 12 12:02:19 voipd[686]: Codec - (-) - audio 0
Jun 12 12:02:19 voipd[686]: bridgelimit: nConnections=1
Jun 12 12:02:20 voipd[686]: number of bridge interfaces 1
Jun 12 12:02:20 voipd[686]: >>>UDP Request: BYE sip:[email protected]:5060;un
iq=B9BB775A844026FAA13790FAA1B01[/color][/b]Was beweisst, dass es nix unmittelbar mit 1&1 und co. zu tun hat.
Jetzt müsste nur mal jemand nen Trace und das Log an AVM schicken.
Komisch, dass in der Beta-Phase keinem der Fehler aufgefallen ist.
Jetzt müsste nur mal jemand nen Trace und das Log an AVM schicken.
Komisch, dass in der Beta-Phase keinem der Fehler aufgefallen ist.
ich habs mal unter meiner Ticket an AVM gesandt.
Aber wie gesagt, lt. AVM bräuchte ich einen Mitschnitt.
Aber wie gesagt, lt. AVM bräuchte ich einen Mitschnitt.
seelenlos schrieb:
Ich sende keiner Firma einen Paketmitschnitt! Letztendlich sind (?) da diverse persönliche Daten drin.???
In der Vergangenheit habe ich die Erfahrung gemacht, dass einige Firmen doch sehr sehr merkwürdig reagieren, wenn man sie auf Fehler aufmerksam macht, so nach dem Motto: "Sind Sie mal ganz ruhig und machen Sie unser Geschäft nicht kaputt, ansonsten gibts gewaltig was auf die Finger ..."
Ich möchte AVM hier nichts unterstellen, aber mit anderen Unternehmen habe ich schon solche Erfahrungen gemacht :-(
Und diese 0 8 15 Schreiben ala ist uns nicht bekannt oder probieren Sie das und das ... habe ich auch satt.
Am besten verweist jemand, der schon ein Ticket hat, auf den Beitrag ;-)
Soll AVM sich einfach eine Fritzbox aus dem Lager holen, 2 Telefone und ein PC anschließen, Sipserver rauf + 2 Accounst einrichten und in der Fritz registrieren ...
Einen Internetanschluss wird hierzu nicht benötigt *g*
Habe ich gerade von AVM bekommen:
Sehr geehrter Herr .....,
vielen Dank für Ihre Anfrage.
Wir konnten den Fehler für dieses Verhalten mitlereweile lokalisieren.
Werden Telefongespräche über das Internet immer oder gelegentlich nach ca.
45 Minuten unterbrochen, installieren Sie für Ihre FRITZ!Box bitte das nächste Firmwareupdate auf eine Version größer xx.04.07, sobald dieses erscheint.
Über aktuelle Updates und viele andere interessante Themen informieren wir regelmäßig im AVM Newsletter, den Sie auf unserer Internetseite unter http://www.avm.de/Newsletter/Anmeldung/ abbonieren können.
Mit freundlichen Grüßen aus Berlin
.......... (AVM Support)
Sehr geehrter Herr .....,
vielen Dank für Ihre Anfrage.
Wir konnten den Fehler für dieses Verhalten mitlereweile lokalisieren.
Werden Telefongespräche über das Internet immer oder gelegentlich nach ca.
45 Minuten unterbrochen, installieren Sie für Ihre FRITZ!Box bitte das nächste Firmwareupdate auf eine Version größer xx.04.07, sobald dieses erscheint.
Über aktuelle Updates und viele andere interessante Themen informieren wir regelmäßig im AVM Newsletter, den Sie auf unserer Internetseite unter http://www.avm.de/Newsletter/Anmeldung/ abbonieren können.
Mit freundlichen Grüßen aus Berlin
.......... (AVM Support)
Na dass ist doch schön, wenn sie den Fehler gefunden haben ... und das Update dann auch Zeitnah kommt.
Ist das Problem mit den Verbindungsabbrüchen über VoIP bei euch mit den neuen Firmwares für die FBF (.15) behoben?
Ich hatte gestern abend wieder mal einen Abbruch nach 16min. Kann es allerdings scheinbar nicht mehr reproduzieren. Ich hoffe, dass das ein einmaliges Ereignis war
Ich hatte gestern abend wieder mal einen Abbruch nach 16min. Kann es allerdings scheinbar nicht mehr reproduzieren. Ich hoffe, dass das ein einmaliges Ereignis war
- Mitglied seit
- 17 Aug 2004
- Beiträge
- 23,104
- Punkte für Reaktionen
- 1,003
- Punkte
- 113
Verbindungsabbruch
Hallo,
hatte jetzt allerdings auch wieder nach 45 min bei einem eingehenden Anruf einen Verbindungsabbruch.
Fritz!Box Fon Wlan 7050
FW 14.04.15
1&1 6000
viele Grüße
Werner
Hallo,
hatte jetzt allerdings auch wieder nach 45 min bei einem eingehenden Anruf einen Verbindungsabbruch.
Fritz!Box Fon Wlan 7050
FW 14.04.15
1&1 6000
viele Grüße
Werner
Gespräch kam über die Festnetznummer von 1&1 rein, allerdings eine 032 Nummer, wahrscheinlich VOIP von Broadnet (Oder wer hat die sonst schon aktiv?).
Muss es mal weiter beobachten.
Muss es mal weiter beobachten.
kann nicht sein, 032 er Nummern vergibt T-Online. Aber nicht 1&1, dort bekommst Du Nummern mit Deiner Ortsvorwahl entweder über Broadnet oder Telefonica.sambal schrieb:
Des weiteren, 1&1 vergibt nur VoIP und keine Festnetzrufnummern. Diese sind an den T-COM Anschluss gebunden.
@thheyer: Das kann sehr wohl sein, dass ein Anrufer mit 032-Rufnummer (also z.B. ein T-Online-Kunden) die Festnetzrufnummer von sambal anruft (welche bei 1&1 geschaltet ist und über VoiP zu sambal geleitet wird) und sambal dann sieht, dass das Gespräch von der 032-Nummer kommt und dass seine 1&1-Festnetzrufnummer angerufen wurde.
1&1 vergibt sehr wohl Festnetzrufnummern, also Rufnummern aus einem normalen Ortsnetz. Natürlich schaltet 1&1 diese Festnetzrufnummern nicht per analoger Standleitung oder ISDN, sonder über VoiP. Es bleiben aber ganz normale Festnetzrufnummern, es sind keine Sonderrufnummern (0180, 032, ...) oder SIP-Adressen ([email protected]).
1&1 vergibt sehr wohl Festnetzrufnummern, also Rufnummern aus einem normalen Ortsnetz. Natürlich schaltet 1&1 diese Festnetzrufnummern nicht per analoger Standleitung oder ISDN, sonder über VoiP. Es bleiben aber ganz normale Festnetzrufnummern, es sind keine Sonderrufnummern (0180, 032, ...) oder SIP-Adressen ([email protected]).
Hier gibt es wohl Probleme mit den Begrifflichkeiten.pseudonymer schrieb:
Noch einmal! Es gibt von 1&1 keine Festnetzrufnummer, es handelt sich um VoIP Rufnummern, die im Vorwahlbereich des entsprechenden Ortsnetzes liegen. Bei einer Festnetzrufnummer muss man eingehend über das normale Telefonnetz erreichbar sein. Eine 1&1 Nummer ist dies mit Sicherheit nicht. Ist die Rufnummer auf dem SIP Server von 1&1 nicht registriert, sprich nicht angemeldet, ist diese Rufnummer schlicht nicht erreichbar. Ein Festnetzrufnummer kann auch für die Voip freigeschaltet sein, damit ist es aber noch lange keine 1&1 Festnetzrufnummer sondern immer noch eine T-COM Nummer.
Hier wird Festnetz und Ortvorwahl gemischt. Meine O2 Homezone ist auch keine Festnetzrufnummer, nur weil man mich zu Festnetzkosten erreichen kann. Die Gespräche gehen immer auf mein Handy. Da erfolgt in den Vermittlungstellen eine entsprechende Portiereung. Wie das funktioniert? Keine Ahnung. Rufnummern aus einem Ortsnetz sind somit nicht automatisch Festnetzrufnummern
Neueste Beiträge
-
FritzBox mit DoT DNS server - DNS request timeouts / "server failed"
- Letzte: bsdmonster
-
VLAN für 6869i an Mitel 104 konfigurieren
- Letzte: bubblegun
-
WAN Port 2,5 Gbit nicht sichtbar
- Letzte: mawadre_new
-
-
[Problem] FritzBox 7590 2,4GHz WLAN nur noch sehr sehr schwach
- Letzte: KunterBunter
-
FritzBox Telefonbuch Service für Cisco Telefone
- Letzte: knockor
