Box with 2 interfaces, wrong one chosen in Contact header

asterisk: 15.2.0 w/ pjsip bundled
OS: ubuntu 16.04
phone: soft-phone or a D80, doesn’t matter


I’m experiencing a problem with Asterisk running on a node with two network interfaces.

In the first set-up only one interface is used, i.e. the router (behind which the ITSP is located, NAT in use) and the phones are found on the same network.
ITSP <–internet–> router/NAT <–net_a–> asterisk, phone

Both incoming and outgoing calls do work in this set-up.

Now, the node’s interfaces should instead be used the following way:
ITSP <–internet–> router/NAT <–net_a–> asterisk <–net_b–> phone

The 1st interface is wired to the router within network A.
Asterisk registers with the ITSP going through this interface and the router’s NAT into the internet; this still seems to work fine.
The 2nd interface has an IP within network B, where also the phone is located.
The phone is registered with asterisk; this is still working fine.

When a call comes in using the two interface set-up, everything still works.
However, outgoing calls are not established.
The reason AFAIS is that the OK send from Asterisk / PJSIP shows a contact URL with an IP of network A (see screenshot with wireshark’s protocol).

The phone then sends its ACK accordingly to the IP of the 1st interface which, of course, cannot be reached because it belongs to the wrong network (see second screenshot w/ OK packet details).

There’re 2 transports, of course:

Don’t know whether the Contact header actually cause the problem. However, IMHO Asterisk / PJSIP has to send the IP of the 2nd interface within network B anyway. It has to respect the interface through which packets to the phone are routed, because the response packets will presumably arrive on that interface, too.

Perhaps I just have missed a configuration thing. On the other hand, Asterisk/PJSIP is already in a dialog with the phone, so they should know each other …

Thanks for help.

(Wording is edited due to the comments of david551 below.)

Your problem is that you don’t have sub-networks. You appear to have two disjoint networks. Sub networks can route between themselves.

chan_sip cannot cope with such cases, beyond a single NATted case. I’m not sure if chan_pjsip has any such support.

Normally the recommended way of dealing with disjoint networks is to turn an instance of Asterisk on each network, on the same machine, and run a “trunk” between the two.

Thanks for your answer.

However, the two networks are of course disjoint, because that is the clue of that set-up. From a routing point of view, the networks are disjoint as soon as the both netmasks produce distinct network numbers. Following classical sub-netting and choosing i.e. and instead of the IP ranges in my actual set-up would not make a difference, because the two networks then were (and shall be) still disjoint.

With real sub-networks, it would not matter that the contact headers contained the address of another interface, because the routers would know how to reach that interface.

Even if the only connection was through the Asterisk box, and route to sub-network A, via that box, would be advertised on sub-network B.

There is no router between the both networks. They are intentionally disjoint. Think of the box being a gateway. Or think of the structure where a SIP proxy runs between the DMZ in the internal zone. (BTW: I know that Asterisk is no SIP proxy; I mentioned this as an example of the network structure only.)

Nevertheless: The question is about why Asterisk puts those IP into the Contact header, not why the both networks are disjoint.

I don’t know how PJSIP handles this, but chan_sip tries to create a socket to the peer and sees what interface the OS chooses, to determine its own address.

Are these two interfaces physically separate connections, as I believe that Linux always returns the primary interface when you try this for a virtual interface.

The initial confusion was the sue of the term sub-network, when you actually meant network, i.e. they weren’t part of the same internet.