VoIP-Ruf geht durch, aber sobald jemand abnimmt ist Stille!

[StefanK]

Hallo,

meine FBF hängt hinter einem Linux-Router (fli4l.
Wenn (mal) ein voip-Ruf nach draussen durchgeht
(Rufton), ist es sofort still in der Leitung, sobald der
Angerufene abnimmt.

Woran kann das liegen?

Ich habe auf meinem Router mal den Portbereich 60000 - 70000
an die FBF durchgereicht.
Die SIP-Registrierung funktioniert auch (Kontrolle über telnet).

Hier mal das telnet-Protokoll eines solchen ausgehenden Rufes:

Dial_h: Slot 1 dialed(X)
Dial_h: Slot 1 dialed(X)
Dial_h: Slot 1 dialed(X)
Dial_h: Slot 1 dialed(X)
Dial_h: Slot 1 dialed(X)
Jan 9 10:27:51 voipd[868]: incoming(4:appl=1 plci=0x204 ncci=0x0 incoming): 11 496321xxxxx <- 0
Jan 9 10:27:51 voipd[868]: >>> Request: REGISTER sip:1und1.de
Jan 9 10:27:51 voipd[868]: <<< Status: 401 Unauthorized
Jan 9 10:27:51 voipd[868]: query_local_ipaddress: 0.0.0.0
Jan 9 10:27:51 voipd[868]: >>> Request: REGISTER sip:1und1.de
Jan 9 10:27:51 voipd[868]: <<< Status: 200 OK
Jan 9 10:27:51 voipd[868]: sip:[email protected]:61002: REGISTER complete (next in 1620 seconds)
Jan 9 10:27:51 voipd[868]: >>> Request: INVITE sip:[email protected]
Jan 9 10:27:51 voipd[868]: <<< Status: 407 Proxy Authentication Required
Jan 9 10:27:51 voipd[868]: >>> Request: ACK sip:[email protected]
Jan 9 10:27:51 voipd[868]: >>> Request: INVITE sip:[email protected]
Jan 9 10:27:51 voipd[868]: <<< Status: 100 trying -- your call is important to us
Jan 9 10:27:51 voipd[868]: x-route-info: costvalue is "PSTN" (INVITE)
Jan 9 10:27:52 voipd[868]: <<< Status: 183 Session Progress
Jan 9 10:27:52 voipd[868]: audio: 99 (99 G.726-24/8000)
Jan 9 10:27:52 voipd[868]: audio: 99 (99 G.726-24/8000) => NOT SUPPORTED
Jan 9 10:27:52 voipd[868]: audio: 101 (101 telephone-event/8000)
Jan 9 10:27:52 voipd[868]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Jan 9 10:27:52 voipd[868]: audio: 100 (100 X-NSE/8000)
Jan 9 10:27:52 voipd[868]: audio: 100 (100 X-NSE/8000) => NOT SUPPORTED
Jan 9 10:27:52 voipd[868]: payload >>> 101
Jan 9 10:28:06 voipd[868]: <<< Status: 200 Ok
Jan 9 10:28:06 voipd[868]: audio: 99 (99 G.726-24/8000)
Jan 9 10:28:06 voipd[868]: audio: 99 (99 G.726-24/8000) => NOT SUPPORTED
Jan 9 10:28:06 voipd[868]: audio: 101 (101 telephone-event/8000)
Jan 9 10:28:06 voipd[868]: audio: 101 (101 telephone-event/8000) => (101 (101 telephone-event/8000))
Jan 9 10:28:06 voipd[868]: audio: 100 (100 X-NSE/8000)
Jan 9 10:28:06 voipd[868]: audio: 100 (100 X-NSE/8000) => NOT SUPPORTED
Jan 9 10:28:06 voipd[868]: payload >>> 101
Jan 9 10:28:06 voipd[868]: >>> Request: ACK sip:[email protected]:5060
Jan 9 10:28:06 voipd[868]: call to sip:[email protected] established
Jan 9 10:28:06 voipd[868]: plci_connected(appl=1 plci=0x204 ncci=0x0 incoming)
Jan 9 10:28:06 voipd[868]: connected(appl=1 plci=0x204 ncci=0x10204 incoming) NCPIlen=0
* state change slot 1 ID 0: D_Connected Reason: 0*
* state change slot 1 ID 0: D_DisconnectPending Reason: 0*
Jan 9 10:28:13 voipd[868]: disconnected(appl=1 plci=0x204 ncci=0x10204 incoming): remote: 0x3490 (0x3301) - Normal call clearing
Jan 9 10:28:13 voipd[868]: ocfree: fail 0 normal 0 small 0 large 0
Jan 9 10:28:13 voipd[868]: underrun 0 max_ackqueuelen 0
Jan 9 10:28:13 voipd[868]: small packets merged 0, output 0 and consumed from CNG 0
Jan 9 10:28:13 voipd[868]: capiqueue[0]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[1]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[2]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[3]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[4]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[5]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[6]: 0 ( 0.0%)
Jan 9 10:28:13 voipd[868]: capiqueue[7]: 0 ( 0.0%)
09.01.05 10:28 7s Slot: 1 outgoing xxxxx ChargeU: 0
* state change slot_hold 1 ID 0: Disconnected Reason: 3400*
Disconnectreason: 3400
Jan 9 10:28:13 voipd[868]: >>> Request: BYE sip:[email protected]:5060
AB_LED: B2 Off
Jan 9 10:28:13 voipd[868]: <<< Status: 200 Ok
Jan 9 10:28:13 voipd[868]: 496321yyyyyy: BYE complete
Jan 9 10:28:13 voipd[868]: call to sip:[email protected] terminated (200)

Merkwürdig finde ich auch die zwei unterschiedlichen Ports für Anfrage (61002) und Antwort(5060).

Wer weiss Rat?

Gruss
Stefan

 

[rollo]

Für die FBF solltest Du es mal mit den UDP Ports 5060 und 7077-7081 versuchen, dann kannst Du sogar angerufen werden.

jo

 

[olistudent]

Was nimmt der denn da für einen Codec?
Überall steht "not supported"...
Hast du was an den Codecs der Box geändert? (pcma/pcmu)
Du hast von der FritzBox auf Festnetz angerufen?
(x-route-info: costvalue is "PSTN" (INVITE))

Bei mir sieht das so aus:

user.info voipd[685]: >>> Request: INVITE sip:[email protected]
user.info voipd[685]: <<< Status: 407 Proxy Authentication Required
user.info voipd[685]: >>> Request: ACK sip:[email protected]
user.info voipd[685]: >>> Request: INVITE sip:[email protected]
user.info voipd[685]: <<< Status: 100 trying -- your call is important to us
user.info voipd[685]: x-route-info: costvalue is "PSTN" (INVITE)
user.info voipd[685]: <<< Status: 180 Ringing

MfG Oliver

 

[markO]

@StefanK
Hallo,
ich hatte gestern das gleiche Problem. Allerdings ohne vorgeschalteten fli4l und nach erfolgtem update auf aktuelle FW.
Nach Deaktivieren von "Bandbreitenoptimierte Sprachkompression" ging es dann. Nach versuchsweisem Wiederaktivieren dann sogar immernoch.
Im Protokoll wurde vorher bei mir auch kein "supporteter" Codec ausgehandelt - jetzt wieder PCMA.
Vielleicht hilft es dir ja...

MfG
Marko

 

[StefanK]

@mark0
Das war's. Genau wie Du es beschrieben hast. Jetzt geht's.
An den Codecs hatte ich nie was geändert. Komisch.
Danke.

Die Portforwardings im Bereich 60000- - 70000 sind unnötig.

Jetzt habe ich nur noch das Problem, daß die FBF nicht mitbekommt,
wenn der fli4l sich neu einwählt und sich die öffenliche IP ändert.
Die FBF versucht dann immer wieder ihre Nummern mit der alten IP
beim SIP-Provider zu registrieren. Das funktioniert nur bei der ersten
Einwahl nach einem Reboot des fli4l. Spätestens nach 24h ist dann wieder
Schluss mit voip.
Der Vorschlag mit einer Zeitschaltuhr für den Fli4l ist mir bekannt.
Das kann es aber nicht sein!

Ich bitte um Vorschläge.

Gruß
Stefan

 

[olistudent]

Entweder ein Script schreiben und auf der Box starten.
Oder das mod52 nehmen, und mit crond irgendwas machen...
Wenn sich der fli4l neu einwählt könnte er doch die Daemons auf der FritzBox neu starten? (wie hier: http://www.wehavemorefun.de/fritzbox/Firmware_Modifikationen_/_Recompiling#Steuern_per_wget)
Dazu müßtest du deine Firmware ändern.
Oder so: http://www.wehavemorefun.de/fritzbo..._Tricks#DSL_Zwangstrennung_und_Uhrzeit_setzen

MfG Oliver

 

[capq]

Das war's. Genau wie Du es beschrieben hast. Jetzt geht's.
An den Codecs hatte ich nie was geändert. Komisch.

Bei mir genauso. Ich habe auch nie etwas an den Codecs geändert, dennoch zeigte meine FBF (ohne WLAN) seid FW .06.22/.23 das Verhalten "VoIP-Ruf geht durch, aber sobald jemand abnimmt ist Stille" (bei vielen oder sogar bei allen Ziel-Rufnummern, habe es nicht so intensiv getestet). Der Angerufene hörte übrigens sofort nach dem Abnehmen ein Besetztzeichen.

Nachdem ich dann wie beschrieben "Bandbreitenoptimierte Sprachkompression" einmal deaktiviert habe, übernehmen geklickt und danach sofort wieder aktiviert habe, kann ich nun wieder normal VoIP anrufen.

Ich muss dabei sagen, dass ich bei den FW-Updates nicht wie empfohlen auf Werkeinstellungen zurückgesetzt, sondern aus Bequemlichkeit einfach "drübergebügelt" habe - ansonsten hatte ich mit dieser Vorgehensweise aber auch noch nie Probleme...

 

[staudtm]

Ich habe das gleiche Problem, wie oben beschrieben: nach dem Verbindungsaufbau ist Stille. Habt Ihr nach der Aenderung bei "Bandbreitenoptimierte Sprachkompression" jeweils eine RESET der Box gemacht?
Markus

 

[capq]

@staudtm: Nein, ich habe einfach das Häkchen weggenommen, auf Übernehmen geklickt, dann sofort das Häkchen wieder gesetzt und nochmal auf Übernehmen geklickt. Dann ging telefonieren wieder korrekt.

Welche FBF hast Du? WLAN? Und welche Firmware hast Du?

 

[staudtm]

Ich habe die FBF WLAN mit der Firmware 08.03.23.

Ich werde heute Abend das Ganze mal ausprobieren und mich wieder melden.

 

[staudtm]

Ich habe inzwischen getestet, aber die Lösung liegt woanders:
Nach der Analyse der Systemmeldungen per Telnet habe ich herausgefunden, dass Port 7078 freigegeben werden muss. Ausserdem musste ich in "/var/flash/voip.cfg" den Parameter "use_audiocodecs" auf "yes" gesetzt werden. Nach dem Neustart des VOIP-Daemons lief alles normal.