[Blink] Improper outgoing interface representation on multihomed host

Alex Balashov abalashov at evaristesys.com
Mon May 30 02:54:56 CEST 2011


I am using Blink 0.2.7 on Linux.  I think I've run into a problem with 
improper selection of outbound network interface information to 
present in SIP initial request bodies.

I have a local network interface on a private network with address  I also have an OpenVPN tunnel interface tun0 with 
address over which a static route to my PBX is pinned in 
the system routing table, e.g.

    route add -host addr.of.pbx gw dev tun0

I am trying to place calls with Blink through that PBX.

The problem is that even though the INVITE to the PBX does go out of 
tun0 from a Layer 3 perspective, obviously, all network and 
transport-layer address artifacts in the INVITE message body, such as, 
for example, the Via header, refer to the hardware interface address 

 From a practical perspective, I suppose the issue is somewhat 
academic;  it can be solved with a variety of conventional 
NAT-traversal strategies.  The PBX is Asterisk, so enabling nat=yes in 
particular would be an obvious fix.

The cause of the problem is quite obvious;  Blink appears to not be 
multi interface-aware, and leaves IP routing mechanics to the OS.  I 
just wanted to report the issue since I assume that this behaviour is 
not desirable in principle.  On the other hand, there is probably a 
very defensible viewpoint that Blink should not concern itself with 
network issues far beneath the application layer, but unfortunately, 
as we know, this leaky abstraction is promulgated by the design of SIP 
itself and thus the issue cannot be entirely avoided.


-- Alex

Alex Balashov - Principal
Evariste Systems LLC
260 Peachtree Street NW
Suite 2200
Atlanta, GA 30303
Tel: +1-678-954-0670
Fax: +1-404-961-1892
Web: http://www.evaristesys.com/

More information about the Blink mailing list