1. Brekeke Product Name and Version: 3.x
2. Java version: 8.1
3. OS type and the version: Win Server 2k16
4. UA (phone), gateway or other hardware/software involved: N/A
5. Your problem:
We have servers with two NIC cards. Each NIC has two ports. We team the ports together so we have A team and B team.
USUALLY, A team is the public facing IP address (10.10.10.10 for example). B team is a private IP address (192.168.1.1) we use to create a UDP backplane so two servers can talk to each other.
What we have found is Microsoft will make its own decisions on outbound SIP requests sometimes, so instead of an Invite coming from 3175555555@10.10.10.10 it will come from @192.168.1.1.
So you can imagine when the outside world responds, it responds to 192.168.1.1 and the call fails.
This doesn't happen all the time on all the systems we send out, but when it does the ONLY thing we have ever found that fixes it is to take the network connections for A and B team and physically swap them, then swap the IP addresses for A and B team.
So, how do I set a dialing plan rule that if it sees and invite from @192.168.1.1 it goes out instead with @10.10.10.10?
This way, no matter what happens the SIP invite will always work and traffic goes to the public IP address.
I have several problems when trying to troubleshoot this myself.
1. I have no real testing system I can fully manipulate and run captures on to test my changes. What I do have is Brekeke SIP Proxy version 2.4.X on a computer I can literally NOT access except through a web browser.
2. The only thing I've ever managed to get sorted out with replacing pieces of an Invite is the outbound caller ID. I think I could change it up to make the IP change instead of the caller ID but I'd like to run it by somebody first.
This replaces a caller ID of ten zeroes with a real phone number:
[MATCHING PATTERN]
$request = ^INVITE
$getURI(From) = sip:(0000000000)@(.+)
Remote-Party-ID = (.+)@(.+)>(.+)
[DEPLOY PATTERN]
$b2bua = true
To = sip:%1@11.12.13.14 (outside Cisco PBX)
$replaceuri = true
Remote-Party-ID = "3175551234"<sip:3175551234@%2>;party=calling;screen=yes;privacy=off
So, what would happen if I made a new dialing plan rule that looked like this:
[MATCHING PATTERN]
$request = ^INVITE
$getURI(From) = sip:(.+)@(192.168.1.1)
Remote-Party-ID = (.+)@(.+)>(.+)
[DEPLOY PATTERN]
$b2bua = true
To = sip:%1@11.12.13.14 (outside Cisco PBX)
$replaceuri = true
Remote-Party-ID = <sip:(.+)@10.10.10.10>;party=calling;screen=yes;privacy=off
Would that cause the Invite to go out as though it's coming from 10.10.10.10 instead of 192.168.1.1?
And if so, is that enough to trick the system into sending responses back to the correct NIC?
Follow-up question is, if my original system is sending out Invites from the wrong IP address, will it even know what to do with the return messages if they hit the right NIC?
2. Java version: 8.1
3. OS type and the version: Win Server 2k16
4. UA (phone), gateway or other hardware/software involved: N/A
5. Your problem:
We have servers with two NIC cards. Each NIC has two ports. We team the ports together so we have A team and B team.
USUALLY, A team is the public facing IP address (10.10.10.10 for example). B team is a private IP address (192.168.1.1) we use to create a UDP backplane so two servers can talk to each other.
What we have found is Microsoft will make its own decisions on outbound SIP requests sometimes, so instead of an Invite coming from 3175555555@10.10.10.10 it will come from @192.168.1.1.
So you can imagine when the outside world responds, it responds to 192.168.1.1 and the call fails.
This doesn't happen all the time on all the systems we send out, but when it does the ONLY thing we have ever found that fixes it is to take the network connections for A and B team and physically swap them, then swap the IP addresses for A and B team.
So, how do I set a dialing plan rule that if it sees and invite from @192.168.1.1 it goes out instead with @10.10.10.10?
This way, no matter what happens the SIP invite will always work and traffic goes to the public IP address.
I have several problems when trying to troubleshoot this myself.
1. I have no real testing system I can fully manipulate and run captures on to test my changes. What I do have is Brekeke SIP Proxy version 2.4.X on a computer I can literally NOT access except through a web browser.
2. The only thing I've ever managed to get sorted out with replacing pieces of an Invite is the outbound caller ID. I think I could change it up to make the IP change instead of the caller ID but I'd like to run it by somebody first.
This replaces a caller ID of ten zeroes with a real phone number:
[MATCHING PATTERN]
$request = ^INVITE
$getURI(From) = sip:(0000000000)@(.+)
Remote-Party-ID = (.+)@(.+)>(.+)
[DEPLOY PATTERN]
$b2bua = true
To = sip:%1@11.12.13.14 (outside Cisco PBX)
$replaceuri = true
Remote-Party-ID = "3175551234"<sip:3175551234@%2>;party=calling;screen=yes;privacy=off
So, what would happen if I made a new dialing plan rule that looked like this:
[MATCHING PATTERN]
$request = ^INVITE
$getURI(From) = sip:(.+)@(192.168.1.1)
Remote-Party-ID = (.+)@(.+)>(.+)
[DEPLOY PATTERN]
$b2bua = true
To = sip:%1@11.12.13.14 (outside Cisco PBX)
$replaceuri = true
Remote-Party-ID = <sip:(.+)@10.10.10.10>;party=calling;screen=yes;privacy=off
Would that cause the Invite to go out as though it's coming from 10.10.10.10 instead of 192.168.1.1?
And if so, is that enough to trick the system into sending responses back to the correct NIC?
Follow-up question is, if my original system is sending out Invites from the wrong IP address, will it even know what to do with the return messages if they hit the right NIC?