LM-Development / aks-sample

Community project providing an undeprecated Microsoft Teams bot sample that runs on Azure Kubernetes Service
https://github.com/LM-Development/aks-sample/tree/main/Samples/PublicSamples/RecordingBot
MIT License
1 stars 0 forks source link

TeamsRecordingBot debug on local machine is not working #64

Open mjoksa opened 3 days ago

mjoksa commented 3 days ago

Hi,

I successfully started to bot in Azure, initiate a call between two users on my machine (myself and other user that has recording policy assigned) and saw logs coming in, but there was no WAV file(s) stored in a Kube pod. All of this is explained at this issue https://github.com/LM-Development/aks-sample/issues/63, and as @1fabi0 stated code is not very applicable for production, so I decided to try to debug it on my local machine in order to see what is happening.

I used ngrok custom domain with certificate that I provided (and is now on my machine too). Also, I set TCP port, updated .env file, updated bot webhook URL in Azure and did everything stated in provided documentation. So far, I managed to start bot locally without any exception, but when I try to initiate call between same two users mentioned above, call fails.

I am trying to figure out if there is anything that I missed and how to debug this locally (without Docker) so any help on this will be much appreciated.

1fabi0 commented 3 days ago

We have not provided an updated documentation for using ngrok yet, but from what you described you did everything right so far. But you also have to take care of the pulbic domain and port for call updates. In an aks setup it uses nginx to route the calls and call updates to the desired pods, to configure this checkout where you're CallControlBaseUrl points to and checkout if you need to change there anything in the environment variables (you can just use a breakpoint here)

smooth-jgb commented 3 days ago

Thank you very much for the update.

We have the service as recordingbottutorial-0, its port number is 8445, all looks good with it, also we do not get communication errors in the logs ( I suppose if there were issues with CallControlBaseUrl there would be at least communication errors). Still no WAV file(s) stored. Could you point us to something specific we may need to touch to get them working?

And in regard to the local development ... are there more complete or up-to-date tutorials somewhere we can check on?

1fabi0 commented 3 days ago

Regarding the Wav File see #63, but you can check if you receive http requests when doing actions like unmuing and muting, if you are using ngrok you can use ngrok to monitor incoming requests. if you dont receive request the CallControlBaseUrl migth be misconfigured and yes a wrong CallControlBaseUrl can cause this kind of issues without any exceptions.