Using RTC.SIP to create application - UnauthorizedException problem RRS feed

  • Question

  • Hi there,

    I am been looking into writing an application which can manipulate the SIP messages coming into the Proxy or OCS server.

    I have created a console exe application in C# using the Microsoft.rtc.sip interface. But I keep getting an error when executing the ServerAgent.WaitForServerAvailable(10) method. This throws the UnauthorizedException exception.

    I have research this and there is not much on this:

    Logged in as administrator with RFC permissions added to the account.
    OCS is up and running.
    Runnning on Windows 2003 Server Standard.
    Developed in C# and on Visual Studio 5 with .NET 2
    I believe I am using the correct ServerAgent (file version 3.0.6090.0) when I look at its properties in VS it comes up with version: and runtime version of v1.1.4322

    Do I have to create a Service to get this working or is an exe ok ??

    Can anyone shed any light on this?

    Wednesday, May 16, 2007 1:18 PM


  • Basically I created a service instead of an exe for the application. During the installation the user is prompted for an administrator username and password. This admin should have the necessary OCS user and group permissions as per documentation
    Monday, July 9, 2007 8:30 AM

All replies

  • Hi Eoin,

    It doesnt appear that many people have had much experience with this. Have you been able to figure this out on your own? If so, do you mind sharing it with the forums?

    Monday, June 25, 2007 10:10 PM
  • Can you let us know the status of your issue?
    Friday, July 6, 2007 8:12 PM
  • Basically I created a service instead of an exe for the application. During the installation the user is prompted for an administrator username and password. This admin should have the necessary OCS user and group permissions as per documentation
    Monday, July 9, 2007 8:30 AM
  • Hi,


    I'm trying to run the samples provided with the OCS SDK. I was able to run the examples which had only manifest file(all processing of messages done in XML only), there was an entry made in Event Viewer saying application successfully registered and the application was giving the specified output.


    But when it comes to applications which have managed api i too get the same execption(Unauthorized exception).  When i compile the .am file of my managed application there are no errors but there is no entry made in event viewer saying applicaiton successfully registed or something like that. The help guide gave some c# code with heading "Registering a SIP Application with Office Communications Server", what i don't understand is where should i place this code and execute, how to check whether my application is registered or not with the OCS server and should i run the exe generated by my managed code after i start the OCS servers or will it be done internally as in case of script only applications?


    Also i was going through the documentation of LCS to find out how they do the same in LCS. It seems in case of LCS a Local Group with name "RTC Server Applications" is created by the LCS set up in ADUC and, the user who is executing the application should be a member of this Local Group. In case of OCS there is no such group created in my ADUC.


    Eoin, did your webservice work as desired? How did you create and what modifications did you make to the am and cs files?





    PS: I'm using VS2008 beta with OCS'07 trail version deployed in a consolidated topology. Excuse me if my question looks too dumb but i need help with this!




    Tuesday, February 26, 2008 2:18 PM
  • I am running into a similar issue.. Appreciate any help!
    Monday, March 10, 2008 3:08 PM
  • I have to say that I am extremely disappointed with the level of help one gets out of these groups. Neverthless, some kind soul has posted a possible solution to this issue on the internet which I ran into. Here it is:

    The key is to add the user this program is running under to the Groups - RTC Server Applications and RTC Server Local User Group. You will not find them in the AD, instead you will find them when you bring up the Manage on the computer running OCS. Here's more detailed information.

       1. Assuming you followed Microsoft’s instructions correctly – your Enterprise server should be running on a Server that is not a Domain Controller, which means that you still have to add the user you intend to run SIPSnoop with, to the LOCAL “RTC Server Applications” group. You can do this by right clicking “My Computer” and choosing “Manage”. Then, in “Local users and groups, find the RTC Server Applications Group, Double click it and press Add. locate the DOMAIN user you intend to run the application with. for example - if I intend to run the Application with the Administrator account - I have to add DomainAdministrator to the members of the RTC Server Applications group.
       2. Log off, and log back in with the user you chose.

    Goto the following link for more information:

    Thursday, March 13, 2008 4:52 AM
  • In any case, all needed answers to run as SDK application (SipSnoop in my case) are here.


    To remember it for myself & to help someone who wants to do it I'll try to write a "step-by-step" here:



    1. OSC front end is up-and-running,

    2. SDK is installed (not obligatory on it)

    3. The user you want ro run a dialog application (SipSnoop is an example) is a member of "RTC Server Applications" group (locally if the server is not DC, globally if overwise - works both ways, YES OCS Front End CAN be a DC - with some not very pleasant side effects, but it works)

    4. To install application you need to be OCS infrastructure administrator (if you try to run a SDK application - this is most probably your test lab or you for sure know what you do in production environment)


    Step 1. Compile the application (for managed ones)


    Use compile.bat in Samples directory (i.e. "compile.bat sipsnoop") is recommended


    In my case where were several errors in both SipSnooper files (SipSnoop.cs & SessionManager.cs)

    The fix is in follow up... (sometimes I think that some errors in SDK samples are made by coders to make the user or developer understand the application logic & appreciate the creativity of developers)


    Step 2. Copy compiled files to folder on OCS Front End, ensure it also has SDK installed or copy BIN folder from SDk also.


    Step 3. Use regapp.exe /I <full path to .am file> to install the application on OCS server

    Step 4. Verify installation using OCS mmc Snap-in, reorder the application as needed (SipSnoop can run as topmost application)

    Step 5. If the needed application fails to start - examine OCS event log.


    For SipSnoop application - run SipSnoop.exe & enjoy!

    Thursday, September 25, 2008 2:25 AM
  • The fix for SDK SipSnoop example:


    The reason that the example does not compile was that "Microsoft.Rtc.Sip.ResponseReceivedEventArgs"  & "Microsoft.Rtc.Sip.RequestReceivedEventArgs"  types cannot be casted to "System.EventArgs" in C# code.


    Maybe it is an .Net version issue (I use VS 2008 sp1 on vista) - for me it does not matter I simply needed SipSnoop running (right now!).

    To fix errors :

    • create new C# forms application SipSnoop (.net 2.0)
    • change name of form1 to SipSnoop
    • close solution
    • delete program.cs & both form files
    • copy SipSnoop.cs, SessionManager.cs & Utils.cs to solution directory
    • reopen solution
    • set references to needed assembles (ServerAgent.dll & System.Management)
    • add existing SessionManager.cs & Utils.cs to solution

    Now you can fix the errors & try to compile the app to satisfy the compiler...


    In my environment C# refused to cast - so I splited event handler StateChangeListener... to 2 (3) different voids with different params (one for request one for responce & one more for notifications - unused),


    In this way you do not need the cast at all, these events are called internally in SipSnooper,

    the processing of these events, made in SipSnooper, is in any case splitted into two parts in one void - so splitting to two voids does not harm the logic...



    The SessionManager.cs fix:


    You need to fix delegate for events

    //public delegate void StateChangeListener(EventArgs) to


    public delegate void StateChangeListenerRequest(RequestReceivedEventArgs args);

    public delegate void StateChangeListenerResponce(ResponseReceivedEventArgs args);

    public delegate void StateChangeListenerNotification(NotificationReceivedEventArgs args); //(not obligatory - to sniff notifications)

    also you 2 or 3 listeners

    //public StateChangeListener StateChangeListeners;


    public StateChangeListenerRequest StateRequestListeners;

    public StateChangeListenerResponce StateResponceListeners;

    public StateChangeListenerNotification StateNotificationListeners; //(not obligatory - to sniff notifications)


    Fix  their calls in Request and Responce event voids to match the "e" parameter type respectively:



    this.StateRequestListeners(e) & this.StateResponceListeners(e)


    In SipSnoop.cs you must fix the events assignment (now we have 2 or even 3 different events)

    //sessionManager.StateChangeListeners +=

    // new SessionManager.StateChangeListener(this.StateChangeListener);


    sessionManager.StateRequestListeners +=

    new SessionManager.StateChangeListenerRequest(this.StateChangeListenerRequest);

    sessionManager.StateResponceListeners +=

    new SessionManager.StateChangeListenerResponce(this.StateChangeListenerResponce);

    sessionManager.StateNotificationListeners +=

    new SessionManager.StateChangeListenerNotification(this.StateChangeListenerNotification); // unused


    & split the event handling void

    //protected virtual void StateChangeListener(EventArgs args)

    to 2 or 3 event handling voids (as in prototypes)...


    protected virtual void StateChangeListenerRequest(RequestReceivedEventArgs args)


    lock (this)


    if (connected == false) return; //ignore spurious event

    RequestReceivedEventArgs reqArgs = args;

    if (reqArgs != null)


    Request request = reqArgs.Request;

    if (request != null && CanShow(request.StandardMethod))

    { DisplayRequest(request, reqArgs.Parameters); }






    // & responce

    protected virtual void StateChangeListenerResponce(ResponseReceivedEventArgs args)


    lock (this)


    if (connected == false) return; //ignore spurious event

    ResponseReceivedEventArgs respArgs = args as ResponseReceivedEventArgs;

    if (respArgs != null)


    Response response = respArgs.Response;

    Request request = respArgs.ClientTransaction.ServerTransaction.Request;

    Debug.Assert(response != null && request != null);

    if (CanShow(response.StatusClass) && CanShow(request.StandardMethod))


    DisplayResponse(response, respArgs.Parameters);




    // Else Ignore notifications.



    The third event handler for notification is generally not needed (by design sipsnoop skips notifications), so You are done.


    For sure, maybe there is a more simple fix - I don't now. But this way sipsnoop is running...



    Thursday, September 25, 2008 2:38 AM