[PolicyRecordingBot] - When running locally, call never connects

[mryderie]

I'm attempting to debug the Policy Recording Bot by running it locally, but when making a call, it rings a few times then the user sees "Forwarding to Voicemail", and a few seconds later the message "Sorry, we couldn't connect you". The call ends, and it does not go to voicemail.

While the call is establishing, I see multiple requests to OnIncomingRequestAsync and OnNotificationRequestAsync happening successfully, which leads me to believe that the issue is with the media port.

My local media port is 8445, and I'm using ngrok to attempt to tunnel traffic to this port.

To troubleshoot, I've tried connecting to the public and local media ports, and they each seem to be open:

Also, it looks like localhost:8445 is being reached. Each time I make a call, the Connections count for the media tunnel increases (highlighted in screenshot).

I've seen other people asking about similar issues here, but none of the proposed solutions in those threads has worked for me. Any help or troubleshooting guidance will be much appreciated.

Trace messages from while a call is establishing are attached:

PolicyRecordingBot-trace.log

[Manojb86]

Hi, I have a few questions to understand your local setup of the PolicyRecordingBot.

1. Didn't you use SSL cert?
2. is it wildcard SSL?
3. is it against ngrok URL(https://ngrok-test.com) or public domain URL(ex: https://testdomain.com)?
4. Where did you apply SSL cert? local machine?
5. What was the CNAME value? ngrok URL (https://ngrok-test.com) or ngrok tcp URL(3.tcp.ngrok.io)?
6. What is your bot channel calling webhook URL? https://ngrok-test.com/api/calling? https://testdomain.com/api/calling? 3.tcp.ngrok.io/api/calling?
7. What are the values enter in ServiceConfiguration.Local.cscfg, ServiceDnsName and ServiceCNAME?
8. what is your serviceFqdn value in AzureConfiguration class? ngrok tcp URL(3.tcp.ngrok.io) or ServiceCNAME?

any other thing you set up to run locally except above?

[mryderie]

Hi, thanks for your questions.

1,2&3 Yes, I'm using a wildcard SSL cert, the cert is for a public domain, like this: "*.testdomain.com"

4. The cert is in the Local Machine store. My feeling is that the cert is ok, because the signalling requests to OnIncomingRequestAsync and OnNotificationRequestAsync are working fine, and the signalling endpoint uses the same cert as the media endpoint.
5. CNAME for the media endpoint is a ngrok TCP URL, it's 3.tcp.ngrok.io
6. Bot channel is using the custom domain, like this: https://recorder.testdomain.com/api/calling
7. ServiceConfiguration.Local.cscfg settings look like this. Note, from the code, it looks like ServiceDnsName is not used when running locally. <Setting name="ServiceDnsName" value="localhost" /> <Setting name="ServiceCNAME" value="recorder.testdomain.com" />
8. serviceFqdn in AzureConfiguration is "3.recorder.testdomain.com". I have a CNAME pointing that at 3.tcp.ngrok.io

[Manojb86]

Hi, thanks for your questions.

1,2&3 Yes, I'm using a wildcard SSL cert, the cert is for a public domain, like this: "*.testdomain.com"

4. The cert is in the Local Machine store. My feeling is that the cert is ok, because the signalling requests to OnIncomingRequestAsync and OnNotificationRequestAsync are working fine, and the signalling endpoint uses the same cert as the media endpoint.
5. CNAME for the media endpoint is a ngrok TCP URL, it's 3.tcp.ngrok.io
6. Bot channel is using the custom domain, like this: https://recorder.testdomain.com/api/calling
7. ServiceConfiguration.Local.cscfg settings look like this. Note, from the code, it looks like ServiceDnsName is not used when running locally. <Setting name="ServiceDnsName" value="localhost" /> <Setting name="ServiceCNAME" value="recorder.testdomain.com" />
8. serviceFqdn in AzureConfiguration is "3.recorder.testdomain.com". I have a CNAME pointing that at 3.tcp.ngrok.io

Thank you for your reply. The call goes to voicemail because it can't enageged with receiver. Actually we require SSL cert for media URL to receive media streams. MS skype media platform not send media stream to connection without SSL cert.

Your serviceFqdn should be 3.tcp.ngrok.io not the 3.recorder.testdomain.com. Because you don't have subdomain of "3.recorder.testdomain.com" right? And other thing is media port 8445 and public port given by ngrok pointing to the 3.tcp.ngrok.io URL.

try changing serviceFqdn to 3.tcp.ngrok.io. let me know it is success or not.

[Manojb86]

What is your name and value of CNAME entry? Name: 3.recorder.testdomain.com and value 3.tcp.ngrok.io? OR Name: recorder.testdomain.com and value 3.tcp.ngrok.io?

[mryderie]

Hi, thanks for your questions again.

When I set serviceFqdn to "3.tcp.ngrok.io", I get the exception:

InvalidOperationException: Failed to match service domain name '3.tcp.ngrok.io' against certificate with subject name 'CN=.testdomain.com, OU=Domain Control Validated' and SAN list:[DNS Name=.testdomain.com, DNS Name=testdomain.com

That's what I'd expect, because I don't have a cert for 3.tcp.ngrok.io installed locally, and the thumbprint I'm passing is for a "*.testdomain.com" cert. Do ngrok offer certs for their subdomains? I'm not aware.

To your question on CNAME entries - I have two entries, one for the signalling endpoint (like "recorder.testdomain.com"), and one for the media endpoint (like "3.recorder.testdomain.com"):

[Manojb86]

Hi, Sorry, I was wrong. You did it in a correct way. I followed the same steps as you did and face the same issue. I get the incoming call and notification requests, but call going to voice mail. I think this issue lies around media URL. ngrok dashboard shows the media URL get it hit but nothing happened. I'm doing further testing to find issue, if you find anything let me know.

[Manojb86]

Hi, Do you able to resolve this?

[mryderie]

Hi, no, unfortunately I have not found any solution.

My only way to test/debug is by running on Azure, which is much more time-consuming than running locally.

[tares003]

Hi, I have the exact same issue. I have the exact same setup, but it throws an exception when establishing the TCP connection.

Any solution to this as of yet?