CSS UDP source group sticky problem

[scain]

I have a CSS 11503 that we use to balance SIP calls(UDP) among our SIP servers.

We have a content rule that balances the incoming traffic and a source group to NAT the outbound traffic. Both the content rule and the source group use the same IP address.

When a SIP call arrives at one of our servers through the VIP an entry is created in the sticky table based on the sip-call-id as expected. But when we initiate a call from one of our SIP servers an entry is not created in the sticky table. When the remote SIP server responds the CSS sees a new sip-call-id and load balances the call instead of sending it back to the originating server.

Is there a way to add an entry to the sticky table for the sip-call-id when a source group is used?

Here is the pertinent config:

circuit VLAN2

  ip address 10.10.1.3 255.255.255.0

    ip virtual-router 25

    ip redundant-interface 25 10.10.1.1

    ip redundant-vip 25 10.10.1.233

    no redirects

circuit VLAN3

  ip address 10.10.2.3 255.255.255.0

    ip virtual-router 52

    ip redundant-interface 52 10.10.2.1

    no redirects

service SIP03

  ip address 10.10.2.233

  redundant-index 130

  active

service SIP08

  ip address 10.10.2.238

  redundant-index 180

owner test

  content sip-udp-test

    application sip

    port 5060

    protocol udp

    flow-timeout-multiplier 38

    vip address 10.10.1.233

    redundant-index 103

    balance weightedrr

    add service TalkingSIP03 weight 1

    add service TalkingSIP08 weight 1

    advanced-balance sip-call-id

    active

!*************************** GROUP ***************************

group sip-udp-test

  vip address 10.10.1.233

  flow-timeout-multiplier 38

  redundant-index 200

  add service SIP03

  add service SIP08

  portmap disable

A call comes into 10.10.1.233 on udp 5060, is load balanced to 10.10.2.233(SIP03), and an entry is added to the sticky-table for the sip-call-id.

When SIP03 starts a call to remote server 1.1.1.1 using source group IP 10.10.1.233 a sticky-table entry is not added for the sip-call-id and when 1.1.1.1 sends a response it is load balanced to either SIP03 or SIP08.

How can I keep the call that was initiated on SIP03 on SIP03?

Thanks,

Steven

[chrhiggi]

Steven-

  The "vip address" on your content rule is what matches the inbound traffic.  Your outbound traffic is initiated to 1.1.1.1 which is not a vip ip, hence, it doesn't match the content rule.  On the reverse - the response is mapping to a vip ip since the source was the natpool.  I would assume that 1.1.1.1 server already had a connection through the vip and/or something changed slightly about the flow that classified it as a new inbound connection instead of re-mapping back through the sourcenat pool. 

Chris

[scain]

I think this problem is unique to UDP.

I assume there is an existing flow with the sourcenat when 1.1.1.1 responds. Is there a way get the CSS to use the flow in this instance instead of load balancing?