How to use irules to do SIP outbounding proxy?

here is something that helped me:

 

when SIP_REQUEST {

 

pool mypool

 

set id "[persist lookup sip [SIP::call_id]]"

 

log local0.alert "ID found in lookup is: $id"

 

if { [llength $id] } {

 

log local0.alert "In if select pool"

 

return

 

}

 

set id "[SIP::call_id] any virtual"

 

set sessionInfo [session lookup uie $id]

 

log local0.alert "Session information found is: $sessionInfo"

 

if { [llength $sessionInfo] } {

 

log local0.alert "Choosing member acording to session info"

 

pool mypool member $sessionInfo

 

}

 

}

Has anyone successfully gotten this to work? If so, can you post your solution, please?

I am trying to achieve SIP session based load balancing using LTM while server is acting as B2BUA.

 

The call flow that I would like to load balance is as following:

 

a. client A sends SIP request to LTM. LTM picks up Server X to forward request to.

 

b. Server X forwards request back to LTM to deliver SIP request to client B.

 

c. Client B send SIP response to LTM. LTM need to forward thus received SIP response to Server X.

 

d. Server X forwards back SIP response to LTM to deliver SIP response to client A.

 

Similarly, when a new SIP request is initiated by Client B then LTM forwards it to Server Y (based on least connections being used) and rest of call flow is same as above.

 

I started of trying to achieve the above call flow by using the iRules provided by you. I added couple of iRules for SIP_RESPONSE event (very similar to your iRules for SIP_REQUEST event) for outgoing (to add to session) and in incoming (lookup for session).

 

But I am running into issues with handling of SIP_RESPONSE events:

 

a. I do not think SIP_RESPONSE event is invoked during outgoing. LTM seems to be dropping SIP response packet received from Server.

 

b. I see TCL error thrown by LTM while processing SIP_RESPONSE event invoked during incoming. But I do see the SIP response packet getting delivered to Server. Find below generated TCL error:

 

Prerequisite operation not in progress line 4 invoked from within session lookup uie [SIP::call_id] any virtual

Thanks Nat for your response. Your suggestion of checking for which side of context iRule help me understand what is happening a little more.

 

We are using version 9.4.6.

 

The incoming virtual server uses following two iRules:

 

sip_in

 

sip_in_2

 

The outgoing virtual server uses following two iRules:

 

sip_out

 

sip_out_2

 

Find below iRules mentioned above.

 

iRule sip_in:

 

when SIP_REQUEST {

 

pool sip

 

log local0. "clientside = [clientside]"

 

set id "[persist lookup sip [SIP::call_id]]"

 

log local0.alert "ID found in lookup is: $id"

 

if { [llength $id] } {

 

logic to use appropriate pool

 

pool sip

 

return

 

}

 

set id "[SIP::call_id] any virtual"

 

set sessionInfo [session lookup uie "[SIP::call_id] any virtual"]

 

logic to use appropriate pool

 

pool sip

 

return

 

}

 

iRule sip_in_2:

 

when SIP_RESPONSE {

 

pool sip

 

set clientside [clientside]

 

log local0. "clientside = [clientside]"

 

if { $clientside == 0 }

 

{

 

log local0. "call id: [SIP::call_id]"

 

log local0. "From: [SIP::from]"

 

log local0. "To: [SIP::to]"

 

log local0. "Method: [SIP::method]"

 

log local0. "Response: [SIP::response code] [SIP::response phrase]"

 

return

 

}

 

set abcd "[SIP::call_id] any virtual"

 

set id "[persist lookup sip $abcd]"

 

log local0.alert "ID found in persist lookup is: $id"

 

if { [llength $id] } {

 

logic to use appropriate pool

 

pool sip

 

return

 

}

 

set id "[SIP::call_id] any virtual"

 

set sessionInfo [session lookup uie "[SIP::call_id] any virtual"]

 

logic to use appropriate pool

 

pool sip

 

return

 

}

 

iRule sip_out:

 

when SIP_REQUEST {

 

pool sip

 

log local0. "clientside = [clientside]"

 

session add uie [SIP::call_id] [IP::client_addr] 3600

 

forward

 

}

 

iRule sip_out_2:

 

when SIP_RESPONSE {

 

pool sip

 

log local0. "clientside = [clientside]"

 

forward

 

}

 

After putting check for which side of context iRules is at the moment. I observed following:

 

a. When a new SIP request comes into LTM from Client 1. LTM uses sip_in iRule and forward it to Server instance 1.

 

b. Then Server processes on that SIP request for forward it to deliver to client 2 through LTM. At this point sip_out iRule is hit.

 

c. Then client 2 responds then sip_in_2 iRule is hit (with clientside context). Per sip_in_2 IRule LTM forwards thus received SIP response to Server instance 1.

 

d. Then Server processes on that SIP response and forward it to be delivered to client 1. At this point sip_in_2 iRule is hit (with serverside context!!!).

 

Can you help me understand why sip_in_2 is hit instead of sip_out_2 in d above?

one quick answer/guess about why sip_in_2 is hit is...

 

 

by default, BIG-IP create connection table for UDP traffic. and if return packet match existing connection table, bigip will treat that return packet as it belongs to previous created connection.

 

you may use packet trace to verify if 4-tuple match existing connection table or not.

 

use command line as examples below to see connection table

 

b conn

 

b conn show all

 

b conn client 1.2.3.4 show all

 

 

you may combine sip_in/sip_out irule together

 

or

 

you may try custom UDP profile with immediate timeout. in that case, bigip will not create connection table.

 

 

hope this helps,

 

Nat

Thanks Nat for your suggestion.

 

 

That make it work as desired for UDP.

 

 

In SIP transport protocol used could be either UDP or TCP. SIP stack switches transport mode from UDP to TCP when packet size is greater than MTU. Therefore, I have created virtual server for both UDP and TCP in both directions (incoming & outgoing).

 

 

After making custom UDP profile with immediate timeout I see all the packets hittng right iRule at the right time. But when sip stack switches transport mode from UDP to TCP, I observe recurrence of similar behvior in which sip_out_2 is bieng hit in serverside.

 

 

Is there some means to customize TCP profile to achieve the same effect.

you cannot use the same technique for TCP. I believe changing some SIP parameters on server may help. (I might be wrong)

 

 

May I ask more information

 

- does server is configured to use bigip as SIP proxy?

 

- does bigip snat traffic to server?

 

- what is destination IP in step d (packet from server to bigip?)

 

 

It would be great if you can post packet trace.

 

 

Thanks,

 

Nat