fritzcap: Tool für Etherreal Trace und Audiodaten-Extraktion v2.0

[JohnDoe42]

Ich denke, dass Du zuerst mal herausfinden solltest, warum die Daten in G723 kodiert sind; Standard für VoIP wäre beispielsweise PCMA und/oder PCMU ( s. RTP-PAyload-Typ 0 oder 8 ). Seit wann klappt denn das Dekodieren nicht mehr ?
Hat es mit Daten aus der gleichen Quelle und der gleichen Fritzcap-Version jemals jeklappt ?
Außerdem scheint die Paketlänge für G723.1 78 Bytes zu sein .....

 

[RainerKeim]

Evtl. wird das ja auch nur von dem Script falsch gezeigt mit Payload type 4. Folgendes sagt Wireshark:
Payload: g711A (G.711)
Frame length: 298 bytes

Ich kann das cap-file sonst auch hier mal anhängen, wenn das hilft.

Das Dekodieren hat noch nie funktioniert bisher.

 

[JohnDoe42]

Auf welchem Gerät läuft denn das Script ?
Das das Script den Payload-Typ direkt aus dem (12 Byte langen) Header jedes Paketes liest, würde ich eher davon ausgehen, dass Wireshark hier etwas falsches liefert ...

 

[RainerKeim]

Auf welchem Gerät läuft denn das Script ?

Auf einem Raspberry Pi

 

[JohnDoe42]

Kannst Du Fritzcap testweise mal auf einem anderen Gerät (NAS, Laptop etc.) laufen lassen, um den Fehler etwas einzugrenzen ?
Entsteht Dein o.g. Fehler, wenn Du ein Capture-File per Hand dekodieren willst ?

 

[RainerKeim]

Habs jetzt auf nem Windows-Rechner probiert mit dem gleichen Ergebnis. Wenn ich das Capture File einfach mit -d dekodieren will, klappt es auch nicht. Es passiert einfach nichts, keine wav Datei wird geschrieben.

Edit: Wie gesagt: Wireshark bekommt einen "glasklaren" Ton hin. Mit sämtlichen anderen Command-KLine Tools bekomme ich nur etwas sehr verrauschtes hin. Mit Fritzcap zur Zeit leider gar nichts :-( Ich glaube aber, dass es nur ene Kleinigkeit ist... nur welche...

 

[JohnDoe42]

Dann kann es nur an dem Dekodier-Modul liegen bzw. einem nicht zu den Audio-Daten passenden Codecs.
Dann mußt Du Dich wohl mit genau diesem Modul ein wenig auseinandersetzen und ggfs. den Code erweitern.

Edit:
Als ersten Ansatz würde ich mir für ein ganz kurzes File nach dieser Zeile

(streamsetup, payloadtype, seqnr, timestamp, ssi) = struct.unpack('>BBHLL', packet[candidate['offs']-12 : candidate['offs']])

mal den Inhalt des Structs ausgeben lassen und schauen, ob wirklich Payload-Typ = 4 ist.

 

[RainerKeim]

Ich habe ja oben die lenmap erweitert, allerdings habe ich bei offs einfach mal 54 eingetragen, weil ich es nicht besser wusste. Wie bekomme ich denn heraus, welcher Wert da rein muss. Da der Wert ja in der Zeile, die du erwähnt hast, berücksichtigt wird, könnte das ja schon die Ursache für den Fehler sein.

 

[JohnDoe42]

Ich meinte eigentlich, daß Du das unmodifierte Script laufen lassen sollst und die g711_decoder.py um die eine Debug-Zeile erweitern solltest um zu schauen, welchen Payload-Typ Deine gecaptureten Daten haben ...

 

[RainerKeim]

Wenn ich das Script nicht modifiziere, komme ich dort nie an, denn diese Bedingung davor liefert immer false:
if len == candidate['len']:

Die Länge meiner Pakete beträgt 298 bytes und den Eintrag gibt's in der lenmap nicht.

 

[JohnDoe42]

Wie wär' 's mit Auskommentieren von dem If-Statement ... ?

 

[RainerKeim]

Wie wär' 's mit Auskommentieren von dem If-Statement ... ?

Dann fehlt mir der passende candidate:
(streamsetup, payloadtype, seqnr, timestamp, ssi) = struct.unpack('>BBHLL', packet[candidate['offs']-12 : candidate['offs']])

Ich stoße dann auf das gleiche Problem: Welchen offs-Wert muss ich angeben?

 

[JohnDoe42]

Wie ist die Box angebunden, über ADSL oder VDSL ?
Für den Fall DSL über PPPoE scheint der Offset 72 zu sein ...

 

[RainerKeim]

Ist kein DSL, habe eine Glasfaserverbindung. Die FritzBox hängt über LAN1 an einem externen Modem bzw. Router.

 

[JohnDoe42]

Dann könnte hier das Problem liegen. Wenn Du Dir die Definition von lenmap anguckst (insbesondere die Kommentare)

lenmap = [
          # PacketLength, AudioChunkLength, Offset of audio data, descriptive text
          {'len': 306, 'chunk': 240, 'offs': 66, 'encap' : 'VDSL' },        # VDSL
          {'len': 226, 'chunk': 160, 'offs': 66, 'encap' : 'VDSL' },        # VDSL
                                                                            # VDSL ComfortNoise ?? not seen yet
                                                        
          {'len': 232, 'chunk': 160, 'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE)
          {'len': 312, 'chunk': 240, 'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE)
          {'len': 73,  'chunk': 0,   'offs': 72, 'encap' : 'DSLPPPoE' },    # DSL (PPPoE) ComfortNoise
          
          {'len': 214, 'chunk': 160, 'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH)
          {'len': 294, 'chunk': 240, 'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH)
          {'len': 55,  'chunk': 0,   'offs': 54, 'encap' : 'DSLETH'  },     # DSL (ETH) ComfortNoise
    ]

siehst Du, dass die Payload-Types der Codecs scheinbar für DSL "hardcoded" sind (0,8,13). Du müßtest also versuchen herauszufinden, welcher Codec zu Deiner mit Wireshark ermittelten Paketlänge gehört und den Dekoder entsprechend erweitern.
Dann wäre interessant zu wissen, ob jemand im Forum unterwegs ist, der fritzcap erfolgreich an einem Kabelanschluss betreibt.

 

[RainerKeim]

Es geht!

Habe jetzt folgendes eingetragen:
{'len': 298, 'chunk': 240, 'offs': 58, 'encap' : 'SWNNET' }, # SWNNET

Sehr schön! Vielen, vielen Dank für deine Hilfe. Am Ende war es im Prinzip nur das Offset, das ich korrekt setzen musste. Dabei hat mir diese Sete geholfen: https://downloads.avaya.com/elmodocs2/s8700/cnet/NW_Ref_Ch72.html

Jetzt habe ich nur noch ein kleines weiteres Problem: Das gemixte wav enthält nur den Ton von meinem AB und nicht den Ton vom Anrufer. Das reine Anrufer-wav enthält aber den Ton des Anrufers (das ist ja auch das wichtigste). Idee, woran das noch liegen könnte?

 

[JohnDoe42]

Wieviele Dateien liegen denn am Ende eines Dekodiervorgangs insgesamt vor ?
Es sollten vier sein: Jeweils ein WAV für Anrufer, Angerufenen und beide gemixt und das Capture-File.
Falls eines fehlt, könnte das auch noch ein Kollateralschaden von den ehemals "falschen" Codecs sein ....

 

[RainerKeim]

Wieviele Dateien liegen denn am Ende eines Dekodiervorgangs insgesamt vor ?
Es sollten vier sein: Jeweils ein WAV für Anrufer, Angerufenen und beide gemixt und das Capture-File.
Falls eines fehlt, könnte das auch noch ein Kollateralschaden von den ehemals "falschen" Codecs sein ....

Ich habe sogar vier wav Files:
capture_20140630162630_0_.wav
capture_20140630162630_1_.wav
capture_20140630162630_2_.wav
capture_20140630162630_mix_0_1.wav

 

[JohnDoe42]

Okay, was genau ist in dem *mix_0_1.wav zu hören ?

 

[rhb5]

Hallo zusammen!
ich bin neu hier und habe schon einiges durch gelesen. Die Möglichkeit Gespräche aufzuzeichnen finde ich sehr gut und ich brauche es auch sehr dringend!
Gibt es denn irgendwo eine Schritt für Schritt Anleitung, wie man das ganze zu erst mal installiert und dann auch benutzt? Für alle, die sich mit PC nicht so gut auskennen.
Dafür wären auch andere Neulinge bestimmt sehr dankbar und man hätte deutlich weniger Beiträge im Forum.
Mit vielen Dank schon mal im Voraus und Gruß,

rhb5.