Activity for Thomas Ries
-
Thomas Ries modified ticket #66
year-2038 issue in plugin_blacklist
-
Thank you for reporting this issue. The suggested fix has been implemented with commit 879925a80b5d80f425abeb82d934b1425c7830cd
-
year-2038 issue in plugin_blacklist
-
1) conditional rewriting using plugin_regex: plugin_regex_desc = prefix outgoing 10 digit numbers with a leading '1' #plugin_regex_pattern = ^(sips?:)(\+?)(.{10}@) plugin_regex_pattern = ^(sips?:)(\+?)([0-9]{10}@) plugin_regex_replace = \1\21\3 or maybe (without '+' prefixed, 10 digit numbers only) plugin_regex_desc = prefix outgoing 10 digit numbers without leading '+' with a leading '1' plugin_regex_pattern = ^(sips?:)([0-9]{10}@) plugin_regex_replace = \11\2 only 10 digit numbers will be processed....
-
Please try without plugin_prefix being active. Looking at the log, I have the impression that the PBX issues a re-INVITE (directed towards flowroute) for the ongoing call that is being affected by plugin_prefix and causes the call to fail. If plugin_prefix is causing an issue in this setup, there are other ways to prefix outgoing calls with the digit 1 (plugin_regex, allows conditionally rewriting outgoing call targets via regular expressions).
-
ping@invalid -> seems to be used by the provider (34.226.36.32) as dummy "From" address in OPTION requests, probably a "ping" feature to check if the client (your PBX) is alive. NULL@192.168.0.189 -> Response Point does send Contact Headers with no user part (only the hostname part) in INVITE requests. This is technically legal and should not cause any issues with siproxd. In the logs, this missing user part is shown as "NULL" to indicate the missing user. There seems to be an unwanted trigger of...
-
My guess would be, you have messed up the siprunk configuration (siptrunk_account): b4: plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyy8000@us-east-va.sip.flowroute.com <<<<< plugin_siptrunk_numbers_regex = ^+?1yyyyyy985([1-9])$ now: plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyy9853@us-east-va.sip.flowroute.com <<<<< plugin_siptrunk_numbers_regex = ^\+?1yyyyyy985([1-9])$
-
12:36:16.415 ERROR:plugin_siptrunk.c:168 Regular expression [^+?1yyyyyy985([1-9])$] failed to compile: Invalid preceding regular expression My bad, missed the '\' character in the REGEX (must have gotten lost between brain and keyboard). Actually, the HTML editor of sourceforge does make them disappear. ^\+?1yyyyyy985([1-9])$ That should be the correct REGEX (at least the preview does show it properly).
-
Your provider uses two different number formats. In the Request URI a format without leading '+' is used, in the To Header the number format does include the leading '+'. check here: 19:36:56.272 plugin_siptrunk.c:203 Request URI: [1yyyyyy9853] 19:36:56.272 plugin_siptrunk.c:209 To: header: [+1yyyyyy9853] 19:36:56.272 plugin_siptrunk.c:231 plugin_siptrunk: matched trunk on rule 0 [^1yyyyyy985([1-9])$] 19:36:56.273 plugin_siptrunk.c:234 plugin_siptrunk: Trunk [Response Point], Account [sip:1yyyyyy8000@us-east-va.sip.flowroute.com]...
-
The debug log looks fine, I cannot see anything bad in the behavior of siproxd. All outgoing packets look correct. What happens is basically: (You can check RFC3261, page 11 for a graphical representation of the signalling flow) <--- INVITE ---> 100 Trying ---> 180 Ringing phone being picked up ---> 200 OK The required 'ACK' request (completes the call establishmend) from the remote side is never received. Either the outgoing SIP packets never make it to your provider, or the ACK is not sent / sent...
-
The number you register is 1yyyyyyy8000. This means, at this point only this number is known and handled by siproxd. If you have a whole number broch attached to this account (account being "1yyyyyyy8000"), then you need to pass this information to siproxd using the plugin_siptrunk. load_plugin=plugin_siptrunk.la plugin_siptrunk_name = Response Point plugin_siptrunk_account = sip:1yyyyyyy8000@us-east-va.sip.flowroute.com plugin_siptrunk_numbers_regex = ^<REGEX to match the whole number block>$ Waring:...
-
00:43:03 sock.c:281 received UDP packet from [192.168.0.189:1852] count=422 ---BUFFER DUMP follows--- 52 45 47 49 53 54 45 52 20 73 69 70 3a 75 73 2d REGISTER sip:us- 65 61 73 74 2d 76 61 2e 73 69 70 2e 66 6c 6f 77 east-va.sip.flow 72 6f 75 74 65 2e 63 6f 6d 20 53 49 50 2f 32 2e route.com SIP/2. 30 0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 0..Via: SIP/2.0/ Your Phone requests registration with "us-east-va.sip.flowroute.com", but siproxd (resp. the host running siproxd on) cannot resolve this host...
-
00:43:03 sock.c:281 received UDP packet from [192.168.0.189:1852] count=422 ---BUFFER DUMP follows--- 52 45 47 49 53 54 45 52 20 73 69 70 3a 75 73 2d REGISTER sip:us- 65 61 73 74 2d 76 61 2e 73 69 70 2e 66 6c 6f 77 east-va.sip.flow 72 6f 75 74 65 2e 63 6f 6d 20 53 49 50 2f 32 2e route.com SIP/2. 30 0d 0a 56 69 61 3a 20 53 49 50 2f 32 2e 30 2f 0..Via: SIP/2.0/ Your Phone requests registration with "us-east-va.sip.flowroute.com", but siproxd (resp. the host running siproxd on) cannot resolve this host...
-
support reproducible builds
-
https://github.com/hb9xar/siproxd/commit/4750bea4ffedb4543a404dafc979c2b16b53e523 implements support for SOURCE_DATE_EPOCH
-
PATCH to 0.7.2 need host_inbound for virtual lan ip?
-
Create UA RTP port mapping dynamically using UPnP/NAT-PCP to remove the need for RTP proxy
-
Outgoing SIP Calls terminated after 30 seconds
-
being closed due to inactivity
-
support reproducible builds
-
being worked on, check https://github.com/hb9xar/siproxd/commit/f47a3e0f0bcd04b425fe31b547b99c19f0a7d9f7
-
Yes, I did mean 163 (the '1' did get lost). Just re-tested with beta 165, Issue with saving does still exist. How to reproduce: - start YAAC - View -> Layers -> Select Geograhpical Map Layers - Change Color of "Limited access highway" and "ramp to limited access hwy" - Save Map Settings -> test.yaacmapset - Restore default Settings -> changes lost - Load Map Settings -> test.yaacmapset Changes made in step 2 above are not restored. However, with beta 165, changes in map layers (color) do survive...
-
Custom map colors do not survive restart & unable to save/reload
-
git master should now build without warnings (gcc 9.3.0)
-
Looking at the debug log, it seems that you have mixed up the inbound and outbound networks. the local UA (phone) must be located in the inbound network the Registrar (PBX) must be located in the outbound network This of course will mess up everything, masquerading stuff with the wrong IP addresses, etc. Also, that's the reason why the fritzbox does send RTP traffic to the 10.x.x.x side of siproxd and not to the 192.168.x.x address of the siproxd host.
-
OF course, you are right. My bad.
-
No. snprintf does include the terminating \0, also if the size limit is triggered. The limit is including the terminating \0 (-> 6 = 5 digits + terminating \0).
-
First, make really sure that no NAT helpers are involved on the system where siproxd is running. 95% of RTP related problems originate by NAT helpers (like SIP conntrack kernel modules). Second, to really see what is going on in your case, a debug log is needed (including the REGISTER and INVITE sequence, up to the failure). See 6.1. Problem Reporting
-
Should be fixed in git master by now.
-
The debug log fragment is too short. To have a chance to properly analyze request processing, the log must be taken with debuglevel=-1 and it should include at least: - Registration - Call Setup, up to the point where the malfunction is observed The above fragment only seems to cover part of the BYE sequence (this is just a guess), so no change to figure out what is really going on there. If you are concerned about publishing confidential information with your log you may send the log directly to...
-
Hi, siproxd does not have support for IPv6. It is not possible to proxy IPv6 SIP traffic. Regards, /Thomas
-
Yes, the plugin_siptrunk will help you with this. # Plugin_siptrunk # # Plugin to handle SIP Trunks where using *one* single SIP account a # whole number block is routed. This means an incoming INVITE does carry # the target number (in SIP URI or To: header field) but does not really # carry any clear indications to which account it belongs to. # Thus, we need some help - a mapping of the number blocks used in a SIP # trunk and the corresponding SIP account (as used during REGISTER) # # ..._name:...
-
Hi Stef, Can you try the latest bleedingedge snapshot or the master branch of the git repo? /Thomas
-
Hi, How does your configuration look like (the part for plugin_stripheader)? Can you provide a debug log covering the reception, processing and transmission of such a SIP packet? Please note that plugin_stripheader is called before all the processing is done, so "Record-Route" headers added by siproxd itself (as part of the processing) will still be present. /Thomas
-
New Siproxd Release 0.8.3
-
siproxd and gcc-10: multiple definition of `configuration' error
-
Hello Seb, Thank you for bringing this to my attention. Yes, the proposed patch is OK. This will be fixed in the next released version of siproxd. Best regards, /Thomas
-
As stated above, if you configure your UA properly, those two headers will be sent correctly by the UA itself.
-
This is a basic design decision that has been made in the very beginning. Siproxd behaves like a proxy It alters header required for NAT traversal It shall not have any knowledge of user credentials (which would be required in a back2back design) There shall be no configuration required in siproxd for individual UAs traversing siproxd. In a back2back design, there would be the requirement to know about the UAs as well as the mapping of the external to internal SIP accounts. This design has its specific...
-
Siproxd acts as a proxy. This means that on your User-Agent (phone) you configure the account with the credentials as provided by your registrar. If your local client (phone) is configured correctly that way, the From header and SIP URIs.
-
Log at around 16:19:46: To me it looks like either: phone does not receive the 200 OK send by siproxd or phone does not send (or siproxd does not receive) the ACK This causes repetitions of the 200 OK (from the registrar). Same later in the log: 16:20:03 outgoing INVITE 16:20:06 incoming "200 OK" that is not ack'd by the phone with an ACK repetitions "200 OK" from registrar 16:20:18 BYE from regsistrar (Reason: SIP;cause=408;text="Request Timeout (1:2)" You have to figure out (network trace on the...
-
Please contact me directly via my SF email address: tries at users .sourceforge .net
-
Create a fully detailed debug log (debug_level=-1) - this includes sufficient information to analyze the SIP traffic, internal doings of siproxd and usually allows to diagnose a problem quickly.
-
TCP fragment reassembly fails
-
TCP fragment reassembly fails
-
Thank you. This fix will be included in the next release as well as into the snapshots.
-
More information about NAT can be found here: https://en.wikipedia.org/wiki/Network_address_translation (see especially the section "Applications affected by NAT") Siproxd is designed to cover the typical case where VoIP equipment in a local network using RFC1918 address space (private IP adrdesses) needs to communicate with a Registrar in the public Internet. This is the typical home- and small office setup. Your use case is completely different. I'm not saying it can't be done, but it ist not a...
-
Hi, No this will not work. Siproxd is desgined to help with NATs where the Client (phone) is in a private network segment and the PBX / SIP provider is in the publicc Internet. you are basically trying to do the reverse. /Thomas
-
Hello, I'd say it depends how your issue exactly looks like. An INVITE starts a new SIP dialog. In such a request there are no via headers involved that would/can influence routing (the only via header is the one put in by the client itself for the return path). So I don't understand where you see the involvenement of a Via header. If (from a client side of view) a specific proxy is to be used always, then usually this can be configured in some way on the client (SIP phone). Siproxd could also enforce...
-
Touche - I realize that my arguments can be used against me ;-) But if gpg-agent is running, then there are no other reasons that prevent enigmail to work with gpg pre 2.0.16? A first quick and dirty test (hacking the MINIMUM_GPG_VERSION) does seem to work at first glance. Ensuring that gpg-agent is automatically started during login is not that complicated, it requires placing some lines to .xsession or .bash_profile. Might I suggest a feature request to implement some kind override flag ("yes,...
-
Hi all, Enigmail 2.0 does no longer work on CentOS 6 - it requires at least gnupg 2.0.16 whereas CentOS 6 does supply 2.0.14. As it's more likely for hell to freeze over than Centos 6 to switch to a newer gnupg release - what options do CentOS 6 users have? upgrade / switch to CentOS 7 - not a short term solution. CentOS 6 is still supported until Nov 2020 roll your own gnupg package - not something that every CentOS user might be capable or wanting to do any chance that Enigmail can be made to still...
-
Hi, Siproxd does not include any client functionality, so it cannot inititate a REGISTER on its own. If yor IMS core provides UAC functionality towards your operator and can send REGISTER requests it should work.
-
This looks like a straight forward setup. eth0 - inbound interface eth1 - outbound interface It will require that the UACs on the eth0 network will REGISTER at the freeswitch on the eth1 network. An example configuration covering exactly this setup does not exist. Regards, /Thomas
-
Correct, siproxd does currently not support SIP TLS, nor SIPS. Currently there are no plans to implement such. /Thomas
-
Hello Dr. Blaxthos, very likely siproxd may help you here. You did not mention exactly...
-
:-) Bug was actually fixed quite some time ago but this entry was never updated....
-
New Siproxd Release 0.8.2
-
Alert-Info does not work through siproxd
-
Support multiple devices with same registration
-
This is currently a known limitation. Workaround: Run multiple siproxd instances...
-
SIP protocol operational errata when NAT with PAT is applied
-
library search path isn't set
-
Hi, I just got OpenSearchServer up and running. Goal is to index all web content...
-
Hi, I just got OpenSearchServer up and running. Goal is to index all web content...
-
masquerade always set
-
ua_string doesn't allow spaces in string
-
Compile/Optimization Warning
-
Compile Warning - dejitter.c
-
Compile warning - siproxd.c
-
Compile Warning - sock.c
-
-Wall hard coded in Makefile in src/
-
Patch for implicit declarations in plugins.c
-
Thanks, fix has been integrated. Will be available in next release.
1
