A) mute/unmute Fehler
B) Ruftaste Fehler (falls sich diese Taste so nennt) HID in: [TEL] Hook = 1/0



A) mute/unmute Fehler
1. Beende Phoner Lite mit Headset im Status unmute

2. a) PC neu gestartet > Headset ist immer im Status mute
      starte Phoner Lite > starte eine Telefonat > merke, dass Status mute ist > drücke Knopf unmute > call wird beendet
      
ODER

2. b) merke nach Beendigung von Phoner Lite dass das Mikro noch auf unmute steht > drücke Knopf für mute
      starte Phoner Lite > starte eine Telefonat > merke, dass Status mute ist > drücke Knopf unmute > call wird beendet

Beim Start steht im Debug immer:
loading USBphone
HID out: reset output = 1
HID out: reset input = 1

es steht aber nichts zum aktuellen Status "HID in:"


Verhaltem beim ersten Call:

1) Geht man mit "HID in: [TEL] Phone Mute = 1" raus und mit mute (1) rein, 
    dann bricht der erste Call mit Druck auf unmute ab. 
    Eintrag im Debug erfolgt beim ersten Druck auf mute/unmute NICHT.

2) Geht man mit "HID in: [TEL] Phone Mute = 1" raus und mit unmute (0) rein, 
    dann bricht der erste Call mit Druck auf mute NICHT ab. 
    Eintrag im Debug erfolgt beim ersten Druck auf mute/unmute.

3) Geht man mit "HID in: [TEL] Phone Mute = 0" raus und mit unmute (0) rein, 
    dann bricht der erste Call mit Druck auf mute NICHT ab. 
    Eintrag im Debug erfolgt beim ersten Druck auf mute/unmute.

4) Geht man mit "HID in: [TEL] Phone Mute = 0" raus und mit mute (1) rein, 
    dann bricht der erste Call mit Druck auf mute NICHT ab. 
    Eintrag im Debug erfolgt beim ersten Druck auf mute/unmute NICHT.


- Der erste Call bricht nur bei 1) ab
- Keine Einträge beim ersten Druck auf unmute sind im Debug bei 1) + 4) zu vermerken

Ich hoffe, das ich nichts verdreht habe. 
Dass der erste Call bei 1) abbricht, existiert schon seit vielen Versionen


B) Ruftaste Fehler (falls sich diese Taste so nennt) HID in: [TEL] Hook = 1/0

Nach mehrmaligen Drücken der Ruftaste geht diese nicht mehr. Drückt man dann stattdessen mute/unmute, dann funktioniert einmalig die mute/unmute-Taste als Ruftaste
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 1
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 0
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 1
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 0
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 1
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 0
HID in: [TEL] Phone Mute = 1
HID in: [TEL] Hook = 1
HID in: [TEL] Hook = 1
Connect Request: x
Connect Request: x to 
HID out: [LED] Hook = 1
HID in: [TEL] Phone Mute = 0

Auch dieses Verhalten existiert schon sehr lange

Lync/Scype funktionieren bis dato ohne Probleme.

Auch ist geprüft, dass im Hardwaremanager für "Audio, Video und Gamecontroller" sowie für Eingabegeräte (HID) unter Eigenschaften und dort im Register Ereignisse der Eintrag "Gerät gestartet" existiert, denn der Eintrag "Das Gerät funktioniert einwandfrei" im Register Allgemein übergeht den Eintrag "Gerät nicht gestartet" aus dem Register Ereignisse. Ist ein Gerät nicht richtig gestartet und zeigt dennoch "funktioniert einwandfrei" an, dann funktioniert es eben doch nicht richtig und zeigt meistens teilweise aber dauerhafte Ausfallerscheinungen. Da hilft dann meistens Gerät deinstallieren, Treiber aber behalten, neu suchen und dann geht es meistens auch in den Ereignissen auf Anhieb auf gestartet. Das lässt sich auf jede Hardware übertragen. Selbst bei Festplattenkontrollern funktioniert diese Vorgehensweise. Meistens ist das auch die Fehlerquelle bei BT/WiFi Problemen. Hier ist diese Porblematik aber bereits ausgeschlossen.

https://freeusbanalyzer.com/ ;
downloaded as zip-file

after installed you get the Free Device Monitoring Studio Software

I figured out, that we can be sure that this problem isn't caused by the headset

the analyzer stated:
if no phone call is running and also if Phoner Lite isn't running
this happens when the headset mute/unmute button was pressed 4 times:

Packet No      Direct.      Status            Function
00000153      UP      0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
      Details:
      Bulk or Interrupt Transfer (UP), (1. Device: HW121N-USB) 
      Status: 0x00000000
      Pipe Handle: 0x362e9098 (Endpoint Address: 0x83)
      Get 0x3 bytes from the device
00000155      UP      0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
00000157      UP      0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
00000159      UP      0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
every mute/unmute event contains the same details

---------------------

Phone call in Phoner Lite ends unexpectedly when you press the mute button 

Step by step
1. Phoner Lite closed with headset status unmute
2. headset status changed from unmute to mute
3. Phoner Lite started
- Following entries are releated to the Headeset initiated by Phoner lite start
 
00000417      DOWN      0x00000000      URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE
00000418      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER

then a bit time shifted:
00000419      DOWN      0x00000000      URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE
00000420      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER
00000421      DOWN      0x00000000      URB_FUNCTION_CLASS_INTERFACE
00000422      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER 
   00000422: Control Transfer (UP), (1. Device: HW121N-USB) Status: 0x00000000
   Pipe Handle: Control Pipe
   Recipient: Interface
   Request Type: Class
   Direction: Host->Device
   Request: 0x9 (Unknown) ?
   Value: 0x218
   Index: 0x3
   Length: 0x2

4. Phoner Lite start finished, ready for call
5. phone call initiated with double click on a phone number in the address book
00000465      DOWN      0x00000000      URB_FUNCTION_CLASS_INTERFACE
00000466      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER
6. phone call is up/running
7. press unmute button
00000489      UP            0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
00000491      DOWN      0x00000000      URB_FUNCTION_CLASS_INTERFACE
00000492      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER
   Recipient: Interface
   Request Type: Class
   Direction: Host->Device
   Request: 0x9 (Unknown) ?
   Value: 0x218
   Index: 0x3
   Length: 0x2


################

after the first call, this happens with a new phone call
1. phone call started with double click in address book
00000505      DOWN      0x00000000      URB_FUNCTION_CLASS_INTERFACE
00000506      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER
2. press unmute:
00000507      UP            0x00000000      URB_FUNCTION_BULK_OR_INTERRUPT_TRANSFER
nothing else happens

It's just the same as described above from the first call, but with the first call Phoner Lite initiates additional action:
00000491      DOWN      0x00000000      URB_FUNCTION_CLASS_INTERFACE
00000492      UP            0x00000000      URB_FUNCTION_CONTROL_TRANSFER

this must be a bug of Phoner Lite


the  Request: 0x9 (Unknown) is also part of the second call, so it has no impact

hm... irgendwas muss da programmiert worden sein, dass Phoner L beim Beenden des Programms den Status des mute/unmute-Zustands der Headsettaste abfragt bzw. sich merkt.
Beim Start und irgendwo beim Ende von Phoner L holt sich Phoner L mit URB_FUNCTION_GET_DESCRIPTOR_FROM_DEVICE den Status der mute-Taste, das sieht man ja analog dazu auch im debug:
13:02:44,034: HID out: reset output = 1
13:02:44,049: HID out: reset input = 1
und dabei läuft es in einem Fall so, dass sich der von Phoner L beim Beenden gemerkte Zustand der unmute-Taste, wenn dieser eben - solange der Phoner L nicht läuft, gewechselt wird, zu diesem Umstand führt. Allerdings nur dann, wenn er vom unmute auf mute wechselt.
Wenn dem so ist, dann braucht es den Memory vom Programmende doch nicht.
Wenn Phonel L startet, soll es diesen Merker auf den Status "nicht vorhanden" setzen und beim Device einfach den Zustand komplett neu Abfragen und dann nur diesen verwenden. Ich gehe davon aus, dass das auch bei manchem BT-Geräten ebenso abläuft, da der BT-Empfang letztlich auch nur über USB eingeschleust wird.

Wenn Sie wollen, dann kann ich Ihnen ja eines meiner USB-Headsets schicken inkl. Rücksendeporto.
So gehe ich davon aus, dass dieses Thema von 2018 das selbe Problem behandelt
https://forum.phoner.de/cgi-bin/yabb2/YaBB.pl?num=1471523517/6

Man merkt zwar, dass mute/unmute den call beenden kann, aber bei mir hat es auch ewig gedauert bis ich begriffen habe, dass das einzig beim Programmstart passieren kann (sporadisch) bis ich auf den Zusammenhang gekommen bin, dass das mit dem Zustand beim Beenden des Programms zusammenhängt. Seitdem ist es nicht mehr sporadisch (wie beim Fall von 2018) sondern genau in einer bestimmten Situation.

Sie haben also auch am Headset eine mute/unmute-Taste, haben bei geöffnetem Phoner L die  unmute-Taste des  Headsets auch wirklich auf unmute gesetzt, dann Phoner L beendet, dann das Headset auf mute umgestellt, dann Phoner L gestartet, dann eine Nummer angewählt, gewartet bis der Call angenommen wurde, dann die unmute-Taste am Headset gedrückt und bei Ihnen bricht es nicht ab? Das ist schwer vorstellbar, dass das nicht überall auftritt, wenn ich mir die debug- und USB- logs ansehe.

Ich kann Ihnen das Headset gerne schicken und evtl finden Sie irgendwann einen Weg, wie Sie im Phoner L den Memoryeffekt des Zustands der mute/unmute-Taste beim Programmstart überspringen können und diesen eben immer nur frisch auslesen.

Oder es liest hier jemand mit, der mehr davon versteht.
Eigentlich wäre es ja egal, weil es nur einmal auftritt, aber die angerufene Seite ist dann immer etwas verwirrt, wenn diese davon betroffen ist.
Wäre das Problem zudem offiziell bekannt gegeben, dann müsste nicht immer wer erneut rätseln, warum das nur sporadisch auftritt.

Was bisher noch nie funktionierte, wenn das Headset und eben nicht default als Mikro/Lautsprecher ausgewählt ist, war und ist, dass Mikro/Luatsprecher automatisch auf unmute gehen. Ich habe jetzt auf default umgestellt, um dann nach dem Testen wieder auf das Headset umzustellen. Erst Programmabsturz beim Umstellen, dann funktionerte plötzlich der automatische Unmute beim Start des ersten Anrufs, dafür beendet jetzt der Anruf, wenn ich die Headsettaste zum muten des laufenden Gesprächs nutze ... ich werde es mal komplett inkl. Profil deinstallieren und dann sehen wir mal. Sehr komplexes Verhalten und es scheint der Mühe nicht wert zu sein, das alles zu fixen. Da mach ich lieber eine frische Installation und lebe mit dem abbruch beim ersten Call, abe es funktioneieren dann wenigsten weiterhin die Tasten am Headset.

Ok, laut API Doku der HID API gibts input/output zur Kommunikation zw Device <=> Software.
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/_hid/
findet sich ja auch bereits in Ihren debug logs wieder.
auch gibts dei den Docs einige Sachen zum button control
da ja so gut wie alles unter plug and play läuft, sollte das möglich sein

https://docs.microsoft.com/en-us/windows-hardware/drivers/hid/introduction-to-hid-concepts
Windows provides a HID parser for use by drivers and applications via APIs (HidP_*) that can be used to discover the types of usages supported by a device, determine the state of such usages in a Report, or to build a Report to change the state of a usage in the device.

ich nehm die Ausage "usages in a Report, or to build a Report to change the state of a usage in the device" um zu ergänzen:
All data transferred to and from an HID device must be structured in the form of reports.
Zu den Reports habe ich auch etwas bei den Microsoft Docs gesehen

Dieses PDF gibt einen ganz guten Einstieg.
https://www.silabs.com/documents/public/application-notes/AN249.pdf
Chapter 3  + 4 als auch die Suche nach Report im PDF bringt ganz gute Ergebnisse

in dem PDF wiederholt sich dann auch, dass es Anfangs das Auslesen der DeviceInfos bedarf, die sich ja auch in den Treiberdetails zeigen, wie Vendor, HW-IDs + weiteres, damit die Kommunikation per Report in Richtung HardwareHeadsetTasten klappt. Stichwort  Hardwaredetails wie z.B. HID\VID_047F&PID_C247&MI_03&COL02, Vendor ID (VID) usw.

Ich bin zwar weit weg vom Porgrammieren, bin aber überzeugt davon, dass das in etwa der Weg sein sollte, dass eben nicht ein Status im Programm beim Start gesetzt wird, der dann im schlimmsten Fall ungleich dem Headsetstatus ist.

Da sich Phoner L bereits heute nach spätestens dem zweiten Druck auf die Mutetaste des Hardwareheadsets synchronisiert hat, so klappt ja bereits nachweislich die Datenübernahme aus dem Headset Report in der Software, allerding sendet da das Headset. Es wird aber eigenständig nichts vom HID abgeholt und auch nichts aktiv ans HID Headset gesendet? Evtl sprechen Sie bisher nur Lautsprecher + Mikro statt dass HID an? Kann das nur vermuten. Da Sie ja bereits auf dem API-Level aufsetzen, sollte das Auslesen des HID Hardware-Status und dessen Übernahme zum Erstellen eines Reports zu Steuerung in Richtung Headset letztlich in der Software den initialen Zustand der Software durch striktes deaktivieren beim Programmstart obsolet werden lassen.

Ein HID-compliant headset nutzt Windows Treiber, HidTelephony.dll und WUDFRd.sys, mehrfach nachlesbar, dass es noch keine WHQL ist. Es nutzt auch die HIDClass und HidUsb. 

Im Register Statistik mit dem Klick auf die mute/unmute LED ist im debug log zu finden:

Klick macht man die LED grün ...
HID out: [LED] Mute = 1
HID IN: [TEL] Phone Mute = 1

wenn das mit dem HID API Report erstellen klappt, dann könnte im debug mal auftauchen
HID out: [LED] Mute = 1
HID OUT: [TEL] Phone Mute = 1
und es wäre synchron
.
Über das Erstellen von Reports würde ein vollständig synchroner Status zw. Software und Hardware per HID API hergestellt und dadurch sicher auch die eine oder andere Fehlfunktion verhindert werden, so z.B. den Abbruch beim ersten Call, was ja mindesten vor 2 Jahren hier schon mal benannt wurde.

Gut, mehr beitragen kann ich auch nicht.
Evtl. liest mal ein Dev diesen Eintrag und gibt dann einen Tipp, wie das aussehen sollte/kann/muss.

Danke