FBF_5012 und skypho.net und dt. Festnetz gehen nicht. FBF_ATA funktioniert. Warum?

[voipd]

Hallo zusammen,

ich werde hier noch i**e und benoetige mal Feedback, bzw. eine Loesung:

Ich habe eine 5012 Box am Kabelmodem mit dus.net (spielt bei dem Problem keine Rolle und funktioniert einwandfrei!) und skypho.net Account.

Nun passiert folgendes: Ich kann keine deutschen Festnetzrufnummer mit dem skypho Account anrufen, deutsche Mobilfunkrufnummern gehen. Mit viel Liebe gehen von ca. 20 Anrufen ins deutsche Festnetz 1 Anruf durch. Wenn ich 20 mal mein deutsches D2 Handy anrufe geht hoechstens mal 1 Anrufversuch daneben.

Wenn ihr jetzt sagt: skypho.net hat Probleme ins deutsche Festnetz zu vermitteln, dann muss ich wiedersprechen! :langenase:

Tausche ich die FBF_5012_(.04.01) gegen eine FBF_ATA_(.04.01DE) aus funktioniert es!!! :gruebel:


Beide Boxen haben den gleichen Releasestand.
Skypho ist richtig konfiguriert, denn ich kann mit beiden Boxen den Dienst nutzen (Handyanwahl)
Ich habe zu testen beide Boxen mal vor den Router (oeffentliche IP), mal hinter den Router (interne IP) gehaengt. Gleiche Phaenomen! (Der Proxy/Stun Eintrag hat auch nichts geholfen)

Wo ist der Fehler bzw. das Problem???????????

Anbei die Telnetfiles.

Wer bitte leitet das "Cancel" bei dem ersten Fall denn ein? Ich nicht!

Versuch ins deutsche Festnetz:

Nov 19 17:37:46 voipd[386]: incoming(5:appl=4 plci=0xe05 ncci=0x0 incoming): 10  <- 3
Nov 19 17:37:46 voipd[386]: telapp_incoming - running (voip=0)
Nov 19 17:37:46 voipd[386]: 0: connected    vcc 0/0/RBE/14 stay online 1
Nov 19 17:37:46 voipd[386]: 0: ip 62.143.xxx.xxx/62.143.xxx.xxx mtu 1500 dns 80.69.98.110/80.69.100.12
Nov 19 17:37:46 voipd[386]: disconnected(appl=4 plci=0xe05 ncci=0x0 incoming): remote: 0x0000 (0x0000) -
Nov 19 17:37:50 voipd[386]: incoming(5:appl=4 plci=0xe05 ncci=0x0 incoming): 10 004929436227 <- 3
Nov 19 17:37:50 voipd[386]: telapp_incoming - running (voip=0)
Nov 19 17:37:50 voipd[386]: 0: connected    vcc 0/0/RBE/14 stay online 1
Nov 19 17:37:50 voipd[386]: 0: ip 62.143.xxx.xxx/62.143.xxx.xxx mtu 1500 dns 80.69.98.110/80.69.100.12
Nov 19 17:37:50 voipd[386]: allowed bandwidth 272000 for sip:[email protected]
Nov 19 17:37:50 voipd[386]: [email protected]: bandwidth left 272000
Nov 19 17:37:50 voipd[386]: >>>udp Request: INVITE sip:[email protected]
Nov 19 17:37:50 voipd[386]: <<<udp Status: 407 Proxy Authentication Required
Nov 19 17:37:50 voipd[386]: >>>udp Request: ACK sip:[email protected]
Nov 19 17:37:50 voipd[386]: allowed bandwidth 272000 for sip:[email protected]
Nov 19 17:37:50 voipd[386]: [email protected]: bandwidth left 272000
Nov 19 17:37:50 voipd[386]: >>>udp Request: INVITE sip:[email protected]
Nov 19 17:37:50 voipd[386]: <<<udp Status: 100 trying -- your call is important to us

[Hier ist die lange Pause des vermittelns]
[Dann bricht der Rufaufbau ab. Im ISDN Telfon steht: Bitte Hoerer auflegen.]

Nov 19 17:38:06 voipd[386]: disconnected(appl=4 plci=0xe05 ncci=0x0 incoming): remote: 0x3490 (0x0000) -
Nov 19 17:38:06 voipd[386]: ocfree: fail 0 normal 0 small 0 large 0
Nov 19 17:38:06 voipd[386]:         underrun 0 max_ackqueuelen 0
Nov 19 17:38:06 voipd[386]:         small packets merged 0, output 0 and consumed from CNG 0
Nov 19 17:38:06 voipd[386]: ocmode: normal 0 merged 0 delayed 0
Nov 19 17:38:06 voipd[386]: dropped 0 packets with 0 samples and one sample in 0 packets
Nov 19 17:38:06 voipd[386]: generated noise: 0
Nov 19 17:38:06 voipd[386]:         capiqueue[0]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[1]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[2]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[3]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[4]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[5]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[6]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         capiqueue[7]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[  0ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 10ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 20ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 30ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 40ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 50ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 60ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 70ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 80ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[ 90ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[100ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[110ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[120ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[130ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[140ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[150ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[160ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[170ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[180ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[190ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[200ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[210ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[220ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]:         txqueue[230ms]: 0 (  0.0%)
Nov 19 17:38:06 voipd[386]: >>>udp Request: CANCEL sip:[email protected]
Nov 19 17:38:06 voipd[386]: <<<udp Status: 200 canceling
Nov 19 17:38:06 voipd[386]: 024xxxxxxx: CANCEL complete
Nov 19 17:38:06 voipd[386]: <<<udp Status: 487 Request Cancelled
Nov 19 17:38:06 voipd[386]: >>>udp Request: ACK sip:[email protected]
Nov 19 17:38:06 voipd[386]: call to sip:[email protected] terminated (487)
Nov 19 17:38:06 voipd[386]: EVENT(78): Internettelefonie mit 00492xxxxxxx ³ber voip.eutelia.it war nicht erfolgreich. Ur
sache: Request Cancelled (487)

Versucht D2 Handy in Deutschland anzurufen:

Nov 19 17:38:27 voipd[386]: incoming(5:appl=4 plci=0x1105 ncci=0x0 incoming): 10  <- 3
Nov 19 17:38:27 voipd[386]: telapp_incoming - running (voip=0)
Nov 19 17:38:27 voipd[386]: 0: connected    vcc 0/0/RBE/14 stay online 1
Nov 19 17:38:27 voipd[386]: 0: ip 62.143.xxx.xxx/62.143.xxx.xxx mtu 1500 dns 80.69.98.110/80.69.100.12
Nov 19 17:38:27 voipd[386]: disconnected(appl=4 plci=0x1105 ncci=0x0 incoming): remote: 0x0000 (0x0000) -
Nov 19 17:38:33 voipd[386]: incoming(5:appl=4 plci=0x1105 ncci=0x0 incoming): 10 0049172xxxxxxx <- 3
Nov 19 17:38:33 voipd[386]: telapp_incoming - running (voip=0)
Nov 19 17:38:33 voipd[386]: 0: connected    vcc 0/0/RBE/14 stay online 1
Nov 19 17:38:33 voipd[386]: 0: ip 62.143.xxx.xxx/62.143.xxx.xxx mtu 1500 dns 80.69.98.110/80.69.100.12
Nov 19 17:38:33 voipd[386]: allowed bandwidth 272000 for sip:[email protected]
Nov 19 17:38:33 voipd[386]: [email protected]: bandwidth left 272000
Nov 19 17:38:33 voipd[386]: >>>udp Request: INVITE sip:[email protected]
Nov 19 17:38:33 voipd[386]: <<<udp Status: 407 Proxy Authentication Required
Nov 19 17:38:33 voipd[386]: >>>udp Request: ACK sip:[email protected]
Nov 19 17:38:33 voipd[386]: allowed bandwidth 272000 for sip:[email protected]
Nov 19 17:38:33 voipd[386]: [email protected]: bandwidth left 272000
Nov 19 17:38:33 voipd[386]: >>>udp Request: INVITE sip:[email protected]
Nov 19 17:38:33 voipd[386]: <<<udp Status: 100 trying -- your call is important to us

[Lange Vermittlungspause und dann kommt der Status 183, der im anderen Fall nicht kommt. Ab hier sieht es immer anders aus!]

Nov 19 17:38:49 voipd[386]: <<<udp Status: 183 Session Progress
Nov 19 17:38:49 voipd[386]: allowed bandwidth 272000 for sip:[email protected]
Nov 19 17:38:49 voipd[386]: [email protected]: bandwidth left 272000
Nov 19 17:38:49 voipd[386]: audio: 8 (8 PCMA/8000)
Nov 19 17:38:49 voipd[386]: audio: 8 (8 PCMA/8000) => (8 (8 PCMA/8000))
Nov 19 17:38:49 voipd[386]: audio: 101 (101 telephone-event/8000)
Nov 19 17:38:49 voipd[386]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Nov 19 17:38:49 voipd[386]: 83.211.2.133 18688 - 7078 audio 8(PCMA)
Nov 19 17:38:49 voipd[386]: capienabledrop 1
Nov 19 17:38:49 voipd[386]: Codec PCMA (8) - audio 98933 hold=none (none) (by local)
Nov 19 17:38:49 voipd[386]: rtp_start_session(image): no session definition
Nov 19 17:38:49 voipd[386]: rtp_start_session(video): no session definition
Nov 19 17:38:49 voipd[386]: bridgelimit: nConnections=1
Nov 19 17:38:49 voipd[386]: number of bridge interfaces 1
Nov 19 17:38:49 voipd[386]: plci_connected(appl=4 plci=0x1105 ncci=0x0 incoming)
Nov 19 17:38:49 voipd[386]: connected(appl=4 plci=0x1105 ncci=0x11105 incoming) NCPIlen=0

[Hier hat mein Handy geklingelt. Ich habe dann wieder aufgelegt. Deshalb steht weiter unten "cancelled". Das ist von mit initiert.]

Nov 19 17:38:52 voipd[386]: disconnected(appl=4 plci=0x1105 ncci=0x11105 incoming): remote: 0x3490 (0x3301) -
Nov 19 17:38:52 voipd[386]: ocfree: fail 0 normal 120 small 3 large 0
Nov 19 17:38:52 voipd[386]:         underrun 0 max_ackqueuelen 4
Nov 19 17:38:52 voipd[386]:         small packets merged 0, output 0 and consumed from CNG 0
Nov 19 17:38:52 voipd[386]: ocmode: normal 123 merged 0 delayed 0
Nov 19 17:38:52 voipd[386]: dropped 0 packets with 0 samples and one sample in 0 packets
Nov 19 17:38:52 voipd[386]: generated noise: 3
Nov 19 17:38:52 voipd[386]:         capiqueue[0]: 1 (  0.8%)
Nov 19 17:38:52 voipd[386]:         capiqueue[1]: 4 (  3.2%)
Nov 19 17:38:52 voipd[386]:         capiqueue[2]: 116 ( 94.3%)
Nov 19 17:38:52 voipd[386]:         capiqueue[3]: 2 (  1.6%)
Nov 19 17:38:52 voipd[386]:         capiqueue[4]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         capiqueue[5]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         capiqueue[6]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         capiqueue[7]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[  0ms]: 1 (  0.8%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 10ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 20ms]: 4 (  3.2%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 30ms]: 4 (  3.2%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 40ms]: 112 ( 91.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 50ms]: 1 (  0.8%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 60ms]: 1 (  0.8%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 70ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 80ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[ 90ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[100ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[110ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[120ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[130ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[140ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[150ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[160ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[170ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[180ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[190ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[200ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[210ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[220ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]:         txqueue[230ms]: 0 (  0.0%)
Nov 19 17:38:52 voipd[386]: Codec - (-) - audio 0
Nov 19 17:38:52 voipd[386]: bridgelimit: nConnections=0
Nov 19 17:38:52 voipd[386]: number of bridge interfaces 1
Nov 19 17:38:52 voipd[386]: >>>udp Request: CANCEL sip:[email protected]
Nov 19 17:38:52 voipd[386]: <<<udp Status: 487 Request Cancelled
Nov 19 17:38:52 voipd[386]: >>>udp Request: ACK sip:[email protected]
Nov 19 17:38:52 voipd[386]: call to sip:[email protected] terminated (487)
Nov 19 17:38:52 voipd[386]: EVENT(78): Internettelefonie mit 0049172xxxxxxx ³ber voip.eutelia.it war nicht erfolgreich.
Ursache: Request Cancelled (487)
Nov 19 17:38:52 voipd[386]: sent: 81 (19440) voice, 0 (0) CN, 0 silence
Nov 19 17:38:52 voipd[386]: jitter packets 120 bytes 19200 drop_toolate 0 drop_duplicates 0
Nov 19 17:38:52 voipd[386]:        wrong_seq 0 packets lost 0 (max burst 0)
Nov 19 17:38:52 voipd[386]: rtpsession drop_nobuffer 0 drop_nonaudio 0 drop_tooshort 0 decoder failed 0
Nov 19 17:38:52 voipd[386]: <<<udp Status: 200 canceling
Nov 19 17:38:52 voipd[386]: 024xxxxxxx: CANCEL complete

Wuerde mich freuen, wenn jemand das mal mit skypho und einer 5012 oder zumindest anderen Firtzbox ausprobieren koennte.

Achso: Wenn ich mit der FBF_ATA deutsche Festnetzrufnummern anrufe, sieht das so aus wie bei dem Handyanruf. Es geht eben.

Danke.

voipd.

 

[gandalf94305]

Das kenne ich irgendwoher... Proxy Authentication Required ist ein Phänomen, das letztendlich auf SIP-Ebene (logge mal die Pakete mit Ethereal) zeigt, daß Client und Server sich ab einem bestimmten Punkt gegenseitig ignorieren. Ich hatte diesen Effekt mit meiner FBF 5050 und behob es durch Abschalten der SIP ALGs im Netgear-Router. SIP-Pakete kamen daraufhin perfekt durch und alles ist wieder in Butter...

In Deinem Fall ist anscheinend kein Router zwischengeschaltet, aber eine Analyse auf Paketebene könnte zeigen, daß hier Antworten vom Server ignoriert werden und damit ein CANCEL ausgelöst wird.

--gandalf.

 

[voipd]

Danke fuer die Antwort.

Zur Nachfrage:

• - "Proxy Authentication Required" steht aber in beiden Faellen da. Sowohl dann wenn es geht, als auch wenn es nicht geht.
  
• - Ich habe es mit und ohne Router probiert. Gleiches Problem.
  
• - Leider habe ich im Moment keinen Hub, damit ich mitschneiden koennte.
  
• - Wie mitschneiden? Ethereal? OK, aber mit welchen Parameter und was mitschneiden?
  
• - Warum geht es mit der FBF_ATA. OK, ist eine andere Box aber mit gleichen Releasestand. Sollte Problemtypen entstehen doch meistens bei unterschiedlichen Releasstaenden.

Kannst du mir noch konstruktives zu Mitschneiden geben? Ich habe mir schonmal mit Ethereal die Finger "gebrochen".

Danke.

voipd.

 

[gandalf94305]

Ethereal ist ganz einfach... alles mit Capture erfassen und dann später mit Filter "sip" nur den SIP-Verkehr anzeigen... das kann man dann schön übersichtlich und in zeitlicher Abfolge inspizieren ;-)

Ich gebe aber zu, daß in Deiner Konfiguration ein paar wilde Vermutungen nur meine Gehirnwindungen durcheilen, denn typischerweise treten diese "Proxy Authentication" Probleme auf, wenn (a) der Provider eine falsche Konfiguration bei sich hat, z.B. für Nummern in bestimmten Zonen, oder (b) Pakete falsch interpretiert bzw. durch einen SIP ALG transcribiert werden.

Mich würden trotzdem mal die SIP-Pakete interessieren... dort muß ja irgendetwas unterschiedlich sein...

--gandalf.

 

[radio_junkie]

Hallo,

meiner Meinung nach hast du in deinem Telnet-Mitschnitt genau die entscheidenden Zeilen rausgeschnitten [Hier ist die lange Pause des Vermittelns]. An dieser Stelle folgt nämlich die Aushandlung des zu verwendenden Codecs. Ich vermute, dass kein Codec gefunden wird, den beide akzeptieren. Wenn kein beiden passender Codec gefunden wird, dann verabschieden sich die beiden SIP-Partner ordentlich und das war's. Die Fritz!Box hat dann nicht mal eine Fehlermeldung im Log. Vermutlich bietet skypho bei Gesprächen ins Festnetz und ins Mobilnetz unterschiedliche Codecs an, deshalb können sie sich bei Anrufen aufs Handy auf einen einigen.
Weiterhin vermute ich, dass die andere Box einen anderen Satz Codecs in der Konfiguration voip.cfg stehen hat, und mit der funtkioniert es dann.

Gruß
radio_junkie

 

[voipd]

Hallo,

da ist nichts rausgeschnitten! Es sind nur Kommentare eingefuegt. Deine Ideen sind OK. Das wuerde bedeuten, dass die FBF_5012 auf die skypho Codecs wartet?! Da kommt aber anscheinend nichts. Die FBF_ATA funktioniert einwandfrei an dieser Stelle!

Ich versuche deine Vermutungen mal zu wiederlegen. Beide Boxen sind nicht in der ar7.cfg oder voip.cfg modifiziert.

use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32";

use_audiocodecs = no;
audiocodecs = "PCMA", "PCMU", "G726-32", "G726-40", "G726-24";

Gute Idee mal nachzusehen, kann aber nichts damit zu tun haben denn wenn ich mit der FBF_ATA (die Problemlos ins Festnetz geht) mal das Telnetlog ansehe steht da:

Feb 26 18:40:07 voipd[354]: <<<udp Status: 100 trying -- your call is important to us
Feb 26 18:40:24 voipd[354]: <<<udp Status: 183 Session Progress
Feb 26 18:40:24 voipd[354]: allowed bandwidth 272000 for sip:[email protected]
Feb 26 18:40:24 voipd[354]: [email protected]: bandwidth left 272000
Feb 26 18:40:24 voipd[354]: audio: 8 (8 PCMA/8000)
Feb 26 18:40:24 voipd[354]: audio: 8 (8 PCMA/8000) => (8 (8 PCMA/8000))
Feb 26 18:40:24 voipd[354]: audio: 101 (101 telephone-event/8000)
Feb 26 18:40:24 voipd[354]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Feb 26 18:40:24 voipd[354]: 83.211.2.217 17132 - 7078 audio 8(PCMA)
Feb 26 18:40:24 voipd[354]: capienabledrop 1
Feb 26 18:40:24 voipd[354]: Codec PCMA (8) - audio 106000 hold=none (none) (by local)
Feb 26 18:40:24 voipd[354]: rtp_start_session(image): no session definition
Feb 26 18:40:24 voipd[354]: rtp_start_session(video): no session definition

Also es wird zum deutschen Festnetz PCMA angeboten und das koennen beide Boxen.

Lass das bitte nochmal sacken. Ich bin fuer jede Idee zu haben.

Danke.

voipd.

 

[radio_junkie]

Hallo,

also wenn du da nix rausgeschnitten hast, bedeutet das wirklich, dass die beiden nicht dazu kommen, den Codec auszuhandeln. Vermutlich erwartet da einer von beiden etwas, was der andere nicht liefert. Hier helfen jetzt die Telnet-Logs nicht mehr weiter, da musst du wirklich die SIP-Session mitschneiden (http://fritz.box/html/capture.html). Möglicherweise benutzt einer der beiden eine Extension, die der andere nicht unterstützt (ich habe da 100rel im Verdacht).

Gruß
radio_junkie