Hello!
I have a problem about volte.
> 4(4467) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
> 4(4467) NOTICE: <script>: PCSCF REGISTER:
> Destination URI: <null>
> Request URI: sip:ims.mnc007.mcc460.3gppnetwork.org
> 4(4467) INFO: rr [rr_mod.c:515]: pv_get_route_uri_f(): No route header present.
> 4(4467) NOTICE: <script>: Source IP and Port: (10.45.0.6:5060)
> Route-URI:
> 4(4467) NOTICE: <script>: Received IP and Port: (192.168.107.6:5060)
> 4(4467) NOTICE: <script>: Contact header: <sip:460070000000001@10.45.0.6:5060>;+sip.instance="<urn:gsma:imei:86772304-493882-0>";+g.3gpp.accesstype="cellular2";audio;video;+g.3gpp.smsip;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mmtel"
> 4(4467) INFO: ims_registrar_pcscf [sec_agree.c:296]: cscf_get_security_verify(): No sec


urity-verify parameters found

[open5gs.tar.gz](https://github.com/kamailio/kamailio/files/6270079/open5gs.…
Can you help me see where the problem is?
Thanks!
Tips:About SQN, the SQN is the same at the beginning of the test (Open5GS, FOHSS), but when it is found that the sip registration fails, the SQN is inconsistent. If this situation is normal? If it is not normal, how to solve it?
open5gs:v2.2.3
kamailio:5.3
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2703
Module: kamailio
Branch: master
Commit: 2d7aee506c617f2d258719562f8debf2b4ba087e
URL: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
Author: Daniel-Constantin Mierla <miconda(a)gmail.com>
Committer: Daniel-Constantin Mierla <miconda(a)gmail.com>
Date: 2021-04-06T08:38:16+02:00
core/mem: removed tlsf_malloc_bits.h
- no longer needed after sync with v3.1
---
Removed: src/core/mem/tlsf_malloc_bits.h
---
Diff: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
Patch: https://github.com/kamailio/kamailio/commit/2d7aee506c617f2d258719562f8debf…
---
diff --git a/src/core/mem/tlsf_malloc_bits.h b/src/core/mem/tlsf_malloc_bits.h
deleted file mode 100644
index 29c783d4a4..0000000000
--- a/src/core/mem/tlsf_malloc_bits.h
+++ /dev/null
@@ -1,119 +0,0 @@
-#ifndef INCLUDED_tlsfbits
-#define INCLUDED_tlsfbits
-
-#if defined(__cplusplus)
-#define tlsf_decl inline
-#else
-#define tlsf_decl static
-#endif
-
-/*
-** Architecture-specific bit manipulation routines.
-**
-** TLSF achieves O(1) cost for malloc and free operations by limiting
-** the search for a free block to a free list of guaranteed size
-** adequate to fulfill the request, combined with efficient free list
-** queries using bitmasks and architecture-specific bit-manipulation
-** routines.
-**
-** Most modern processors provide instructions to count leading zeroes
-** in a word, find the lowest and highest set bit, etc. These
-** specific implementations will be used when available, falling back
-** to a reasonably efficient generic implementation.
-**
-** NOTE: TLSF spec relies on ffs/fls returning value 0..31.
-** ffs/fls return 1-32 by default, returning 0 for error.
-*/
-
-/*
-** Detect whether or not we are building for a 32- or 64-bit (LP/LLP)
-** architecture. There is no reliable portable method at compile-time.
-*/
-#if defined (__alpha__) || defined (__ia64__) || defined (__x86_64__) \
- || defined (_WIN64) || defined (__LP64__) || defined (__LLP64__)
-#define TLSF_64BIT
-#endif
-
-/*
-** gcc 3.4 and above have builtin support, specialized for architecture.
-** Some compilers masquerade as gcc; patchlevel test filters them out.
-**
-** Note: clang is compatible with GCC builtins and will also define those macros
-*/
-#if defined (__GNUC__) && (__GNUC__ > 3 || (__GNUC__ == 3 && __GNUC_MINOR__ >= 4)) \
- && defined (__GNUC_PATCHLEVEL__)
-
-tlsf_decl int tlsf_ffs(unsigned int word)
-{
- return __builtin_ffs(word) - 1;
-}
-
-tlsf_decl int tlsf_fls(unsigned int word)
-{
- const int bit = word ? 32 - __builtin_clz(word) : 0;
- return bit - 1;
-}
-
-#if defined (TLSF_64BIT)
-tlsf_decl int tlsf_fls_sizet(size_t size)
-{
- const int bit = size ? 64 - __builtin_clzl(size) : 0;
- return bit - 1;
-}
-#endif
-#else
-/* Fall back to generic implementation. */
-
-tlsf_decl int tlsf_fls_generic(unsigned int word)
-{
- int bit = 32;
-
- if (!word) bit -= 1;
- if (!(word & 0xffff0000)) { word <<= 16; bit -= 16; }
- if (!(word & 0xff000000)) { word <<= 8; bit -= 8; }
- if (!(word & 0xf0000000)) { word <<= 4; bit -= 4; }
- if (!(word & 0xc0000000)) { word <<= 2; bit -= 2; }
- if (!(word & 0x80000000)) { word <<= 1; bit -= 1; }
-
- return bit;
-}
-
-/* Implement ffs in terms of fls. */
-tlsf_decl int tlsf_ffs(unsigned int word)
-{
- return tlsf_fls_generic(word & (~word + 1)) - 1;
-}
-
-tlsf_decl int tlsf_fls(unsigned int word)
-{
- return tlsf_fls_generic(word) - 1;
-}
-
-#if defined (TLSF_64BIT)
-tlsf_decl int tlsf_fls_sizet(size_t size)
-{
- int high = (int)(size >> 32);
- int bits = 0;
- if (high)
- {
- bits = 32 + tlsf_fls(high);
- }
- else
- {
- bits = tlsf_fls((int)size & 0xffffffff);
-
- }
- return bits;
-}
-#endif /* defined (TLSF_64BIT) */
-
-#endif /* GNUC */
-
-
-#if !defined (TLSF_64BIT)
-#define tlsf_fls_sizet tlsf_fls
-#endif
-
-#undef tlsf_decl
-
-#endif
### Description
It doesn't look like the "pua_dialoginfo" module has support for the "display" attribute in the identity tag. This tag is used by some phones to update the phone display with caller/callee information for the respective key. I'm wondering how difficult it would be to add this feature. Thanks in advance for anyone who reads this!
### Expected behavior
Kamailio includes display attribute in identity tags in generated publish messages.
<pre>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full">
<dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766" direction="initiator">
<state>early</state>
<local>
<identity <b><i>display="Alice"</i></b>>sip:alice@example.com</identity>
<target uri="sip:alice@phone11.example.com"/>
</local>
<remote>
<identity <b><i>display="Bob"</i></b>>sip:bob@example.org</identity>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
</pre>
#### Actual observed behavior
Kamailio generates a publish request for dialog events similar to the one below. The display attribute is not included in the "identity" tags. This means that when a notify message is sent to a watcher for this publish, the name is not rendered on the phone display.
<pre>
<dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info" version="1" state="full">
<dialog id="as7d900as8" call-id="a84b4c76e66710" local-tag="1928301774" remote-tag="456887766" direction="initiator">
<state>early</state>
<local>
<b><identity>sip:alice@example.com</identity></b>
<target uri="sip:alice@phone11.example.com"/>
</local>
<remote>
<b><identity>sip:bob@example.org</identity></b>
<target uri="sip:bobster@phone21.example.org"/>
</remote>
</dialog>
</dialog-info>
</pre>
### Possible Solutions
I added a small modification to the module as a POC and it works as expected. With the following modification, the phone display is updated with the string in the “display” attribute. I added line 191-193 below, between lines 190 & 191 on the current master branch. The example below shows the “remote” tag, I also did the same thing for the local tag a few more lines down.
<pre>
184 tag_node = xmlNewChild(remote_node, NULL, BAD_CAST "identity",
185 BAD_CAST buf) ;
186 if( tag_node ==NULL)
187 {
188 LM_ERR("while adding childn");
189 goto error;
190 }
191 /* Testing - adding display attribute to the identity tag */
192 xmlNewProp(tag_node, BAD_CAST "display", BAD_CAST "RemoteCallerName");
193 /* */
195
196 tag_node = xmlNewChild(remote_node, NULL, BAD_CAST "target", NULL);
197 if( tag_node ==NULL)
</pre>
Here is a link to the file in the module I’m referring to:
https://github.com/kamailio/kamailio/blob/master/src/modules/pua_dialoginfo…
I don’t really have any professional experience writing C code, and I was unable to identify a way to grab this string from the “From” header. Unfortunately, because I would have really loved to give this feature back to the community!
### Additional Information
Thank you so much for this amazing software. I absolutely adore Kamailio! If someone is interested in this, please let me know if there is anything I can do to help.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/2615