> Meanwhile, the transformations can be used to get a body by index.
@miconda - I'd appreciate a quick code sample to further explain. With "body",
do you mean the message body or something else?
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
@miconda I've tested it with $(di{uri.user}); on the 4.4 branch and it works.
--
You are receiving this because you commented.
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/841#issuecomment-257859598___
s
Sure. But why can't Kamailio (the Diversion module or whatever it would affect)
be extended to support newer RFCs as long as it doesn't break backwards
compatibility? I'm not necessarily reporting a bug, it's more of a feature
request.
--
You are receiving this because you commented.
Reply to
You're correct in that it's obsoleted and History-Info is the solution adopted
by IETF but the Diversion header is far from obsolete in practice as it's used
by major IP telephony system providers like Broadsoft and Sonus and probably
quite a few more. In addition, Kamailio has the Diversion mod
Hmm, isn't RFC 5806 (March 2010) older than RFC 6044 (October 2010)? Given
that, I fail to see how 5806 can be a replacement? RFC 6044 is obsoleted by RFC
7544 however (August 2015) which also says that comma separated diversions are
allowed.
--
You are receiving this because you commented.
Re
Given a Diversion header like the following:
```
Diversion:"Foo
Bar";privacy=off;answered-count=2;re
ason=deflection;counter=1;answered,"_
somewhere";privacy=off;answered-coun
t=1;reason=deflection;counter=1;answered
```
Kamailio 4.4.3 (and probably earlier versions) emit error messages
complaini
Thank you very much!
The issue was fixed through the following commits:
* 47086a4ee0a6ee6a766d7591e91e5663acf31562
* 74fadc549929d3dc873ce3b8b1db20559562ab54
* c36b93f61a7fe76321aab8e62e1bbeee5122c5ed
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issu
> I propose a fix would entail making Kamailio support prefixes of 32
> characters since we then can use GUIDs/UUIDs as "prefixes" without alteration
GUIDs/UUIDs with the hyphens removed that is.
---
Reply to this email directly or view it on GitHub:
https://github.com/kamailio/kamailio/issues/1
mtree.h defines MT_MAX_DEPTH as 32 and the tprefix database table field is
defined as a varchar(32) but the module fails to start if a prefix of 32
characters is present in the database table mapped to the mtree. The error
message on start is:
> 0(10465) ERROR: mtree [mtree.c:156]: mt_add_to_tr
