Ok no problem.
May be it wouldbe easier if you update your version to
current CVS HEAD?

If you have other modifications in your own tree
I invite you to submit a patch (with explanation)
this way we may merge your modifications to the mainline.

Hi Zhen,

I'm not sure to understand your bug.
In current CVS RTIA_network we have:
case NetworkMessage::START_REGISTRATION_FOR_OBJECT_CLASS:
      D.Out(pdTrace, "Receiving Message from RTIG, "
      " type StartRegForObjClass.");
      queues->insertLastCommand(msg);
  break;

thus the "START_REGISTRATION_FOR_OBJECT_CLASS" is inserted
in the command queue of RTIA.

Then "some times" later when the federate issue a "tick"
call a command message may be poped from this queue
by the TimeManagement:

bool
TimeManagement::tick(TypeException &e)
{
    bool msg_donne = false ;
    bool msg_restant = false ;
    NetworkMessage *msg = NULL ;

    G.Out(pdGendoc," enter TimeManagement::tick");
    // Note: While msg_donne = RTI::RTI_FALSE, msg_restant doesn't matter.

    // 1st try, give a command message. (requestPause, etc.)
    msg = queues->giveCommandMessage(msg_donne, msg_restant);

[..]

then the "command" message will trigger
a RTIA-->Federate "service" callback

executeFederateService(*msg);

which will

case NetworkMessage::START_REGISTRATION_FOR_OBJECT_CLASS: {
      NM_Start_Registration_For_Object_Class& SRFOC = static_cast<NM_Start_Registration_For_Object_Class&>(msg);
dm->startRegistrationForObjectClass(SRFOC.getObjectClass(), msg.getRefException());
      }

"dm" being a DeclarationManagement instance
which will send a "M_Start_Registration_For_Object_Class"
message back to libRTI which will call the appropriate
callback when inside a tick.

The code looks good?
But may be I'm wrong, could you give us a test case?