Re: [SR-Users] The problem of get_aor_hash function

Hi, Danial I had modified ims_usrloc_pcscf/udomain.c about hash function and related codes. ex. via_host replaces with aor aorhash = get_aor_hash(_d, _info->aor, contact_info->via_port, contact_info->via_prot); //aorhash = get_aor_hash(_d, _info->via_host, contact_info->via_port,

Re: [SR-Users] uri==myself

So, i think i have determined the root cause of my issue: Background info: - I have a request URI of an INVITE that contains no port number. - My application is not listening on the default port of 5060 The is_myself(...) function handles a 'no port in request uri' differently than

Re: [SR-Users] dialog module : questions about dialog states

Thank you for your help. We use TLS protocol from mobile networks. In most cases we have no problems during the three way handshake (invite -> 200Ok -> ACK). But sometimes, we didn't received the ACK of 200OK (the TCP connection appears broken during the three way handshake per example). In

Re: [SR-Users] uri==myself

standby, i have the debug mode spitting out tons of logs now. time for me to review. will let you know if i need help. thanks, karthik On Thu, Jul 19, 2018 at 3:15 PM, Karthik Srinivasan wrote: > Unfortunately same result as before: > > $var(myself) = 0; >if (uri =~ "" || uri ==

Re: [SR-Users] uri==myself

Unfortunately same result as before: $var(myself) = 0; if (uri =~ "" || uri == myself){ $var(myself) = 1; xlog("L_INFO", "[$ci] in uri == myself check: var myself = $var(myself)"); } if (uri =~ "" || is_myself("$ru")){ $var(myself) = 1; xlog("L_INFO", "[$ci] in

Re: [SR-Users] dialog module : questions about dialog states

If state < 0, then practically the INVITE transaction is active, it needs to be cancelled or replied with t_reply(...) and a code >=400. >From where you need to terminate this ongoing INVITE, from kamailio.cfg or from external app? Cheers, Daniel On 19.07.18 19:20, Abdoul Osséni wrote: >

Re: [SR-Users] uri==myself

Hello, things are different that one may expect from evaluation of an expression compared with other established scripting/programming languages. One thing to be sure you are aware of are the return code evaluation:   -

Re: [SR-Users] uri==myself

Also, the INIT_VARS route is the very first thing that executes within the main routing block. The case that i am interested in that results in one statement returning false and the other true is for an INVITE. I tried printing the uri variable but was unsuccessful in doing so. Maybe if that's

Re: [SR-Users] dialog module : questions about dialog states

ERRATUM. What is the best way to end calls for states < 3 ? Abdoul OSSENI Ingénieur DevOps chez Néo-Soft Co-Fondateur de ON SERVICES Tél : +33 601 135 167 2018-07-19 19:19 GMT+02:00 Abdoul Osséni : > Thank you Daniel. > What is the best way to end calls for states 3 and 4 ? > > Regards > >

Re: [SR-Users] uri==myself

Yes, they are used at the very same place. here is a code snippet of where i added it for testing purposes: route[INIT_VARS] { $var(myself) = uri =~ "" || uri == myself; //if i print $var(myself) it prints 0 $var(myself) = uri =~ "" || is_myself("$ru"); //if i print $var(myself) it prints 1 //

Re: [SR-Users] dialog module : questions about dialog states

Hello, On 19.07.18 18:15, Abdoul Osséni wrote: > Hello list, > > When the dialog state for a call is < 4, is it possible to use > dlg_bye() function to end the call? > it should be possible to use it for states 3 and 4. Lower state than 3 means that the dialog was not answered yet (no 200ok

Re: [SR-Users] uri==myself

Hello, On 19.07.18 18:32, Karthik Srinivasan wrote: > Hello, > > Can someone explain to me why statement A returns True and statement B > returns False. > > Statement A: > is_myself("$ru") > > Statement B: > uri == myself > > > Isn't uri and $ru referencing the same data?    > > With my current

Re: [SR-Users] Locking htable entries

Yes. Daniel On 19.07.18 14:18, Alex Balashov wrote: > Oh, I see. So, if I understood correctly, the primary intended use-case is > really to make operations consisting of multiple accesses/writes atomic? > > -- Alex > > -- > Sent via mobile, please forgive typos and brevity. > >

[SR-Users] dialog module : questions about dialog states

Hello list, When the dialog state for a call is < 4, is it possible to use dlg_bye() function to end the call? Best regards Abdoul OSSENI Ingénieur DevOps chez Néo-Soft Co-Fondateur de ON SERVICES Tél : +33 601 135 167 ___ Kamailio (SER) - Users

Re: [SR-Users] No cdr after Kamailio 5.0.4 and 5.2 dev restart

Hello, I have a test environment with Kamailio 5.1.4 where I can investigate the bug. After restart 'kamctl dialog show' command shows the present dialog. After hangup kamailio does an insert into acc table and makes delete from dialog and dialog_vars tables. Any idea? Thanks, Szabolcs

Re: [SR-Users] Locking htable entries

Oh, I see. So, if I understood correctly, the primary intended use-case is really to make operations consisting of multiple accesses/writes atomic? -- Alex -- Sent via mobile, please forgive typos and brevity. ___ Kamailio (SER) - Users Mailing

Re: [SR-Users] Locking htable entries

... worth mentioning that locking for htable is re-entrant, so it is not ending into a deadlock when doing:  - lock slot for $sht(x=>y)  - read/write $sht(x=>y)  - unlock slot for $sht(x=>y) But always do unlock if doing the lock explicitly. Cheers, Daniel On 19.07.18 14:08,

Re: [SR-Users] Locking htable entries

Hello, readn and write operations are safe, done under mutex locking. So it is always safe to do: $sht(x=>y) = $var(y); or: $var(y) = $sht(x=>y); But there could be operations where you want that the value is not changed by another process while doing some operations, like: get the value from

[SR-Users] Locking htable entries

Hi, Sorry if this question has been answered before, but I'm rather puzzled as to the intent behind sht_lock() / sht_unlock(). Presumably, "thread"-safe / shm mutex locking is already implemented in htable query and mutation operations, otherwise htable would be unusable in a route script

Re: [SR-Users] Module RTPPROXY param Timeout_Socket not Working

I started the RTPproxy with the following command. /usr/bin/rtpproxy -u root -A [PUBLIC IP] -F -f -T 45 -i -2 -l 192.168.3.22 -b -m 35000 -M 65000 -s udp:127.0.0.1:7722 -n tcp:127.0.0.1:8000 -d DBUG Regards Hamid R. Hashmi __

Re: [SR-Users] Options for SIP traffic duplicating to third party tcp port

Am Mittwoch, 18. Juli 2018, 20:16:37 CEST schrieb Максим Баранов: > Hello, what are the options for duplicating sip traffic to arbitrary tcp > port in Kamailio? Hello, have you already looked into the sipcapture module? From the README: "The sipcapture module stores incoming/outgoing SIP

[SR-Users] Module RTPPROXY param Timeout_Socket not Working

Kamailio didn't start listening on IP mentioned in Module RTPPROXY parameter Timeout_Socket. Below is my configuration file. loadmodule "rtpproxy.so" modparam("rtpproxy", "rtpproxy_sock",

[SR-Users] Options for SIP traffic duplicating to third party tcp port

Hello, what are the options for duplicating sip traffic to arbitrary tcp port in Kamailio? ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users