[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