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

[skb007]

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]

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]

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

[skb007]

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]

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

Try $replaceuri = true

[skb007]

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]

Put this in Deploy Patterns

Deploy Patterns

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

[skb007]

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

[redroof]

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

[skb007]

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

[Tata]

It will be combination of your settings..

[skb007]

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]

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

[skb007]

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.1 --> 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]

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]

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]

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]

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]

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]

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

[skb007]

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]

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

[rwilliams]