[OpenSIPS-Users] siptrace picks incorrect source socket

Wed Feb 8 16:12:45 EST 2017

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 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; 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>
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:
>
>    223 loadmodule "siptrace.so"
>    224 modparam("siptrace", "trace_on", 1)
>    225 modparam("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>
> wrote:
>
>> Hi Jeff,
>>
>> Thank you for detailed report. I was able to reproduce and fix it. Please
>> see:
>>     https://github.com/OpenSIPS/opensips/commit/b30af734cdb84991
>> e1f906e3920a94e87c33ea04
>>
>> If you confirm the fix, I will do the backporting to 2.2 too.
>>
>> Thanks and Regards,
>>
>> Bogdan-Andrei Iancu
>> OpenSIPS Founder and Developerhttp://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
>> listen=tls:131.132.133.134:5061
>> listen=hep_udp: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;t
>> ransport=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 listUsers at lists.opensips.orghttp://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>
>> _______________________________________________
> Users mailing listUsers at lists.opensips.orghttp://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/20170208/7a215a5a/attachment-0001.html>