[Blink] no audio if multiple ip-addresses are active

Kenny MacDermid kenny.macdermid at gmail.com
Fri Aug 13 15:29:56 CEST 2010


On 13 August 2010 10:15, Luci Stanescu <luci at ag-projects.com> wrote:
> On 13/08/10 16:00, Kenny MacDermid wrote:
>>> Blink currently sends all traffic through the default route, so this is
>>> expected. If your default route gos through that IP address, it will be the
>>> one chosen. There is no support for selecting other interfaces.
>>
>> You say this is expected. Do you mean it's expected currently, but a
>> bug? The SIP traffic is not being sent out the default route, it's
>> being sent out the 10.1.15.10 interface (as I would expect). If it's
>> using an IP for a route it's not using I'd consider that a bug.
>>
> [..]
>>
>> Again, not quite sure what you mean by expected.
>
> Blink announces the address by seeing which address is used as a source
> for routing on the default route (well, to be more precise, for getting
> to 1.2.3.4 port 56, UDP - we assume there's no specific route for this
> address as 1.0.0.0/8 is not used). This address is used in the Contact
> SIP header and the SDP payload. The actual IP packet's source and
> routing is determined by the operating system (this cannot be controlled
> by Blink). This basically explains why your packets do go through the
> VPN, but they use the IP address on the interface associated with your
> default route. We use this simplistic process due to complications which
> may arise otherwise.
>

Thanks for the reply Luci. I still don't think I fully understand
though. If the default route addresses are passed in the SDP setup how
can you expect the audio to ever connect in cases where the RTP should
travel over the non-default interface?



More information about the Blink mailing list