siproxd-users — Users Mailing List

[Siproxd-users] Some thoughts

[Evgeniy S. <itn...@gm...>]

Hello,

I'm using siproxd for some years and I have some ideas about it. May be
some of them will be useful, may be not. May be I'm wrong somewhere. I
wrote some plugins to siproxd and I want to tell about some of them.
I'm using Internet Service Provider (ISP) with hard NAT, so I'm using
STUN plugin to fix addresses in connections with PBX. But because of
ISP NAT I've got another kinds of problems.

First problem is loosing NAT port for incoming traffic because of rare
exchange. This problem persists in SIP UDP traffic exchange between
siproxd and PBX where usual traffic is (re-)registration traffic with
some packets per minutes. Nearly 30-45 seconds after absence of packet
exchange ISP NAT "forgets" about traffic transferring between external
port and local port, so all incoming packet will be lost. This problem
causes loosing INVITE packets, loosing incoming calls. I wrote small
plugin called "plugin_keepalive" which just sends UDP packets with
"\r\n\r\n". RFC 5626 includes similar keep-alive for TCP, but not for
UDP, so this method is non-standart. But in practice I've seen phones
with this kind of keep-alive: Siemens Gigaset C610A DECT Base sends
these packets. As I remember some of servers answered with "\r\n" for
these packets (may be "ekiga" did that?). I've added such "pinging" for
local clients (telephones), because of firewalls. I've configured
firewall on internal interface for host with siproxd just for incoming
packet exchange with remembering state, but not outgouing. It's usefull
if someone hacks siproxd - it will not get permission to scan whole
network. But to keep firewall exchange state it is have to make any
exchange for some time. There is one problem with this plugin. I have
not found any way how to select only UDP servers/clients from siproxd
structures, excluding TCP. I have not worked with TCP client/servers at
all, but it looks like that this plugin will send UDP "pings" for all
defined hosts.

Second problem caused by ISP NAT is local call loops for RTP. When I'm
trying to call from one telephone to another, call goes to siproxd and
to SIP PBX. SIP PBX sends call to siproxd again and to called local
telephone. At first point of view it looks good. But STUN plugin and/or
SIP PBX changes RTP media IP address to external IP address (Internet
IP address), so siproxd have to send RTP traffic to external
IP-address. For example: siproxd have ISP LAN address 192.X.Y.Z and ISP
Internet address 1.2.3.4. After INVITE/OK exchange siproxd will have to
send all RTP data to 1.2.3.4 because SIP PBX told this address to
siproxd for exchange. But ISP NAT does not allow such forwarding when
sending packets to external NAT address (1.2.3.4) goes back to internal
NAT address (192.X.Y.Z). So all RTP packets are lost. So I wrote small
plugin called "plugin_fix_nat_call_loop", which changes media
IP-address in incoming INVITE/UPDATE/OK SDP packets from external NAT
IP address (got by STUN plugin for example) to local outbound
IP-address. It makes RTP loop for local calls on outbound interface, so
local calls RTP goes "properly" through siproxd. This is not beautiful
solution, but it helps.

In addition I wrote plugin which changes SDP username and session
name which is called "plugin_sdp_name". These fields sometimes are
useless for connections, but it shows SIP software/hardware, and I want
to hide that. :-)

These plugins may be are not good, may be there are some errors, but it
may be interesting for someone. May be just an ideas of these plugins
helps someone to write own plugin.

------

In addition I just want to tell some my thoughts about siproxd.
Yesterday I've built lastest release version 0.8.3 and I was badly
surprised: it allocates too much memory! Previous version 0.8.2
allocates ~4.5 megabytes, last version allocates ~18 megabytes. I'm
using old PC for router and SIP proxy tasks (Pentium 2 with 366MHz and
64 megabytes of RAM), so eating so much memory is unacceptable. I've
read changelog and reduced URLMAP_SIZE to 64 and RTPPROXY_SIZE to 64,
and... now it eats just 2.5 megabytes and it's wonderful! I do not need
such huge count of simultaneously connections, but there is no way to
change it without patching. Nothing says that just these values makes
siproxd so "hungry". I think that these values can be set by any
"user-friendly" way: parameter of "configure" or may be memory can be
allocated dynamically and these parameters can be moved to siproxd.conf.

Another thought is about blacklist plugin. I have not found any "proper"
way to disable that during building, just patching Makefile.in and/or
Makefile.am. I have not tried to use this plugin, may be it's good, but
it requires SQLite. I have no SQLite and do not want to build it. But
there is no check for SQLite presence during "configure" and no way to
exclude blacklist plugin from building. :-(

Third thought is about current version of "plugin_stripheader". It uses
"strndup" function. My old FreeBSD does not have such function. So...
I've wrote another "bad" patch for that
(plugin_stripheader_strndup.patch). May be strndup can be replaced to
any other function or can use rewritten strndup function (or may be
presence of strndup in system will be checked by "configure")? :-) 

And the last thought is about RTP, NAT and keep-alive. Because of NAT
there can be 2 possible problems with RTP. First problem is that NAT
ports are not controlled by SIP peers. So if peers want to exchange
RTP packets NAT ports have to be opened/forwarded. There is only one way
to open NAT ports: just send a packet. I'm not controlling ISP NAT, but
potentially such situation can persist: while making a call SIP PBX
may send RTP packet first for any reason. RTP packets will go to ISP NAT
potentially closed ports and potentially NAT can answer by ICMP for all
RTP packets from SIP PBX that port is closed. And... potentially SIP
PBX may be will not like that. So I think that when RTP proxy makes
relay it may send stub empty packets just to kick NAT. Other problem
with NAT is missing packet for some time and loosing RTP port on NAT.
So... I think that siproxd can send periodically empty packets just to
save activity for NAT. RTP clients should ignore these empty packets (I
hope :-) ). I've wrote small dirty patch (siproxd_keepalive.patch) to
send it. In addition: there is other problem with NAT: it can give
random ports for RTP. There is no external port checking for RTP
streams, but it can be done using STUN for example. STUN can send
packets for STUN server from all RTP ports and getting real RTP port
address; or sending packets to STUN can be done before making relay.
That is not a proper/good solution for all NATs. NAT is real pain,
but... Sometimes there is no good choise for ISP.

------
With Best Regards,
Evgeniy Shtrenyov

[Siproxd-users] New Release 0.8.3

[Thomas R. <tr...@gm...>]

A new release of siproxd is available.

Release Notes for siproxd-0.8.3
===============================



Major changes since 0.8.2:
 - mostly bugfixes and performance improvements


 New plugins:
 - plugin_stats: write some statistics about currently active calls
 - plugin_blacklist: new plugin to block UACs that cause excessive
   failures during REGISTER attempts


Upgrade Notes 0.8.2 to 0.8.3:
 - Merge the configuration file

General Overview:
 - SIP (RFC3261) Proxy for SIP based softphones hidden behind a
   masquerading firewall
 - plugin system allows loading extensions to accomplish various tasks
 - Support for PRACK messages (RFC3262)
 - Support for UPDATE messages (RFC3311)
 - SIP UDP and TCP supported
 - Works with "dial-up" connections (dynamic IP addresses)
 - Multiple local users/hosts can be masqueraded simultaneously
 - Access control (IP based) for incoming traffic
 - Proxy Authentication for registration of local clients (User Agents)
   with individual passwords for each user
 - May be used as pure outbound proxy (registration of local UAs
   to a 3rd party registrar)
 - runs on various operating systems (see below)
 - Full duplex RTP data stream proxy for *incoming* and *outgoing*
   audio data - no firewall masquerading entries needed
 - Port range to be used for RTP traffic is configurable
   (-> easy to set up appropriate firewall rules for RTP traffic)
 - RTP proxy can handle multiple RTP streams (eg. audio + video)
   within a single SIP session.
 - Symmetric RTP support
 - Symmetric SIP signaling support
 - Supports running in a chroot jail and changing user-ID after startup
 - All configuration done via one simple ASCII configuration file
 - Logging to syslog in daemon mode
 - RPM package (Spec file)
 - The host part of UA registration entries can be masqueraded
   (mask_host, masked_host config items). Some Siemens SIP phones seem to
   need this 'feature'.
 - Provider specific outbound proxies can be configured
 - Can run "in front of" a NAT router.(in the local LAN segment)
 - supports "Short-Dials"
 - configurable RFC3581 (rport) support for sent SIP packets

Plugins:
 - plugin_fix_fbox_anoncall
   This plugin attempts to work-around some SIP issues with
   Fritzbox devices and anonymous calls. Fritzbox devices do change their
   Contact header when answering an anonymous call (suppressed CLID) - this
   in turn confuses siproxd. This plugin attempts to work around this by
   sanitizing the Contact Header before processing.
 - plugin_siptrunk
   Plugin to handle SIP Trunks where using *one* single SIP account a
   whole number block is routed. Please read the comments in the config
   file section.
 - plugin_codecfilter
   Allows blacklisting of codecs and removes those from any passing SDP
   payload in both (incoming and outgoing) directions. This allows the
   proxy to force the exclusion of particular codecs in the negotiation
   between a local UA and a remote side.
 - plugin_stripheader
   Allows to strip particular headers from SIP messages. Useful if your
   provider chokes on some headers included by your local UA.
 - plugin_regex
   Applies an extended regular expression to the 'To' URI.
 - plugin_prefix
   Unconditionally prefixes all outgoing calls with a prefix.
 - plugin_stun
   Uses an external STUN server to determine the public IP
   address of siproxd. Useful for "in-front-of-NAT-router"
   scenarios.
 - plugin_fix_DTAG
   This plugin attempts to work-around some SIP issues with
   T-ONLINE SIP (as of 2015). T-Online.de sends broken Via headers in
   responses, causing the received SIP response to be discarded by
   any SIP client that properly checks the Via chain.
 - plugin_fix_bogus_via
   Incoming (from public network) SIP messages are checked for broken
   SIP Via headers. If the IP address in the latest Via Header is
   part of the list below, it will be replaced by the IP where the
   SIP message has been received from.
 - plugin_shortdial
   Quick Dial (Short Dial)
   Ability to define quick dial numbers that can be accessed by
   dialing e.g. "*01" from a local phone.

Requirements:
 - pthreads (Linux)
 - glibc2 / libc5 / uClibc
 - libosip2 (3.x.x)

Mainly tested on:
- CentOS
  This is the main development and testing environment. Other platforms
  are not extensively tested. However, the code should be quite portable
  and build on many UNIX/Linux flavors.

Builds on (tested by dev-team or reported to build):
- Linux:	CentOS/RedHat
- FreeBSD:	FreeBSD 10

Reported interoperability with softphones:
 - SNOM series
 - Fritzbox UAs
 - Grandstream BudgeTone-100 series
 - Linphone (local and remote UA) (http://www.linphone.org)
 - Kphone (local and remote UA) (http://www.wirlab.net/kphone/)
 - MSN messenger 4.6 (remote and local UA)
 - X-Lite
 - SJPhone softphone
 - Asterisk PBX (using a SIP Trunk, masqueraded via siproxd, chan_sip driver)
 - Ekiga
 - FreePBX
 - Yealink series

Reported interoperability with SIP service providers:
 - Sipgate	(http://www.sipgate.de)
 - Stanaphone	(SIP Gateway to PSTN)
 - Sipcall.ch	(Swiss VoIP provider)
 - Nexphone.ch	(Swiss VoIP provider - via resellers)
 - Ekiga
 - DTAG (Deutsche Telecom AG) -> requires plugin_fix_DTAG to work around
                                 some issues with this provider


 If you have siproxd successfully running with another SIP phone
 and/or service provider, please drop me a short note so I can update
 the list.

Known interoperability issues with SIP service providers:
 - callcentric.com	(AFAIK callcentric fails with "500 network failure"
 			during REGISTER if more than one Via header is
			present in a SIP packet. Having multiple Via headers
			is completely in compliance with RFC3261. This might
			be related to their "NAT problem avoidance magic".
			There is nothing that can be done within siproxd
			to avoid this issue as callcentric does not comply
			with the SIP specification.



Known bugs:
   - SRV DNS records are not yet looked up, only A records
   There will be more for sure...

If you port siproxd to a new platform or do other kinds of changes
or bugfixes that might be of general interest, please drop me a
line. Also if you intend to include siproxd into a software
distribution I'd be happy to get a short notice.


-----
Signatures for siproxd-0.8.3.tar.gz archive:
SHA-256 Hash:	9a6d7a6bb6fff162775b1e1fb7018de9c69642cbf8626185dc6ffceeeba07736

GnuPG signature for siproxd-0.8.3.tar.gz:
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)

iQIcBAABCgAGBQJfRBlxAAoJEJ13f30qwnQAf3wP/RWBUqZHZgEVTAYyrXglZtFK
bA1BPTpcOxyD4F2+wtuOCnyLJYjMLqA2+A6QCMImBhimBQ4ihtOpZZD/dka9Bjz/
tYzY4YbAODDrCJoWtyRkGSXD3rgiOnwoa3r141HrIm0bfXBD8KK58a96nTavBG7b
t09S9GmTaj6UW8ObfRarS6yfAer00F6EdA5U/cTIEh3HHwBjxi6uCe6XocduzEfl
56RwFEcSqnd1QBXMMkJo0C9xfYpwbU4Iam8nYLtf7YCXEimZS+N2XSBCq/gMow7V
5DZXLIFCyEAeA1Rp+/+Qf7HZmCbZG+MZgWj/ISoigon/xRzuaAjprJDPlBEFJuyh
bapgXvqxBO+RzPK7TutTK+U3jwwuvtNH3+EUaYkognMS6C0KARrtTj7oKI3OyU/s
xdHN22vspWQjxRZ3WUd2Oo3fuPdnhFScgfmwI1eSzD/9VbIsuWWXuTTIm3rlFkXM
5cCwHvT/JppHp2j0bj35/LAtwb3FlOY+WPt6jX52Lh/VKWi1I2SIbSYU0MQGuPyX
asqp4ZdmyEP2vsHl/DaYyMEJwo2Lgdqp9UUhkbIsI7yZOEHquKcWrD04RdsIEBTG
DbpIcbgc/O3Bf0ZGuKDxgvSxwDLtDIvoTxRGOAaIQ+DRo1E0WV+h0yx8PbWGWuui
brwhMLv9ZERzLcsXF2t4
=DkVM
-----END PGP SIGNATURE-----

NEW GPG KEY!
pub  4096R/2AC27400 2017-07-11 Thomas Ries (HB9XAR) <tho...@ea...>
      Key fingerprint = 6560 75BE 4D4D 6C4D 8005  D4B4 9D77 7F7D 2AC2 7400
      Key available at http://siproxd.tuxworld.ch/2AC27400.pub

Re: [Siproxd-users] Configure siproxd to use behind a openvpn connection

[Thomas R. <tr...@gm...>]

Hi,

1) Your 3 line config file seems a bit minimalistic. Please make sure to base
your config on the sample config file to ensure sane values for various options.

2) Can you be more specific about the "but does not allow me to make calls"?
  Any error message? What does Asterisk Log say?

3) Does Microsip properly register with Assterisk? Check on Microsip and
Asterisk side.

4) enable siproxd logging and check for errors/warnings.
  (<http://siproxd.sourceforge.net/siproxd_guide/siproxd_guide_c6s2.html>)

best regards,
/Thomas


On 5/19/20 11:43 AM, Panocila Smith wrote:
> Hello,
> 
> I need to configure a proxy-sip. I discovered siproxd, but I am not
> able to use it.
> 
> My network is as follows:
> 
> PC-Windows -> Use MicroSip -> 192.168.1.10
> PC-Linux -> Use siproxd ->
> -->   Network interface -> ens33 -> 192.168.1.111
> -->   Network interface -> tun0 ->  10.10.2.33 (OpenVPN raised)
> PC-Asterisk -> 10.10.2.222
> 
> I use this configuration file for siproxd (the other default options)
> 
> if_inbound  = ens33
> if_outbound = tun0
> host_outbound = 10.10.2.222
> 
> In microsip, I configure the Proxy field and put: 192.168.1.111. The
> other fields I leave them the same as when I have direct access to
> PC-Asterisk (10.10.2.222) (or when I can use openvpn in this machine)
> 
> Microsip connects correctly, but does not allow me to make calls.
> 
> What am I doing wrong?
> 
> Thanks
> 
> 
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
> 

[Siproxd-users] Configure siproxd to use behind a openvpn connection

[Panocila S. <pan...@gm...>]

Hello,

I need to configure a proxy-sip. I discovered siproxd, but I am not
able to use it.

My network is as follows:

PC-Windows -> Use MicroSip -> 192.168.1.10
PC-Linux -> Use siproxd ->
-->   Network interface -> ens33 -> 192.168.1.111
-->   Network interface -> tun0 ->  10.10.2.33 (OpenVPN raised)
PC-Asterisk -> 10.10.2.222

I use this configuration file for siproxd (the other default options)

if_inbound  = ens33
if_outbound = tun0
host_outbound = 10.10.2.222

In microsip, I configure the Proxy field and put: 192.168.1.111. The
other fields I leave them the same as when I have direct access to
PC-Asterisk (10.10.2.222) (or when I can use openvpn in this machine)

Microsip connects correctly, but does not allow me to make calls.

What am I doing wrong?

Thanks

[Siproxd-users] It never find libosip2

[Saint M. <ve...@gm...>]

I am having a nervous breakdown. My libosip is where is supposed to be. I
tyle
ldconfig -p
ldconfig -p | grep libosip
        libosip2.so.11 (libc6,x86-64) => /usr/lib64/libosip2.so.11
        libosip2.so.11 (libc6,x86-64) => /usr/lib/libosip2.so.11
        libosipparser2.so.11 (libc6,x86-64) =>
/usr/lib64/libosipparser2.so.11
        libosipparser2.so.11 (libc6,x86-64) => /usr/lib/libosipparser2.so.11

but ./configure cannot find it. I add
./configure  --with-libosip-prefix=/usr/lib

and it does not find it.

Any idea what am I doing wrong?

Saint

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

[Kai D. <KD...@su...>]

On 09.08.19 12:00, Tim Woodall wrote:
> 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 agree to this. A proxy of course is not only to bridge between
networks but also to separate and clarify access. It has a functional, a
security, and management component.

Just for my own setup I used it to also rewrite numbers - which is
beyond the base proxy idea but very convenient.

While I have no need today for IPv6 I assume it will become very needed
in the not too far future.

Please do not stop thinking about implementing IPv& into siproxd just
because in IPv6 an option exists not to need it anymore. Else we would
not need HTTP proxies anymore, do we?

Best regards,
Kai Dupke
Senior Product Manager
SUSE Linux Enterprise 15
-- 
Sell not virtue to purchase wealth, nor liberty to purchase power.
Phone:  +49-(0)5102-9310828     Mail: kd...@su...
Mobile: +49-(0)173-5876766      WWW:  www.suse.com

SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer, Mary Higgins, Sri Rasiah HRB 21284 (AG Nürnberg)

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

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

[Thomas R. <tr...@gm...>]

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
> 

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

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

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] FUZE anyone?

[Kai D. <KD...@su...>]

Hi,

I wonder if anyone is using FUZE with siproxd and might share a config
or experience?

Best regards,
Kai Dupke

[Siproxd-users] issue with multiple subnets

[<Gai...@gm...>]

Hi,

I am using siproxd on my NAT firewall. I have multiple subnets with different VoIP clients in my environment (let's call them LAN and GUEST). My configuration looks like this:

if_inbound  = eth0
if_outbound = ppp0
hosts_allow_reg = 192.168.0.0/16

On eth0 I have my LAN subnet (192.168.1.x), the siproxd/firewall address is 192.168.1.1. VoIP calls from the same subnet (clients registered through siproxd) work like a charm. The issue is with clients from my GUEST net (192.168.10.x).

My GUEST net is on eth1 (192.168.10.1). The clients from the GUEST net can also use 192.168.1.1 as a SIP proxy, but in this case RTP streams only work in one direction. The firewall rules itself should not be an issue, as I have allowed all LAN <-> GUEST communication for testing reasons.

My suspicion is that spixroxd gets confused when rewriting the RTP source/destination address. Is there any way to work around this so that clients from subnets which are not the same as the "if_inbound" subnet can still use siproxd? I really want to avoid running a seperate siproxd instance for every subnet.


Thanks,
Jonas

Re: [Siproxd-users] siproxd not reacting on incoming connections

[bloodcarter <blo...@gm...>]

OK, now I am recieving this. I want my 192.168.31.98 machine connect to
35.184.99.143 siproxd, and the remote SIP server 195.19.70.1 thought that
my machine IP is 35.184.99.143


11:42:01 register.c:237 sip_register:11:42:01 register.c:323 register:
1305@192.168.31.98 expires=300 seconds11:42:01 register.c:348 found entry
for 1305@192.168.31.98 <-> 1305@195.19.70.1 at slot=0, exp=32611:42:01
utils.c:361 fetching outbound IP by HOSTNAME11:42:01 register.c:448
masquerading UA 1305@192.168.31.98 local 1305@35.184.99.14311:42:01
proxy.c:86 proxy_request11:42:01 utils.c:394 fetching interface IP by
INTERFACE [1]11:42:01 utils.c:472 ifaddr lookup - from cache: ens4 ->
10.128.0.5 UP11:42:01 utils.c:361 fetching outbound IP by HOSTNAME11:42:01
route_processing.c:135 route_preprocess: checking topmost Route header11:42:01
route_processing.c:150 removed Route header pointing to myself11:42:01
sip_utils.c:1026 sip_find_direction: beginning search11:42:01
sip_utils.c:1069 sip_find_direction: no OUTGOING found11:42:01
sip_utils.c:326 compare_url: IP mismatch11:42:01 sip_utils.c:1114
sip_find_direction: no INCOMING (To:) found11:42:01 sip_utils.c:326
compare_url: IP mismatch11:42:01 sip_utils.c:1136 sip_find_direction: no
INCOMING RQ (SIP URI) found11:42:01 sip_utils.c:1209 sip_find_direction: no
INCOMING RS (via header) found11:42:01 utils.c:394 fetching interface IP by
INTERFACE [1]11:42:01 utils.c:472 ifaddr lookup - from cache: ens4 ->
10.128.0.5 UP11:42:01 utils.c:361 fetching outbound IP by HOSTNAME11:42:01
sip_utils.c:1237 sip_find_direction: no INCOMING (redirected) found11:42:01
sip_utils.c:1243 sip_find_direction: unable to determine direction of SIP
packet11:42:01 proxy.c:239 request [REGISTER] from/to unregistered UA (RQ:
1305@195.19.70.1 -> *NULL*@195.19.70.1)



--Vladislav Chernyshov


On Wed, Sep 5, 2018 at 12:12 AM Thomas Ries <tr...@gm...> wrote:

> Hi,
>
> 1) setting hosts_allow_reg = 0.0.0.0/0  is a bad idea,
> you don't want all the internet be able to register with your siproxd.
> hosts_allow_reg should be restricted to your local network.
> Remember, siproxd does proxy between public Internet and local networks
> that
> are connected to the Internet via NAT.
>
> 2) if using the same interface for if_inbound and if_outbound you must tell
> siproxd what its public IP is. Either by setting host_outbound or using the
> STUN plugin.
>
> 3) Enabling debug output will give more information about what is
> happening.
>
> Regards,
> /Thomas
>
> On 09/04/2018 01:36 PM, bloodcarter wrote:
> > iptables is configured properly, because when I set hosts_allow_reg for
> some
> > fake subnet and try to connect using my sip client, siproxd warns about
> > non-authorised attempt. And that's correct. But when I change
> hosts_allow_reg
> > = 0.0.0.0/0 <http://0.0.0.0/0> to allow registrations from any IP, then
> just
> > nothing happens, no logs, nothing.
> >
> > My siproxd.conf is below:
> > if_inbound  = eth0
> > if_outbound = eth0
> > hosts_allow_reg = 0.0.0.0/0 <http://0.0.0.0/0>
> > sip_listen_port = 5060
> > daemonize = 0
> > silence_log = 0
> > log_calls = 1
> > user = siproxd
> > registration_file = /var/lib/siproxd_registrations
> > pid_file = /var/run/siproxd/siproxd.pid
> > rtp_proxy_enable = 1
> > rtp_port_low  = 10000
> > rtp_port_high = 30000
> > rtp_timeout = 300
> > default_expires = 600
> > debug_level = 0
> > debug_port = 0
> >
> > --Vladislav Chernyshov
> >
> >
> >
> ------------------------------------------------------------------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> >
> >
> >
> > _______________________________________________
> > Siproxd-users mailing list
> > Sip...@li...
> > https://lists.sourceforge.net/lists/listinfo/siproxd-users
> >
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
>

Re: [Siproxd-users] siproxd not reacting on incoming connections

[Thomas R. <tr...@gm...>]

Hi,

1) setting hosts_allow_reg = 0.0.0.0/0  is a bad idea,
you don't want all the internet be able to register with your siproxd.
hosts_allow_reg should be restricted to your local network.
Remember, siproxd does proxy between public Internet and local networks that
are connected to the Internet via NAT.

2) if using the same interface for if_inbound and if_outbound you must tell
siproxd what its public IP is. Either by setting host_outbound or using the
STUN plugin.

3) Enabling debug output will give more information about what is happening.

Regards,
/Thomas

On 09/04/2018 01:36 PM, bloodcarter wrote:
> iptables is configured properly, because when I set hosts_allow_reg for some
> fake subnet and try to connect using my sip client, siproxd warns about
> non-authorised attempt. And that's correct. But when I change hosts_allow_reg
> = 0.0.0.0/0 <http://0.0.0.0/0> to allow registrations from any IP, then just
> nothing happens, no logs, nothing.
> 
> My siproxd.conf is below:
> if_inbound  = eth0
> if_outbound = eth0
> hosts_allow_reg = 0.0.0.0/0 <http://0.0.0.0/0>
> sip_listen_port = 5060
> daemonize = 0
> silence_log = 0
> log_calls = 1
> user = siproxd
> registration_file = /var/lib/siproxd_registrations
> pid_file = /var/run/siproxd/siproxd.pid
> rtp_proxy_enable = 1
> rtp_port_low  = 10000
> rtp_port_high = 30000
> rtp_timeout = 300
> default_expires = 600
> debug_level = 0
> debug_port = 0
> 
> --Vladislav Chernyshov
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> 
> 
> 
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
> 

[Siproxd-users] siproxd not reacting on incoming connections

[bloodcarter <blo...@gm...>]

iptables is configured properly, because when I set hosts_allow_reg for
some fake subnet and try to connect using my sip client, siproxd warns
about non-authorised attempt. And that's correct. But when I change
hosts_allow_reg = 0.0.0.0/0 to allow registrations from any IP, then just
nothing happens, no logs, nothing.

My siproxd.conf is below:
if_inbound  = eth0
if_outbound = eth0
hosts_allow_reg = 0.0.0.0/0
sip_listen_port = 5060
daemonize = 0
silence_log = 0
log_calls = 1
user = siproxd
registration_file = /var/lib/siproxd_registrations
pid_file = /var/run/siproxd/siproxd.pid
rtp_proxy_enable = 1
rtp_port_low  = 10000
rtp_port_high = 30000
rtp_timeout = 300
default_expires = 600
debug_level = 0
debug_port = 0

--Vladislav Chernyshov

Re: [Siproxd-users] Using siproxd to access my provider from outside my network

[Alex C. <al...@co...>]

OK, I've made some progress. As it was running in a chroot (default
Debian package), I needed to tweak resolv.conf/hosts within the chroot.
Now I can get my softphone to register, and calls can be made and
received, but they don't establish...

On Sat, 2018-05-12 at 19:37 +0200, Alex Corcoles wrote:
> Hi!
> 
> My ISP provides both Internet and phone service. I've found out that
> I
> can connect use a SIP soft phone to make/receive calls using the
> landline.
> 
> I need to use a weird 10.x.y.z non-routeable IP address as my SIP
> proxy
> to do this. This IP is just reachable from my home network, but I
> would
> like to access the SIP service from other networks.
> 
> I've tried siproxd with the following configuration changes:
> 
> if_inbound  = eth0
> if_outbound = eth0
> 
> outbound_proxy_host = 10.x.y.z
> outbound_proxy_port = 5070
> 
> , to chain proxies. However, when I try to register:
> 
> May 12 17:13:14 maelcum siproxd[27314]: utils.c:197
> gethostbyname(myisp.net) failed: h_errno=1 [Unknown host]
> 
> and it goes downhill from there. They are using a SIP domain which
> does
> not resolve using DNS and siproxd fails there (instead of just
> contacting the outbound proxy). Even adding a bogus record to my DNS
> does not do anything.
> 
> Can this be done?
> 
> Cheers,
> 
> Álex
> 

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/

[Siproxd-users] Using siproxd to access my provider from outside my network

[Alex C. <al...@co...>]

Hi!

My ISP provides both Internet and phone service. I've found out that I
can connect use a SIP soft phone to make/receive calls using the
landline.

I need to use a weird 10.x.y.z non-routeable IP address as my SIP proxy
to do this. This IP is just reachable from my home network, but I would
like to access the SIP service from other networks.

I've tried siproxd with the following configuration changes:

if_inbound  = eth0
if_outbound = eth0

outbound_proxy_host = 10.x.y.z
outbound_proxy_port = 5070

, to chain proxies. However, when I try to register:

May 12 17:13:14 maelcum siproxd[27314]: utils.c:197 gethostbyname(myisp.net) failed: h_errno=1 [Unknown host]

and it goes downhill from there. They are using a SIP domain which does
not resolve using DNS and siproxd fails there (instead of just
contacting the outbound proxy). Even adding a bogus record to my DNS
does not do anything.

Can this be done?

Cheers,

Álex

-- 
   ___
 {~._.~}
  ( Y )
 ()~*~()  mail: alex at corcoles dot net
 (_)-(_)  http://alex.corcoles.net/

[Siproxd-users] Auerswald 5020 and siproxd does not work after upgrade

[Kai D. <kd...@su...>]

Hi,

anyone using siproxd with an Auerswald 5020 telephone system?

I had to upgrade the phone system to enable VOIP on the same level as
POTS. Unfortunately after the upgrade siproxd doesn't work any more for me.


> 20:46:44.069947 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: REGISTER sip:voip.suse.de SIP/2.0
> 20:46:44.071340 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 200 OK
> 20:46:45.513570 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: REGISTER sip:voip.suse.de SIP/2.0
> 20:46:45.515242 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: REGISTER sip:voip.suse.de SIP/2.0
> 20:46:45.541171 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 401 Unauthorized
> 20:46:45.546048 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 401 Unauthorized
> 20:46:45.600825 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: REGISTER sip:voip.suse.de SIP/2.0
> 20:46:45.605098 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: REGISTER sip:voip.suse.de SIP/2.0
> 20:46:45.631536 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 200 OK
> 20:46:45.636897 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 200 OK
> 20:47:01.044070 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: INVITE sip:004...@vo... SIP/2.0
> 20:47:01.045618 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 302 Moved Temporarily
> 20:47:01.052270 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: ACK sip:004...@vo... SIP/2.0

When it comes to the invite, the proxy redirects
INFO:redirecting 00491735876766 -> 000491735876766
using the plugin_prefix

The leading 0 is needed to leave the telephone system.

Same happens when using the regex plugin.

> plugin_regex_desc    = adding a leading 0
> plugin_regex_pattern = ^(sips?:)
> plugin_regex_replace = \10


This has worked before, but not now anymore.



Without plugin_prefix/regex this works:

> 20:54:01.673197 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: INVITE sip:000...@vo... SIP/2.0
> 20:54:01.677449 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: INVITE sip:000...@vo... SIP/2.0
> 20:54:01.703584 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 401 Unauthorized
> 20:54:01.708469 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 401 Unauthorized
> 20:54:01.716745 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: ACK sip:000...@vo... SIP/2.0
> 20:54:01.718885 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: ACK sip:000...@vo... SIP/2.0
> 20:54:01.728231 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: INVITE sip:000...@vo... SIP/2.0
> 20:54:01.734404 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: INVITE sip:000...@vo... SIP/2.0
> 20:54:01.761435 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 100 Trying
> 20:54:01.764314 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 100 Trying
> 20:54:03.450172 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 100 Trying
> 20:54:03.453175 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 100 Trying
> 20:54:03.505223 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 183 Session Progress
> 20:54:03.509743 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 183 Session Progress
> 20:54:10.038751 IP 149.44.176.15.5060 > 10.163.0.158.5060: SIP: SIP/2.0 486 Busy Here
> 20:54:10.041511 IP 172.16.12.2.5060 > 172.16.9.2.5062: SIP: SIP/2.0 486 Busy Here
> 20:54:10.048977 IP 172.16.9.2.5062 > 172.16.12.2.5060: SIP: ACK sip:000...@vo... SIP/2.0
> 20:54:10.049907 IP 10.163.0.158.5060 > 149.44.176.15.5060: SIP: ACK sip:000...@vo... SIP/2.0

Network setup: Auerswald telephone system 172.16.9.2 - siproxd
172.16.12.2 - VPN tunnel entry 10.163.0.158 - 149.44.176.15 (asterisk
based) SIP server

The RFC addresses before and after siproxd are routed.

Might be this is an issue of the telephone system but unfortunately I'm
not able to change the this, only lever I have is siproxd.

Is it the moved temporarily message that confuses my phone system?

Best regards,
Kai Dupke
Senior Product Manager
SUSE Linux Enterprise 15
-- 
Sell not virtue to purchase wealth, nor liberty to purchase power.
Phone:  +49-(0)5102-9310828     Mail: kd...@su...
Mobile: +49-(0)173-5876766      WWW:  www.suse.com

SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)

Re: [Siproxd-users] ERROR 483 too many hops

[Thomas R. <tr...@gm...>]

Hello Kai,

The 483 is the result of siply exceeding the number of hops (Max-Forwards).
Siproxd does not implement specific OPTIONS processing that covers this case
you observe. I will have to look into this.

Would you be able to send me a trace (pcap or siproxd debug log fragment) of
such an OPTIONS message your PBX generates?

Best regards,
/Thomas

On 11/14/2017 11:05 PM, Kai Dupke wrote:
> On 11/14/2017 10:42 PM, Kai Dupke wrote:
>> I looked into the dumps and what I get is
>>
>> TK.5062 > siproxd.5060: SIP: OPTIONS sip:kai@voip SIP/2.0
>> siproxd.5060 > TK.5062: SIP: SIP/2.0 483 Too Many Hops
>>
>> The dumps show the telephone system sends with "Max-Forwards:0" which is
>> rejected by siproxd for obvious reasons.
> 
> Never believe in something that looks obvious.
> 
> RFC3261:
> The target of the OPTIONS request is identified by the Request-URI,
>    which could identify another UA or a SIP server.  If the OPTIONS is
>    addressed to a proxy server, the Request-URI is set without a user
>    part, similar to the way a Request-URI is set for a REGISTER request.
> 
>    Alternatively, a server receiving an OPTIONS request with a *Max-
>    Forwards* header field value of 0 *MAY* respond to the request
>    regardless of the Request-URI.
> 
> So, it looks like the phone system tries to get some data from the
> proxy, by setting max-forward to zero.
> 
> Not sure if the 'may' in the RFC could be answered by the 483 siproxd
> sends or if this is a bug in siproxd handling of the OPTIONS message.
> 
> Does siproxd implements options handling at all (not forwarding an
> options message, but answering a dedicated request via options message
> to the proxy)?
> 
> However, this might explains why it still is working, as the answer is
> optional, even I doubt optional is same as 483.
> 
> Best regards,
> kai
> 
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
> 

Re: [Siproxd-users] ERROR 483 too many hops

[Kai D. <kd...@su...>]

On 11/14/2017 10:42 PM, Kai Dupke wrote:
> I looked into the dumps and what I get is
> 
> TK.5062 > siproxd.5060: SIP: OPTIONS sip:kai@voip SIP/2.0
> siproxd.5060 > TK.5062: SIP: SIP/2.0 483 Too Many Hops
> 
> The dumps show the telephone system sends with "Max-Forwards:0" which is
> rejected by siproxd for obvious reasons.

Never believe in something that looks obvious.

RFC3261:
The target of the OPTIONS request is identified by the Request-URI,
   which could identify another UA or a SIP server.  If the OPTIONS is
   addressed to a proxy server, the Request-URI is set without a user
   part, similar to the way a Request-URI is set for a REGISTER request.

   Alternatively, a server receiving an OPTIONS request with a *Max-
   Forwards* header field value of 0 *MAY* respond to the request
   regardless of the Request-URI.

So, it looks like the phone system tries to get some data from the
proxy, by setting max-forward to zero.

Not sure if the 'may' in the RFC could be answered by the 483 siproxd
sends or if this is a bug in siproxd handling of the OPTIONS message.

Does siproxd implements options handling at all (not forwarding an
options message, but answering a dedicated request via options message
to the proxy)?

However, this might explains why it still is working, as the answer is
optional, even I doubt optional is same as 483.

Best regards,
kai

Re: [Siproxd-users] ERROR 483 too many hops

[Kai D. <kd...@su...>]

On 11/14/2017 09:53 PM, Kai Dupke wrote:
[...]

I'm confused. When going back to the old firmware and restore the old
config I can use siproxd as before. However I still get the 'too many
hops' message.

I will dig into the issue of new firmware does not work anymore
separately, but want still to ask for help on the "too many hops" topic.

I looked into the dumps and what I get is

TK.5062 > siproxd.5060: SIP: OPTIONS sip:kai@voip SIP/2.0
siproxd.5060 > TK.5062: SIP: SIP/2.0 483 Too Many Hops

The dumps show the telephone system sends with "Max-Forwards:0" which is
rejected by siproxd for obvious reasons.

However, the system still works, so not processing the options message
is not an issue (or it works because of not processing, who knows).

What is the intention of the options message and what does it mean it
does not get processed?

Best regards, will try a systems update the next weekend,
kai

[Siproxd-users] ERROR 483 too many hops

[Kai D. <kd...@su...>]

Hi,

I am a proud user of siproxd for a while and it served me ever well.

Due to an upgrade of my telephone system I ended with an ERROR 483....

Unfortunately I had to upgrade my telephone system (Auerswald 5020) and
with the new firmware I now get "SIP/2.0 483 Too Many Hops" when
connecting via siproxd to a registrar.


... however, after downgrading the firmware back to the version worked
before I still have the same error.

So it might be just coincident.

Any ad hoc solution available before I dig into details, analyze the
data and patch siproxd if needed?

I'm still on siproxd 0.8.2 - sorry. If an upgrade fix it please let me
know as well.

It already build in
https://build.opensuse.org/package/show/home:kdupke:siproxd-0.8.3dev/siproxd

If you want me to add repositories/platforms please let me know.

This of course is totally untested yet.

Best regards,
Kai Dupke
Senior Product Manager
SUSE Linux Enterprise 15
-- 
Sell not virtue to purchase wealth, nor liberty to purchase power.
Phone:  +49-(0)5102-9310828     Mail: kd...@su...
Mobile: +49-(0)173-5876766      WWW:  www.suse.com

SUSE Linux GmbH - Maxfeldstr. 5 - 90409 Nuernberg (Germany)
GF:Felix Imendörffer,Jane Smithard,Graham Norton,HRB 21284 (AG Nürnberg)

Re: [Siproxd-users] loadsharing or multiple instance setup

[Thomas R. <tr...@gm...>]

Hi Sascha,

In this case you would need to run multiple instances of siproxd.

1) The outbound interfaces (alias IPs) need to be configured in such a way
that they appear on individual alias interfaces (like eth0:1, eth0:2, ...).
Then in the  siproxd config you need to reference the appropriate outbound
interface.

2) You can use the same inbound interface (same IP) but must use a different
port numbers (for SIP signaling and RTP port range for audio). The Clients
then need to be distributed to the individual instances of siproxd by
configuring the outbound proxy setting of the client, or use a transparent
proxy setup (using iptables redirect rules).

Best regards,
/Thomas

On 09/08/2017 04:08 PM, Sascha Müller via Siproxd-users wrote:
> Hello,
> 
> we have siproxd running on a Debian machine and it works very well.
> 
> We have the problem that our ISP doesn't allow more than 100 registrations per IP, so we had the idea to use more than one outbound interface with different IPs und build up a loadsharing.
> 
> Is that possible and how it should work.
> 
> An other idea is to run multiple instances from siproxd and use the access control to switch the users between the instances. Is it possible to run more than one instance with the same inbound interface?
> 
> Best regards,
> Sascha
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Siproxd-users mailing list
> Sip...@li...
> https://lists.sourceforge.net/lists/listinfo/siproxd-users
> 

[Siproxd-users] loadsharing or multiple instance setup

[Sascha M. <sas...@in...>]

Hello,

we have siproxd running on a Debian machine and it works very well.

We have the problem that our ISP doesn't allow more than 100 registrations per IP, so we had the idea to use more than one outbound interface with different IPs und build up a loadsharing.

Is that possible and how it should work.

An other idea is to run multiple instances from siproxd and use the access control to switch the users between the instances. Is it possible to run more than one instance with the same inbound interface?

Best regards,
Sascha

[Siproxd-users] [CFP] reminder! FOSDEM RTC dev-room talks: deadline tomorrow

[FOSDEM R. T. <fos...@fr...>]

Reminder: speaker's deadline tomorrow, 17 November at 23:59 UTC

The Free RTC dev-room has already received some really exciting
talk proposals but there is still time for people to propose talks or
encourage friends or colleagues to speak.

Many other dev-rooms also have a deadline in the next few days and if
your topic is applicable to more than one dev-room, you are welcome
to make more than one submission.  Please contact us or put a note in
the memo field at the top of the talk proposal if you do that.

All projects are encouraged to consider making a lightning talk too,
it is an excellent opportunity to get exposure for your project:
even though you only have 15 minutes, it can be a much larger and more
diverse audience than in some dev-rooms.

For full details, please see the original call for participation:
https://danielpocock.com/fosdem-2017-rtc-cfp

We invite all potential speakers and participants to discuss the selection 
process and other aspects of FOSDEM on the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc

[Siproxd-users] [CFP] FOSDEM 2017, RTC devroom, speakers, volunteers neeeded

[FOSDEM R. T. <fos...@fr...>]

FOSDEM is one of the world's premier meetings of free software developers,
with over five thousand people attending each year.  FOSDEM 2017
takes place 4-5 February 2017 in Brussels, Belgium.  https://fosdem.org

This email contains information about:
- Real-Time communications dev-room and lounge,
- speaking opportunities,
- volunteering in the dev-room and lounge,
- related events around FOSDEM, including the XMPP summit,
- social events (the legendary FOSDEM Beer Night and Saturday night dinners
    provide endless networking opportunities),
- the Planet aggregation sites for RTC blogs

Call for participation - Real Time Communications (RTC)
=======================================================

The Real-Time dev-room and Real-Time lounge is about all things involving
real-time communication, including: XMPP, SIP, WebRTC, telephony,
mobile VoIP, codecs, peer-to-peer, privacy and encryption.  The dev-room
is a successor to the previous XMPP and telephony dev-rooms.
We are looking for speakers for the dev-room and volunteers and
participants for the tables in the Real-Time lounge.

The dev-room is only on Saturday, 4 February 2017.  The lounge will
be present for both days.

To discuss the dev-room and lounge, please join the FSFE-sponsored
Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc

To be kept aware of major developments in Free RTC, without being on the
discussion list, please join the Free-RTC Announce list:
http://lists.freertc.org/mailman/listinfo/announce

Speaking opportunities
----------------------

Note: if you used FOSDEM Pentabarf before, please use the same account/username

Real-Time Communications dev-room: deadline 23:59 UTC on 17 November.
Please use the Pentabarf system to submit a talk proposal for the
dev-room.  On the "General" tab, please look for the "Track" option and
choose "Real-Time devroom".  https://penta.fosdem.org/submission/FOSDEM17/

Other dev-rooms and lightning talks: some speakers may find their topic is
in the scope of more than one dev-room.  It is encouraged to apply to more
than one dev-room and also consider proposing a lightning talk, but please
be kind enough to tell us if you do this by filling out the notes in the form.
You can find the full list of dev-rooms at
   https://www.fosdem.org/2017/schedule/tracks/
and apply for a lightning talk at https://fosdem.org/submit

Main track: the deadline for main track presentations is 23:59 UTC
31 October.  Leading developers in the Real-Time Communications
field are encouraged to consider submitting a presentation to
the main track at https://fosdem.org/submit

First-time speaking?
--------------------

FOSDEM dev-rooms are a welcoming environment for people who have never
given a talk before.  Please feel free to contact the dev-room administrators
personally if you would like to ask any questions about it.

Submission guidelines
---------------------

The Pentabarf system will ask for many of the essential details.  Please
remember to re-use your account from previous years if you have one.

In the "Submission notes", please tell us about:
- the purpose of your talk
- any other talk applications (dev-rooms, lightning talks, main track)
- availability constraints and special needs

You can use HTML and links in your bio, abstract and description.

If you maintain a blog, please consider providing us with the
URL of a feed with posts tagged for your RTC-related work.

We will be looking for relevance to the conference and dev-room themes,
presentations aimed at developers of free and open source software about
RTC-related topics.

Please feel free to suggest a duration between 20 minutes and 55 minutes
but note that the final decision on talk durations will be made by the
dev-room administrators.  As the two previous dev-rooms have been
combined into one, we may decide to give shorter slots than in previous
years so that more speakers can participate.

Please note FOSDEM aims to record and live-stream all talks.
The CC-BY license is used.

Volunteers needed
=================

To make the dev-room and lounge run successfully, we are looking for
volunteers:

- FOSDEM provides video recording equipment and live streaming,
  volunteers are needed to assist in this
- organizing one or more restaurant bookings (dependending upon number of
  participants) for the evening of Saturday, 4 February
- participation in the Real-Time lounge
- helping attract sponsorship funds for the dev-room to pay for the
  Saturday night dinner and any other expenses
- circulating this Call for Participation to other mailing lists

See the mailing list discussion for more details about volunteering:
https://lists.fsfe.org/pipermail/free-rtc/2016-October/000285.html

Related events - XMPP and RTC summits
=====================================

The XMPP Standards Foundation (XSF) has traditionally held a summit
in the days before FOSDEM.  There is discussion about a similar
summit taking place on 2 and 3 February 2017
http://wiki.xmpp.org/web/Summit_21 - please join the mailing
list for details: http://mail.jabber.org/mailman/listinfo/summit

We are also considering a more general RTC or telephony summit,
potentially in collaboration with the XMPP summit.
Please join the Free-RTC mailing list and send an email if you would
be interested in participating, sponsoring or hosting such an event.

Social events and dinners
=========================

The traditional FOSDEM beer night occurs on Friday, 3 February.

On Saturday night, there are usually dinners associated with
each of the dev-rooms.  Most restaurants in Brussels are not so
large so these dinners have space constraints and reservations are
essential.  Please subscribe to the Free-RTC mailing list for
further details about the Saturday night dinner options and how
you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc

Spread the word and discuss
===========================

If you know of any mailing lists where this CfP would be relevant, please
forward this email. If this dev-room excites you, please blog or microblog
about it, especially if you are submitting a talk.

If you regularly blog about RTC topics, please send details about your
blog to the planet site administrators:

  All projects    http://planet.freertc.org       pl...@fr...

  XMPP            http://planet.jabber.org        ra...@ik...

  SIP             http://planet.sip5060.net       pl...@si...
    (Español)     http://planet.sip5060.net/es/   pl...@si...

Please also link to the Planet sites from your own blog or web site as
this helps everybody in the free real-time communications community.

Contact
=======

For any private queries, contact us directly using the address 
fos...@fr... and for any other queries please ask on
the Free-RTC mailing list:
https://lists.fsfe.org/mailman/listinfo/free-rtc

The dev-room administration team:

  Saúl Ibarra Corretgé <sa...@gm...>
  Iain R. Learmonth <ir...@de...>
  Ralph Meijer <ra...@ik...>
  Daniel-Constantin Mierla <mi...@gm...>
  Daniel Pocock <da...@po...>