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 <[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, 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
        [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

Reply via email to