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

skb007 · Post by **skb007** » Thu Sep 27, 2018 9:25 am

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>

skb007 · Post by **skb007** » Thu Sep 27, 2018 9:27 am

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

redroof · Post by **redroof** » Thu Sep 27, 2018 11:04 am

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

skb007 · Post by **skb007** » Thu Sep 27, 2018 11:17 am

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)

redroof · Post by **redroof** » Thu Sep 27, 2018 1:07 pm

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

Try $replaceuri = true

skb007 · Post by **skb007** » Thu Sep 27, 2018 1:13 pm

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.

redroof · Post by **redroof** » Thu Sep 27, 2018 2:34 pm

Put this in Deploy Patterns

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

skb007 · Post by **skb007** » Thu Sep 27, 2018 3:52 pm

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

redroof · Post by **redroof** » Thu Sep 27, 2018 4:19 pm

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

skb007 · Post by **skb007** » Fri Sep 28, 2018 9:02 am

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

Tata · Post by **Tata** » Fri Sep 28, 2018 9:36 am

It will be combination of your settings..

skb007 · Post by **skb007** » Fri Sep 28, 2018 10:15 am

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

Thanks in advance.

Tata · Post by **Tata** » Fri Sep 28, 2018 10:27 am

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

skb007 · Post by **skb007** » Fri Sep 28, 2018 10:53 am

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

redroof · Post by **redroof** » Fri Sep 28, 2018 11:07 am

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.

skb007 · Post by **skb007** » Fri Sep 28, 2018 11:12 am

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.

redroof · Post by **redroof** » Fri Sep 28, 2018 11:21 am

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.

skb007 · Post by **skb007** » Fri Sep 28, 2018 12:35 pm

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

skb007 · Post by **skb007** » Mon Oct 15, 2018 9:43 am

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>

Tata · Post by **Tata** » Tue Oct 16, 2018 10:11 am

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

skb007 · Post by **skb007** » Tue Oct 16, 2018 1:39 pm

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.

james · Post by **james** » Wed Oct 17, 2018 4:28 pm

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

rwilliams · Post by **rwilliams** » Tue Oct 30, 2018 9:26 am

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

That works!