siproxd-users Mailing List for siproxd - SIP proxy/masquerading daemon
Status: Beta
Brought to you by:
tries
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(4) |
Oct
(1) |
Nov
(3) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(3) |
Feb
|
Mar
(9) |
Apr
(7) |
May
|
Jun
(3) |
Jul
(1) |
Aug
(1) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(1) |
2004 |
Jan
(3) |
Feb
(3) |
Mar
|
Apr
(4) |
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
(2) |
Nov
(1) |
Dec
|
2005 |
Jan
(14) |
Feb
(1) |
Mar
(1) |
Apr
(2) |
May
(6) |
Jun
|
Jul
|
Aug
(7) |
Sep
(1) |
Oct
(5) |
Nov
|
Dec
|
2006 |
Jan
(5) |
Feb
(4) |
Mar
(3) |
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(2) |
Dec
(4) |
2007 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(10) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
(7) |
2008 |
Jan
(2) |
Feb
(2) |
Mar
(2) |
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
|
2009 |
Jan
|
Feb
(4) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
(4) |
Dec
(1) |
2010 |
Jan
(2) |
Feb
(4) |
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
(4) |
Dec
(4) |
2011 |
Jan
(2) |
Feb
(1) |
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
(1) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
2012 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2013 |
Jan
|
Feb
|
Mar
|
Apr
(9) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(5) |
Oct
|
Nov
|
Dec
|
2014 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2016 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(1) |
Nov
(4) |
Dec
|
2018 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(3) |
Oct
|
Nov
|
Dec
|
2019 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
(1) |
From: Evgeniy S. <itn...@gm...> - 2020-12-13 11:15:59
|
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 |
From: Thomas R. <tr...@gm...> - 2020-08-24 20:13:03
|
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 |
From: Thomas R. <tr...@gm...> - 2020-05-21 08:49:43
|
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 > |
From: Panocila S. <pan...@gm...> - 2020-05-19 09:44:14
|
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 |
From: Saint M. <ve...@gm...> - 2020-05-11 04:16:20
|
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 |
From: Kai D. <KD...@su...> - 2019-08-12 07:59:48
|
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) |
From: Tim W. <si...@wo...> - 2019-08-09 10:00:23
|
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 >> > > |
From: Thomas R. <tr...@gm...> - 2019-07-30 16:58:03
|
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 > |
From: Tim W. <si...@wo...> - 2019-07-28 10:09:28
|
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, |
From: Kai D. <KD...@su...> - 2019-03-18 13:56:08
|
Hi, I wonder if anyone is using FUZE with siproxd and might share a config or experience? Best regards, Kai Dupke |
From: <Gai...@gm...> - 2019-03-15 16:57:55
|
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 |
From: bloodcarter <blo...@gm...> - 2018-09-05 11:44:28
|
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 > |
From: Thomas R. <tr...@gm...> - 2018-09-04 17:12:46
|
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 > |
From: bloodcarter <blo...@gm...> - 2018-09-04 11:36:58
|
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 |
From: Alex C. <al...@co...> - 2018-05-12 19:36:48
|
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/ |
From: Alex C. <al...@co...> - 2018-05-12 18:09:20
|
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/ |
From: Kai D. <kd...@su...> - 2018-01-13 20:46:06
|
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) |
From: Thomas R. <tr...@gm...> - 2017-11-14 22:55:37
|
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 > |
From: Kai D. <kd...@su...> - 2017-11-14 22:05:20
|
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 |
From: Kai D. <kd...@su...> - 2017-11-14 21:43:05
|
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 |
From: Kai D. <kd...@su...> - 2017-11-14 20:53:58
|
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) |
From: Thomas R. <tr...@gm...> - 2017-10-17 20:24:33
|
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 > |
From: Sascha M. <sas...@in...> - 2017-09-08 15:19:56
|
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 |
From: FOSDEM R. T. <fos...@fr...> - 2016-11-16 14:31:41
|
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 |
From: FOSDEM R. T. <fos...@fr...> - 2016-10-24 09:28:34
|
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...> |