i-Rule for Diameter AVP realm rewrite on a virtual server

I asked about the version because the Diameter handling in 11.x is quite different than in 12.x. In 12.x, one uses the Message Routing Framework for Diameter traffic. However, the rule below should work for both 11.x and 12.x (though under 12.x, it must be applied both to the Message Routing Virtual Server and to the transport-config).

For this rule, I made a few assumption. Firstly, I assume that by "change the diameter realm", you mean "change the Origin-Realm" (rather than, say, the Destination-Realm, though if you need to do that instead of or in addition to the Origin-Realm, it is a simple change of the rule below). I further assume that in any message in your Diameter application, the Origin-Realm is present no more than once, and is never part of a grouped AVP.

when DIAMETER_EGRESS {                                                                                                                
    switch [DIAMETER::avp data get "Origin-Realm"] {                                                                                  
        "ims.mnc090.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc099.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
                                                                                                                                          
        "ims.mnc099.mcc100.3gppnetwork.org" {                                                                                         
            DIAMETER::avp data set "Origin-Realm" "ims.mnc090.mcc100.3gppnetwork.org"                                                 
        }                                                                                                                             
    }                                                                                                                                 
}            

As a somewhat important aside, under 11.x, the BIG-IP will act (more-or-less) as a Diameter proxy. However, unless you tell it to do so, it will not assert its own Origin-Host and Origin-Realm. It will also not pro-actively open transport and Diameter sessions toward pool members. Instead, when a client makes a connection to the Virtual Server and a Diameter message LB decision is made, if an existing Diameter connection is not open to the target pool member, a connection will be opened, and the client's Origin-Host and Origin-Realm will be used. When the pool member responds, it's Origin-Host and Origin-Realm will be asserted toward the client. However, the BIG-IP will maintain independent Diameter sessions on each side. Among other things, this means that watchdog messages are not proxied in any way.