Requirements:

At the beginning we thought we will not support Setup Failure, so we store the new RAN in RNIB even before communicating with Resource Manager. 
In a Phone call on the 12/04 we (Natalya, Idan and Avinoam) agree:

1. In case Setup Request arrives (either new one or existing one) - for any Setup Request - we are calling RM
2. If  RM responds OK - BAU - Upsert (Insert or Update) NodeB with connected & Functions and with E2T Instance, Add NodeB to E2T Instance array of supported NodeB, Return Setup Response
3. If RM fails (Not answering or Reject) - Upsert (Insert or Update) NodeB with Disconnected & Functions but clear E2T Instance, and return Setup Failure .

How we are sending Setup Failure? Not in the normal way, since the RMR file isn't updated with the new MEID. 

At first we thought Using rmr_rts_msg (See https://rancodev.atlassian.net/wiki/spaces/RICPLT/pages/60653833/RMr+--+Ric+Message+Routing+Library in the old Wiki):

• We are using the same RMR Message buffer that we received (Setup Request). in this buffer I think we have the IP / Port of the originating RAN.
• We are filling the XML with the mandatory Cause reason. I choose the CHOICE Cause Group = Transport Layer and the cause equal "Transport Resource Unavailable" 
• Fill the RMR of Setup Failure RMR is 12003 .
• Call rmr_rts_msg - E2T should map it to Setup Failure (Like the RMR).

 But Natalya is telling us we can't do it since the Buffer is already free. So we will use the "wormhole": - taken from RMR Wiki 

There is no way via RMr to determine which applications are "available". Message types which are defined to route to an instance of any application (as established by the route manager) are delivered by round robin with no explicit selection needed on the application's part. If a message must be sent back as a response, and thus must be delivered to the originator, the rmr_rts_msg() function (return to sender) can be used to ensure that the response is returned to the same endpoint that sent the message (the message payload, and message type may be updated by the application before sending). RMr supports direct sending to a specific endpoint through what it terms "wormholes." The user application must know the DNS name, or IP address and port of the endpoint; that is not something that RMr can supply. The rmr_wh_open() function is used to open a wormhole, and the rmr_wh_send_msg() function can be used to send messages on an open wormhole. For explicit details on these functions, I suggest that you install the dev package (see the link near the top of this page), and then you can use the standard UNIX man command to see the man pages for the RMr API functions.

E2 SETUP FAILURE

This message is sent by the near-RT RIC to indicate E2 Setup failure.

Direction: near-RT RIC ® E2 Node

 Acceptance

• Setup on new RAN, w/out RM - See RNIB is updated with new RAN, Status = Disconnect, see RTS_MSG (RMR) was called with the exact RMR (Setup Failure) message and appropriate Cause. See E2T sends the Setup Failure on the right SCTP
• See Setup while RM is up is behaving as Normal.