Re: [Siproxd-users] ipv6, SVR, sip2sip etc.

[Tim W. <si...@wo...>]

Hi Thomas,

I have bitten the bullet and decided to migrate to Asterisk.
Interestingly, I was unable to get ipv6 working with v13 but an upgrade
to v16 fixed it.

My reluctance to going to asterisk is its complexity when handling just
a few clients. A small mistake can easily leave a system open to toll
fraud.

Which is why I liked siproxd. Everything through a single point and easy
to configure.

I'm not convinced by the 'you have a globally routable IP' so don't need
a proxy argument. If anything, a proxy becomes more important as it's
much harder to firewall IPv6 when privacy addressing is in use (and it's
not always trivial, or advisable, to disable it on clients)


I was doing something akin to forking which mostly seemed to work. I
agree that it adds a lot of complexity. But my sip provider only gives
me one account for my pots number which happily supports multiple
clients. But siproxd silently overwriting the registation data
internally leads to bizarre results where things start and stop working
randomly.

I'm still using siproxd currently for my (billable) sip provider but
I've got a working asterisk installation with a free provider. Once I'm
confident I understand what I'm doing I'll migrate everything over.

(I've discovered that two different android sip clients do not seem to
handle ipv6 on multihomed devices (wifi+vpn) similar to asterisk v13 -
nothing at all appears to leave the app on any interface. Strangely,
web, dns are happily using ipv6 on the same device. So you might find
more requests for a ipv4 to ipv6 proxy in time as and when sip providers
become ipv6 only. If you only connect to a trusted provider and do
not publish your sip ip in dns then your local pbx (or siproxd instance)
is, essentially, undiscoverable if it's ipv6 only)

Regards,

Tim.


On Tue, 30 Jul 2019, Thomas Ries wrote:

> Hi Tim,
>
> 1) IPv6:
> Implementing IPv6 support on SIP and RTP level as well as relaying SIP/RTP
> between IPv4 and IPv6 is not on the TODO list.
> - Relaying between IPv4/IPv6 endpoints is a task that I see on the PBX or VoIP
> provider level.
> - If I have native IPv6 connectivity, NAT should not be an issue at all.
>
>
> 2) SRV records
> They are on the TODO list, but no commitment up to when they will be supported
> exists yet. Your way of getting it to work is the recommended workaround :-)
> However, this workaround does not deal with multiple SRV records (e.g. when
> using redundancy).
>
>
> 3) One siproxd instance can handle multiple clients (as long as each client
> uses it's own SIP account). Siproxd should include as little call handling
> logic as possible, so implementing call forking to support multiple devices on
> the same SIP account would heavily increase complexity of the code (too much
> complexity in my opinion).
> What is your approach to deal with this? I could maybe imaging some unique
> identifier per local client that is used to distinguish the local devices and
> pass all the registrations through to the registrar.
>
>
> Best regards,
> /Thomas
>
>
> On 7/28/19 11:57 AM, Tim Woodall wrote:
>> Hi,
>>
>> I've been using siproxd successfully on debian for a while now, thanks!
>>
>> Some comments and questions.
>>
>> 1. My setup is almost exclusively IPV6. I've some local changes to
>> enable debugging via an IPv6 connection. I'd like to extend it to
>> enabling internal IPv4 to external IPv6 proxy (I have ipv4 only hardware
>> for making sip calls) and internal IPv6 to external IPv4 (some providers
>> are ipv4 only)
>>
>> Is there any general interest in this? I don't have a huge amount of
>> time to work on this and I've got to get permission from work to
>> contribute (I don't think it will be a problem but I don't want to make
>> the effort if the general consensus is IPv6 is not appropriate for this
>> application)
>>
>> 2. SRV records are not supported - this breaks, for example, sip2sip.
>> However, in that case I've got it working with:
>>
>> outbound_domain_name = sip2sip.info
>> outbound_domain_host = proxy.sipthor.net
>> outbound_domain_port = 5060
>>
>> This should, of course, be looked up via srv records.
>>
>> Any plans to support this? If I eventually get around to it it will be
>> after IPv6 DNS support.
>>
>> 3. It's annoying to have to run a separate proxy for each client that
>> shares an upstream - the registrations get overwritten. I've made some
>> progress on removing this restriction but it needs completely reworking
>> for the 0.8.2 release and it definitely still had bugs. Has anyone else
>> already solved this one? Or knows that it's never going to work and I'm
>> wasting my time?
>>
>>
>> Despite all the above, siproxd has been a lifesaver. Since switching
>> from PTSN to VOIP I've been dependent on reliable NAT traversal and it's
>> the only thing that has worked for me.
>>
>> Thanks again,
>>
>>
>>
>> _______________________________________________
>> Siproxd-users mailing list
>> Sip...@li...
>> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>>
>
>