Re: [SR-Users] Cannot get service to start

[Ginhoux, Patrick]

Hi Stephen,

 

I had similar issues fix by changes in the kamailio.cfg and kamctlrc files, but 
also in the Kamailio rpm as well recently fixed. Are you using the latest 
Kamailio 5.0.1 release?

 

If so please review you config file as I think your problem is related to such 
entries:

 

In my Kamailio.cfg I have the following :

 

!!define DEFINE_FIFO_NAME "/var/run/kamailio/kamailio_rpc_fifo"

 

loadmodule "jsonrpcs.so"

 

modparam("jsonrpcs", "pretty_format", 1)

modparam("jsonrpcs", "transport", 2)

modparam("jsonrpcs", "fifo_name", DEFINE_FIFO_NAME)

modparam("jsonrpcs", "fifo_mode", 0755)

modparam("jsonrpcs", "fifo_group", "kamailio")

modparam("jsonrpcs", "fifo_user", "kamailio")

 

you should have also in the kamctlrc file this enty that matches the one in the 
Kamailio.cfg :

 

## path to FIFO file for engine RPCFIFO

# RPCFIFOPATH="/var/run/kamailio/kamailio_rpc_fifo"

 

In the latest 5.0.1, the Kamailio script has been change to handle the rights 
on the /var/run/Kamailio folder.

 

I hope this helps.

 

Cordialement

Patrick GINHOUX

 

De : sr-users [mailto:sr-users-boun...@lists.kamailio.org] De la part de 
Stephen Tyers
Envoyé : vendredi 28 avril 2017 13:31
À : sr-users@lists.kamailio.org
Objet : [SR-Users] Cannot get service to start

 

Hi Apologies,

 

I was a bit hasty in my previous email, I forgot to run the Chown command

 

I still can’t get the service to start and I’m getting the below error. I’ve 
gone through all the steps multiple times, please help.

 

/etc/init.d/kamailio start

[] Starting kamailio (via systemctl): kamailio.serviceFailed to start 
kamailio.service: Unit kamailio.service failed to load: No such file or 
directory.

 failed!

 

Kind regards

Stephen tyers



smime.p7s
Description: S/MIME cryptographic signature
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Cannot get service to start

[Stephen Tyers]

Hi Apologies,

I was a bit hasty in my previous email, I forgot to run the Chown command

I still can’t get the service to start and I’m getting the below error. I’ve 
gone through all the steps multiple times, please help.

/etc/init.d/kamailio start
[] Starting kamailio (via systemctl): kamailio.serviceFailed to start 
kamailio.service: Unit kamailio.service failed to load: No such file or 
directory.
 failed!

Kind regards
Stephen tyers
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] An Potential Issue in Kamailio Installation Guide

[Edward Lu]

Dear Sir,

This is Edward, nice to meet you.

When I follow the installation guide of Kamailio 5.0.x
https://kamailio.org/docs/tutorials/5.0.x/kamailio-install-guide-git/ to
install Kamailio, I met an issue, it report "unit kamailio.service not
found" when I issue command /etc/init.d/kamailio start. After google, I
found one step was missed: to copy kamailio.service to /etc/system.d/system.

Except above issue, all others are all okay for my installation on Ubuntu
16.04.

Thanks & Regards,
Edward
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] htable Arrays and dbmode 1

[Sebastian Damm]

Hi,

I'm trying to use a htable array. For that, I have inserted some
values in the database (in pseudo CSV):

key_name; key_type; value_type; key_value
'1234567'; 1; 0; 'foo'
'1234567', 1, 0, 'bar'
'1234567', 1, 0, 'baz'

insert into htable (key_name , key_type , value_type , key_value )
values ('1234567', 1, 0, 'foo'),('1234567', 1, 0, 'bar'),('1234567',
1, 0, 'baz');

Now after just starting Kamailio, reading those values, from db and
then stopping Kamailio again, the table content looks like this:

key_name; key_type; value_type; key_value
'1234567[2]'; 0; 0; 'baz'
'1234567[0]', 0, 0, 'foo'
'1234567[1]', 0, 0, 'bar'
'1234567::size', 0, 1, 3

Is this how it is supposed to work? When re-reading those entries, the
htable contents look the same as during the first start, but in the
database it is a bit harder to read.


And while I'm at it: Is there a way to regularly write back the
current htable contents to the database? Or even to sync every write
directly into the database?

Thanks in advance
Sebastian

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos module - possible bug

[Sergey Basov]

Some more debug

after adding debug output after each iteration I got:

Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
[tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[](84)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
[tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[](348)
Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
[tps_msg.c:457]: tps_pack_message(): sbasov compacted headers - b_rr:
[](554)

Apr 28 15:51:51 csbc-uat /usr/sbin/kamailio[13743]: DEBUG: topos
[tps_msg.c:475]: tps_pack_message(): compacted headers - a_rr: [](0) -
b_rr: 
[](554)
- s_rr: [](0)

So size are computed correctly, but part of record-routes
disappears And we can see correct size of the record but only last
part of the record-routes

Hope it helps
--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com


2017-04-28 15:37 GMT+03:00 Sergey Basov :
> One more detail
>
> When debug=3 I see in logs (look at size of record and it contents)
>
> Apr 28 14:16:44 csbc-uat /usr/sbin/kamailio[13287]: DEBUG: topos
> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
> b_rr: [](0) - s_rr:
> [,](453)
>
> 453 - is a real size of shown header
>
> s_rr parses normal, but b_rr
>
> Apr 28 14:16:48 csbc-uat /usr/sbin/kamailio[13273]: DEBUG: topos
> [tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
> b_rr: 
> [](553)
> - s_rr: [](0)
>
> 553 - seems a real correct size of the recordroute header and it
> differs from size with \0 at the end
>
>
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-28 14:46 GMT+03:00 Sergey Basov :
>> Hi All.
>>
>> I just try to pass call throught 3 kamailio.
>> I got result like yours
>>
>> If you need testers for patch - I am ready )
>>
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>
>>
>> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla :
>>> There seems to be an issue saving the record-route list for b-side in
>>> topos_d table -- first two are saved but then there are only 0 characters
>>> instead of the rest of record routes:
>>>
>>> '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'
>>>
>>>  I will have to dig a bit into the code.
>>>
>>> Cheers, Daniel
>>>
>>>
>>> On 27.04.17 14:30, Pete Kelly wrote:
>>>
>>> Yes no problem. I wanted to come but the life schedule would not allow it
>>> this time.
>>>
>>>
>>> On 27 April 2017 at 13:11, Daniel-Constantin Mierla 
>>> wrote:

 Hello,

 time, I need more time :-) ... with Kamailio World Conference around the
 corner, I am caught in a lot of admin tasks...

 Daniel


 On 27.04.17 13:11, Pete Kelly wrote:

 Hi Daniel

 Is there anything else you need on this?

 On 26 April 2017 at 15:06, Pete Kelly  wrote:
>
> Hi Daniel
>
> It's CSeq 1, fromtag A1
>
> DB attached
>
> On 26 April 2017 at 15:03, Daniel-Constantin Mierla 
> 

Re: [SR-Users] topos module - possible bug

[Sergey Basov]

One more detail

When debug=3 I see in logs (look at size of record and it contents)

Apr 28 14:16:44 csbc-uat /usr/sbin/kamailio[13287]: DEBUG: topos
[tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
b_rr: [](0) - s_rr:
[,](453)

453 - is a real size of shown header

s_rr parses normal, but b_rr

Apr 28 14:16:48 csbc-uat /usr/sbin/kamailio[13273]: DEBUG: topos
[tps_msg.c:473]: tps_pack_message(): compacted headers - a_rr: [](0) -
b_rr: 
[](553)
- s_rr: [](0)

553 - seems a real correct size of the recordroute header and it
differs from size with \0 at the end


--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com


2017-04-28 14:46 GMT+03:00 Sergey Basov :
> Hi All.
>
> I just try to pass call throught 3 kamailio.
> I got result like yours
>
> If you need testers for patch - I am ready )
>
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla :
>> There seems to be an issue saving the record-route list for b-side in
>> topos_d table -- first two are saved but then there are only 0 characters
>> instead of the rest of record routes:
>>
>> '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'
>>
>>  I will have to dig a bit into the code.
>>
>> Cheers, Daniel
>>
>>
>> On 27.04.17 14:30, Pete Kelly wrote:
>>
>> Yes no problem. I wanted to come but the life schedule would not allow it
>> this time.
>>
>>
>> On 27 April 2017 at 13:11, Daniel-Constantin Mierla 
>> wrote:
>>>
>>> Hello,
>>>
>>> time, I need more time :-) ... with Kamailio World Conference around the
>>> corner, I am caught in a lot of admin tasks...
>>>
>>> Daniel
>>>
>>>
>>> On 27.04.17 13:11, Pete Kelly wrote:
>>>
>>> Hi Daniel
>>>
>>> Is there anything else you need on this?
>>>
>>> On 26 April 2017 at 15:06, Pete Kelly  wrote:

 Hi Daniel

 It's CSeq 1, fromtag A1

 DB attached

 On 26 April 2017 at 15:03, Daniel-Constantin Mierla 
 wrote:
>
> Can you paste here the from tag or cseq for the dialog you are referring
> to? Because the number of frames are not matching my pcap viewer.
>
> Send also the db dump, they should reveal if something is broken there.
>
> Cheers,
> Daniel
>
>
> On 26.04.17 14:46, Pete Kelly wrote:
>
> Ah I see why it is confusing
>
> This setup maintains a Call-ID through an SBC downstream, so the
> INVITE's you see have the same Call-ID but they have a different
> fromtag/cseq, Wireshark shows them all as one call which is annoying when
> looking at the viewer!
>
> If you check the first call only between 252.70 and 252.75 you will see
> INVITE (frame 4), 200OK (frame 16) with lots of RR headers.
>
> The ACK generated by topos (frame 21) only contains 1 Route header, it
> should contain more so the request can hop through the proxy chain as 
> shown
> in frame 16.
>
> I see the example from Sergey is working, but there is only 1 RR header
> in this example - as you can see from my example the topos module uses the
> first RR header but ignores the other 5.
>
> I have the DB dump and logfiles from this call too if useful.
>
> Pete
>
>
> On 26 April 2017 at 12:41, Daniel-Constantin Mierla 
> wrote:
>>
>> As I could notice upon a quick look, there seems to be two calls -- two
>> INVITE requests having same call id but different cseq. Can you confirm
>> this is the case? Because the capture doesn't seem to have all the
>> incoming/outgoing messages, some are missing.
>>
>> Cheers,
>> Daniel
>>
>> On 26.04.17 12:59, Sergey Basov wrote:
>> > You give to us very hard callflow...
>> >
>> > Without any pauses between 

Re: [SR-Users] Not able to replace route_uri in contact header uri

[Narayan P]

Hi Daniel,


Thanks for your response.I have added this in the registrar module but it 
didn't work.


Please see the sip trace.


-end msg--
17:28:47.162 sip_endpoint.c  .Response msg 408/REGISTER/cseq=52880 
(rdata0x231b418) from 185.122.205.178:5070 was dropped/unhandled by any modules
17:28:47.404   pjsua_core.c  .TX 597 bytes Request msg REGISTER/cseq=3179 
(tdta0x2320060) to UDP 185.122.205.178:5070:
REGISTER sip:185.122.205.178:5070 SIP/2.0
Via: SIP/2.0/UDP 
172.22.13.41:5067;rport;branch=z9hG4bKPjd734f1a6-d644-4a96-913c-c31738a33eed
Max-Forwards: 70
From: 
;tag=9f62c1ea-36a3-4318-a767-55a6b278fd23
To: 
Call-ID: 6fc0b9f9-8439-4fc6-a28e-05ce1e52ec80
CSeq: 3179 REGISTER
User-Agent: PJSUA v2.3 Linux-4.4.0.64/x86_64/glibc-2.19
Contact: 
Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS
Content-Length:  0

Thanks,

Narayan


From: Daniel-Constantin Mierla 
Sent: Friday, April 21, 2017 9:36:37 AM
To: Narayan P; sr-us...@lists.sip-router.org
Subject: Re: Not able to replace route_uri in contact header uri


Hello,


skipping to understand exactly the purpose of what you want to achieve, if you 
want to replace the contact header uri with [username from old 
Contact]@[kamailio ip]:[kamailio port] , you can try this:


if(is_present_hf("Contact")) {

  remove_hf("Contact");

  append_hf("Contact: 
\r\n)");

}


If doesn't work, let me know.


Cheers,
Daniel

On 20.04.17 16:09, Narayan P wrote:

Thanks for your kind Response Daniel,


Yes as you told with the requirement I have mentioned call will not reach 
client, I have explained my requirement in detail,


My requirement is to establish a call between 2 SIP clients Alice and Bob which 
are using 185.122.205.178(Kamailio) as outbound proxy and registered to a SIP 
SERVER,


I am not able to establish call between Alice and Bob, So I am trying to 
Replace the Contact header in Register request with Kamailio IP and then I will 
direct the Invite request to callee client using the data(Username to IP:port 
tuple) I have stored in Kamailio database.


Please suggest me if you have better Idea than what i am doing


Thanks & Regards

Narayan


From: Daniel-Constantin Mierla 
Sent: Tuesday, April 18, 2017 1:04:38 PM
To: Narayan P; 
sr-us...@lists.sip-router.org
Subject: Re: Not able to replace route_uri in contact header uri


Hello,


to clarify, in the REGISTER you sent and pasted again below, from


Contact: 



you want to have:


Contact: 



If yes, then this doesn't look right at all, then the device cannot receive 
calls anymore. Maybe you can explain the purpose and then we may be able to 
offer some hints.


Cheers,
Daniel



REGISTER sip:185.122.206.62 SIP/2.0
Via: SIP/2.0/UDP 
125.16.231.74:25841;rport;branch=z9hG4bKPj592750e4-9a06-4662-a55e-a8a71dedb974
Route: 
Max-Forwards: 70
From: 
;tag=35af1666-a2b1-4c6e-a7b6-8675845036e7
To: 
Call-ID: 5bc6558f-1ffc-4990-bc99-d099c4fdcbcb
CSeq: 41801 REGISTER
User-Agent: PJSUA v2.3 Linux-4.4.0.64/x86_64/glibc-2.19
Contact: 

Expires: 300
Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY, REFER, 
MESSAGE, OPTIONS
Authorization: Digest username="OTT919620649614", realm="185.122.206.62", 
nonce="af7780946d2b72ddc5e765a68798e937", 
uri="sip:185.122.206.62", 
response="a4c0614fbc3c72ece619247de5766a4b", algorithm=MD5
Content-Length:  0


SIP/2.0 200 OK
Via: SIP/2.0/UDP 
125.16.231.74:25841;rport=25841;branch=z9hG4bKPj592750e4-9a06-4662-a55e-a8a71dedb974;received=125.16.231.74
From: 
;tag=35af1666-a2b1-4c6e-a7b6-8675845036e7
Call-ID: 5bc6558f-1ffc-4990-bc99-d099c4fdcbcb
CSeq: 41801 REGISTER
To: 
;tag=1492409213989
Expires: 50
Contact: 
;expires=50
Content-Length: 0

On 17.04.17 08:38, Narayan P wrote:

Hi Daniel,


I am attaching here my sip trace at client side.Request you to see this.

My client IP in register request is 125.16.231.74 and the server on which 
kamailio is running is 185.122.205.178.


I want 

Re: [SR-Users] Memory leak when reloading htable using db_cluster

[Kristian F . Høgh]

Hi,

I did some more testing.

reloading address and domain is fixed in master 
(08f8e0bc72b9f16f76b78110c9c95b1ba7f1ce25)
If I only have one htable, I can reload many times without memory leak. (The 
content i database is unchanged)
If I have 2 htables and keep reloading both, kamailio leaks as below. (The 
content i database is unchanged)

Regards,
Kristian.


On Friday, April 28, 2017 11:20:29 AM CEST Kristian F. Høgh wrote:
> Hi Daniel.
> 
> Thanks alot.
> It fixed the problem at my testbed.
> In production i reload several htables + address and domain, so I updated my 
> config.
> 
> 16(31430) ALERT: qm_status:1700. N  address=0x7f9bf03905e8 
> frag=0x7f9bf03905b0 size=64 used=1
> 16(31430) ALERT: qm_status:   alloc'd from db_mysql: km_res.c: 
> db_mysql_get_columns(77)
> 16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(31430) ALERT: qm_status:1701. N  address=0x7f9bf0390690 
> frag=0x7f9bf0390658 size=64 used=1
> 16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
> db_allocate_columns(150)
> 16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(31430) ALERT: qm_status:1702. N  address=0x7f9bf0390738 
> frag=0x7f9bf0390700 size=64 used=1
> 16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
> db_allocate_columns(160)
> 16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(31430) ALERT: qm_status:1703. N  address=0x7f9bf03907e0 
> frag=0x7f9bf03907a8 size=64 used=1
> 16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
> db_new_result(114)
> 16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(31430) ALERT: qm_status:1706. N  address=0x7f9bf0390a58 
> frag=0x7f9bf0390a20 size=64 used=1
> 16(31430) ALERT: qm_status:   alloc'd from db_mysql: km_res.c: 
> db_mysql_new_result(236)
> 
> Regards,
> Kristian.
> 
> On Friday, April 28, 2017 9:38:25 AM CEST Daniel-Constantin Mierla wrote:
> > Hello,
> > 
> > can you fetch the master and try again -- I just pushed some fixes.
> > 
> > Cheers,
> > Daniel
> > 
> > 
> > On 28.04.17 08:17, Kristian F. Høgh wrote:
> > > Hi list,
> > >
> > > I use current git master.
> > > When I reload a htable using "kamcmd htable.reload htable1", the "ctl 
> > > handler" process leaks 384 bytes of pkg memory
> > > If I use a direct mysql connection without db_cluster, the is no memory 
> > > leak
> > >
> > > modparam("db_cluster", "connection", 
> > > "con1=>mysql://user:p...@ip.addr/database")
> > > modparam("db_cluster", "connection", 
> > > "con2=>mysql://user:pass@ip.addr2/database")
> > > modparam("db_cluster", "cluster", "cls1=>con1=9s9s;con2=8s8s")
> > >
> > > modparam("htable", "db_url", "cluster://cls1")
> > > # modparam("htable", "db_url", "mysql://user:p...@ip.addr/database"
> > > modparam("htable", "htable", 
> > > "htable1=>size=8;autoexpire=0;dbtable=htable1;")
> > >
> > > 16(10429) ALERT: qm_status:6513. N  address=0x7f4e65e01720 
> > > frag=0x7f4e65e016e8 size=128 used=1
> > > 16(10429) ALERT: qm_status:   alloc'd from db_cluster: 
> > > dbcl_api.c: db_cluster_init(294)
> > > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > > c0c0c0c0, abcdefed
> > > 16(10429) ALERT: qm_status:6514. N  address=0x7f4e65e01808 
> > > frag=0x7f4e65e017d0 size=128 used=1
> > > 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> > > db_do_init2(298)
> > > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > > c0c0c0c0, abcdefed
> > > 16(10429) ALERT: qm_status:6515. N  address=0x7f4e65e018f0 
> > > frag=0x7f4e65e018b8 size=128 used=1
> > > 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> > > db_do_init2(298)
> > > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > > c0c0c0c0, abcdefed
> > >
> > > Regards,
> > > Kristian Høgh
> > > Uni-tel A/S
> > >
> > >  
> > >
> > > ___
> > > Kamailio (SER) - Users Mailing List
> > > sr-users@lists.kamailio.org
> > > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> > 
> > 
> 
> 
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos module - possible bug

[Sergey Basov]

Hi All.

I just try to pass call throught 3 kamailio.
I got result like yours

If you need testers for patch - I am ready )

--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com


2017-04-28 12:57 GMT+03:00 Daniel-Constantin Mierla :
> There seems to be an issue saving the record-route list for b-side in
> topos_d table -- first two are saved but then there are only 0 characters
> instead of the rest of record routes:
>
> '\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'
>
>  I will have to dig a bit into the code.
>
> Cheers, Daniel
>
>
> On 27.04.17 14:30, Pete Kelly wrote:
>
> Yes no problem. I wanted to come but the life schedule would not allow it
> this time.
>
>
> On 27 April 2017 at 13:11, Daniel-Constantin Mierla 
> wrote:
>>
>> Hello,
>>
>> time, I need more time :-) ... with Kamailio World Conference around the
>> corner, I am caught in a lot of admin tasks...
>>
>> Daniel
>>
>>
>> On 27.04.17 13:11, Pete Kelly wrote:
>>
>> Hi Daniel
>>
>> Is there anything else you need on this?
>>
>> On 26 April 2017 at 15:06, Pete Kelly  wrote:
>>>
>>> Hi Daniel
>>>
>>> It's CSeq 1, fromtag A1
>>>
>>> DB attached
>>>
>>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla 
>>> wrote:

 Can you paste here the from tag or cseq for the dialog you are referring
 to? Because the number of frames are not matching my pcap viewer.

 Send also the db dump, they should reveal if something is broken there.

 Cheers,
 Daniel


 On 26.04.17 14:46, Pete Kelly wrote:

 Ah I see why it is confusing

 This setup maintains a Call-ID through an SBC downstream, so the
 INVITE's you see have the same Call-ID but they have a different
 fromtag/cseq, Wireshark shows them all as one call which is annoying when
 looking at the viewer!

 If you check the first call only between 252.70 and 252.75 you will see
 INVITE (frame 4), 200OK (frame 16) with lots of RR headers.

 The ACK generated by topos (frame 21) only contains 1 Route header, it
 should contain more so the request can hop through the proxy chain as shown
 in frame 16.

 I see the example from Sergey is working, but there is only 1 RR header
 in this example - as you can see from my example the topos module uses the
 first RR header but ignores the other 5.

 I have the DB dump and logfiles from this call too if useful.

 Pete


 On 26 April 2017 at 12:41, Daniel-Constantin Mierla 
 wrote:
>
> As I could notice upon a quick look, there seems to be two calls -- two
> INVITE requests having same call id but different cseq. Can you confirm
> this is the case? Because the capture doesn't seem to have all the
> incoming/outgoing messages, some are missing.
>
> Cheers,
> Daniel
>
> On 26.04.17 12:59, Sergey Basov wrote:
> > You give to us very hard callflow...
> >
> > Without any pauses between responces..
> >
> > Some requests go through 127.0.0.1... But responces from 127.0.0.1
> > not present.
> >
> > There are peers from which invites not present in dump. I can not see
> > ful path of the initial Invite, but there is responses.
> >
> > I will send dump in next email directly.
> > --
> > Best regards,
> > Sergey Basov e-mail: sergey.v.ba...@gmail.com
> >
> >
> > 2017-04-26 11:01 GMT+03:00 Pete Kelly :
> >> Attached is the pcap from latest nightly.
> >>
> >> As you can see (frame 21) the ACK is incorrect, I believe it should
> >> specify
> >> all the hops from the 200OK (frame 16) so that the hop by hop ACK
> >> can be
> >> routed via the proxy chain.
> >>
> >> topoh module works fine.
> >>
> >> Pete
> >>
> >> On 26 April 2017 at 05:18, Sergey Basov 
> >> wrote:
> >>> I dont know how nightly builds are done.
> >>>
> >>> Just try with latest 5.0.1 nightly and send new dump.
> >>>
> >>> As I understud topos module done to remove record-route headers to
> >>> hide
> >>> topology...  Am I wright,  Daniel?
> >>>
> >>> And try to disable topos module and enable topoh module. Will it
> >>> all work
> >>> as you expecrs?
> >>>
> >>> --
> >>> WBR
> >>> Sergey Basov
> >>>
> >>> 25 апр. 2017 г. 11:31 PM пользователь "Pete Kelly"
> >>> 

Re: [SR-Users] topos module - possible bug

[Daniel-Constantin Mierla]

There seems to be an issue saving the record-route list for b-side in
topos_d table -- first two are saved but then there are only 0
characters instead of the rest of record routes:

'\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0'

 I will have to dig a bit into the code.

Cheers, Daniel


On 27.04.17 14:30, Pete Kelly wrote:
> Yes no problem. I wanted to come but the life schedule would not allow
> it this time.
>
>
> On 27 April 2017 at 13:11, Daniel-Constantin Mierla  > wrote:
>
> Hello,
>
> time, I need more time :-) ... with Kamailio World Conference
> around the corner, I am caught in a lot of admin tasks...
>
> Daniel
>
>
> On 27.04.17 13:11, Pete Kelly wrote:
>> Hi Daniel
>>
>> Is there anything else you need on this?
>>
>> On 26 April 2017 at 15:06, Pete Kelly > > wrote:
>>
>> Hi Daniel
>>
>> It's CSeq 1, fromtag A1
>>
>> DB attached
>>
>> On 26 April 2017 at 15:03, Daniel-Constantin Mierla
>> > wrote:
>>
>> Can you paste here the from tag or cseq for the dialog
>> you are referring to? Because the number of frames are
>> not matching my pcap viewer.
>>
>> Send also the db dump, they should reveal if something is
>> broken there.
>>
>> Cheers,
>> Daniel
>>
>>
>> On 26.04.17 14:46, Pete Kelly wrote:
>>> Ah I see why it is confusing
>>>
>>> This setup maintains a Call-ID through an SBC
>>> downstream, so the INVITE's you see have the same
>>> Call-ID but they have a different fromtag/cseq,
>>> Wireshark shows them all as one call which is annoying
>>> when looking at the viewer!
>>>
>>> If you check the first call only between 252.70 and
>>> 252.75 you will see INVITE (frame 4), 200OK (frame 16)
>>> with lots of RR headers.
>>>
>>> The ACK generated by topos (frame 21) only contains 1
>>> Route header, it should contain more so the request can
>>> hop through the proxy chain as shown in frame 16.
>>>
>>> I see the example from Sergey is working, but there is
>>> only 1 RR header in this example - as you can see from
>>> my example the topos module uses the first RR header but
>>> ignores the other 5.
>>>
>>> I have the DB dump and logfiles from this call too if
>>> useful.
>>>
>>> Pete
>>>
>>>
>>> On 26 April 2017 at 12:41, Daniel-Constantin Mierla
>>> > wrote:
>>>
>>> As I could notice upon a quick look, there seems to
>>> be two calls -- two
>>> INVITE requests having same call id but different
>>> cseq. Can you confirm
>>> this is the case? Because the capture doesn't seem
>>> to have all the
>>> incoming/outgoing messages, some are missing.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 26.04.17 12:59, Sergey Basov wrote:
>>> > You give to us very hard callflow...
>>> >
>>> > Without any pauses between responces..
>>> >
>>> > Some requests go through 127.0.0.1... But
>>> responces from 127.0.0.1 not present.
>>> >
>>> > There are peers from which invites not present in
>>> dump. I can not see
>>> > ful path of the initial Invite, but there is
>>> responses.
>>> >
>>> > I will send dump in next email directly.
>>> > --
>>> > Best regards,
>>> > Sergey Basov e-mail:
>>> sergey.v.ba...@gmail.com
>>> 
>>> >
>>> >
>>> > 2017-04-26 11:01 GMT+03:00 Pete Kelly
>>> >:
>>> >> Attached is the pcap from latest nightly.
>>> >>
>>> >> As you can see (frame 21) the ACK is incorrect, I
>>> believe it should specify
>>> >> all the hops from the 200OK (frame 16) so that
>>> 

Re: [SR-Users] Memory leak when reloading htable using db_cluster

[Kristian F . Høgh]

Hi Daniel.

Thanks alot.
It fixed the problem at my testbed.
In production i reload several htables + address and domain, so I updated my 
config.

16(31430) ALERT: qm_status:1700. N  address=0x7f9bf03905e8 
frag=0x7f9bf03905b0 size=64 used=1
16(31430) ALERT: qm_status:   alloc'd from db_mysql: km_res.c: 
db_mysql_get_columns(77)
16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(31430) ALERT: qm_status:1701. N  address=0x7f9bf0390690 
frag=0x7f9bf0390658 size=64 used=1
16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
db_allocate_columns(150)
16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(31430) ALERT: qm_status:1702. N  address=0x7f9bf0390738 
frag=0x7f9bf0390700 size=64 used=1
16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
db_allocate_columns(160)
16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(31430) ALERT: qm_status:1703. N  address=0x7f9bf03907e0 
frag=0x7f9bf03907a8 size=64 used=1
16(31430) ALERT: qm_status:   alloc'd from core: db_res.c: 
db_new_result(114)
16(31430) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(31430) ALERT: qm_status:1706. N  address=0x7f9bf0390a58 
frag=0x7f9bf0390a20 size=64 used=1
16(31430) ALERT: qm_status:   alloc'd from db_mysql: km_res.c: 
db_mysql_new_result(236)

Regards,
Kristian.

On Friday, April 28, 2017 9:38:25 AM CEST Daniel-Constantin Mierla wrote:
> Hello,
> 
> can you fetch the master and try again -- I just pushed some fixes.
> 
> Cheers,
> Daniel
> 
> 
> On 28.04.17 08:17, Kristian F. Høgh wrote:
> > Hi list,
> >
> > I use current git master.
> > When I reload a htable using "kamcmd htable.reload htable1", the "ctl 
> > handler" process leaks 384 bytes of pkg memory
> > If I use a direct mysql connection without db_cluster, the is no memory leak
> >
> > modparam("db_cluster", "connection", 
> > "con1=>mysql://user:p...@ip.addr/database")
> > modparam("db_cluster", "connection", 
> > "con2=>mysql://user:pass@ip.addr2/database")
> > modparam("db_cluster", "cluster", "cls1=>con1=9s9s;con2=8s8s")
> >
> > modparam("htable", "db_url", "cluster://cls1")
> > # modparam("htable", "db_url", "mysql://user:p...@ip.addr/database"
> > modparam("htable", "htable", 
> > "htable1=>size=8;autoexpire=0;dbtable=htable1;")
> >
> > 16(10429) ALERT: qm_status:6513. N  address=0x7f4e65e01720 
> > frag=0x7f4e65e016e8 size=128 used=1
> > 16(10429) ALERT: qm_status:   alloc'd from db_cluster: dbcl_api.c: 
> > db_cluster_init(294)
> > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > c0c0c0c0, abcdefed
> > 16(10429) ALERT: qm_status:6514. N  address=0x7f4e65e01808 
> > frag=0x7f4e65e017d0 size=128 used=1
> > 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> > db_do_init2(298)
> > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > c0c0c0c0, abcdefed
> > 16(10429) ALERT: qm_status:6515. N  address=0x7f4e65e018f0 
> > frag=0x7f4e65e018b8 size=128 used=1
> > 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> > db_do_init2(298)
> > 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> > c0c0c0c0, abcdefed
> >
> > Regards,
> > Kristian Høgh
> > Uni-tel A/S
> >
> >  
> >
> > ___
> > Kamailio (SER) - Users Mailing List
> > sr-users@lists.kamailio.org
> > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> 


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos and PRACK problem

[Daniel-Constantin Mierla]

I think the BYE for early dialog branches should follow same rules as
with PRACK. If a 200ok was not received yet for INVITE, BYE can be sent
to close a single branch, if the caller wants to terminate the entire
call, then it has to send CANCEL at that moment.

I haven't had the time to look at traces yet...

Cheers,
Daniel

On 28.04.17 08:56, Sergey Basov wrote:
> Sorry, this not regarding prack.
>
> This for correct contact for bye without 200 OK.
>
> In call-to-2-dest-bye-on-caller-side.pcap file, you can see correct
> handling of the BYE request with contact from 180 Ringing
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-28 9:52 GMT+03:00 Daniel-Constantin Mierla :
>> Hello,
>>
>> were the two branches both requiring prack?
>>
>> Cheers,
>> Daniel
>>
>>
>> On 28.04.17 08:47, Sergey Basov wrote:
>>> Hi Daniel.
>>>
>>> I does not see problem with parallel forking to 2 destinations.
>>>
>>> I will send 2 dumps in private email.
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>>
>>>
>>> 2017-04-27 15:34 GMT+03:00 Sergey Basov :
 May be, but there is one more problem.

 I just test call to CSIPSimple softphone, it does not returm 183, it
 just return 180 Ringing.Call was not answered for some time, and I
 decide to terminate it from the caller side.
 BYE massege goes wrong, to recor-route value, as PRACK before, because
 contact from CSIPSimple side was not get from 180, call was not
 answered so 200 OK was not send.
 And topos doea not have contact value to send by to CSIPSimple.

 I will send dump to your private e-mail, it has real IP adreses.

 Thank you.
 --
 Best regards,
 Sergey Basov e-mail: sergey.v.ba...@gmail.com


 2017-04-27 15:12 GMT+03:00 Daniel-Constantin Mierla :
> Hello,
>
> although I just looked briefly at the patch, I think that works in case
> of a single branch sent out, but if there is going to be a parallel
> forking to two or more destinations, this is not going to work.
>
> Cheers,
> Daniel
>
> On 27.04.17 13:33, Sergey Basov wrote:
>> Hi, Daniel.
>>
>> Seems I found how to fix PRACK handling.
>>
>> It works for me.
>>
>> please lock at https://github.com/kamailio/kamailio/pull/1097
>>
>> Thank you.
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>
>>
>> 2017-04-27 13:04 GMT+03:00 Sergey Basov :
>>> Yes, you are right.
>>>
>>> But now before 200 OK there empty field b_contact.
>>>
>>> May be you does not populate it from contact in 183 Progress?
>>>
>>> I see that this field is not empty only after 200 OK with a Contact 
>>> field.
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>>
>>>
>>> 2017-04-27 12:37 GMT+03:00 Daniel-Constantin Mierla :
 Hello,

 thanks for troubleshooting further. I haven't got the time to look at
 the source code, but I expect that the b-leg attributes (contact, 
 record
 routes) to be set on 200ok for dialog (topos_d). I think for PRACK, the
 routing information should be stored and taken from transaction 
 (topos_t).

 Cheers,
 Daniel

 On 27.04.17 11:29, Sergey Basov wrote:
> Hi, Daniel.
>
> I just done one more test topos with re-invite which comes from caller
> to callee, same direction as PRACK.
>
> And I found that, in case of prack, b_contact field is empty...
>
> Please find attached debug=3 part of re-invite message.
>
> Hope it helps.
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-27 10:30 GMT+03:00 Sergey Basov :
>> Hi, Daniel
>>
>> Please look at attached part of debug=3 while receiving and parsing 
>> PRACK.
>> At line 208 seems rr module does not find correct part of 
>> record_route
>> which in DB consists from 2 parts.
>>
>> So at line 219 and later uac module cannot restore uris.
>>
>> Thank you.
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>
>>
>> 2017-04-26 17:08 GMT+03:00 Sergey Basov :
>>> Thanks for workaround.
>>>
>>> But I will wait for you solution )
>>>
>>> I ready for testing )
>>>
>>> Thank you Daniel for your 

Re: [SR-Users] Memory leak when reloading htable using db_cluster

[Daniel-Constantin Mierla]

Hello,

can you fetch the master and try again -- I just pushed some fixes.

Cheers,
Daniel


On 28.04.17 08:17, Kristian F. Høgh wrote:
> Hi list,
>
> I use current git master.
> When I reload a htable using "kamcmd htable.reload htable1", the "ctl 
> handler" process leaks 384 bytes of pkg memory
> If I use a direct mysql connection without db_cluster, the is no memory leak
>
> modparam("db_cluster", "connection", 
> "con1=>mysql://user:p...@ip.addr/database")
> modparam("db_cluster", "connection", 
> "con2=>mysql://user:pass@ip.addr2/database")
> modparam("db_cluster", "cluster", "cls1=>con1=9s9s;con2=8s8s")
>
> modparam("htable", "db_url", "cluster://cls1")
> # modparam("htable", "db_url", "mysql://user:p...@ip.addr/database"
> modparam("htable", "htable", "htable1=>size=8;autoexpire=0;dbtable=htable1;")
>
> 16(10429) ALERT: qm_status:6513. N  address=0x7f4e65e01720 
> frag=0x7f4e65e016e8 size=128 used=1
> 16(10429) ALERT: qm_status:   alloc'd from db_cluster: dbcl_api.c: 
> db_cluster_init(294)
> 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(10429) ALERT: qm_status:6514. N  address=0x7f4e65e01808 
> frag=0x7f4e65e017d0 size=128 used=1
> 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> db_do_init2(298)
> 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
> 16(10429) ALERT: qm_status:6515. N  address=0x7f4e65e018f0 
> frag=0x7f4e65e018b8 size=128 used=1
> 16(10429) ALERT: qm_status:   alloc'd from core: db.c: 
> db_do_init2(298)
> 16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= 
> c0c0c0c0, abcdefed
>
> Regards,
> Kristian Høgh
> Uni-tel A/S
>
>  
>
> ___
> Kamailio (SER) - Users Mailing List
> sr-users@lists.kamailio.org
> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com


___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos and PRACK problem

[Daniel-Constantin Mierla]

Hello,

were the two branches both requiring prack?

Cheers,
Daniel


On 28.04.17 08:47, Sergey Basov wrote:
> Hi Daniel.
>
> I does not see problem with parallel forking to 2 destinations.
>
> I will send 2 dumps in private email.
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-27 15:34 GMT+03:00 Sergey Basov :
>> May be, but there is one more problem.
>>
>> I just test call to CSIPSimple softphone, it does not returm 183, it
>> just return 180 Ringing.Call was not answered for some time, and I
>> decide to terminate it from the caller side.
>> BYE massege goes wrong, to recor-route value, as PRACK before, because
>> contact from CSIPSimple side was not get from 180, call was not
>> answered so 200 OK was not send.
>> And topos doea not have contact value to send by to CSIPSimple.
>>
>> I will send dump to your private e-mail, it has real IP adreses.
>>
>> Thank you.
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>
>>
>> 2017-04-27 15:12 GMT+03:00 Daniel-Constantin Mierla :
>>> Hello,
>>>
>>> although I just looked briefly at the patch, I think that works in case
>>> of a single branch sent out, but if there is going to be a parallel
>>> forking to two or more destinations, this is not going to work.
>>>
>>> Cheers,
>>> Daniel
>>>
>>> On 27.04.17 13:33, Sergey Basov wrote:
 Hi, Daniel.

 Seems I found how to fix PRACK handling.

 It works for me.

 please lock at https://github.com/kamailio/kamailio/pull/1097

 Thank you.
 --
 Best regards,
 Sergey Basov e-mail: sergey.v.ba...@gmail.com


 2017-04-27 13:04 GMT+03:00 Sergey Basov :
> Yes, you are right.
>
> But now before 200 OK there empty field b_contact.
>
> May be you does not populate it from contact in 183 Progress?
>
> I see that this field is not empty only after 200 OK with a Contact field.
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-27 12:37 GMT+03:00 Daniel-Constantin Mierla :
>> Hello,
>>
>> thanks for troubleshooting further. I haven't got the time to look at
>> the source code, but I expect that the b-leg attributes (contact, record
>> routes) to be set on 200ok for dialog (topos_d). I think for PRACK, the
>> routing information should be stored and taken from transaction 
>> (topos_t).
>>
>> Cheers,
>> Daniel
>>
>> On 27.04.17 11:29, Sergey Basov wrote:
>>> Hi, Daniel.
>>>
>>> I just done one more test topos with re-invite which comes from caller
>>> to callee, same direction as PRACK.
>>>
>>> And I found that, in case of prack, b_contact field is empty...
>>>
>>> Please find attached debug=3 part of re-invite message.
>>>
>>> Hope it helps.
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>>
>>>
>>> 2017-04-27 10:30 GMT+03:00 Sergey Basov :
 Hi, Daniel

 Please look at attached part of debug=3 while receiving and parsing 
 PRACK.
 At line 208 seems rr module does not find correct part of record_route
 which in DB consists from 2 parts.

 So at line 219 and later uac module cannot restore uris.

 Thank you.
 --
 Best regards,
 Sergey Basov e-mail: sergey.v.ba...@gmail.com


 2017-04-26 17:08 GMT+03:00 Sergey Basov :
> Thanks for workaround.
>
> But I will wait for you solution )
>
> I ready for testing )
>
> Thank you Daniel for your work!
>
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-26 16:57 GMT+03:00 Daniel-Constantin Mierla 
> :
>> Hello,
>>
>>
>> On 26.04.17 14:53, Sergey Basov wrote:
>>> Hi All.
>>>
>>> I have just try to test topos with GW which requires PRACK.
>>>
>>> As you can see UA at packet 21 send PRACK to topos contact, but 
>>> after
>>> topos, on other kamailio side in PRACK request line present not
>>> kontact but record-route header.
>>>
>>> Can you fix it?
>>>
>>>
>> probably needs to look into the code. If you need a quick workaround,
>> try to remove Supported header from INVITE so the callee should no
>> longer Require 100rel.
>>
>> Cheers,
>> Daniel
>>
>> --
>> Daniel-Constantin Mierla
>> 

Re: [SR-Users] Date Time with microsec

[Daniel-Constantin Mierla]

Hello,


On 28.04.17 04:00, Diego Nadares wrote:
> Hi Guys,
>
> Is to convert or obtain 
>
> $TV(s) - seconds (cached at first call per sip message)
> $TV(u) - microseconds (cached at first call per sip message)
>
> to datetime.microsecs?
>
> I'm trying to save 180/183 datetime (cached) like -MM-DD
> HH:mm:SS.microsecs
>
> $dlg_var(ring_time) = $timef(%Y-%m-%d %H:%M:%S); <--this is current
> time, not cached
> $dlg_var(ring_time_micro) = $TV(u); <-- this is cached us
>
if you mix cached with no cached values, then you get them from
different points in time and they are not accurate.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] topos and PRACK problem

[Sergey Basov]

Hi Daniel.

I does not see problem with parallel forking to 2 destinations.

I will send 2 dumps in private email.
--
Best regards,
Sergey Basov e-mail: sergey.v.ba...@gmail.com


2017-04-27 15:34 GMT+03:00 Sergey Basov :
> May be, but there is one more problem.
>
> I just test call to CSIPSimple softphone, it does not returm 183, it
> just return 180 Ringing.Call was not answered for some time, and I
> decide to terminate it from the caller side.
> BYE massege goes wrong, to recor-route value, as PRACK before, because
> contact from CSIPSimple side was not get from 180, call was not
> answered so 200 OK was not send.
> And topos doea not have contact value to send by to CSIPSimple.
>
> I will send dump to your private e-mail, it has real IP adreses.
>
> Thank you.
> --
> Best regards,
> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>
>
> 2017-04-27 15:12 GMT+03:00 Daniel-Constantin Mierla :
>> Hello,
>>
>> although I just looked briefly at the patch, I think that works in case
>> of a single branch sent out, but if there is going to be a parallel
>> forking to two or more destinations, this is not going to work.
>>
>> Cheers,
>> Daniel
>>
>> On 27.04.17 13:33, Sergey Basov wrote:
>>> Hi, Daniel.
>>>
>>> Seems I found how to fix PRACK handling.
>>>
>>> It works for me.
>>>
>>> please lock at https://github.com/kamailio/kamailio/pull/1097
>>>
>>> Thank you.
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>>
>>>
>>> 2017-04-27 13:04 GMT+03:00 Sergey Basov :
 Yes, you are right.

 But now before 200 OK there empty field b_contact.

 May be you does not populate it from contact in 183 Progress?

 I see that this field is not empty only after 200 OK with a Contact field.
 --
 Best regards,
 Sergey Basov e-mail: sergey.v.ba...@gmail.com


 2017-04-27 12:37 GMT+03:00 Daniel-Constantin Mierla :
> Hello,
>
> thanks for troubleshooting further. I haven't got the time to look at
> the source code, but I expect that the b-leg attributes (contact, record
> routes) to be set on 200ok for dialog (topos_d). I think for PRACK, the
> routing information should be stored and taken from transaction (topos_t).
>
> Cheers,
> Daniel
>
> On 27.04.17 11:29, Sergey Basov wrote:
>> Hi, Daniel.
>>
>> I just done one more test topos with re-invite which comes from caller
>> to callee, same direction as PRACK.
>>
>> And I found that, in case of prack, b_contact field is empty...
>>
>> Please find attached debug=3 part of re-invite message.
>>
>> Hope it helps.
>> --
>> Best regards,
>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>
>>
>> 2017-04-27 10:30 GMT+03:00 Sergey Basov :
>>> Hi, Daniel
>>>
>>> Please look at attached part of debug=3 while receiving and parsing 
>>> PRACK.
>>> At line 208 seems rr module does not find correct part of record_route
>>> which in DB consists from 2 parts.
>>>
>>> So at line 219 and later uac module cannot restore uris.
>>>
>>> Thank you.
>>> --
>>> Best regards,
>>> Sergey Basov e-mail: sergey.v.ba...@gmail.com
>>>
>>>
>>> 2017-04-26 17:08 GMT+03:00 Sergey Basov :
 Thanks for workaround.

 But I will wait for you solution )

 I ready for testing )

 Thank you Daniel for your work!

 --
 Best regards,
 Sergey Basov e-mail: sergey.v.ba...@gmail.com


 2017-04-26 16:57 GMT+03:00 Daniel-Constantin Mierla 
 :
> Hello,
>
>
> On 26.04.17 14:53, Sergey Basov wrote:
>> Hi All.
>>
>> I have just try to test topos with GW which requires PRACK.
>>
>> As you can see UA at packet 21 send PRACK to topos contact, but after
>> topos, on other kamailio side in PRACK request line present not
>> kontact but record-route header.
>>
>> Can you fix it?
>>
>>
> probably needs to look into the code. If you need a quick workaround,
> try to remove Supported header from INVITE so the callee should no
> longer Require 100rel.
>
> Cheers,
> Daniel
>
> --
> Daniel-Constantin Mierla
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio Advanced Training - May 22-24 (USA) - www.asipto.com
> Kamailio World Conference - May 8-10, 2017 - www.kamailioworld.com
>
>
> ___
> 

[SR-Users] Memory leak when reloading htable using db_cluster

[Kristian F . Høgh]

Hi list,

I use current git master.
When I reload a htable using "kamcmd htable.reload htable1", the "ctl handler" 
process leaks 384 bytes of pkg memory
If I use a direct mysql connection without db_cluster, the is no memory leak

modparam("db_cluster", "connection", "con1=>mysql://user:p...@ip.addr/database")
modparam("db_cluster", "connection", 
"con2=>mysql://user:pass@ip.addr2/database")
modparam("db_cluster", "cluster", "cls1=>con1=9s9s;con2=8s8s")

modparam("htable", "db_url", "cluster://cls1")
# modparam("htable", "db_url", "mysql://user:p...@ip.addr/database"
modparam("htable", "htable", "htable1=>size=8;autoexpire=0;dbtable=htable1;")

16(10429) ALERT: qm_status:6513. N  address=0x7f4e65e01720 
frag=0x7f4e65e016e8 size=128 used=1
16(10429) ALERT: qm_status:   alloc'd from db_cluster: dbcl_api.c: 
db_cluster_init(294)
16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(10429) ALERT: qm_status:6514. N  address=0x7f4e65e01808 
frag=0x7f4e65e017d0 size=128 used=1
16(10429) ALERT: qm_status:   alloc'd from core: db.c: db_do_init2(298)
16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed
16(10429) ALERT: qm_status:6515. N  address=0x7f4e65e018f0 
frag=0x7f4e65e018b8 size=128 used=1
16(10429) ALERT: qm_status:   alloc'd from core: db.c: db_do_init2(298)
16(10429) ALERT: qm_status:  start check=f0f0f0f0, end check= c0c0c0c0, 
abcdefed

Regards,
Kristian Høgh
Uni-tel A/S

 

___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users