Re: [SR-Users] xhttp_rpc commands ?

Thanks. Daniel, Regarding jsonrpc-s, 2 questions if I may: 1. Is it possible to send multiple requests that are handled simultaneously like sip workers? or are they handled one by one on the listening fifo ? 2. can you send an example of how to use dlg.dlg_end with the relevant dialog params?

Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in reply

Any ideas how to solve this? Regards, Grant From: sr-users on behalf of Grant Bagdasarian Sent: Monday, March 14, 2016 3:09:47 PM To: 'mico...@gmail.com'; Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Kamailio 4.3.4: receive_msg(): no via found in

Re: [SR-Users] SIP reg request not print in kamailio.log

So i recommend for you to not waste your time with logging until it becomes really necessary. Just install sngrep and run it while you make your test calls so that you can easily follow the message flows. If you cannot understand kamailio behavior from SIP messa

Re: [SR-Users] xhttp_rpc commands ?

The module is not intended to be used in a "scripted" mode. It simply provides a simple web interface with all the available rpc commands. Point a web browser to http://myserver:myport/http_rpc and browse through the available rpc commands. Suggestion on how to make the documentation more clear are

[SR-Users] for kamailio registration

For registration , we would like to see the complete traces at all nodes whoever processing UE sending REGISTER method. could you please let me know how can we check the logging at all IMS nodes? i am able to successfully register and got 200OK but i want understand what and all processing has been

Re: [SR-Users] Kamailio and UCARP with Multiple VIPs defined

Perfect, thanks Daniel, all works! Sorry for the noise :) Jon Subject: Re: [SR-Users] Kamailio and UCARP with Multiple VIPs defined To: hunter...@hotmail.com; sr-users@lists.sip-router.org From: mico...@gmail.com Date: Tue, 15 Mar 2016 08:48:31 +0100 Hello, On 14/03/

Re: [SR-Users] SIP reg request not print in kamailio.log

Thanks for help We need this for test /development On 15 Mar 2016 2:39 p.m., "Shiv Patidar" wrote: > Thank you for help > For registration , we would like to see the complete traces at all nodes > whoever processing UE sending REGISTER method. > could you please let me know how can we check the l

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

Hello, On 15/03/16 09:16, Alex Balashov wrote: > [...] > > However, I don't know what other dependencies it would have; are > branches not a part of TM state as well? Or is it just a question of > far too many data structures to dump/restore? It is a ton of stuff there, from avps, xavps, flags, b

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

On 15/03/16 09:31, Juha Heinanen wrote: > Alex Balashov writes: > >> ‎I don't know about that. Granted, I work largely within the >> intra-carrier/intra-industrial space, not so much with end-user >> endpoints, but to me it seems UDP is still the overwhelming norm. > In that space I would assume

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

Alex Balashov writes: > ‎I don't know about that. Granted, I work largely within the > intra-carrier/intra-industrial space, not so much with end-user > endpoints, but to me it seems UDP is still the overwhelming norm. In that space I would assume that SIP over TLS is mandatory. Anything else is

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

‎I don't know about that. Granted, I work largely within the intra-carrier/intra-industrial space, not so much with end-user endpoints, but to me it seems UDP is still the overwhelming norm.  TCP has made some inroads as a solution to certain categories of problems, and has become rather less "

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

Alex Balashov writes: > I definitely had in mind a minimalistic solution which has few > dependencies on other elements of state -- and certainly, in my mind, it > was implicitly UDP-only. I thought that SIP over UDP had already disappeared from the planet. -- Juha ___

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

Hi Daniel, On 03/15/2016 04:04 AM, Daniel-Constantin Mierla wrote: This was discussed a lot during early days of SER and even many times along the 15 years so far. I see! Sorry, perhaps I should have dug deeper into list archives and folklore before suggesting it. The persistence of tran

Re: [SR-Users] TCP connection select problem

Can you attach a pcap with such situation, which includes the REGISTER, replies and the call showing the issue? Cheers, Daniel On 15/03/16 03:36, 张顺通 wrote: > sorry，I have not expressed clearly. > > kamailio will recive two REGISTER at a time.In first 200 OK to > REGISTER, Server will tell Linpho

Re: [SR-Users] Kamailio 5.0 - Better way of dealing with stateless CANCELs

This was discussed a lot during early days of SER and even many times along the 15 years so far. The persistence of transaction is not something easy, because of its complex relations with timers for retransmissions over udp, but also with connections for tcp/tls. Each transaction has a lot of sta

Re: [SR-Users] Kamailio and UCARP with Multiple VIPs defined

Hello, On 14/03/16 17:39, Jonathan Hunter wrote: > Hi Daniel, > > Actually I see I need to go to 4.3 to use the ds_default_socket parameter. ... and per destination by using socket param in attributes: http://www.kamailio.org/docs/modules/stable/modules/dispatcher.html#dispatcher.ex.attributes C

Re: [SR-Users] Kamailio and UCARP with Multiple VIPs defined

Hello, with recent versions, there is a socket parameter that you can add to attributes field for each destination. Cheers, Daniel On 14/03/16 16:59, Jonathan Hunter wrote: > Hi Daniel, > > Thanks for the reply, sorry I keep missing you ! :) > > I have added force_send_socket in the correct plac

Re: [SR-Users] RTPPROXY error message

Hello, if rtpproxy is listening on udp:127.0.0.1:7722, then you may have some limits in place regarding sockets/traffic -- if you have selinux enabled, try without it. Also, you can try by lowering the value for children parameter. Regarding the SQL errors, it seems you run the config from Siremi