Re: ipv6, SVR, sip2sip etc.

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--===============0952846438030107838==
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature";
 boundary="zTQHhBvPNYBZBjoQxYOUJsQg0qE5bycRH"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--zTQHhBvPNYBZBjoQxYOUJsQg0qE5bycRH
Content-Type: multipart/mixed; boundary="YXCbf7o2qSfVZqG2BBfFeNCEsLONNG0QS";
 protected-headers="v1"
From: Thomas Ries <[email protected]>
To: [email protected]
Message-ID: <d259813d-af02-adea-4751-e2d38c606547-hi6Y0CQ0nG0@public.gmane.org>
Subject: Re: [Siproxd-users] ipv6, SVR, sip2sip etc.
References: <alpine.DEB.2.20.1907281018590.8250-z7/QA7fyNSQL9CW/JpObV6LS1BSwnZFk9dF7HbQ/[email protected]>
In-Reply-To: <alpine.DEB.2.20.1907281018590.8250-z7/QA7fyNSQL9CW/JpObV6LS1BSwnZFk9dF7HbQ/[email protected]>

--YXCbf7o2qSfVZqG2BBfFeNCEsLONNG0QS
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Hi Tim,

1) IPv6:
Implementing IPv6 support on SIP and RTP level as well as relaying SIP/RT=
P
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 supp=
orted
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. wh=
en
using redundancy).


3) One siproxd instance can handle multiple clients (as long as each clie=
nt
uses it's own SIP account). Siproxd should include as little call handlin=
g
logic as possible, so implementing call forking to support multiple devic=
es on
the same SIP account would heavily increase complexity of the code (too m=
uch
complexity in my opinion).
What is your approach to deal with this? I could maybe imaging some uniqu=
e
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,
>=20
> I've been using siproxd successfully on debian for a while now, thanks!=

>=20
> Some comments and questions.
>=20
> 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 hardwar=
e
> for making sip calls) and internal IPv6 to external IPv4 (some provider=
s
> are ipv4 only)
>=20
> 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)
>=20
> 2. SRV records are not supported - this breaks, for example, sip2sip.
> However, in that case I've got it working with:
>=20
> outbound_domain_name =3D sip2sip.info
> outbound_domain_host =3D proxy.sipthor.net
> outbound_domain_port =3D 5060
>=20
> This should, of course, be looked up via srv records.
>=20
> Any plans to support this? If I eventually get around to it it will be
> after IPv6 DNS support.
>=20
> 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?
>=20
>=20
> 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.
>=20
> Thanks again,
>=20
>=20
>=20
> _______________________________________________
> Siproxd-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>=20


--YXCbf7o2qSfVZqG2BBfFeNCEsLONNG0QS--

--zTQHhBvPNYBZBjoQxYOUJsQg0qE5bycRH
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)

iQIcBAEBCgAGBQJdQHcOAAoJEJ13f30qwnQAxG0P/AitJScyteLXCZj9o5d0z8k1
djBzNAsElmgdNgaaZyLXTli+Tk62U/aCBeHxvGCfxyMHrENamlOu4P06odR7dB3G
Hgr4yUD6McBPRcsxRzctBzvnGyG12BorDnNr1egSLL0UQmqErJO1gku4b6PnBRSK
ykDWXHpfTZGMupR5C6vWvAVKhmefXSdDi9CRk1JMB9XX7SOycm4F3czwKdqLmHJs
hWaCXe6Ju5chKs3yJNdW1oRTQzx9dQOKaa95Smp+R/hXAoIfCmMBv2Gsc3EAih4I
i/FVkOLWAGS5pwm6qG1UXK3wvOpvum1JZ7pBMPN5WBthDfKxhK2bzbFUxzs/UCxz
9AifP5r8stEZvlQ8HMP+B14O6bW3m5l1cwwlH8pgEinikbyukN9VFslvvO8phCQ4
HXKVe487XuTPwdmTZY6Vw8ge4sKowEWoljwhK+7mmpNbUn9EucHovZPzeQTlseIv
ZxNXsh5krnmZSV8k8lSBJMAlfw2dtjyuiUFtRjlDzxjDZCL26fTksXF8Uc+4WG8k
2ywBvw6rT6C/iN1gXLnqB949nxF2W5k9P5IzxHUkozyvEK66ZUWhiROxe6XixBg5
JTJFi740dJNvuZDiKRfO+Ze4z77ekA4uxi7pILIiPFadZTqU7Qf+JtBkRvktWmZZ
vh8+I5DqpVupXHzV3sk6
=FlBG
-----END PGP SIGNATURE-----

--zTQHhBvPNYBZBjoQxYOUJsQg0qE5bycRH--


--===============0952846438030107838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============0952846438030107838==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Siproxd-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/siproxd-users

--===============0952846438030107838==--