Hi Jeff,Somehow it's very difficult to accept your report, as both IPv4 and IPv6 are handled (in terms of reporting) exactly in the same way. Are the logs from "pipport2su" showing the same IPs too ?
Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com On 02/10/2017 04:29 PM, Jeff Pyle wrote:
Bogdan,Yes. Here's a Homer DB record written on the capture server from the HEP packet:date: 2017-02-10 09:08:04 method: REGISTERvia_1: SIP/2.0/TLS [2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5]:60640;branch=z9hG4bKo9TPB60p8Y2aQLbm;rportsource_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5 destination_ip: 2607:FB90:1234:5678:9ABC:DEF0:955D:F1E5 (IPs mangled to protect the guilty.) - JeffOn Wed, Feb 8, 2017 at 4:21 PM, Bogdan-Andrei Iancu <[email protected] <mailto:[email protected]>> wrote:Jeff, So, for the REGISTER request, in HEP, you have as both src and dst the incoming IP of the request ?? Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com <http://www.opensips-solutions.com> On 02/08/2017 11:12 PM, Jeff Pyle wrote:Bogdan and team, This does appear to fix the source interface issue ... at least for IPv4. On IPv6, the errors are gone, but the source address is being reported as both the source and destination address for a message in siptrace. I'm using the following: listen=hep_udp:127.0.0.1:4530 <http://127.0.0.1:4530> children=1 listen=hep_udp:[::1]:4530 children=1 # Not doing anything loadmodule "proto_hep.so" modparam("proto_hep", "hep_id", "[heppy] 127.0.0.1:9060 <http://127.0.0.1:9060>; version=3; transport=udp") loadmodule "siptrace.so" modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_id", "[tid]uri=hep:heppy") I was looking at a registration in this particular case captured with sip_trace("tid", "t"). - Jeff On Tue, Feb 7, 2017 at 3:08 AM, Ionut Ionita <[email protected] <mailto:[email protected]>> wrote: It's not that syntax anymore, but the docs weren't updated. Now you have to declare an hep_id in proto_hep like: /modparam("proto_hep", "hep_id", "[heppy] 10.0.0.135:6061 <http://10.0.0.135:6061>; version=3; transport=tcp")/ then in sip_trace you have to declare a trace_id like: / modparam("siptrace", "trace_id", "[hep_id]uri=hep:heppy")/ The docs will be updated soon. Regards, Ionut Ionita OpenSIPS Developer On 02/07/2017 04:27 AM, Jeff Pyle wrote:Hi Bogdan, Now it won't start. I see the following errors on config check: Feb 6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_uri: Invalid key <version> in trace id! Feb 6 21:21:03 [30051] ERROR:siptrace:parse_siptrace_id: invalid uri <3;transport=udp;> Feb 6 21:21:03 [30051] ERROR:siptrace:parse_trace_id: failed to parse siptrace uri [3;transport=udp;] Feb 6 21:21:03 [30051] CRITICAL:core:yyerror: parse error in config file /usr/local//etc/opensips/opensips.cfg, line 225, column 20-21: Parameter <trace_id> not found in module <siptrace> - can't set Feb 6 21:21:03 [30051] ERROR:core:main: bad config file (1 errors) Feb 6 21:21:03 [30051] NOTICE:core:main: Exiting.... The script has: 223loadmodule "siptrace.so" 224modparam("siptrace", "trace_on", 1) 225modparam("siptrace", "trace_id", "[tid]uri=hep:127.0.0.1:9060 <http://127.0.0.1:9060>;version=3;transport=udp;") This is on 2.3/devel git revision 2bcf891 from around 01:00 UTC Feb 07. - Jeff On Sun, Feb 5, 2017 at 11:00 AM, Bogdan-Andrei Iancu <[email protected] <mailto:[email protected]>> wrote: Hi Jeff, Thank you for detailed report. I was able to reproduce and fix it. Please see: https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991e1f906e3920a94e87c33ea04 <https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991e1f906e3920a94e87c33ea04> If you confirm the fix, I will do the backporting to 2.2 too. Thanks and Regards, Bogdan-Andrei Iancu OpenSIPS Founder and Developer http://www.opensips-solutions.com <http://www.opensips-solutions.com> On 02/04/2017 04:41 AM, Jeff Pyle wrote:Hello, I recently enabled siptrace on an OpenSIPS 2.2.2 system acting as a registrar and a proxy. It has one IPv4 address with several ports for UDP, TCP and TLS. In a case where the INVITE is relayed from TLS to UDP, the replies to the UAC are incorrectly being reported as coming from the UDP socket. In the below scenario the UAC is at 64.65.66.67, andits ephemeral TCP client port for this call is 61235. The OpenSIPS proxy is at 131.132.133.134 listening onUDP 5060 and TLS 5061. Also on 131.132.133.134 thereis a Freeswitch media server listening on UDP 5080. The UAC sends an INVITE to the proxy over TLS whichroutes it to the media server over UDP. The replies relayed to the UAC are reported as having come from port 5060 over UDP when in reality they have come from port 5061 over TCP (TLS). My config: listen=udp:131.132.133.134:5060 <http://131.132.133.134:5060> listen=tls:131.132.133.134:5061 <http://131.132.133.134:5061> listen=hep_udp:127.0.0.1:9030 <http://127.0.0.1:9030> loadmodule "siptrace.so" modparam("siptrace", "trace_on", 1) modparam("siptrace", "trace_id", "[hep]uri=hep:127.0.0.1:9060 <http://127.0.0.1:9060>;transport=udp;") Debugs: INVITE in from UAC over TLS Feb 3 21:20:22 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061 INVITE out to media server over UDP Feb 3 21:20:22 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080 100 Trying in from media server over UDP Feb 3 21:20:22 testproxy /usr/sbin/opensips[24650]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24650]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 180 Ringing in from media server over UDP Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 180 Ringing out to UAC over TLS (even though it reports UDP) Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235 200 OK in from media server over UDP Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 200 OK out to UAC over TLS (even though it reports udp) Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 Feb 3 21:20:22 testproxy /usr/sbin/opensips[24651]: DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235 ACK in from UAC over TLS Feb 3 21:20:23 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 22, host 64.65.66.67 , port 61235 Feb 3 21:20:23 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 22, host 131.132.133.134 , port 5061 ACK out to media server over UDP Feb 3 21:20:23 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5060 Feb 3 21:20:23 testproxy /usr/sbin/opensips[24673]: DBG:siptrace:pipport2su: proto 17, host 131.132.133.134 , port 5080 Everything routes properly, but it isn't reported by siptrace properly. Is this a bug or am I doing something wrong? - Jeff _______________________________________________ Users mailing list [email protected] <mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>_______________________________________________ Users mailing list [email protected] <mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>_______________________________________________ Users mailing list [email protected] <mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
