Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v5.0.4: Transformation param.value,name: Returning incorrect result #1305

Closed
00Asgaroth00 opened this issue Nov 7, 2017 · 2 comments
Closed

Comments

@00Asgaroth00
Copy link

Description

Given the following Path header:

Path: <sip:10.7.0.186:5062;lr;received=sip:212.2.172.228:39808>

When logging with the following log line

xlog("L_INFO", "received_address: '$(hdr(Path){param.value,received})'");

I am seeing the following being logged in the logs:

INFO: <script>: received_address: 'sip:212.2.172.228:39808>'

Notice the trailing angle bracket (>).

I would have expected it to return something like the following:

'sip:212.2.172.228:39808'

Am I using this transformation correctly, or is this indeed a small bug?

Possible Solutions

Unknown

Additional Information

  • Kamailio Version - output of kamailio -v
version: kamailio 5.0.4 (x86_64/linux) 
flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, USE_RAW_SOCKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES
ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB
poll method support: poll, epoll_lt, epoll_et, sigio_rt, select.
id: unknown 
compiled on 10:57:22 Oct 26 2017 with gcc 4.8.5
  • Operating System:
CentOS Linux release 7.4.1708 (Core) 
Linux localhost 3.10.0-693.5.2.el7.x86_64 #1 SMP Fri Oct 20 20:32:50 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
@miconda
Copy link
Member

miconda commented Nov 7, 2017

Path header value is not a sip parameters string (which is name1=value1;name2=value2; ...), but a name-address. You are using the wrong approach by doing only param transformation. Sometimes you may get the right value (eg., in this case, when there is another parameter after received), but that's because of a pure string delimiter parsing.

So, you have to combine {tobody.uri} and {param.value,received}

@miconda miconda closed this as completed Nov 7, 2017
@00Asgaroth00
Copy link
Author

Thanks for the correct usage explanation, sorry for the noise on the issue tracker.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants