Suche Asterisk-Sound...

Hauptsache für gute Ansagen in Asterisk sind jedenfalls die Dateien die du mit den Applikationen Playback() oder ähnliche als Quelle nutzt.
Das sind ja meist die installierten für "Telefonqualität" ausreichende *.gsm Dateien.
Wenn da aber auch eine *.g722 gleichen Namens rumliegt, dann wird bei diesem ausgehandelten Codec auch die *.g722 abgespielt, und nicht die *.gsm.

Apropos, *.gsm muss deshalb auch transkodiert werden nach G.722, was natürlich irgendwie keinen Sinn ergibt.
Der qualitativ beste trankodierbare Codec ist meines Erachtens *.pcm, der bleibt auch transkodiert nach G.722 gut.
...die lassen sich mit Asterisk' 'file convert' einer *.g722 zu einer *.pcm erstellen.
 
Ja, das vorgehen hatten wir ja hier schonmal besprochen...
 
Deswegen liest sich Post #21 auch so "kryptisch" ;)
 
Find ich jetzt nicht, aber OK... ;)

Anderes problem @koyaanisqatsi: ich hab jetzt mal meine "blacklisted" sound Datei entsprechend in g722 vorliegen, werden von Asterisk auch korrekt erkannt & abgespielt (laut CLI) allerdings kommt aus dem Hörer des anrufenden Telefons nur ein undeutliches Gestammel, abgehackt und mit Tonfragmenten..

Ruf ich intern auf die Testnummer für meine Soundfiles an, läuft alles wunderbar... Was kann das sein?
Ausgabe vom CLI:

Code:
    -- Executing [08154711@von-voip-provider:1] NoOp("SIP/08154711-0000000c", "47110815 ruft an (08154711)") in new stack
    -- Executing [08154711@von-voip-provider:2] ExecIf("SIP/08154711-0000000c", "1?GoTo(blacklisted,999,1):GoTo(3)") in new stack
    -- Goto (blacklisted,999,1)
    -- Executing [999@blacklisted:1] NoOp("SIP/08154711-0000000c", "47110815 who is Blacklisted is Calling...") in new stack
    -- Executing [999@blacklisted:2] Answer("SIP/08154711-0000000c", "") in new stack
       > 0x1d4ae10 -- Strict RTP switching to RTP target address 192.168.1.1:7080 as source
    -- Executing [999@blacklisted:3] Wait("SIP/08154711-0000000c", "1") in new stack
    -- Executing [999@blacklisted:4] Playback("SIP/08154711-0000000c", "blacklist") in new stack
    -- <SIP/08154711-0000000c> Playing 'blacklist.g722' (language 'de')
    -- Executing [999@blacklisted:5] Playback("SIP/08154711-0000000c", "tt-somethingwrong") in new stack
    -- <SIP/08154711-0000000c> Playing 'tt-somethingwrong.gsm' (language 'de')
       > 0x1d4ae10 -- Strict RTP learning complete - Locking on source address 192.168.1.1:7080
    -- Executing [999@blacklisted:6] Wait("SIP/08154711-0000000c", "1") in new stack
    -- Executing [999@blacklisted:7] Hangup("SIP/08154711-0000000c", "") in new stack
    == Spawn extension (blacklisted, 999, 7) exited non-zero on 'SIP/08154711-0000000c'

sieht für mich absolut OK aus... Kann mir das daher nicht erklären...

Hier mal die Zeilen aus dem Dialplan..

Code:
[from-extern]  ; externe Anrufe verteilen => bei aktiver Tag / Nachtschaltung
exten => 08154711,1,NoOp(${CALLERID(num)} ruft an (${EXTEN}))
; Check if Caller ID is Blacklisted or not...           if Yes:                 if not:
same  => 2,ExecIf($[${DB_EXISTS(blacklist/${CALLERID(num)})}]?GoTo(blacklisted,999,1):GoTo(3))
same  => 3,NoOp(The Caller ${CALLERID(num)} is not blacklisted, continue..)
same  => n,ExecIf($[${DB_EXISTS(Device/1000)}]?Set(DIALGROUP(main,add)=SIP/1000):NoOp(nothing to do for SIP/1000))
same  => n,ExecIf($[${DB_EXISTS(Device/1001)}]?Set(DIALGROUP(main,add)=SIP/1001):NoOp(nothing to do for SIP/1001))
same  => n,ExecIf($[${DB_EXISTS(Device/1002)}]?Set(DIALGROUP(main,add)=SIP/1002):NoOp(nothing to do for SIP/1002))
same  => n,ExecIf($[${DB_EXISTS(dialgroup/main)}]?Dial(${DIALGROUP(main)}, 30,tT):VoiceMail(3000,t))
same  => n,VoiceMail(3000,t)

[...]

; ############################################# Begin Blacklisted Caller Rufbehandlung
[blacklisted]
exten => 999,1,NoOp(${CALLERID(num)} who is Blacklisted is Calling...)
same  => n,Answer()
same  => n,Wait(1)
same  => n,Playback(blacklist)
same  => n,Playback(tt-somethingwrong)
same  => n,Wait(1)
same  => n,Hangup()
; ############################################# Ende Blacklisted Caller Rufbehandlung
 
Zuletzt bearbeitet:
Soweit ich vermute sind die Dateien allesamt Headerless und Asterisk geht stur davon aus, dass die auch korrekt konvertiert/hergestellt wurden.
Mal andersrum, eine in Asterisk funktionierende G.722 nach WAV konvertieren...
(ffmpeg -i zap.g722 zap.wav)
Rich (BBCode):
[g722 @ 0x623e40] Estimating duration from bitrate, this may be inaccurate
Input #0, g722, from 'zap.g722':
  Duration: 00:00:00.54, bitrate: 64 kb/s
    Stream #0:0: Audio: adpcm_g722, 16000 Hz, mono, s16, 64 kb/s
Stream mapping:
  Stream #0:0 -> #0:0 (adpcm_g722 (g722) -> pcm_s16le (native))
Press [q] to stop, [?] for help
Output #0, wav, to 'zap.wav':
  Metadata:
    ISFT            : Lavf58.20.100
    Stream #0:0: Audio: pcm_s16le ([1][0][0][0] / 0x0001), 16000 Hz, mono, s16, 256 kb/s
...ffmpeg muss, da Headerless 'raten' wie lang die Aufnahme ist.
Wenn also nicht richtig konvertiert (bitrate?) dann Geschwindigkeitsänderung.
In Grün siehste auch das Format, was die funktionierende G.722 haben muss.


Headerless
Das Linux Gizmo file guckt sich die Datei an und gibt die Infos aus die es findet.
Beispiel...
Code:
# file zap.g722
zap.g722: ISO-8859 text, with very long lines, with no line terminators
# file zap.wav
zap.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 16000 Hz
 
Zuletzt bearbeitet:
Warum funktioniert es den Tadellos wen ein Internes Telefon auf diese Soundfiles "stößt"? Das irritiert mich etwas...
Zumal ich das Soundfile NUR in g722 vorliegen habe um eben auszuschließen, das intern ein anderes file Verwendung findet als bei externen anrufern... o_O
 
Dann mach mal nacheinander diese Konvertierungen und anschliessende Tests, wo und ob es damit besser wird.
1. *.g722 nach *.pcm - Ein Test mit beiden Files, ein Test nur mit *.pcm
2. *.g722 nach *.gsm - Ein Test mit beiden Files, ein Test nur mit *.gsm
Bei den Tests mit beiden Files natürlich prüfen ob der Bessere auch genommen wird.
Sinn: Wenn *.g722 als Standard für/zur Transkodierung (für den externer RTP Audio Kanal) nicht sooo gut ist, dann PCM probieren und wenn das auch nicht funzt, als Fallback auf jeden Fall GSM dafür bereithalten.
Ich nutze: *.gsm, *.g722, *.alaw und *.ulaw
Und die Codecpriorität(en): allow=!all,g722,alaw,ulaw
 
Zuletzt bearbeitet:
Ach so? das Allow setzt auch gleichzeitig die Priorität der zu verwendeten Codecs fest??? Nice to know...

Das problem ist, das er die Tonprobleme auch beim tt-somethingwrong sound (standard .gsm sound) hat..
hatte den tt-somethingwrong extra mal mit reingenommen um eben zu testen obs am encodierten file liegt...
Heute morgen lief es 1x ohne Probleme, danach wieder diese abgehackte sch***e...

Evtl macht auch das Handynetz diese Probleme?

Nichts desto trotz, werde ich die umcodierungsgeschichte mal testen...
 
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.