b2b is true but leg-b still shows the ip address of leg-a

1. Brekeke Product Name and Version:BSS 3.8.6.4/501 Adv Ed

2. Java version:1.80

3. OS type and the version:RHEL7

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

5. Your problem:

$b2b is true but leg-b still shows the ip address of leg-a in the FROM header.

Matching Patterns
$addr = 192.168.2.10
$request = ^INVITE


Deploy Patterns
To/uri = sip:9999@10.1.1.10
$b2bua = true
$rtp = false
$ifsrc = 192.168.10.10
$ifdst = 192.168.10.11

UAC IP : 192.168.2.5
BSS IP : 192.168.2.10,192.168.2.11
UAS IP :10.1.1.10

Call Flow:
UAC(192.168.2.5) --> BSS(192.168.2.10--192.168.2.11)-->10.1.1.10


DialPlan-History-IncomingPacket
NVITE sip:1111@192.168.2.10:5060 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.5
To: 1111<sip:1111@192.168.2.10:5060>
From: 8440<sip:8440@192.168.2.5:5060>;tag=6662015801470
Call-ID: 8393840.340@192.168.2.5
Contact: 8440<sip:8440@192.168.2.5:5060>

DialPlan-History-OutgoingPacket
INVITE sip:9999@10.1.1.10 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.11;branch=z9hG4bK6580c53ede78-56110f4b-1959f8
To: "1111" <sip:9999@10.1.1.10>
From: "8440" <sip:8440@192.168.2.5:5060>;tag=b2486bc76s
Call-ID: 7b433783-867a8b75-94c6601a-6987f5bc
Contact: 8440<sip:8440@192.168.2.11>

Same dial plan shows desirable results in my lab where I have installed the trial version of BSS Adv Ed - 3.8.5.2/493-3

Put "$replaceuri.from = true" in the Deploy Patterns.

I did put $replaceuri.from = true in the deploy pattern and I am getting following error:


Rule@1 [ROUTE]: Error: Deploy Pattern class is not found (2): replaceuri

Dispatcher.1: Exception: 09/27/18 19:13:33.871
com.brekeke.net.sip.sv.rule.RuleSyntaxException: Deploy Pattern class is not found (2): replaceuri: (depth=6)
com.brekeke.net.sip.sv.rule.RuleMatch.execDeployPlugin (null:-1)
com.brekeke.net.sip.sv.rule.RuleMatch.dispatchVariable (null:-1)
com.brekeke.net.sip.sv.rule.RuleMatch.<init> (null:-1)
com.brekeke.net.sip.sv.rule.RuleTable.evalRule (null:-1)
com.brekeke.net.sip.sv.rule.RuleTable.getMatch (null:-1)
com.brekeke.net.sip.sv.Dispatcher.run (null:-1)

Sorry.. because it depends on the version of Brekeke SIP Server.

Try $replaceuri = true

I tried it, error is fixed but original problem is still not resolved. FROM header of leg-b is still showing the IP address of leg-a.

Your quick response would be much appreciated.

Thanks in advance.

Put this in Deploy Patterns

Deploy Patterns
From/uri = sip:%{$getSIPuser(From)}@192.168.10.11

This is working, but why do we have to go through this trouble. in b2b mode, it should have automatically done it.

There are several conditions.
Is the UAC registered in the Brekeke SIP Server?
If so, Brekeke SIP Server replaces From-URI automatically.

No UAC is not registered. We do not see this problem in BSS 3.8.5.2.

It will be combination of your settings..

I compared the settings between the 2 servers and everything is same. Is there any particular setting I should look for?

Thanks in advance.

Can you paste both Incoming and Outgoing packets what BSS v3.8.5.2 processed ?

Here is the lab setup which shows the correct IP on the outgoing side.


UAC IP : 192.168.2.18
BSS IP : 192.168.2.156,192.168.2.157
UAS IP :192.168.2.13

Call Flow:
UAC(192.168.2.18) --> BSS(192.168.2.156 --192.168.2.157)-->192.168.2.13


DialPlan-History-IncomingPacket
INVITE sip:5555@192.168.2.156:5060;user=phone;key1=value1 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.18:5060;branch=branch1991311765
From: CALLING_PARTY <sip:1111@192.168.2.18:5060;user=phone>;tag=19913SIPpTag0011765
To: CALLED_PARTY <sip:5555@192.168.2.156:5060;user=phone;key1=value1>
Call-ID: 11765-19913@192.168.2.18


DialPlan-History-OutgoingPacket
INVITE sip:9999@192.168.2.13;user=phone;key1=value1 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.157;branch=z9hG4bK7f61179bc6e0-30-1a860b
From: "CALLING_PARTY" <sip:1111@192.168.2.157;user=phone>;tag=bc2e5ff3es
To: "9999" <sip:9999@192.168.2.13;key1=value1;user=phone>
Call-ID: e1344569-d3ebc218-564e908a-ff34dc8c

In your first post, why did you set "$addr=192.168.2.10" in the Matching Patterns?

Because 192.168.2.10 is one of BSS's interface addresses, $addr must be 192.168.2.5, UAC's IP address.
$addr = 192.168.2.5

If you have $addr=192.168.2.10, the DialPlan rule doesn't work.

You are correct ,it was a typing mistake. Actually,192.168.2.5 is in the dial plan. I made a mistake while typing in the forum.

I tested your DialPlan rule in my BSS 3.8.5.2 and I confirmed that the From-URI is NOT replaced without tuning the rule.
It means 3.8.6.4 and 3.8.5.2 are same in this case.

If you paste all of your DialPlan rules you set at 3.8.5.2, I can look at them.

I am sending you all the dial plans configured in my lab.

UAC IP : 192.168.2.18
BSS IP : 192.168.2.156,192.168.2.157
UAS IP :192.168.2.13




Rule-1 : LOG

Matching Patterns
$request = ^INVITE
$rule.sps = (.+)


Deploy Patterns
$log = DIAG:%{$date} %{$time},"BREKEKE",%1,%{$sessionNum}
$continue = true


Rule-2 : ROUTE

Matching Patterns
$addr = ^192.168.2.18$
$request = ^INVITE

Deploy Patterns
To/uri = sip:9999@192.168.2.13
$b2bua = true
$rtp = false
$ifsrc = 192.168.2.156
$ifdst = 192.168.2.157

Rule-3: REJECT

Matching Patterns
$request = ^INVITE

Deploy Patterns
$action = 503




DialPlan-History-IncomingPacket
INVITE sip:5555@192.168.2.156:5060;user=phone;key1=value1 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.18:5060;branch=branch217641
From: CALLING_PARTY <sip:1111@192.168.2.18:5060;user=phone>;tag=21764SIPpTag001
To: CALLED_PARTY <sip:5555@192.168.2.156:5060;user=phone;key1=value1>
Call-ID: 1-21764@192.168.2.18

DialPlan-History-OutgoingPacket
INVITE sip:9999@192.168.2.13;user=phone;key1=value1 SIP/2.0
Via: SIP/2.0/UDP 192.168.2.157;branch=z9hG4bK7bd73f544d0e-30-1a7c9f
From: "CALLING_PARTY" <sip:1111@192.168.2.157;user=phone>;tag=b6d98a667s
To: "CALLED_PARTY" <sip:9999@192.168.2.13;key1=value1;user=phone>
Call-ID: 7c69542b-651ed716-12feae88-8440d3b6

We are also facing an issue where SIP:CONTACT header from leg-B is being passed onto leg-A. I would appreciate if someone can look into this and provide us a resolution.

UAS is responding with 180 to BSS INVITE as following

Contact: 9999 <sip:+9999@192.168.2.13:5060;transport=udp>

BSS is sending 180 back to UAC with CONTACT header as
Contact: 9999 <sip:9999@192.168.2.156:5060;transport=udp>

The correct Contact header should be
Contact: 5555 <sip:5555@192.168.2.156:5060;transport=udp>

Why do you expect 5555 even though UAS sends +9999?

In B2B mode, SIP proxy is maintaining TO/FROM headers separately on each leg, we are expecting it to do the same for other headers such as CONTACT.

You can replace a response's Contact header with desired value by DialPan.

james wrote:You can replace a response's Contact header with desired value by DialPan.

That works!