Forum Discussion
daviddaoud2_205
Nimbostratus
NimbostratusBUG in iRule with SIP messages
Hello,
I have found what looks like a "bug" in the use of iRules to modify SIP messages and redirect them. Here is the thing:
My code looks like:
when SIP_REQUEST {
if { ( [SIP::method] equals "INFO" ) } {
log local0. " INFO IS HERE "
node 1.2.3.4 5060
}
The goal is simply to redirect the INFO messages to 1.2.3.4 (I could use the command pool, it's the same!). I can see in the log "INFO IS HERE", I can even modify headers for the INFO messages BUT the message is NOT redirected !
Why? Probably because there is some kind of SIP Persistence that forces the decision of the BIG-IP. This latter probably thinks: ' with this call-id I should send it to this server'.
However I havent configured any SIP persistence but just a simple SIP Profile (all options disabled).
Do you have a clue how to change this and provok the REDIRECTION of the messages?
Thanks a lot, I'm really stuck here!
Cheers,
David
11 Replies
hoolioCirrostratus
Hi David,
Going back to your last post on this (Click here), did your last rule work for your requirements? Do you have address translation enabled on the VIP? It seems like there is a requirement to have address and/or port translation enabled on the VIP if you want to specify a new destination IP and/or port. This seems fairly logical, but not something I expected at first in your last post.
Aaron- hoolioOr... maybe what you're running into is the default UDP packet handling? If you enable 'Datagram LB' on the UDP profile, does it resolve the issue?
SOL3605: Configuring the BIG-IP system to load balance UDP packets individually
https://support.f5.com/kb/en-us/solutions/public/3000/600/sol3605.html?sr=811334
Aaron 
daviddaoud2_205Yes, the iRule worked: the problem was that when the option ADDRESS TRANSLATION was not activated, the new destination address wasnt changed by the BIG-IP.
It works fine now with AT and port translation activated.
But some messages are not redirected. In my example I receive am INFO SIP message whose URI is 123@1.1.1.1
I dont want to send it to 1.1.1.1 but to 1.2.3.4 (on port 5060) ... and as I told you the command pool or node
has no effect!
The INFO still goes to 1.1.1.1 instead of 1.2.3.4.
I don't know how to change this.- daviddaoud2_205hmm sorry I didnt see your last post. Im using the Protocole Profile : UDP (default one).
Let me try this and I get back to you in a minute.
David - daviddaoud2_205piew ... you are excellent man! You just solved my problem.
Thanks a lot,
it works fine with Diagram LB activated. I wouldnt have found it by myself! Thx again!
David - daviddaoud2_205A last question:
Is there a way to modify SIP RESPONSES?
It seems like the commands such as SIP::header remove
work only on SIP requests.
Is there a way to make them work on the RESPONSES too? - hoolioI would guess SIP::header should work on both requests and responses, but I've never tested it. Can you post the code from the SIP_RESPONSE event in your rule? Do you see any errors in /var/log/ltm when the event is triggered? If you add a debug log line, do you see it logged?
Aaron - daviddaoud2_205when SIP_RESPONSE {
if { [SIP::header Via] contains "192.168.113.99" } {
log local0. " 200 OK coming from MGW to the module"
SIP::header remove "To"
SIP::header insert "To" ""
}
I can see the log message but none modifications are done. - daviddaoud2_205Hey hoolio,
please rescue me a second time!
I don't find a way to modify SIP responses.
Any idea ?
Cheers,
David. - hoolioHi David,
Can you post your VIP configuration by running 'b virtual VIP_NAME list'?
Thanks,
Aaron
