none
[MS-RDPRFX] - Forcing a RemoteFX-only RDP session RRS feed

  • Question

  • Hi,

     

    I am Marc-Andre from the FreeRDP project. We recently got a RemoteFX software decoder contributed, which needs further optimizations, but still works. I've been looking at RemoteFX, the way it is different from messages sent by older versions of the protocol, and I thought that it would actually be trivial to save RemoteFX messages to a file in order to be played at a later time. With few efforts, one could make a program to record RDP sessions, and it would be tremendously easier than saving the older RDP graphical messages which are loosely based on GDI.

     

    However, from my experimentation, it appears that even if RemoteFX is negotiated, the server keeps sending older RDP graphical messages along with RemoteFX messages. Most messages are RemoteFX, but some graphical messages are still sent using GDI, probably for performance reasons. If I want to experiment trying to record an RDP session, getting those GDI messages are a problem, because they add a lot of complexity to get the feature right without that much value.

     

    I would like to know: would there be a way to force the RDP server into sending *only* RemoteFX graphical messages, without any of the GDI messages? This way, all that would need to be done is to save the data to a file and decode it later, instead of saving the GDI messages as well which are much more work to handle. If it cannot be negotiated by the client, and needs to be configured on the server manually, I wouldn't mind, it would still be great experiment to try.

     

    Best regards,

    - Marc-Andre

    Monday, June 6, 2011 4:30 PM

Answers

  • Hi Marc-Andre:

    We have finished our investigation on mixed encoding in RemoteFx.

    Please make sure that captureFlags in TS_RFX_CLNT_CAPS_CONTAINER structure is not set to CARDP_CAPS_CAPTURE_NON_CAC (0x00000001). As explained in section 2.2.1.1 of MS-RDPRFX, setting captureFlag to CARDP_CAPS_CAPTURE_NON_CAC maens that client supports mixing RemoteFx data with data compressed by other codec.

     

    Please let me know if this resolves your issue.


    Regards, Obaid Farooqi
    Wednesday, June 8, 2011 3:59 PM
    Owner

All replies

  • Hi Marc-Andre,

    Thank you for your question regarding MS-RDPRFX and RemoteFX vs GDI messages.  One of the Open Specifications team members will contact you shortly to start working with you.

    Best regards,
    Tom Jebo
    Escalation Engineer
    Microsoft Open Specifications

    Monday, June 6, 2011 5:12 PM
  • Hi Marc-Andre:

    I'll help you with this issue and would be in touch as soon as I have an answer through this thread.


    Regards, Obaid Farooqi
    Tuesday, June 7, 2011 5:56 AM
    Owner
  • Hi Marc-Andre:

    Can you please let me know the value of flags you are sending in TS_RFX_ICAP structure?


    Regards, Obaid Farooqi
    Tuesday, June 7, 2011 6:19 AM
    Owner
  • Hi Marc-Andre:

    We have finished our investigation on mixed encoding in RemoteFx.

    Please make sure that captureFlags in TS_RFX_CLNT_CAPS_CONTAINER structure is not set to CARDP_CAPS_CAPTURE_NON_CAC (0x00000001). As explained in section 2.2.1.1 of MS-RDPRFX, setting captureFlag to CARDP_CAPS_CAPTURE_NON_CAC maens that client supports mixing RemoteFx data with data compressed by other codec.

     

    Please let me know if this resolves your issue.


    Regards, Obaid Farooqi
    Wednesday, June 8, 2011 3:59 PM
    Owner
  • Hi Marc-Andre:

    Please let me know if my answer resolved your issue.


    Regards, Obaid Farooqi
    Thursday, June 16, 2011 4:11 PM
    Owner
  • Hi Obaid,

     

    Sorry for the late reply! I have been very busy with FreeRDP. Thank you for taking the time to investigate this, I didn't know there was a flag that could be used to force a RemoteFX-only session. I had noticed that sometimes I could get GDI messages while in RemoteFX, but I didn't know those could disabled with a flag.

     

    This answers my question, thank you :)

    Thursday, July 14, 2011 5:07 PM