How to set up dual NICs with pjsip?

FreePBX Configuration
21

Does require an asterisk restart, AFAIK

1 Like
22

So after making the changes as per billiimon’s instructions, I’ve got some good news and bad news.

The good news is that after restarting the asterisk service, SOME things have improved. I can confirm via “lsof -ni” that the asterisk daemon is indeed now listening to udp&tcp port 5060 on the ip addresses individually, and not “just” to 0.0.0.0 as before. And I (kind of, sort of) managed to get a working audio call while my iphone’s groundwire sip client was logged in to the eth1’s ip address.

The bad news is that it is still in an unusable state, and I again do not know where or how to proceed further. Any advice would be muchly appreciated.

To answer another question elsewhere in the thread as to “why”, I cannot get into that beyond that my situation requires it. My situation may be unusual but is not unique; for example consider the circumstances required in an ip address migration. All these things need to happen at the same time: 1. the pbx cannot have any downtime (beyond that entailed in installing the eth1 device). 2. The client sip devices are geographically widespread, and generally don’t have remote-access capabilities, and must be migrated to the new server individually.

So there are four scenarios that I can test with my groundwire client:

  1. Connect to eth0’s ip on the pbx with udp for sip transport
  • pbx reports “Endpoint XXX is now Reachable”
  • calls can be made in/out of the extension with bidirectional audio
  1. Connect to eth0’s ip on the pbx with tcp for sip transport
  • pbx reports “Endpoint XXX is now Reachable”
  • calls can be made in/out of the extension with bidirectional audio
  1. Connect to eth1’s ip on the pbx with udp for sip transport
  • pbx reports “Endpoint XXX is now Unreachable”
  • outbound call worked with bidirectional audio; but upon remote “hangup” my extension did not know
  • inbound call went straight to voicemail, as the extension was unavailable
  1. Connect to eth1’s ip on the pbx with tcp for sip transport
  • pbx reports “Endpoint XXX is now Reachable”
  • outbound call connected, but no audio
  • inbound call connected, but no audio
  • upon remote “hangup” my extension was informed and knew the call was disconnected
23

Could you post the contents of the /etc/asterisk/pjsip.transports.conf file? (mask your public IPs)

24

with XXX.XX.XXX.ip = ip address of the eth0, and XXX.XX.XXX.sn being its subnet
YYY.YY.YYY.ip = ip address of eth1, and YYY.YY.YYY.sn being its subnet

(stripped out the “this is autogenerated” comments from the top)

#include pjsip.transports_custom.conf

[XXX.XX.XXX.ip-udp]
type=transport
protocol=udp
bind=XXX.XX.XXX.ip
allow_reload=no
tos=cs3
cos=3
local_net=XXX.XX.XXX.sn/28
local_net=YYY.YY.YYY.sn/27

[YYY.YY.YYY.ip-udp]
type=transport
protocol=udp
bind=YYY.YY.YYY.ip
allow_reload=no
tos=cs3
cos=3
local_net=XXX.XX.XXX.sn/28
local_net=YYY.YY.YYY.sn/27

[XXX.XX.XXX.ip-tcp]
type=transport
protocol=tcp
bind=XXX.XX.XXX.ip
allow_reload=no
tos=cs3
cos=3
local_net=XXX.XX.XXX.sn/28
local_net=YYY.YY.YYY.sn/27

[YYY.YY.YYY.ip-tcp]
type=transport
protocol=tcp
bind=YYY.YY.YYY.ip
allow_reload=no
tos=cs3
cos=3
local_net=XXX.XX.XXX.sn/28
local_net=YYY.YY.YYY.sn/27
25

Asterisk logs and SIP would be helpful too.

Back to “what do you see in sngrep?”

In your Extension settings, Advanced tab, transport should be set to “Auto”

26

I haven’t (yet) collected the syslog files (sadly time is short, and there are other “higher priority” tasks being foisted upon me), but I will say this about the setup:

This is LITERALLY a base setup of Freepbx, with all extensions set as pjsip, with default settings for all. I’ve only made two “weird” things here:

  1. this is mostly irrelevant, but my manager had mandated “tcp” be avaialble for sip, so that was enabled for pjsip
  2. as linux does not otherwise support dual-nic “real world” ip addresses, I’ve got (as detailed above) the original ip address on eth0, and the new ip address on eth1 using the very few commands shown above for the source routing.

I’ve now also added in the other bits for pjsip to listen on the second interface, which DID indeed have some improvement in functionality, but not enough to actually be usable.

I will say that when I was watching the “full” log file as the calls were done live, everything LOOKED normal, that it was working – except for the case with total silence, and the case where the sip client was neither showing as logged in, nor was it getting sip progress updates (ie. when the remote end disconnected).

27

Linux supports Border Gateway Protocol, so not only does it support multiple public addresses, but it can do so in a true multi-homed configuration. You can also do lots of non-standard things with routing tables.

I think you mean source based routing. Linux can do true source routing, but it is normally considered a security risk and is disabled by default:

root@dhcppc4:/proc/sys/net/ipv4/conf/all# cat accept_source_route
0
28

I’m not saying you’ve messed anything up. We just need more to review. If the logs looked “normal” then I think the evidence is in the SIP traces. Now that you have separated out the interfaces in the PJSIP config the questions I have are as follows:

  • does traffic arriving on eth0 get responded to with the correct eth0 IP in the SIP reply–in the headers and SDP both?
  • does that response get routed out eth0?
  • same two questions for eth1

You can narrow your view with sngrep by telling it only to monitor one network interface (check the man page; I forget the parameter).

29

Some minor progress, but not quite enough to fully solve my problem. (ie. the tcp transport for sip had been enabled on this system for a reason, and that’s still dysfunctional.)

I noted that with “asterisk -rx 'pjsip show endpoint '” there are these entries:

bind_rtp_to_media_address : true
media_address :
transport : <blank, aka “Auto”>

Looking at the extension’s pjsip “Advanced” tab, the “Transport” option is a pulldown, that lets me manually select from five options:

  • Auto (the default)
  • ip.of.eth0-udp
  • ip.of.eth1-udp
  • ip.of.eth0-tcp
  • ip.of.eth1-tcp

Manually switching between to ip.of.eth1-udp got the extension to be fully functional, as in calls could be made with bidirectional audio, and the sip client was properly notified when the other extension hung up.

So this PARTIALLY helps me out, although it’s decidedly creating more work with personal interventions needed per-extension as they migrate.

And it decidedly still DOES NOT work properly with tcp sip transport on eth1.

I note that no matter how I change that “Transport” option here, the "pjsip show endpoint " never ever changes its “media_address” from the ip on eth0. The option “Media Use Received Transport” apparently does nothing.

30

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.