[Blink] Improper outgoing interface representation on multihomed host

[Alex Balashov]

Greetings,

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 
10.0.42.211.  I also have an OpenVPN tunnel interface tun0 with 
address 10.5.30.13 over which a static route to my PBX is pinned in 
the system routing table, e.g.

    route add -host addr.of.pbx gw 10.5.30.12 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 
of 10.0.42.211.

 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.

Cheers,

-- 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/