It is not legal to repeat the SDP answer in a subsequent reliable 18x. Technically this should be treated as a new offer. However that flow that flow is highly discouraged. Subsequent offer/answer exchanges are recommended to be done via UPDATE messaging instead.
Here are comments from the MasterProfile header file about the UAC PRACK support:
// UAC PRACK support. UPDATE must be enabled(currently defaults to on, do
// not disable w/out disabling UAC PRACK support).
//
// Flows where an an answer is received in a 180rel and subsequent O/A
// exchanges using UPDATE occur in the early dialog
// have been tested.
//
// A subsequent O/A exchange using 180rel/PRACK is also supported. This is
// a really bad idea, as an answer must be generated; the offer cannot be
// rejected. UPDATE should always be used for O/A exchanges once the
// dialog is established.
//
// Invite/18x(offer)/PRACK(ans) also works
//
// Invite(offer)/18x(ans)/PRACK(offer)/200P(ans) issupported, but not recommended.
// The UAC MUST call provideOffer from the onAnswer callback in order to generate
// the offer in the PRACK.
//
// Explicit limitations are:
// - Overlapping reliable provisional responses that contain a body are not
// handled.
//
// Note: Using SupportedEssential is exactly the same as using Supported,
// SupportedEssential only effects UAS Prack implementation
All that being said - the text doesn't seem to indicate explicitly that your scenario isn't support (assuming the 2nd reliable 183 SDP is treated as a new offer) - it is just discouraged. If this is the case I suspect you can pin point the issue in the code, by following the log file output and the code logic in ClientInviteSession to track down exactly what is happening (hint: look at dispatchEarlyWithAnswer). If indeed the 2nd 183 is not intended to be a new offer, then I would say your scenario is invalid.