Hi Daniel,
Thanks a lot :-)
Regard,
/Kristian Høgh
On Thursday, February 2, 2017 1:46:12 PM CET Daniel-Constantin Mierla wrote:
Hello,
On 02/02/2017 13:00, Kristian F. Høgh wrote:
Hi list,
We provision our kamailio database from
Hi list,
We provision our kamailio database from an external system.
In the future we would like to provision from two different systems.
To prevent the two systems from touching each others data, we would like to
create views from the two tables.
provision system 1 would write to table1
Hi,
Is your question related to t_newtran() and t_reply("200", "OK")?
(http://lists.sip-router.org/pipermail/sr-users/2016-March/092123.html)
Then you should be able to drop the ACK using "exit;"
tm module should see the ACK is related to the "200 OK".
Do you see retransmissions from kamailio?
Hi,
The following works for me:
t_newtran();
$var(sdp)="v=0\r\n" +
"o=- 909325628 825120060 IN IP4 $Ri\r\n" +
"s=-\r\n" +
"c=IN IP4 $Ri\r\n" +
"t=0 0\r\n" +
"m=audio 5004 RTP/AVP 0 8 101\r\n" +
"a=fmtp:101 0-15\r\n" +
Hi,
I hope the correct solution to the problem is to add RR parameters on
sequential requests.
The attached patch restores vsf=, vst= and did=.
Dragons ahead, so far it works for me.
Regards,
Kristian Høgh
Uni-tel A/S
On Friday 27 November 2015 14:07:08 Kristian F. Høgh wrote:
> Hi ag
sequential requests?
Regards,
Kristian.
On Friday 27 November 2015 12:54:50 Kristian F. Høgh wrote:
Hi list,
Record-route on sequential requests doesn't have did/vsf parm.
On initial INVITE, I call record_route() and set dialog flag.
kamailio adds the following RR
Record-Route: <sip:ww.xx.yy.zz;lr;f
Hi again,
Sorry, false alarm...
We had a patch which disabled the callback from dialog to RR.
Regards,
Kristian.
On Friday 27 November 2015 12:54:50 Kristian F. Høgh wrote:
> Hi list,
>
> Record-route on sequential requests doesn't have did/vsf parm.
>
> On initial
Hi,
This might get you started:
$var(test1)=bbbaddaa34;
$var(test2)=$(var(test1){s.replace,a,});# replace a with nothing
$var(a)=$(var(test1){s.len});
$var(b)=$(var(test2){s.len});
$var(c)=$var(a) - $var(b);
xlog($var(a), $var(b), $var(c));
ERROR: script: 10, 7, 3
Regards,
Kristian Høgh
was fixed in 3.1 branch,
being quite old by now.
Cheers,
Daniel
On 14/01/15 14:21, Kristian F. Høgh wrote:
Hi Daniel,
# kamailio -V
version: kamailio 3.1.1 (x86_64/linux) c274ce
flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, TLS_HOOKS, USE_RAW_SOCKS,
DISABLE_NAGLE, USE_MCAST
/pid? I still wonder if it is
a overwritten core.
Otherwise, there might be physical problems with memory...
By pointer addresses, I guess it is a 32b CPU, right?
Cheers,
Daniel
On 14/01/15 11:30, Kristian F. Høgh wrote:
Hi Daniel,
(gdb) p *row-values
$1 = {type = DB1_STRING, nul
between it and
handling any sip packet, no shared memory accessed.
Do you get only one corefile?
From the backtrace it looks like row pointer is not ok, can you get the
output for:
p *row
Cheers,
Daniel
On 13/01/15 15:08, Kristian F. Høgh wrote:
Hi,
On an ancient kamailio 3.1, we
and packing it for nathelper usage. It is no race between it and
handling any sip packet, no shared memory accessed.
Do you get only one corefile?
From the backtrace it looks like row pointer is not ok, can you get the
output for:
p *row
Cheers,
Daniel
On 13/01/15 15:08, Kristian F. Høgh
.
On Wednesday 14 January 2015 11:13:43 Daniel-Constantin Mierla wrote:
Hello,
get also:
p *row-values
p i
Cheers,
Daniel
On 14/01/15 10:50, Kristian F. Høgh wrote:
Hi Daniel,
(gdb) p *row
$1 = {values = 0x9bd2b8, n = 13}
Regards,
Kristian.
On Wednesday 14 January
Hi,
I've been hunting a memory error in publish handling the last couple of days.
The error is on our old but good 3.1.x presence server.
Using memory debug, I located the memory leak in modules/presence/hash.c,
function insert_phtable, line 492 (in trunk):
p= (pres_entry_t*)shm_malloc(size);
(for trunk) with debug=3 ... I may be able to
catch it without testing it myself, which can take a bit longer.
Cheers,
Daniel
On 30/10/14 16:21, Kristian F. Høgh wrote:
Hi,
Tested on 4.0.6 (+contact header REFER patch) and trunk.
When appending header on originating INVITE
Hi,
Tested on 4.0.6 (+contact header REFER patch) and trunk.
When appending header on originating INVITE, the ACK from kamailio gets messed
up.
I generate call, using myself as proxy
kamctl fifo dlg_bridge sip:201@[domain] sip:202@[domain] sip:[kamailio-ip]:5060
In route[tm:local-request], i
Hi,
Our kamailio 4.0.6 proxy uses pua/pua_dialoginfo and an external presence
server.
The PUBLISH requests generated by pua* appear in tm:local-request event route.
Before sending, we call set_advertised_address and force_send_socket.
Still the requests have the IP address from the first
Hi,
After making changes to database, run kamctl dispatcher reload from
commandline.
Regards,
Kristian Høgh
On Friday 08 August 2014 01:23:43 Yuriy Gorlichenko wrote:
Hello. I try to integrate dispathcer module (with db table dispatcher) to
my Kamailio server.
I have problem with
Hi,
We've had the following crash. Kamailio 4.0.4
Client sends SUBSCRIBE, kamailio answers 202.
Kamailio sends NOTIFY, client answers 100 trying.
fr_timer is 5000. The client doesn't send 200 OK, so kamailio generates 408.
Any suggestions?
Regards,
Kristian Høgh
(gdb) bt
#0
Hi,
After restarting kamailio, pua_dialoginfo doesn't get updated when active
dialogs change status.
I see the dialogs are read from the database, but when they receive eg. BYE the
callback are not called.
I use db_mode 0 in pua, but tried mode 2 with no luck.
Should pua_dialoginfo register
On Tuesday 29 October 2013 12:09:34 Daniel-Constantin Mierla wrote:
Hello,
On 10/29/13 11:42 AM, Kristian F. Høgh wrote:
Hi,
After restarting kamailio, pua_dialoginfo doesn't get updated when active
dialogs change status.
I see the dialogs are read from the database, but when
Hi David,
overrride_lifetime modify the presence duration for the dialog, early,
confirmed or terminated.
The patch I created, modify the lifetime after the call terminates, to remove
it from pua.
When the call i active, I use the lifetime of the dialog.
/Kristian.
On Wednesday 23 October
Hi,
I think I've got the same issue.
At call creation we set dialog lifetime to 6 hours.
pua_dialoginfo uses that value and send PUBLISH for each hour, even after the
dialog terminates.
After 6 hours the entry is deleted.
To prevent the updates, I've made a small change to pua_dialoginfo
Hi,
I have send the patch directly to Toni.
I try attaching it here again for completeness, as I wasn't subscribed to the
list using this email address.
/Kristian.
On Wednesday 23 October 2013 15:35:42 SIP Guru wrote:
Hi Kristian,
thank you. I'll check this. I think in some cases we are
24 matches
Mail list logo
