[OpenSIPS-Users] add_path_received and TLS - received address problem

[Mark Allen]

Hi Liviu

On Wed, 21 Jul 2021 at 16:45, Liviu Chircu <liviu at opensips.org> wrote:

>
> > ERROR:core:unescape_user: invalid hex digit <37>
> > ERROR:path:path_rr_callback: failed to unescape
> > received=sip:35.x.x.x:60026%%3btransport%%3dtls
>
> ...Which scenario of the two below would you
> say we are in, and with what degree of certainty?
>
> A.  OpenSIPS generates those erroneous '%%' strings right from the
> beginning, when building the Path headers and passing through the
> SUBSCRIBE or REGISTER requests.


> B.  The Path headers are okay when generated by OpenSIPS (containing
> just '%3b' and '%3d'), but the issue is on the backend side, which
> originates ping messages with doubled '%%' strings in Route headers,
> which OpenSIPS is obviously having a hard time parsing/routing?
>
>
As far as I can see, it's option A:

At the start of the route{} block in opensips.cfg, I write the SIP message
OpenSIPS is receiving with...

   *xlog("$mb"); *

...here's what I see (entries reformatted to convert #015#012 to a
newline). When the NATed TLS UAC first registers, OpenSIPS receives...

REGISTER sip:me.our-domain.com;transport=tls SIP/2.0
Via: SIP/2.0/TLS
192.x.x.9:49462;rport;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias
Max-Forwards: 70
From: "1001" <sip:1001 at me.our-domain.com
>;tag=41310a1aa6504e6d8d03fa8f9d74cd52
To: "1001" <sip:1001 at me.our-domain.com>
Call-ID: cadaee22e6484dcab11ffc8f94b17aa2
CSeq: 43881 REGISTER
User-Agent: MicroSIP/3.20.6
Supported: outbound, path
Contact: "1001" <sip:1001 at 192.x.x.x
:49462;transport=TLS;ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000ac493192>"
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length:  0

...we're using mid_registrar with AOR throttling. Because of the lumps
system, to get the information to save in the mid_registrar we use...

    fix_nated_register();
    fix_nated_contact();
    add_path_received("$tU");

...and then t_relay the message back to the OpenSIPS server (192.x.x.123)
to continue and store the registration using mid_registrar_save(). When it
arrives - this is what OpenSIPS is receiving...

REGISTER sip:me.our-domain.com;transport=tls SIP/2.0
Via: SIP/2.0/TCP 192.x.x.123:5060;branch=z9hG4bK3c27.80ba0c03.0;i=1b075e53
Via: SIP/2.0/TLS
192.x.x.9:49462;received=31.x.x.x;rport=49462;branch=z9hG4bKPjb2bbf33dd6ad483bb7a6f169b4e01930;alias
Max-Forwards: 70
From: "1001" <sip:1001 at me.our-domain.com
>;tag=41310a1aa6504e6d8d03fa8f9d74cd52
To: "1001" <sip:1001 at me.our-domain.com>
Call-ID: cadaee22e6484dcab11ffc8f94b17aa2
CSeq: 43881 REGISTER
User-Agent: MicroSIP/3.20.6
Supported: outbound, path
Contact: "1001" <sip:1001 at 31.x.x.x
:49462;transport=TLS;ob>;+sip.ice;reg-id=1;+sip.instance="<urn:uuid:00000000-0000-0000-0000-0000ac493192>"
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
REFER, MESSAGE, OPTIONS
Content-Length:  0
Path: <sip:1001 at 192.x.x.123;transport=tcp;r2=on;lr>
Path: <sip:1001 at 192.x.x.123
:5061;transport=tls;r2=on;lr;received=sip:31.x.x.x:49462%%3btransport%%3dtls>

...so it seems to be the add_path_received() that's the source of the
problem
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20210722/b2bbc642/attachment-0001.html>