### Description SIP OPTION relayed using `t_forward_nonack()` not being URI decoded
<!-- Explain what you did, what you expected to happen, and what actually happened. -->
### Troubleshooting
#### Reproduction
register with PATH and use SIP OPTION keep alive or simply send relay a SIP OPTIONS with a route.
#### Debugging Data
<!-- If you got a core dump, use gdb to extract troubleshooting data - full backtrace, local variables and the list of the code at the issue location.
gdb /path/to/kamailio /path/to/corefile bt full info locals list
If you are familiar with gdb, feel free to attach more of what you consider to be relevant. -->
```#1 0x00007fa3067a998f in t_forward_nonack (t=0x7fa3246fce88, p_msg=0x7fa3885aa1c0, proxy=0x0, proto=0) at t_fwd.c:1729 1729 raise(SIGSEGV); (gdb) l 1724 ser_error=MIN_int(lowest_ret, E_CFG); 1725 return -1; 1726 } 1727 if(lowest_ret!=E_CFG) { 1728 LM_ERR("failure to add branches\n"); 1729 raise(SIGSEGV); << raising exception to get the coredump 1730 } 1731 ser_error=lowest_ret; 1732 return lowest_ret; 1733 }
```
#### Log Messages
``` 4(34) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: sip:247.25.169.51:52307%3Btransport%3Dtls 4(34) ERROR: tm [t_fwd.c:1728]: t_forward_nonack(): failure to add branches ```
### Possible Solutions
This patch can fix the problem from the routing script : ``` if (is_method("OPTIONS") && uri!=myself) { $var(path_uri) = $(hdr(Route){re.subst,/<(.*)>/\1/}); if (defined $(var(path_uri){uri.params}) && $(var(path_uri){uri.params}{param.value,received}) != "") { $var(received) = $(var(path_uri){uri.params}{param.value,received}); if ($var(received) =~ "sip:.*:.*") { $du = $var(received); $avp(received) = $(var(path_uri){uri.params}{param.value,received}); avp_subst("$avp(received)", "/%3Btransport%3Dtcp/;transport=tcp/ig"); if ($avp(received) =~ "sip:.*:.*") { $du = $avp(received); } } t_relay(); } ```
### Additional Information
tested on 5.3.2, something changed during 5.3.0.dev, I will try to pin point the commit
Is this about an OPTIONS request received on the proxy that added Path to REGISTER?
Can you paste the parameters you set for path module? What add-path function do you use?
Yes,
``` loadmodule "path" modparam("path", "use_received", 1) ... if (is_method("REGISTER")) add_path_received(); ```
The message sent by the edge proxy using the path module
``` REGISTER sip:test-domain.com SIP/2.0 Via: SIP/2.0/UDP 137.15.81.151;branch=z9hG4bKf5c2.d20338c99be2a579d16152c911a268b8.0;i=00064 Via: SIP/2.0/TCP 147.175.169.51:55767;received=147.175.169.51;rport=55767;branch=z9hG4bKPjQlJgWj8tJk1NvpNE7lM3gjNfQJIeBlqE;alias Max-Forwards: 69 From: sip:143146457@test-domain.com;tag=rydv5QkPn2iFXIn1KkgTPpZG.L.ygQ9. To: sip:143146457@test-domain.com Call-ID: bIS2ORgG6OFQ8zFvMcdwQ9r1CeEnKItJ CSeq: 29884 REGISTER User-Agent: <voip_patrol> Contact: sip:143146457@147.175.169.51:2534;ob Expires: 300 Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, MESSAGE, OPTIONS Content-Length: 0 Path: sip:137.15.81.151;lr;received=sip:147.175.169.51:55767%3Btransport%3Dtcp ```
And what is the OPTIONS making problems? Route header should be handled automatically.
I concluded that the URI in the route should be escaped automatically by `t_relay()`.
But t_relay / t_forward_nonack is not unescaping the transport and failing with : ``` 4(34) ERROR: tm [ut.h:245]: uri2dst2(): bad_uri: sip:247.25.169.51:52307%3Btransport%3Dtls 4(34) ERROR: tm [t_fwd.c:1728]: t_forward_nonack(): failure to add branches ```
``` OPTIONS sip:143146457@147.175.169.51:59843;transport=TCP;ob SIP/2.0. Max-Forwards: 20. Record-Route: sip:137.15.81.151;transport=tcp;r2=on;lr. Record-Route: sip:137.15.81.151;r2=on;lr. Via: SIP/2.0/TCP 137.15.81.151;branch=z9hG4bK8c0f.3cf10122ac1fcfef5235efdcf33063e6.0. Via: SIP/2.0/UDP 52.40.141.109:5060;branch=z9hG4bK6096674. Route: sip:137.15.81.151;lr;received=sip:147.175.169.51:59843%3Btransport%3Dtcp. From: sip:ping@invalid;tag=uloc-5e3e08d7-1c-fb94099-a8e0dba6-897d7be9. To: sip:143146457@147.175.169.51:59843;transport=TCP;ob. Call-ID: cb1d2386-8cf283b9-46be071@0.0.0.0. CSeq: 1 OPTIONS. Content-Length: 0. Max-Forward: 10. ```
The decoding should be done by `path` module, via a callback function executed when running `loose_route()`. If you do the loose_route() for OPTIONS, attach the log messages with `debug=3` for processing the OPTIONS request.
I will look in the path module, thanks for the hints
quick look at the path header, I did test the first 5.x version, with the same result.
I will probably start to debug, looking at this, it seems like the escaping may be expected :
``` static int prepend_path(sip_msg_t* _m, str *user, path_param_t param, str *add_params) { struct lump *l; char *prefix, *suffix, *cp, *dp; const char *proto_str; int prefix_len, suffix_len; struct hdr_field *hf;
/* maximum possible length of suffix */ suffix_len = sizeof(";lr;r2=on;received=sip::12345%3Btransport%3Dsctp;ob;>\r\n") + IP_ADDR_MAX_STR_SIZE + 2 + (add_params ? add_params->len : 0) + 1; ```
I will try to dig it further shortly
Sorry I forgot to attach the logs for the SIP OPTIONS
According to the doc the param should be escaped by default ? ``` 3.2. received_format (int)
If set to 0, the “received” parameter value will be in the escaped SIP URI format.
Default value is 0. ```
Yes, that would be a valid format for Path header with escaped uri in received parameter.
Still getting any issue?
@jchavanton - was this sorted out for you and can be closed? Or do you still need time for it.
I did not find the time to dig it, still using a config patch ...
This has aged quite a lot so I am closing it, if you find something new reopen or even make a PR for a fix.
Closed #2255.