Roboterstimme

Hallo zusammen,

ich habe mit meiner MD folgendes Problem:
Im Schnitt tritt bei jedem zweiten externen Gespräch eine verzerrte Stimme auf. Dies aber nicht ab Gesprächsbeginn sondern erst nach 30 Sekunden bis 1 Minute.
Wenn das Gespräch dennoch fortgesetzt wird, verschwindet mit der Zeit dieses Phänomen wieder und die Qualität ist wieder i.O.
Teilweise können aber auch längere Gespräche bis zu 1 Stunde geführt werden, ohne das dieses Problem auftritt.

Was ich bisher unternommen habe:

  • Leitungsprüfung über den Provider (Telefonica). Hier ist kein Problem erkennbar.
  • Prüfung durch unseren Trunk-Provider (Placetel / Finocom). Auch hier scheint alles i.O. zu sein.
  • Prüfung unserer Switche (Cisco). Auch alles i.O. Keine Drops oder dergleichen.
  • Firewall (WatchGuard XTM515) geprüft. Regelwerk ist ok, auch hier keine Drops oder Errors auf den Netzwerkports.
  • TK-Hardware geprüft. CPU, Memory, HDD und Netzwerk zeigen auch hier keine Probleme oder erhöhte Last
  • Netzwerkkabel und Port gewechselt

Hat einer von euch noch eine Idee bzw. Lösungsansatz? Bin mit meinem Latein am Ende.

Danke und viele Grüße,
Thomas

P.S.: Noch als Ergänzung: Interne Gespräche laufen allesamt Problemlos.

Hi,

welchen Codec verwendest du, wird eine Transcodierung vorgenommen, wenn das Problem auftritt?

Gruß
Markus

Hi Markus,

lt. der MD sind folgende Codecs erlaubt bzw. als Standard eingetragen: alaw ulaw gsm
Eine Transcodierung sollte nicht stattfinden - zumindest wüsste ich nicht wo. Aktiviert habe ich derartiges nicht.

Gruss,
Thomas

Re,

was sind beim Amt für Codecs eingestellt? Hier kannst du abweichende Codecs erlauben, siehe allow= …

Gruß
Markus

Hi Markus,

type = peer
host = fpbx.de
outboundproxy = fpbx.de
port = 5060
username = xxx
fromuser = xxx
fromdomain = fpbx.de
secret = xxx
dtmfmode = rfc2833
insecure = port,invite
directmedia = no
registertimeout = 300
disallow = all
allow = alaw
allow = ulaw

Das sind die Vorgaben vom Provider.

Gruss,
Thomas

Re,

das ist ok!
Bandbreite zum Zeitpunkt wenn es Laggt? QoS aktiv?

Gruß
Markus

Hi Markus,

QoS habe ich zeitweise aus- und wieder angeschalten. Leider brachte dies auch keine Lösung.
Bei der Bandbreite habe ich auch kein Problem. Wenn wir viel Traffic haben, sind max. 1,5 bis 2 MBit belegt. Sprich es wären noch mind. 2,5 bis 3 MBit verfügbar.
Das Problem tritt aber auch auf wenn nur ein Gespräch geführt wird - und dieses belegt max. 150 kb.
Was mich immer wieder wundert ist, das die Gespräche anfangs gut, dann schlechter und irgendwann wieder besser werden. Ohne erkennbaren Grund und auch nicht immer…

Gruss,

Thomas

Re,

hast du für die Gespräche Mitschnitt an? Fällt die lastmäßig etwas auf?
Kannst du mal bitte versuchen bei einem peer, wo es auftritt die SIP Option “directmedia=no” zu setzen, so dass wir einen re-invite auch ausschließen können.
Bzw. kannst du mal mit SIP SHOW CHANNEL <kanal> überprüfen, ob das Gespräch mit alaw als Codec geführt wird. So dass vom Amt alaw reinkommt und zum Endgerät auch alaw verwendet wird oder ob hier wie gesagt transcodiert wird?!

Gruß
Markus

Hi Markus,

werde ich testen. Mitschnitte habe ich nicht aktiviert. Das hier habe ich gerade im Protokoll gesehen:

[Jun 20 10:12:13] NOTICE[21651][C-000016d9]: channel.c:4257 __ast_read: Dropping incompatible voice frame on SIP/mdc_trunk_conf-4-00003150 of format alaw since our native format has changed to (ulaw)

Hilft das vielleicht schon weiter?

Gruss,

Thomas

Hi Markus,

ich denke das ist wohl das Problem. Kollegin hatte eben wieder eine miese Qualität. Zeitgleich habe ich die folgenden Meldungen in der CLI gesehen:


Jetzt ist das Bild zu klein um etwas erkennen zu können. Daher als Text:
[Jun 20 10:48:44] NOTICE[27323][C-000016f8]: channel.c:4257 __ast_read: Dropping incompatible voice frame on SIP/mdc_trunk_conf-4-0000318d of format alaw since our native format has changed to (ulaw)
[Jun 20 10:48:45] NOTICE[27323][C-000016f8]: channel.c:4257 __ast_read: Dropping incompatible voice frame on SIP/mdc_trunk_conf-4-0000318d of format ulaw since our native format has changed to (alaw)

Wieso wechselt der immer zwischen alaw und ulaw? Wenn ich auf der MD eines der beiden Codecs verbiete, sollte es doch funktionieren, oder?

Gruss,
Thomas

Hi Markus,

hier mal ein Auszug:

  • SIP Call
    Curr. trans. direction: Outgoing
    Call-ID: 78da483a14f1842e6e52394@fpbx.de
    Owner channel ID: SIP/mdc_trunk_conf-4-00003259
    Our Codec Capability: (ulaw|alaw)
    Non-Codec Capability (DTMF): 1
    Their Codec Capability: (ulaw|alaw)
    Joint Codec Capability: (ulaw|alaw)
    Format: (alaw)
    T.38 support No
    Video support No
    MaxCallBR: 384 kbps
    Theoretical Address: 62.134.52.212:5060
    Received Address: 62.134.52.212:5060
    SIP Transfer mode: open
    Force rport: Auto (No)
    Audio IP: xxx.xx.x.x (local)
    Our Tag: as3de22f28
    Their Tag: as3ce625fd
    SIP User agent:
    Username: 015111234567
    Peername: mdc_trunk_conf-4
    Original uri: sip:015111234567@212.82.xxx.xx:7010
    Need Destroy: No
    Last Message: Tx: ACK
    Promiscuous Redir: No
    Route: <sip:62.134.52.212;lr=on;nat=yes>
    DTMF Mode: rfc2833
    SIP Options: (none)
    Session-Timer: Active
    S-Timer Interval: 14400
    S-Timer Refresher: us
    S-Timer Sched Id: 4786030
    S-Timer Peer Sts: Active
    S-Timer Cached Min-SE: 90
    S-Timer Cached SE: 0
    S-Timer Cached Ref: unknown
    S-Timer Cached Mode: Accept

Gruss,

Thomas

Hallo Thomas,

du musst beide Richtungen prüfen, sprich beim Amt sollte dann sowas stehen wie

disallow=all
allow=alaw

Somit sollte beim Amt nur noch der alaw verwendet werden.

Und auf der MobyDick nimmst du den ulaw aus der Codec Liste raus. Jedes Endgerät hat in der Regel seine eigene Codec-Reihenfolge, welche versucht wird einzuhalten. Beim Verbindungsaufbau mit dem Endgerät handelt das mit der MobyDick den Codec aus. Falls der Codec vom Amt und der vom Endgerät nicht übereinstimmt, transcodiert der asterisk entsprechend.

Wieso er meint die Codecs wechseln zu müssen, kann ich dir so nicht sagen.

Gruß
Markus

Hi Markus,

ich habe jetzt in den Codecs nur noch alaw und gsm eingestellt. Im Amt habe ich allow=ulaw rausgenommen.

Jetzt sieht das ganze wie folgt aus:

Our Codec Capability: (alaw)

Kmobydick*CLI>
0K Non-Codec Capability (DTMF): 1
Their Codec Capability: (alaw)
0K Joint Codec Capability: (alaw)
0K Format: (alaw)

Die MD lässt jetzt nur noch alaw zu. Ich bekomme aber nach wie vor die Meldung:
Dropping incompatible voice frame on SIP/mdc_trunk_conf-4-0000376f of format ulaw since our native format has changed to (alaw)

Sobald ich Feedback von den Kollegen habe ob sich die Qualität verbessert hat, melde ich mich nochmal.

Danke und Gruss,
Thomas

Re,

die Telefonie hast du angewendet, so dass die Konfiguration richtig geschrieben wurden? Du kannst auch noch bei dem Endgerät überprüfen, welche Codec-Reihenfolge hier vorgeschlagen wird.

Gruß
Markus

Hi Markus,

ja, habe ich angewendet. Die Telefone sind so konfiguriert, das zuerst alaw und danach erst ulaw verwendet wird.
Die Anzahl der Meldungen hat auch stark nachgelasen wenn auch nicht ganz. Qualität der Gepräche beobachte ich noch.

Gruss,
Thomas

Hi,

kannst du rein zwecks Interesse mal den translation table posten, in der CLI “core show translation recalc” ausführen.
Danke!

Gruß
Markus

Natürlich:

gsm ulaw alaw g726 adpcm slin lpc10 speex speex16 ilbc g726aal2 g722 slin16 testlaw speex32 slin12 slin24 slin32 slin44 slin48 slin96 slin192
gsm - 15000 15000 15000 15000 9000 15000 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
ulaw 15000 - 9150 15000 15000 9000 15000 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
alaw 15000 9150 - 15000 15000 9000 15000 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
g726 15000 15000 15000 - 15000 9000 15000 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
adpcm 15000 15000 15000 15000 - 9000 15000 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
slin 6000 6000 6000 6000 6000 - 6000 6000 14000 6000 6000 8250 8000 6000 14000 8000 8000 8000 8000 8000 8000 8000
lpc10 15000 15000 15000 15000 15000 9000 - 15000 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
speex 15000 15000 15000 15000 15000 9000 15000 - 23000 15000 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
speex16 23500 23500 23500 23500 23500 17500 23500 23500 - 23500 23500 15000 9000 23500 23000 17500 17000 17000 17000 17000 17000 17000
ilbc 15000 15000 15000 15000 15000 9000 15000 15000 23000 - 15000 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
g726aal2 15000 15000 15000 15000 15000 9000 15000 15000 23000 15000 - 17250 17000 15000 23000 17000 17000 17000 17000 17000 17000 17000
g722 15600 15600 15600 15600 15600 9600 15600 15600 15000 15600 15600 - 9000 15600 23000 17500 17000 17000 17000 17000 17000 17000
slin16 14500 14500 14500 14500 14500 8500 14500 14500 6000 14500 14500 6000 - 14500 14000 8500 8000 8000 8000 8000 8000 8000
testlaw 15000 15000 15000 15000 15000 9000 15000 15000 23000 15000 15000 17250 17000 - 23000 17000 17000 17000 17000 17000 17000 17000
speex32 23500 23500 23500 23500 23500 17500 23500 23500 23500 23500 23500 23500 17500 23500 - 17500 17500 9000 17000 17000 17000 17000
slin12 14500 14500 14500 14500 14500 8500 14500 14500 14000 14500 14500 14000 8000 14500 14000 - 8000 8000 8000 8000 8000 8000
slin24 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 14000 8500 - 8000 8000 8000 8000 8000
slin32 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 6000 8500 8500 - 8000 8000 8000 8000
slin44 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 14500 8500 8500 8500 - 8000 8000 8000
slin48 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 14500 8500 8500 8500 8500 - 8000 8000
slin96 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 14500 8500 8500 8500 8500 8500 - 8000
slin192 14500 14500 14500 14500 14500 8500 14500 14500 14500 14500 14500 14500 8500 14500 14500 8500 8500 8500 8500 8500 8500 -

Was sagt Dir das bzw. was sagt diese Tabelle aus?

Gruss,
Thomas

Re,

Translation times between formats (in microseconds) for one second of data
Source Format (Rows) Destination Format (Columns)

Scheint alles im Rahmen zu sein.
Gruß
Markus

Hi Markus,

wenn ich sip show channels aufrufe, erscheint folgendes:

Peer User/ANR Call ID Format Hold Last Message Expiry Peer
172.25.5.70 (None) 3205562648@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.40 (None) REGISTER_7C2F80 (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 2131405200@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 4216313053@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 3900426128@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.43 (None) REGISTER_7C2F80 (nothing) No Rx: REGISTER <guest>
172.25.5.51 (None) REGISTER_7C2F80 (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 3072358165@172_ (nothing) No Rx: REGISTER <guest>
62.134.52.212 (None) 5ec7bde7-447e10 (nothing) No Rx: OPTIONS <guest>
172.25.5.70 (None) 284112649@172_2 (nothing) No Rx: REGISTER <guest>
172.25.5.47 (None) REGISTER_7C2F80 (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 3558840914@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 716086998@172_2 (nothing) No Rx: REGISTER <guest>
62.134.52.212 (None) 5ec7bde7-5b7e10 (nothing) No Rx: OPTIONS <guest>
172.25.5.70 (None) 1717464222@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 3697124579@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 2845435779@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 3004835162@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 1898543820@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.70 (None) 1505810550@172_ (nothing) No Rx: REGISTER <guest>
172.25.5.50 (None) REGISTER_7C2F80 (nothing) No Rx: REGISTER <guest>

Ist das ok? Die Einträge werden mal mehr mal weniger. Handelt sich aber hierbei nicht um Gespräche.

Danke und Gruss,
Thomas

Re,
die laufenden Gespräche findest du unter CORE SHOW CHANNELS.
Trotzdem solltest du mal herausfinden/überprüfen wem die IP gehört und wie du die mobydick im Internet hängen hast.
Sollte nämlich nicht so sein!

Gruß
Markus