[Blink] Improper outgoing interface representation on multihomed host

Klaus Darilion klaus.mailinglists at pernau.at
Mon May 30 14:01:53 CEST 2011

Am 30.05.2011 10:25, schrieb Saul Ibarra Corretge:
> Hi Alex,
> On May 30, 2011, at 2:54 AM, Alex Balashov wrote:
>> 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
>>  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 of
> We are aware of the Via header issue, it's a limitation we have to
> live with, at least for now. Other fields such as c line should be
> correct, were they?
>> 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.
> Yes, that's right. Actually only by doing rport should be enough.
> Please let us know if you found incorrect information in the SIP
> messages other than in the Via header.

Actually the IP address in Via is more or less irrelevant. Even without
rport the UAS must send back to the IP address from which the request
was received (received= parameter in Via header).


More information about the Blink mailing list