If no operator is matched in the first two characters of expression part
for $shtcn(...), then regexp is used. That's because initially the
$shtcn() was doing only regexp matching, later it was added support for
additional operators.
Yes, == is the operator for equal.
Cheers,
Daniel
On 16.10.18 11:53, jenus(a)cyberchaos.nl wrote:
> Daniel,
>
> Ok so if i'm correct i can prefix the callid with for example 1234 to
> avoid matching the eq. In other words eq will only match the …
[View More]regex
> code if the callid string starts with it?
>
> And by mathing on equal you mean: $shtcn(ht_test=>==$var(htid)) ?
>
> Thanks,
>
> Jan
>
> Daniel-Constantin Mierla schreef op 2018-10-16 10:16:
>> Just to add that regexp matching when using keys from the sip message
>> such as call-id is exposed further to some issues -- for example, it is
>> common to have . (dot) in call-id, which for a regexp is matching any
>> char, so a call id having 123.456 is matching 123x456. So depending on
>> what you want to count, might be better to match by equal or prefix
>> rules.
>>
>> Cheers,
>> Daniel
>>
>> On 16.10.18 10:03, jenus(a)cyberchaos.nl wrote:
>>> Daniel,
>>>
>>> Thanks for the quick response, that indeed solves my problem.
>>>
>>>
>>> Jan
>>>
>>> Daniel-Constantin Mierla schreef op 2018-10-16 09:55:
>>>> Hello,
>>>>
>>>> the expression in the $shtcn(table=>exp) can have some operators at
>>>> the
>>>> beginning, see:
>>>>
>>>> -
>>>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#shtcn_htable_…
>>>>
>>>>
>>>>
>>>> So, eq is one of them, the safest is to explicitly set the operator if
>>>> you cannot predict what is the key, like in this case. If the operator
>>>> is missing, then the exp is matched as regular expression, so you can
>>>> do:
>>>>
>>>> $shtcn(ht_test=>~~$var(htid))
>>>>
>>>> Cheers,
>>>> Daniel
>>>>
>>>>
>>>> On 16.10.18 09:47, jenus(a)cyberchaos.nl wrote:
>>>>> Hello,
>>>>>
>>>>> I'm running kamailio 5.1.4 and running into a issue with htable. I
>>>>> use
>>>>> it to store some dialog data so i can use it in a http route. When i
>>>>> use the callid as a key it creates a issue for callid's starting with
>>>>> eq. Here some example code that i use to reproduce the issue:
>>>>>
>>>>>
>>>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
>>>>>
>>>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::"
>>>>> + $Ts;
>>>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
>>>>> eq1234");
>>>>> $var(htid) = "eq1234";
>>>>> $sht(ht_test=>$var(htid)) = $var(htable-val);
>>>>> $var(htable-val) = $null;
>>>>>
>>>>> if ($shtcn(ht_test=>$var(htid)) > 0)
>>>>> {
>>>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!");
>>>>> } else {
>>>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
>>>>> }
>>>>> $var(htid) = $null;
>>>>>
>>>>> Results in :
>>>>>
>>>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
>>>>> HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234
>>>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
>>>>> HT_TEST: Key eq1234 NOT found!
>>>>>
>>>>>
>>>>> When i prefix eq with a 1 it works fine:
>>>>>
>>>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
>>>>>
>>>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::"
>>>>> + $Ts;
>>>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
>>>>> eq1234");
>>>>> $var(htid) = "1eq1234";
>>>>> $sht(ht_test=>$var(htid)) = $var(htable-val);
>>>>> $var(htable-val) = $null;
>>>>>
>>>>> if ($shtcn(ht_test=>$var(htid)) > 0)
>>>>> {
>>>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!");
>>>>> } else {
>>>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
>>>>> }
>>>>> $var(htid) = $null;
>>>>>
>>>>> Results in:
>>>>>
>>>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
>>>>> HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234
>>>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
>>>>> HT_TEST: Key eq1234 found!
>>>>>
>>>>>
>>>>> Am i running into a bug? Or are there some restrictions on the
>>>>> key's i
>>>>> can use? I'm still going trough the logs to check if there are more
>>>>> callid's that have a issue with matching.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Jan Hazenberg
>>>>>
>>>>> _______________________________________________
>>>>> Kamailio (SER) - Users Mailing List
>>>>> sr-users(a)lists.kamailio.org
>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>
>
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
[View Less]
Just to add that regexp matching when using keys from the sip message
such as call-id is exposed further to some issues -- for example, it is
common to have . (dot) in call-id, which for a regexp is matching any
char, so a call id having 123.456 is matching 123x456. So depending on
what you want to count, might be better to match by equal or prefix rules.
Cheers,
Daniel
On 16.10.18 10:03, jenus(a)cyberchaos.nl wrote:
> Daniel,
>
> Thanks for the quick response, that indeed solves my …
[View More]problem.
>
>
> Jan
>
> Daniel-Constantin Mierla schreef op 2018-10-16 09:55:
>> Hello,
>>
>> the expression in the $shtcn(table=>exp) can have some operators at the
>> beginning, see:
>>
>> -
>> https://www.kamailio.org/wiki/cookbooks/devel/pseudovariables#shtcn_htable_…
>>
>>
>> So, eq is one of them, the safest is to explicitly set the operator if
>> you cannot predict what is the key, like in this case. If the operator
>> is missing, then the exp is matched as regular expression, so you can
>> do:
>>
>> $shtcn(ht_test=>~~$var(htid))
>>
>> Cheers,
>> Daniel
>>
>>
>> On 16.10.18 09:47, jenus(a)cyberchaos.nl wrote:
>>> Hello,
>>>
>>> I'm running kamailio 5.1.4 and running into a issue with htable. I use
>>> it to store some dialog data so i can use it in a http route. When i
>>> use the callid as a key it creates a issue for callid's starting with
>>> eq. Here some example code that i use to reproduce the issue:
>>>
>>>
>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
>>>
>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::"
>>> + $Ts;
>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
>>> eq1234");
>>> $var(htid) = "eq1234";
>>> $sht(ht_test=>$var(htid)) = $var(htable-val);
>>> $var(htable-val) = $null;
>>>
>>> if ($shtcn(ht_test=>$var(htid)) > 0)
>>> {
>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!");
>>> } else {
>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
>>> }
>>> $var(htid) = $null;
>>>
>>> Results in :
>>>
>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
>>> HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234
>>> Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
>>> HT_TEST: Key eq1234 NOT found!
>>>
>>>
>>> When i prefix eq with a 1 it works fine:
>>>
>>> modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
>>>
>>> $var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::"
>>> + $Ts;
>>> xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
>>> eq1234");
>>> $var(htid) = "1eq1234";
>>> $sht(ht_test=>$var(htid)) = $var(htable-val);
>>> $var(htable-val) = $null;
>>>
>>> if ($shtcn(ht_test=>$var(htid)) > 0)
>>> {
>>> xlog("L_WARN", "HT_TEST: Key eq1234 found!");
>>> } else {
>>> xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
>>> }
>>> $var(htid) = $null;
>>>
>>> Results in:
>>>
>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
>>> HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234
>>> Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
>>> HT_TEST: Key eq1234 found!
>>>
>>>
>>> Am i running into a bug? Or are there some restrictions on the key's i
>>> can use? I'm still going trough the logs to check if there are more
>>> callid's that have a issue with matching.
>>>
>>>
>>> Thanks,
>>>
>>> Jan Hazenberg
>>>
>>> _______________________________________________
>>> Kamailio (SER) - Users Mailing List
>>> sr-users(a)lists.kamailio.org
>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
--
Daniel-Constantin Mierla -- www.asipto.comwww.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio World Conference -- www.kamailioworld.com
Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
[View Less]
Hello,
I'm running kamailio 5.1.4 and running into a issue with htable. I use
it to store some dialog data so i can use it in a http route. When i use
the callid as a key it creates a issue for callid's starting with eq.
Here some example code that i use to reproduce the issue:
modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
$var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" +
$Ts;
xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
…
[View More]eq1234");
$var(htid) = "eq1234";
$sht(ht_test=>$var(htid)) = $var(htable-val);
$var(htable-val) = $null;
if ($shtcn(ht_test=>$var(htid)) > 0)
{
xlog("L_WARN", "HT_TEST: Key eq1234 found!");
} else {
xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
}
$var(htid) = $null;
Results in :
Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
HT_TEST: Adding 531::926::1539675391 to ht_test with key eq1234
Oct 16 09:36:31 sip03 /usr/sbin/kamailio[22344]: WARNING: <script>:
HT_TEST: Key eq1234 NOT found!
When i prefix eq with a 1 it works fine:
modparam("htable", "htable", "ht_test=>size=16;autoexpire=10")
$var(htable-val) = $_s($dlg(h_entry)) + "::" + $_s($dlg(h_id)) + "::" +
$Ts;
xlog("L_WARN", "HT_TEST: Adding $var(htable-val) to ht_test with key
eq1234");
$var(htid) = "1eq1234";
$sht(ht_test=>$var(htid)) = $var(htable-val);
$var(htable-val) = $null;
if ($shtcn(ht_test=>$var(htid)) > 0)
{
xlog("L_WARN", "HT_TEST: Key eq1234 found!");
} else {
xlog("L_WARN", "HT_TEST: Key eq1234 NOT found!");
}
$var(htid) = $null;
Results in:
Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
HT_TEST: Adding 3050::1098::1539675445 to ht_test with key eq1234
Oct 16 09:37:25 sip03 /usr/sbin/kamailio[22555]: WARNING: <script>:
HT_TEST: Key eq1234 found!
Am i running into a bug? Or are there some restrictions on the key's i
can use? I'm still going trough the logs to check if there are more
callid's that have a issue with matching.
Thanks,
Jan Hazenberg
[View Less]
Hi,
I'm using Kamailio 4.2.0 and I'm developing a SIP-based application.
Today I made a test connecting two devices directly to an S7 sharing the
Internet, I usually use a VPN even if they are both connected to the same
network because in the future they will be in different networks.Without
the VPN calls were not received.
This has never happened to me, I have repeated tests and in an S6 it has
also happened to me.
So I have checked my Kamailio server and I have detected that when
executing: …
[View More]kamctl ul show,
the received field did not appear:
With VPN:
Contact:: sip:pruebaT@47.60.42.40:10924;transport=udp Q=
Expires:: 1992
Callid:: iwNoYb~QR-
Cseq:: 21
User-agent:: Unknown (belle-sip/1.6.1)
Received:: sip:47.60.42.40:10924
State:: CS_NEW
Flags:: 0
Cflag:: 64
Socket:: udp:10.0.0.4:5060
Methods:: 4294967295
Ruid:: uloc-5a9d9097-9fa-431c
Instance::
<urn:uuid:8b50dde3-d07f-4752-9a24-7b8ddf219a99>
Reg-Id:: 0
Last-Keepalive:: 1539614732
Last-Modified:: 1539614732
Without VPN:
Contact:: sip:pruebaT@37.10.156.189:51163;transport=udp Q=
Expires:: 1996
Callid:: webjvHycBs
Cseq:: 21
User-agent:: Unknown (belle-sip/1.6.1)
State:: CS_NEW
Flags:: 0
Cflag:: 0
Socket:: udp:10.0.0.4:5060
Methods:: 4294967295
Ruid:: uloc-5a9d9097-9fc-1feb
Instance::
<urn:uuid:89306a81-e2d1-4b7a-8206-107e3cbc0688>
Reg-Id:: 0
Last-Keepalive:: 1539614531
Last-Modified:: 1539614531
Would someone know why it happened? Thanks
--
José Antonio Gutiérrez Delgado
Responsable técnico
Oficina: (+34) 923040031
<http://www.arsoft-company.com/>
*Este mensaje se dirige exclusivamente a su destinatario/s y puede contener
información privilegiada o confidencial. Si no es vd. el destinatario
indicado, queda notificado de que la utilización, divulgación y/o copia sin
autorización está prohibida en virtud de la legislación vigente. Si ha
recibido este mensaje por error, le rogamos que nos lo comunique
inmediatamente por esta misma vía y proceda a su destrucción.*
*Antes de imprimir, piensa si es necesario. Cuidar el medioambiente es
tarea de todos.*
[View Less]
I am fresher and want to learn about Kamailio Soft switch,
Anyone can provide me link or document from where i can learn.
I will be thankful for such help,
Thanks & Regards,
Shailendra Kumar
Hi all,
I have an issue with SDP from Kamailio side in the following scenario: simple call from A to B.
When B answers a call and sends '200 OK' to A, A delays ACK for a while, so '200 OK' re-transmission happens.
After the fourth try to re-send '200 OK' towards A, Kamailio changes SDP (specifically connection information 'c', IP address become address of A instead of proxy IP as it was in the previous attempts). At some point A sends ACK and call is established, but last received '200 OK' …
[View More]has invalid SDP and it prevents successful media establishment.
I wonder if there any re-transmission counter or whatever what can affect this scenario and change SDP?
Roman Romanchenko
VoIP devel
Sipwise GmbH
[View Less]
Hi,
I forget, can $dlg_var(...) variables nowadays be reconstituted, along
with dialog state in general, using database backing?
What about profile membership?
Last time I brushed with this topic was probably in 4.x days, and as I
remember the general idea was that dialog state could be recovered on
restart, but without dialog variables or profile counts. Is this
accurate? Is it still true? Or has the amount of state serialised into
database persistence increased since then?
Thanks much!
-…
[View More]- Alex
--
Alex Balashov | Principal | Evariste Systems LLC
Tel: +1-706-510-6800 / +1-800-250-5920 (toll-free)
Web: http://www.evaristesys.com/, http://www.csrpswitch.com/
[View Less]
Hi ppl,
I have this problem with call transfer, may be someone can help.
The phone to the far right is registered with the Registrar to the far left
using two PATH headers (trespassing two proxy ports, 5070 then 5060).
As you can see in the graph below, after receiving the UPDATE request,
Kamailio relays it further from port 5060, I expect it to be from 5070 just
like the dialog forming INVITE and the CANCEL afterwards.
[image: image.png]
The UPDATE has a to-tag, but unlike the original …
[View More]INVITE - it has no Route
header!???
route[*WITHINDLG*] {
if (!has_totag()) return;
if (loose_route()) {
route(DLGURI);
if (is_method("BYE")) {
...
}
else if ( is_method("ACK") ) {
route(NATMANAGE);
}
else if ( is_method("NOTIFY") ) {
record_route();
}
route(RELAY);
exit;
}
if ( is_method("ACK") ) {
...
}
# handle UPDATE method for in-dialog requests
if (is_method("*UPDATE*")) {
route(DLGURI);
record_route();
route(RELAY);
}
}
Thanks in advance.
[View Less]
Greetings,
in order to upgrade kamailio server from 3.0.3 to 5.1.4 version, I am
conducting test calls and it is not completelly successful. The main
components I have are:
1- Media Gateway (Asterisk) : 192.168.226.133
2- Signalling Gateway (Kamailio 5.1.4) 192.168.226.132
3- Global Dispatcher (Kamailio 3.0.3 in front of the Signalling Gateway.) :
192.168.226.130
Both caller and callee have the dispatcher's IP as a proxy and their
registration requests is passed to be registered at the …
[View More]Signalling Gateway
(Kamailio 5.1.4) and saved on the MySQL server. The caller reaches the
callee properly, who in its turn answeres the call and sends the OK msg to
the caller who gets it. Unfortunately, when the caller sends the ACK for
this INVITE to the callee, the ACK does not reach the callee because it is
trapped by the dispatcher at the last stage because the uri was dropped and
the Route header was used instead. This behaviour is abnormal since as I
know the Route header should be converted into a Via header and the uri
stays untouchable.
The ACK was looped into the dispatcher itself .i.e. the dispatcher sent it
to itself adding always the via header ""Via: SIP/2.0/UDP
192.168.226.130;branch=0"" endlessly.
Once again, here is an example of the ACK before the dispatcher and how the
dispatcher forwards the ACK afterwards.
the supposed path is as following:
caller --> GDP--> SGW --> MGW--> SGW --> GDP --> callee
Although the GDP (before the calle after the SGW) received the uri well
from SGW inside the ACK as it appears below:
ACK sip:yyyyyyyyyyyy@192.168.226.130:5060;rinstance=1608f7c153f40093;transport=UDP
SIP/2.0
Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f>
Via: SIP/2.0/UDP
192.168.226.132;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0
Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9
Route: <sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6>
Max-Forwards: 69
From: "xxxxxxxxxxxxxx" <sip:xxxxxxxxxxxx@domain.com>;tag=as3b989c5f
To: <sip:yyyyyyyyyyyyy@192.168.226.132:5060>;tag=1af2c424
Contact: <sip:xxxxxxxxx@192.168.226.133:5060>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com
CSeq: 102 ACK
User-Agent: MGW
Content-Length: 0
The global dipstacher (GDP) has used the Route header (which has no R-URI
yyyyyyyyy) instead of the uri:
ACK sip:192.168.226.130;lr;ftag=as3b989c5f;did=d5b.87890dc6 SIP/2.0
Record-Route: <sip:192.168.226.132;lr=on;ftag=as3b989c5f>
Via: SIP/2.0/UDP 192.168.226.130;branch=0
Via: SIP/2.0/UDP
192.168.226.132;rport=5060;branch=z9hG4bK136f.1e8349c235fff01ee1849f3456f8868a.0
Via: SIP/2.0/UDP 192.168.226.133:5060;rport=5060;branch=z9hG4bK34871fe9
Max-Forwards: 68
From: "xxxxxxxxxx" <sip:xxxxxxxxxxx@domain.com>;tag=as3b989c5f
To: <sip:yyyyyyyyy@192.168.226.132:5060>;tag=1af2c424
Contact: <sip:xxxxxxx@192.168.226.132:5060>
Call-ID: 7ed2ab533d4c43086746d0e620bdff06(a)domain.com
CSeq: 102 ACK
User-Agent: MGW
Content-Length: 0
Thanks in advance for your contribution
Abdulaziz
[View Less]