locked
Lync Client Extensibility 488 Error RRS feed

  • Question

  • Hi

    we have developed a Lync client extensibility application using UCMA 3.0. I have tested in under my login on a test machine and it works as intended. However, on other user's logins on the same machine the context application does not appear.

    The server logged the following error 'Message: 488 Error (Not Acceptable Here) response from the network and the operation failed ... Source: Microsoft.Rtc.Collaboration'

    My initial thoughts are that it is there are missing settings from the test users accounts; are there any pre-requisites for enabling context delivery to a client?

    Any help would be appreciated

    Monday, June 27, 2011 3:46 PM

Answers

  • We have identified the issue; we have desk phones and PCs. Users are logged into Lync on both the PC and the phone.

    When the default device in set in the Lync client to the telephone, the server attempts to send the context app to the phone endpoint and not the Lync client, even if we answer the call using the Lync client. As the phone will not accept a context app, we get a 488 error.

    If we set the default device to a headset (local device connected via USB) then the context application appears because the endpoint is the PC.

    It would be preferable to get the context application delivered to the pc regardless of what answers the call but I believe that this may not be possible. 

     

     

    Tuesday, July 5, 2011 8:20 AM

All replies

  • Did you register the context application for those other users?

    George Durzi's blog post at http://blogs.claritycon.com/georgedurzi/2010/11/25/establishing-a-context-channel-between-a-ucma-3-0-application-and-a-silverlight-application-in-the-lync-extensibility-window has a good walkthrough on this.

    Let me know if that turns out not to be the issue.


    Michael Greenlee | linkedin: http://www.linkedin.com/in/michaelgreenlee | blog: http://blog.greenl.ee
    Wednesday, June 29, 2011 1:39 PM
  • Hi

    thanks for the link. I have previously added the reg keys into the registry for the users but the Lync client does not either display the context app or display an error message: it just behaves as normal.

     

     

    Friday, July 1, 2011 9:32 AM
  • Where are you seeing the 488 error? Is the UCMA code throwing an exception, or are you seeing the 488 in SIP logs?

    One other thing you might try just as a troubleshooting step is adding a Thread.Sleep of a second or two before you send the context message, to see if that gets it working consistently. If so, you may need to change at what point you're sending the context.


    Michael Greenlee | linkedin: http://www.linkedin.com/in/michaelgreenlee | blog: http://blog.greenl.ee
    Monday, July 4, 2011 12:27 PM
  • Hi there

     

    I am working on the same project with Julian.

    488 is issued on server side upon establishing the context.

    We have not added yet sip tracing for this particular issue.

     

    If loaded manually, the client application loads (but as one would expect, getting application data from context fails).

    This is not surprise as server is not sending any due to 488 on establish.

     

    We will try a delayed establish to see how that works. 

     

    Thanks for sugession

    Dan

     


    Monday, July 4, 2011 4:43 PM
  • We have identified the issue; we have desk phones and PCs. Users are logged into Lync on both the PC and the phone.

    When the default device in set in the Lync client to the telephone, the server attempts to send the context app to the phone endpoint and not the Lync client, even if we answer the call using the Lync client. As the phone will not accept a context app, we get a 488 error.

    If we set the default device to a headset (local device connected via USB) then the context application appears because the endpoint is the PC.

    It would be preferable to get the context application delivered to the pc regardless of what answers the call but I believe that this may not be possible. 

     

     

    Tuesday, July 5, 2011 8:20 AM