[OpenSIPS-Users] siptrace picks incorrect source socket

Bogdan-Andrei Iancu bogdan at opensips.org
Wed Feb 8 16:21:05 EST 2017


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

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 <ionutionita at opensips.org 
> <mailto:ionutionita at opensips.org>> 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
>>     <bogdan at opensips.org <mailto:bogdan at opensips.org>> 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, and its
>>>         ephemeral TCP client port for this call is 61235.  The
>>>         OpenSIPS proxy is at 131.132.133.134 listening on UDP 5060
>>>         and TLS 5061.  Also on 131.132.133.134 there is a Freeswitch
>>>         media server listening on UDP 5080.  The UAC sends an INVITE
>>>         to the proxy over TLS which routes 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
>>>         Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>>         http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>         <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>>
>>     _______________________________________________
>>     Users mailing list
>>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>     <http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
>     _______________________________________________ Users mailing list
>     Users at lists.opensips.org <mailto:Users at lists.opensips.org>
>     http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>     <http://lists.opensips.org/cgi-bin/mailman/listinfo/users> 
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170208/1b538c08/attachment-0001.html>


More information about the Users mailing list