[OpenSIPS-Users] siptrace picks incorrect source socket

Ionut Ionita ionutionita at opensips.org
Tue Feb 7 03:08:23 EST 2017


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; 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;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
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20170207/e8b37ba0/attachment-0001.html>


More information about the Users mailing list