Wrong IP in VIA header after session roll over

[skb007]

1. Brekeke Product Name and Version:BSS Adver Ver 3.8.6.4/501

2. Java version:1.8.201

3. OS type and the version: RHEL7.7

4. UA (phone), gateway or other hardware/software involved:NA

5. Your problem:
I have following 3 IP's configured on the server.

10.20.30.29 (SIP)
10.20.30.30 (SIP)
10.20.30.62 (RTP)

Matching Patterns

$request = ^INVITE $addr = 192.168.10.10$ To = sip:123456(.+)@ From = sip:(.+)@

Deploy Patterns

To = sip:%1@1.1.1.1 From = sip:+%2@10.20.30.30 $session = failover sip:%1@2.2.2.2 %1@3.3.3.3 $b2bua = true $rtp = true $ifsrc = 10.20.30.30 $ifdst = 10.20.30.30 $replaceuri = true &net.sip.remove.displayname = true &net.rtp.ifsrc = 10.20.30.62 &net.rtp.ifdst = 10.20.30.62 &net.rtp.bindsrc = 10.20.30.62 &net.rtp.binddst = 10.20.30.62 &net.rtp.audio.payloadtype = 8

Everything works fine if call is completed by 1.1.1.1. VIA header has the ip address 10.20.30.30. But if call rolls over to 2.2.2.2 then via header contains 10.20.30.29 which is causing problem on the UAS side. Why VIA header IP gets switched from 10.20.30.30 to 10.20.30.29 after call fails over to second or third IP? Is there any solution?

[janP]

Are these destination IP addresses located in same network segment?

[skb007]

[skb007]

Anyone ?

[skb007]

I would appreciate if someone can help me to resolve this issue.
I have this issue at multiple BSS servers every time calls roll over on the BSS server having more than one IP.

[snuyzm]

This is because the SIP Server re-selects a destination side interface IP address.

If you use some tricks, you can avoid the issue.

Rule-1:

Matching Patterns

$request = ^INVITE $localhost = ^false $addr = 192.168.10.10$ To = sip:123456(.+)@ From = sip:(.+)@

Deploy Patterns

To = sip:%1@1.1.1.1 From = sip:+%2@10.20.30.30 $session = failover sip:a%1@localhost sip:b%1@localhost $b2bua = true $rtp = true $ifsrc = 10.20.30.30 $ifdst = 10.20.30.30 $replaceuri = true &net.sip.remove.displayname = true &net.rtp.ifsrc = 10.20.30.62 &net.rtp.ifdst = 10.20.30.62 &net.rtp.bindsrc = 10.20.30.62 &net.rtp.binddst = 10.20.30.62 &net.rtp.audio.payloadtype = 8

Rule-2:

Matching Patterns

$request = ^INVITE $localhost = ^true To = sip:a(.+)@ From = sip:(.+)@

Deploy Patterns

To = sip:%1@2.2.2.2 From = sip:+%2@10.20.30.30 $b2bua = true $rtp = false $ifsrc = 10.20.30.30 $ifdst = 10.20.30.30 $replaceuri = true &net.sip.remove.displayname = true &net.rtp.ifsrc = 10.20.30.62 &net.rtp.ifdst = 10.20.30.62 &net.rtp.bindsrc = 10.20.30.62 &net.rtp.binddst = 10.20.30.62 &net.rtp.audio.payloadtype = 8

Rule-3:

Matching Patterns

$request = ^INVITE $localhost = ^true To = sip:b(.+)@ From = sip:(.+)@

Deploy Patterns

To = sip:%1@3.3.3.3 From = sip:+%2@10.20.30.30 $b2bua = true $rtp = false $ifsrc = 10.20.30.30 $ifdst = 10.20.30.30 $replaceuri = true &net.sip.remove.displayname = true &net.rtp.ifsrc = 10.20.30.62 &net.rtp.ifdst = 10.20.30.62 &net.rtp.bindsrc = 10.20.30.62 &net.rtp.binddst = 10.20.30.62 &net.rtp.audio.payloadtype = 8

The line below puts an INVITE packet in DialPlan again to execute Rule-2 and Rule-3.
$session = failover sip:a%1@localhost sip:b%1@localhost

[skb007]

Appreciate your response.

Does that mean that for every dial plan, I have to write 2 more dial plans?

I have BSS installed at 4 different locations with 100 plus dial plans at each site.

Can this be classified as a bug and fixed in the future release?

[snuyzm]

I think there are several ways to avoid the issue without having many DialPlan rules.

Let you contact Brekeke's support to report the issue.