Mar 03 2017 08:59 PM
I am tasked with implementing a bot connector for Skype for Business Online, and to say it has been challenging is an understatement. I realize that the Trusted Application API is very new, and just for fun, I also work in a PHP shop, so I'm really not doing myself any favors. However the beauty of a REST api is supposedly that the language I choose to implement in doesn't matter.
In any case, I have jumped through the many hoops of Azure AD authentication and have gotten a reliable process built for getting a token and retrieving the top-level resource urls. But, when I call these resources (which should be the last step before seeing "hello" in my skype client) I am stymied by an error.
I am calling my "startMessaging" resource, as defined by the communication group on the main Application resource request. Example call going to https://api.skypeforbusiness.com/platformservice/v1/applications/3168576520/communication/messagingI... sends this data in the body:
{ "to":"sip:awaschick@equityim.onmicrosoft.com", "operationId":"1", "callbackUrl": "https://janedev8001.ngrok.io/event" }
In response, I get:
{ "code": "BadRequest", "subcode": "CallbackUriUnreachable", "message": "Exception of type 'PlatformService.Web.ValidationException' was thrown.", "debugInfo": { "errorReportId": "7ade7fb108cd4d28b5ecfebafe6e86bc" } }
The thing is, on my dev proxy, it never registers an incoming request at my specified callback URL. It's there, I can hit it myself, so everybody else should be as well.
When I configured my Skype endpoint as instructed by the trusted api documentation, in Powershell, though, I get back this information:
RunspaceId : e62a1040-160f-4d5f-a186-d114b76992e2 FriendlyName : jane-dev Id : 458ff1f0-53b3-495b-b0ce-47d1cbad5849 TenantId : e39d3de2-8d8c-4285-a31d-b4144c3d82d8 EndpointType : Targeted SipUri : sip:joanbot@equityim.onmicrosoft.com PhoneNumber : CallbackUri : Ring : ClientAudience :
No default callback Uri. I'm wondering, is this the callback endpoint that it can't reach when I try to start messaging? I'm at a loss here as to how to define this, if so. I can't find documentation on a specific cmdlet I can run that will let me set this value, if so.
I'm quite at the end of my rope here. What am I missing?
Andy
Mar 17 2017 08:05 AM
Hi Andy,
i'm in the same situation.
Have you resolved the issue?
Mar 17 2017 08:36 AM - edited Mar 17 2017 08:42 AM
No, I was forced to fall back and build something using the oauth authentication flow, where my service puppets an Office 365 user account to interact with humans. It's super hacky, but will get me by until such time that the trusted App Api is actually ready for use.
Since I have spent my time going in this direction, I haven't had a chance to review the current state of the Trusted Application API, and was hoping it wouldn't be long until the issue I was having was resolved. You encountering the same problem weeks later confirms my temporary solution was unfortunately the right course of action.
Mar 20 2017 01:31 PM
Are you still seeing issues with callback? The callback is configured at the application level and you should be able to set that up from the Skype for Business online application registration portal
https://skypeappregistration.azurewebsites.net/appregistration
If you don’t see the callback Uri in the tenant admin shell that is expected.
Could you share your traces if you are still seeing issues with callback we could see what is happening there and help with debugging further.
Mar 22 2017 06:58 AM
I'm in the same situation. I did success via skypeappregistration.azurewebsites.net/appregistration. But callback url doesn't set in result of powershell. How do I gets other debug information?
Mar 23 2017 10:39 PM - edited Mar 23 2017 10:40 PM
I too am facing this issue when trying to get the TrustedJoinMeeting sample working. I am listening on the callback uri and have verified that it is reachable. However, I do not see a request come in before receiving the 'CallbackUriUnreachable' error.
See attached file for a trace of this.
-Tom
Mar 24 2017 12:42 PM
Hi Tom,
Thanks for the traces. We will look into this and get back to you.
Also, could you please share your HTTP Request and Response headers when you get a chance. We would like to see what comes in the response header. Also, we are looking to improve debuggability or work on a solution to help with debugging call back failures.
Mar 24 2017 12:48 PM
Hi Keji,
The callback is not shown in the endpoint in the Tenant Admin shell and that is expected.
If you have used the registration portal and registered a callback url. You should be good.
Could you also share your http request and response headers we can look into why the callback fails.
You can also look into the X-MS-Client diagnostics code in your response header. Its base 64 encode.
Let me know if this helps.
Mar 26 2017 09:14 AM
@Renukha Rajaraman wrote:
The callback is not shown in the endpoint in the Tenant Admin shell and that is expected.
If you have used the registration portal and registered a callback url. You should be good.
This raises more questions.
This all seems rather awkward.
Mar 26 2017 06:19 PM
Hi Renukha,
Thanks. However S4B doesn't accessing to my callback url. (Of course, my callback url can access).
A callback access doesn't show in my web server's access log.
Mar 28 2017 03:04 AM
Mar 28 2017 10:32 AM
I'm facing the same problem, I used the registration tool and the callback URI was registered in New-CsOnlineApplicationEndpoint . Here is my X-MS-ClientDiagnostics:
T3BlcmF0aW9uQ29udGV4dC1PdXRnb2luZ0h0dHBSZXF1ZXN0RXhjZXB0aW9uTWVzc2FnZT1Db3VsZCBub3QgZ2V0IE9BdXRoIEVWTyB0b2tlbi4gTWVzc2FnZTogQUFEU1RTNTAwMDE6IFRoZSBhcHBsaWNhdGlvbiBuYW1lZCBodHRwczovL2V2ZW50cy5nZXJpcm1lLmNvbS5iciB3YXMgbm90IGZvdW5kIGluIHRoZSB0ZW5hbnQgbmFtZWQgOTg5ZDA1M2EtZThhYi00ODAwLWE0ZGEtZGJiZjAzYjQzY2NiLiAgVGhpcyBjYW4gaGFwcGVuIGlmIHRoZSBhcHBsaWNhdGlvbiBoYXMgbm90IGJlZW4gaW5zdGFsbGVkIGJ5IHRoZSBhZG1pbmlzdHJhdG9yIG9mIHRoZSB0ZW5hbnQgb3IgY29uc2VudGVkIHRvIGJ5IGFueSB1c2VyIGluIHRoZSB0ZW5hbnQuICBZb3UgbWlnaHQgaGF2ZSBzZW50IHlvdXIgYXV0aGVudGljYXRpb24gcmVxdWVzdCB0byB0aGUgd3JvbmcgdGVuYW50Lg0KVHJhY2UgSUQ6IDI5ZDViOTY4LWRmYzMtNDA3ZS1hNjI4LTk4MGIyYjdhMGIwMA0KQ29ycmVsYXRpb24gSUQ6IDAwNTFiMWY5LWIzOTQtNDMwNy1hMzlmLTIyNjJmOGVkMmM3MQ0KVGltZXN0YW1wOiAyMDE3LTAzLTI4IDE3OjIxOjMyWi1FcnJvckNvZGU9QmFkUmVxdWVzdC1FcnJvclN1YkNvZGU9Q2FsbGJhY2tVcmlVbnJlYWNoYWJsZS1FcnJvckRlYnVnUHJvcGVydGllcz1lcnJvclJlcG9ydElkPSI0NDgwZDk5NGY1ODg0ZTEyYjQzN2RlOTM0YTA0YzJlZiIKLUNvcnJlbGF0aW9uSWQ9MjE0NzQ4NDQzNi1IdHRwTWV0aG9kPVBPU1QtU3RhdHVzQ29kZT00MDAtVXJpUGF0aD0vcGxhdGZvcm1zZXJ2aWNlL3YxL2FwcGxpY2F0aW9ucy8yMzgyMDA3ODExL2NvbW11bmljYXRpb24vbWVzc2FnaW5nSW52aXRhdGlvbnMtVXJpUXVlcnlQYXJhbWV0ZXJzPT9lbmRwb2ludElkPXNpcDpza3lwZWZvcnRoZXdpbnMxQHRlbmZvbGRpbmMub25taWNyb3NvZnQuY29tLVVzZXJBZ2VudD1za3lwZWZvcnRoZXdpbnMxLUxhdGVuY3k9MjE4LjczOTktVGltZXN0YW1wPTEvMS8wMDAxIDg6MDA6MDAgQU0tQ2xpZW50SWQ9ZGI5MmJhN2QtYWI3ZC00ZWIwLTg2ZTUtMjgwYjM3MTc5MzJhLUNsaWVudE5hbWU9c2t5cGUgZm9yIHRoZSB3aW5zLUVuZHBvaW50SWQ9c2lwOnNreXBlZm9ydGhld2luczFAdGVuZm9sZGluYy5vbm1pY3Jvc29mdC5jb20tVGVuYW50SWQ9OTg5ZDA1M2EtZThhYi00ODAwLWE0ZGEtZGJiZjAzYjQzY2NiLU1hY2hpbmU9QkwyMFIwMkZFUzAxLmluZnJhLmx5bmMuY29tLUZvcm1hdFZlcnNpb249UGxhdGZvcm1TZXJ2aWNlIDEuNC1SZXF1ZXN0ZWRWZXJzaW9uPTAt
Mar 28 2017 04:00 PM
Hi Andy,
Thankyou for your feedback. As Patrick mentioned callback should be added as one of the reply urls.
Yes, I agree that we should not be showing the callback uri when we get the endpoint properties. Thanks for the feedback again. We are tracking this one and will have an update soon.
I am not clear about why we would need multiple endpoints when we move from staging to production.
We are also working on improving the registration portal tool for better developer experience.
We could look at the reason for failure from the response header and debug from there.
Renukha
Mar 28 2017 04:01 PM
Just checking if you did the step for tenant admin consent as this is the exception that we are seeing when we decode the X-Ms-ClientDiagnostics
OperationContext-OutgoingHttpRequestExceptionMessage=Could not get OAuth EVO token. Message: AADSTS50001: The application named https://events.gerirme.com.br was not found in the tenant named 989d053a-e8ab-4800-a4da-dbbf03b43ccb. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You might have sent your authentication request to the wrong tenant.
Trace ID: 29d5b968-dfc3-407e-a628-980b2b7a0b00
Correlation ID: 0051b1f9-b394-4307-a39f-2262f8ed2c71
Timestamp: 2017-03-28 17:21:32Z-ErrorCode=BadRequest-ErrorSubCode=CallbackUriUnreachable-ErrorDebugProperties=errorReportId="4480d994f5884e12b437de934a04c2ef"
-CorrelationId=2147484436-HttpMethod=POST-StatusCode=400-UriPath=/platformservice/v1/applications/2382007811/communication/messagingInvitations-UriQueryParameters=?endpointId=sip:skypeforthewins1@tenfoldinc.onmicrosoft.com-UserAgent=skypeforthewins1-Latency=218.7399-Timestamp=1/1/0001 8:00:00 AM-ClientId=db92ba7d-ab7d-4eb0-86e5-280b3717932a-ClientName=skype for the wins-EndpointId=sip:skypeforthewins1@tenfoldinc.onmicrosoft.com-TenantId=989d053a-e8ab-4800-a4da-dbbf03b43ccb-Machine=BL20R02FES01.infra.lync.com-FormatVersion=PlatformService 1.4-RequestedVersion=0-
Meanwhile I will try to pull logs off the server for this one and see if we have more information. We are working on improving debuggability for callback failures in general.
Will get back with updates. Thanks
Mar 28 2017 05:51 PM
Thanks for the reply Renukha,
After change the one configuration on my azure AD the error has changed, and now it seems to have less information about what really happened.
Does it help you?
X-MS-ClientDiagnostics: (Decoded)
OperationContext-OutgoingHttpRequestExceptionMessage=Error on resolve DNS-ErrorCode=BadRequest-ErrorSubCode=CallbackUriUnreachable-ErrorDebugProperties=errorReportId="a43807d33fec450585accd6a279c5292"
-CorrelationId=2147489441-HttpMethod=POST-StatusCode=400-UriPath=/platformservice/v1/applications/2382007811/communication/audioVideoInvitations-UriQueryParameters=?modalities=AudioVideo&endpointId=sip:skypeforthewins1@tenfoldinc.onmicrosoft.com-UserAgent=skypeforthewins1-Latency=3155.5886-Timestamp=3/29/2017 12:44:23 AM-ClientId=db92ba7d-ab7d-4eb0-86e5-280b3717932a-ClientName=skype for the wins-EndpointId=sip:skypeforthewins1@tenfoldinc.onmicrosoft.com-TenantId=989d053a-e8ab-4800-a4da-dbbf03b43ccb-Machine=BL20R02FES04.infra.lync.com-FormatVersion=PlatformService 1.4-RequestedVersion=0-
Mar 28 2017 06:29 PM
Hi,
I hope I can answer a few of your questions.
Thank you,
Vinay Chandra Dommeti
Mar 29 2017 02:33 AM
Hi Vinay,
Can you confirm which portal you mean? I can't find any reference to callbackurl in any of the portals
Thanks,
Richard
Mar 29 2017 06:41 AM
For anyone who has stumbled accross this thread I found the below on the Github repo about callback uris:
"I was finally able to get the callback working. I configured the 'App ID URI' in Azure to be only a fqdn (no path and no port), eg 'https://my.domain.com' (not 'https://my.domain.com:443, not 'https://my.domain.com/callback'). I configured the callback uri to be the same exact string as my App ID URI."
It seems the skype registration put :443 into the app ID URI which makes the validation fail
Hope this helps
Mar 29 2017 12:42 PM
The fqdn you use for the 'App ID Uri' and the callback url must be in a 'verified custom domain', (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-add-domain) have you done this?
-Tom
PS - Sorry for my name being 'null null', I updated it in my profile, but it doesn't take.