[SR-Users] htable not visible in another thread

[Kjeld Flarup]

Im trying to do a t_suspend, but cant get htable to work

I save to $sht

$sht(vtp=>join::$rU) = "" + $T(id_index) + ":" + $T(id_label);
xlog( "L_ALERT", "Suspended transaction sht(vtp=>join::$rU) = 
[$sht(vtp=>join::$rU)]\n" );


    Mar 19 23:36:28 raspberrypi /usr/sbin/kamailio[2167]: ALERT: 

[SR-Users] Push and tcpconn_main_timeout

[Kjeld Flarup]

I got a bit wiser on my problem.

It seems that the sequence of events matters.

I have a PBX which should send the call to the App. If the App does not 
respond within three seconds, the call should be forwarded to a GSM number.


I have two scenarios, this one works:

1. PBX gets call
2. App registers
3. PBX sends invite
4. App rings

This fails

1. PBX gets call
2. PBX sends a push
3. App registers
4. PBX generates tcpconn_main_timeout or handle_tcpconn_ev on connect
   to App

I'm using a simple loop to wait for the registration (I got plenty of 
ressources!)


The obvious difference is that in the failing scenario, the call is in 
progress when the register arrives.


I do  not use the technique with t_suspend. Would that make a difference?

We are using TCP. We have tried with UDP, and then the Invite is send to 
the App.



 Med Liberalistiske Hilsner --
   Civilingeniør, Kjeld Flarup - Mit sind er mere åbent end min tegnebog
   Sofienlundvej 6B, 7560 Hjerm, Tlf: 40 29 41 49
   Den ikke akademiske hjemmeside for liberalismen - www.liberalismen.dk

On 03/19/2018 05:57 PM, Daniel Tryba wrote:

On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:

Interesting

Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.

That is not what I tried to say. All I wanted to say was:

uac ipA:portX -> syn -> server ipB:5060
uac ipA:portX <- syn-ack <- server ipB:5060
uac ipA:portX -> ack -> server ipB:5060
uac ipA:portX <->   server ipB:5060

Whether the uac is behind NAT or not, it is impossible to recreate the
connection between ipA:portX and ipB:5060 if there is ever a network
interruption.

Atleast that used to be true before SO_REUSEPORT support in kernels so
maybe the uac may be capable to reconnect with the same port, but it is
definitly impossible for the server to do this since there is simply no
listener to connect to.
  

I agree, that a perfect implementetion would be to keep the TCP stream up
while the client is connected, and use that connection for all
communication between the two stacks.

How about reregisters can they reuse the connection? Or should the
connection be closed once the packet is consumed?

This is all up to the endpoint, but having a DNS based loadbalancing
setup (SRV records, round robin A records) may have an influence.

Most clients I have seen sofar will simply reuse an existing TCP
connection for both INVITEs and re-REGISTERs. Clients with decend
NAPTR/SRV implementation will probably query DNS and iterate over the
available servers (with hopefuly 1 per server).

Kamailio will just reuse an existing connection as far as I have seen.


___
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] Issue in cdr generation in seconds format

[Henning Westerholt]

Am Montag, 19. März 2018, 13:49:52 CET schrieb Narayan P:
> Any update on this please.
> 

Hello Naryan,

have you tried with time_mode = 1?

6.45. time_mode (int)

   Store additional value related to the time of event.

   Values can be:
 * 0 - (default), save only unix timestamp for syslog and datetime for
   database.
 * 1 - save seconds in time_attr and microseconds in time_exten.

Best regards,

Henning



 
> Hello Sir,
> 
> 
> I need your expertise for kamailio cdr generation in seconds format.
> 
> 
> I have a requirement to generate cdr duration in second format.Now I am
> getting second.milliseconds format.Below is the log where duration is
> 18.676 but I want this to be 19.(suppose where duration =18.234, I need it
> to be 18).
> 
> 
> Mar 16 10:38:22 vm11-kamailio /usr/local/sbin/kamailio[20787]: NOTICE: acc
> [acc_cdr.c:352]: log_write_cdr(): start_time=1521196683.464;
> end_time=1521196702.140; duration=18.676; src_user=71097345;
> src_domain=185.122.XXX.XXX; src_ip=185.122.XXX.XXX; dst_user=;
> dst_ouser=91786042; dst_domain=185.122.XXX.XXX; sip_code=; sip_reason=;
> callid=LVHyTCFWYBpEFp.sFpY204aBdx.nez9B; dst_ip=185.122.XXX.XXX
> 
> 
> 
> My kamailio configuration related to cdr is like this;
> 
> /* what special events should be accounted ? */
> modparam("acc", "db_url", "flatstore:/var/log/cdr.log")
> #modparam("acc", "cdr_extra", "c1=$dlg_var(caller);c2=$dlg_var(callee)")
> modparam("acc", "log_facility", "LOG_DAEMON")
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdr_start_on_confirmed", 1)
> modparam("acc", "cdr_log_enable", 1)
> modparam("acc", "time_mode", 0)
> modparam("acc", "time_attr", "seconds")
> modparam("acc", "cdr_start_id", "start_time")
> modparam("acc", "cdr_end_id", "end_time")
> modparam("acc", "cdr_duration_id", "duration")
> #modparam("acc", "cdr_flag", 3)
> #modparam("acc", "early_media", 0)
> #modparam("acc", "report_ack", 0)
> #modparam("acc", "report_cancels", 0)
> #modparam("dialog", "enable_stats", 1)
> modparam("dialog", "hash_size", 1024)
> modparam("dialog", "dlg_flag", 3)
> modparam("dialog", "db_url", DBURL)
> 
> /* by default ww do not adjust the direct of the sequential requests.
>  * if you enable this parameter, be sure the enable "append_fromtag"
>  * in "rr" module */
> modparam("acc", "detect_direction", 0)
> /* account triggers (flags) */
> #modparam("acc", "log_flag", FLT_ACC)
> #modparam("acc", "log_missed_flag", FLT_ACCMISSED)
> #modparam("acc", "log_extra",
> #   "src_user=$fU;src_domain=$fd;src_ip=$si;"
> #   "dst_user=$tU;dst_user=$rU;dst_domain=$rd")
> modparam("acc",
>
> "cdr_extra","src_user=$fU;src_domain=$fd;src_ip=$si;dst_user=$rU;dst_ouser=
> $tU;dst_domain=$rd;sip_code=$rs;sip_reason=$rr;callid=$dlg(callid);dst_ip=$R
> i")
> 
> Please suggest me what to configure more in kamailio to achieve cdr in
> second format.
> 
> Thanks,
> Narayan



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

Re: [SR-Users] Security announcement related to Kamailio

[Henning Westerholt]

Am Montag, 19. März 2018, 19:51:17 CET schrieb Henning Westerholt:
> [..]
> You'll find all information about this issue consolidated on our web page
> at:
> 
> https://www.kamailio.org/w/2018/03/kamailio-security-announcement-tmx-lcr/

There was a small error in the configuration (missing braces). You find the 
fixed version in the link to our web page.

Regards,

Henning Westerholt

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

[SR-Users] phonenum module erratic behaviour with 5.1.2

[George Diamantopoulos]

Hello all,

It seems that the phonenum module in at least 5.1.2 (haven't tried previous
versions) is behaving somewhat erratically. More specifically, if there are
any references to any phn PVs with the key other than "number":

if ( phonenum_match("1-484-555-", "src") ) {
xlog("number norm: $phn(src=>number)\n");
xlog("number country: $phn(src=>country)\n");
dbg_pv_dump(30, "L_ERR");
}

kamailio will not start:

Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: 
[core/pvapi.c:494]: pv_spec_lookup(): PV <$phn(src=>country)> is not in
cache
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) DEBUG: phonenum
[phonenum_pv.c:160]: pv_parse_phonenum_name(): phonenum [src] - key
[country]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: phonenum
[phonenum_pv.c:205]: pv_parse_phonenum_name(): error at PV phonenum name:
src=>country
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
[core/pvapi.c:951]: pv_parse_spec2(): pvar "phn" has an invalid name param
[src=>country]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: 
[core/pvapi.c:1106]: pv_parse_spec2(): wrong char [)/41] in
[$phn(src=>country)] at [17 (5)]
Mar 19 20:06:49 modcom-sbc-dev1 kamailio[5042]:  0(5044) ERROR: xlog
[xlog.c:513]: xdbg_fixup_helper(): wrong format[number country:
$phn(src=>country)

If I comment the offending line, all is well, but when dumping PVs with
dbg_pv_dump(30, "L_ERR");, only $phn(src=>number) is listed, not the other
keys (country, operator, region according to the docs)

However, what is more disturbing is that phn(src=>number) always contains
the string provided to phonenum_match() function, even if invalid
characters are included, with no normalization. For example:

phonenum_match("14~8%^88", "src")

will result in dbg_pv_dump reporting:

"$phn(src=>number)": "14~8%^88"

Please note that I'm using sipwise's debian repository for stretch for
kamailio, and debian's stable stretch repository for libphonenumnber
(currently at 7.1.0-5+b1). I have also tried building current
libphonenumber myself (version v8.9.2), but the result is the same.

Is this a bug? Or am I missing something? Thanks!

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

Re: [SR-Users] msilo on proxy in front of registrar

[Daniel-Constantin Mierla]

Hello,


On 15.03.18 22:41, Stefan Sayer wrote:
> Hello,
>
> I have a bit of a strange situation where I want to add SIP MESSAGE
> reliability (store and forward) for a proxy that is in front of the
> (message-wise unreliable) registrar/message originator. So I m_store
> MESSAGEs in the failure_route of MESSAGE requests.
>
> By default, msilo's m_dump works only for REQUEST_ROUTE, thus I can't
> use that in the 200 to REGISTER. But when I add a function to msilo
> for ONREPLY_ROUTE (without the check for MESSAGE support) it works.

m_dump() uses the From URI, so it is no reason not to work for a reply.
Likely this limitation comes from the planned use for registration
request processing.

>
> So, is there a reason that there's m_dump only for REQUEST_ROUTE? And,
> is this:
>   if ((msg->first_line).type == SIP_REQUEST)
> the correct way to check whether we're handling a request or reply?

If you don't handle other protocol, yes. Otherwise you can also add the
constraint with IS_SIP() or IS_SIP_REPLY() macros (iirc, you still need
to check if it is a SIP_REQUEST ...).
>
> Also, is there a way to check the expires of contacts in the 200 to
> REGISTER from the script, so I don't try to m_dump on de-REGISTER? Or
> does this have to go into the m_dump function for the ONREPLY_ROUTE case?
>
See:
https://www.kamailio.org/wiki/cookbooks/5.1.x/pseudovariables#expires_key_-_expires_values

Cheers,
daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - 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] Some clarifications needed on async_task_route

[Daniel-Constantin Mierla]

Hello,

no actions are executed in the same route block after the line with
async_task_route("NICE_TO_HAVE") -- see the readme of the async module
at the documentation for this function.

If you want to continue executing the actions after pushing a task for
another process, you can try to combine mqueue+rtimer, but in your
example won't work, because the rtimer won't have the current sip
message in order to get the dialog for it.

Cheers,
Daniel


On 19.03.18 16:41, George Diamantopoulos wrote:
> Hello all,
>
> I've been exploring the async module a little, and async_task_route()
> more specifically. I have async_workers set, and the async module loaded.
>
> However, whenever this async function is involved in SIP processing,
> kamailio returns a 500 error to the UAC. I was hoping that someone
> could confirm that this function is suitable for my needs, I'm not
> sure I understand the docs very well on this one.
>
> So the plan is to have some of the processing of the transaction
> performed asynchronously, as it is not required for routing etc.
> Here's an example of what I'm trying to achieve, it's not really
> critical if NICE_TO_HAVE route functions fail etc, I just need
> request_route processing to continue normally without waiting
> for async_task_route("NICE_TO_HAVE") to finish whatever it's going to
> be doing:
>
> request_route() {
>
> ...
>
> SIP_PROCESSING_A
>
> ...
>
> async_task_route("NICE_TO_HAVE")
>
> ...
>
> SIP_PROCESSING_B
>
> t_relay();
>
> }
>
> route(NICE_TO_HAVE) {
>
> dlg_var(sth) = something_derived_from_global_vars();
>
> }
>
> Is this possible, or am I completely out of scope here? Thanks!
>
> BR,
> George
>
>
> ___
> 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 - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - 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] INFO: Relevant fixes in the last releases

[Daniel-Constantin Mierla]

On 16.03.18 19:00, Daniel Tryba wrote:
> On Wed, Mar 14, 2018 at 05:30:23PM +0100, Daniel-Constantin Mierla wrote:
>> I want to highlight that the last stable versions (for the latest 3
>> release series: 4.4, 5.0 and 5.1) include fixes for two issues that can
>> crash a running instance of Kamailio, therefore it is strongly
>> recommended to upgrade if you are using tmx or lcr modules.
>>
>> Next week a CVE report is going to be created with more details about
>> one of these issues.
> It is not totaly clear for me if the issue that will be revealed is
> already fixed in 4.4.7, 5.0.6, and 5.1.2 or whether we will need to
> update to a new release next week. I guess/hope it is the former.
>
> Kudos to the people/organisations finding these flaws and disclosing
> responsibly.
>
I missed your response so far, today Henning sent also an email with
more details.

The issues were fixed before 4.4.7, 5.0.6, and 5.1.2 releases (on Feb 5
lcr and Feb 10 tmx). There is nothing else that is expected to be done
in the code to fix them.

The announcement was not done at the time of discovery and fix, being
rather old code not reported to be exploited at all till that moment --
but the commits were pushed to public git, as we do with usual fixes
(and still no report of exploit afterwards) -- anyhow, we wanted to get
the new releases propagated naturally for a while, then give more
details, just in case such announcement may make the issues popular.

As a matter of fact, there were similar cases in the past, but we aim to
become more organized in these aspects, especially now that we were
helped by Enabled Security guys with the tmx issue, which did some
fuzzing stress on Kamailio (no other issue discovered so far).

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - 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] tcpconn_main_timeout

[Daniel Tryba]

On Mon, Mar 19, 2018 at 04:23:01PM +0100, Kjeld Flarup wrote:
> Interesting
> 
> Just to be sure that I understand You correctly.
> When a Register is done, then an Invite, must create a new TCP connection.

That is not what I tried to say. All I wanted to say was:

uac ipA:portX -> syn -> server ipB:5060
uac ipA:portX <- syn-ack <- server ipB:5060
uac ipA:portX -> ack -> server ipB:5060
uac ipA:portX <->   server ipB:5060

Whether the uac is behind NAT or not, it is impossible to recreate the
connection between ipA:portX and ipB:5060 if there is ever a network
interruption.

Atleast that used to be true before SO_REUSEPORT support in kernels so
maybe the uac may be capable to reconnect with the same port, but it is
definitly impossible for the server to do this since there is simply no
listener to connect to.
 
> I agree, that a perfect implementetion would be to keep the TCP stream up
> while the client is connected, and use that connection for all
> communication between the two stacks.
> 
> How about reregisters can they reuse the connection? Or should the
> connection be closed once the packet is consumed?

This is all up to the endpoint, but having a DNS based loadbalancing
setup (SRV records, round robin A records) may have an influence.

Most clients I have seen sofar will simply reuse an existing TCP
connection for both INVITEs and re-REGISTERs. Clients with decend
NAPTR/SRV implementation will probably query DNS and iterate over the
available servers (with hopefuly 1 per server).

Kamailio will just reuse an existing connection as far as I have seen.


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

[SR-Users] Some clarifications needed on async_task_route

[George Diamantopoulos]

Hello all,

I've been exploring the async module a little, and async_task_route() more
specifically. I have async_workers set, and the async module loaded.

However, whenever this async function is involved in SIP processing,
kamailio returns a 500 error to the UAC. I was hoping that someone could
confirm that this function is suitable for my needs, I'm not sure I
understand the docs very well on this one.

So the plan is to have some of the processing of the transaction performed
asynchronously, as it is not required for routing etc. Here's an example of
what I'm trying to achieve, it's not really critical if NICE_TO_HAVE route
functions fail etc, I just need request_route processing to continue
normally without waiting for async_task_route("NICE_TO_HAVE") to finish
whatever it's going to be doing:

request_route() {

...

SIP_PROCESSING_A

...

async_task_route("NICE_TO_HAVE")

...

SIP_PROCESSING_B

t_relay();

}

route(NICE_TO_HAVE) {

dlg_var(sth) = something_derived_from_global_vars();

}

Is this possible, or am I completely out of scope here? Thanks!

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

Re: [SR-Users] tcpconn_main_timeout

[Kjeld Flarup]

Interesting

Just to be sure that I understand You correctly.
When a Register is done, then an Invite, must create a new TCP connection.

I agree, that a perfect implementetion would be to keep the TCP stream up
while the client is connected, and use that connection for all
communication between the two stacks.

How about reregisters can they reuse the connection? Or should the
connection be closed once the packet is consumed?

2018-03-19 13:47 GMT+01:00 Daniel Tryba :

> On Sun, Mar 18, 2018 at 12:59:28PM +0100, Kjeld Flarup wrote:
> > Does this mean that Kamailio doesn't reuse this connection, and instead
> > tries to establish a new one.
> >
> > And is it possible to have two concurrent connections, especially when
> it is
> > trying to send an invite to a client behind NAT.
>
> It is impossible for a listener to reuse/reconnect a TCP connection even
> without NAT (a listener can only reuse the ip/port it was listening on).
> This is the main drawback of SIP over TCP with a REGISTERing endpoint
> IMHO.
>
> ___
> 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] Issue in cdr generation in seconds format

[Narayan P]

Hello All,


Any update on this please.


Thanks,

Narayan






From: sr-users  on behalf of Narayan P 

Sent: Friday, March 16, 2018 11:02:19 AM
To: sr-users@lists.kamailio.org
Subject: [SR-Users] Issue in cdr generation in seconds format


Hello Sir,


I need your expertise for kamailio cdr generation in seconds format.


I have a requirement to generate cdr duration in second format.Now I am getting 
second.milliseconds format.Below is the log where duration is 18.676 but I want 
this to be 19.(suppose where duration =18.234, I need it to be 18).


Mar 16 10:38:22 vm11-kamailio /usr/local/sbin/kamailio[20787]: NOTICE: acc 
[acc_cdr.c:352]: log_write_cdr(): start_time=1521196683.464; 
end_time=1521196702.140; duration=18.676; src_user=71097345; 
src_domain=185.122.XXX.XXX; src_ip=185.122.XXX.XXX; dst_user=; 
dst_ouser=91786042; dst_domain=185.122.XXX.XXX; sip_code=; sip_reason=; 
callid=LVHyTCFWYBpEFp.sFpY204aBdx.nez9B; dst_ip=185.122.XXX.XXX



My kamailio configuration related to cdr is like this;

/* what special events should be accounted ? */
modparam("acc", "db_url", "flatstore:/var/log/cdr.log")
#modparam("acc", "cdr_extra", "c1=$dlg_var(caller);c2=$dlg_var(callee)")
modparam("acc", "log_facility", "LOG_DAEMON")
modparam("acc", "cdr_enable", 1)
modparam("acc", "cdr_start_on_confirmed", 1)
modparam("acc", "cdr_log_enable", 1)
modparam("acc", "time_mode", 0)
modparam("acc", "time_attr", "seconds")
modparam("acc", "cdr_start_id", "start_time")
modparam("acc", "cdr_end_id", "end_time")
modparam("acc", "cdr_duration_id", "duration")
#modparam("acc", "cdr_flag", 3)
#modparam("acc", "early_media", 0)
#modparam("acc", "report_ack", 0)
#modparam("acc", "report_cancels", 0)
#modparam("dialog", "enable_stats", 1)
modparam("dialog", "hash_size", 1024)
modparam("dialog", "dlg_flag", 3)
modparam("dialog", "db_url", DBURL)

/* by default ww do not adjust the direct of the sequential requests.
 * if you enable this parameter, be sure the enable "append_fromtag"
 * in "rr" module */
modparam("acc", "detect_direction", 0)
/* account triggers (flags) */
#modparam("acc", "log_flag", FLT_ACC)
#modparam("acc", "log_missed_flag", FLT_ACCMISSED)
#modparam("acc", "log_extra",
#   "src_user=$fU;src_domain=$fd;src_ip=$si;"
#   "dst_user=$tU;dst_user=$rU;dst_domain=$rd")
modparam("acc",

"cdr_extra","src_user=$fU;src_domain=$fd;src_ip=$si;dst_user=$rU;dst_ouser=$tU;dst_domain=$rd;sip_code=$rs;sip_reason=$rr;callid=$dlg(callid);dst_ip=$Ri")

Please suggest me what to configure more in kamailio to achieve cdr in second 
format.

Thanks,
Narayan

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

Re: [SR-Users] tcpconn_main_timeout

[Daniel Tryba]

On Sun, Mar 18, 2018 at 12:59:28PM +0100, Kjeld Flarup wrote:
> Does this mean that Kamailio doesn't reuse this connection, and instead
> tries to establish a new one.
> 
> And is it possible to have two concurrent connections, especially when it is
> trying to send an invite to a client behind NAT.

It is impossible for a listener to reuse/reconnect a TCP connection even
without NAT (a listener can only reuse the ip/port it was listening on).
This is the main drawback of SIP over TCP with a REGISTERing endpoint
IMHO. 

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

[SR-Users] Kamailio World 2018 - grants for students and underrepresented people

[Daniel-Constantin Mierla]

Hello,

we are glad to announces that, thanks to the sponsors, we can offer
again couple of free seats at Kamailio World Conference, May 14-16,
2018, in Berlin, for students as well as for underrepresented people.

In this way we are continuing the program from last years, based on the
roots and the tight relation of Kamailio project with the academic
environment, the eligible people being students enrolled in universities
or research institutes (bachelor, master and PhD programs qualify) as
well as people from underrepresented groups.

If you think you are eligible and want to participate, email me directly
(mico...@gmail.com) or to registrat...@kamailio.org . Participation to
all the content of the event (workshops, conference and social event) is
free, but you will have to take care of expenses for traveling and
accommodation. Write a short description about your interest in real
time communications and, when it is the case  what is the university or
the research institute you are affiliate to.

Also, if you are not a student, but you are in touch with some or have
access to students forums/mailing lists, it will be very appreciated if
you forward these details.

More information about Kamailio World is available on the web site:

  - https://www.kamailioworld.com

Many thanks to the event sponsors that allowed to continue this program,
respectively: Evosip, 2600hz, Sipwise, Sipgate, Simwood, NG-Voice,
Evariste Systems, Digium, LOD.com, Pascom, Core Network Dynamics, FhG
Fokus and Asipto.

Expect a full house event! Looking forward to meeting many of you in Berlin!

Cheers,
Daniel

-- 
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - April 16-18, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - 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] Select last URI from Record-Route

[Andrew Pogrebennyk]

On 03/19/2018 10:37 AM, Andrew Pogrebennyk wrote:
> On 03/16/2018 05:07 PM, John Petrini wrote:
>> The simple answer to that is it's a last ditch effort to look up an AOR
>> record on a reply but it's part of other logic we use to establish
>> direct media.
> 
> try with $(hdr(Record-Route)[-1]).. it works for us (though, with
> another header name).
> Andrew
> 

Considering you might have multiple header fields all comma-separated in
one header, to access the last uri you'd have to do something like:

$(hdr(Record-Route)[-1]{s.select,-1,,}{nameaddr.uri});

Andrew

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

Re: [SR-Users] Select last URI from Record-Route

[Andrew Pogrebennyk]

On 03/16/2018 05:07 PM, John Petrini wrote:
> The simple answer to that is it's a last ditch effort to look up an AOR
> record on a reply but it's part of other logic we use to establish
> direct media.

try with $(hdr(Record-Route)[-1]).. it works for us (though, with
another header name).
Andrew

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

[SR-Users] Security announcement related to Kamailio

[Henning Westerholt]

Hello,

as already announced from Daniel-Constantin Mierla on the lists last Wednesday 
[1], we strongly advise you to update your Kamailio installation to the latest 
stable release for security reasons.

All supported releases (4.4, 5.0. and 5.1) contains two important security 
fixes related to the tmx and lcr module.


Technical details for the tmx issue:

A specially crafted REGISTER message with a malformed branch or From tag 
triggers a so called "off-by-one heap overflow". This vulnerability existed in 
the tmx module and makes it possible to remotely crash the Kamailio service. 

If an attacker sends many of this messages this would lead to a Denial of 
Service of the attacked infrastructure. This is especially critical as no 
authentication for the remote source is needed.

This vulnerability was found from Sandro Gauci and Alfred Farrugia from the 
Security Company Enable Security. Many thanks to them for finding the issue 
and reporting it to us.

You find all the details including a proof of concept code in the published 
security announcement from them:

https://github.com/EnableSecurity/advisories/tree/master/ES2018-05-kamailio-heap-overflow


Technical details for the lcr issue:

A vulnerability existed in the lcr next_gw() function. It happens when
a very long R-URI username is sent with an INVITE due to an mistake in the 
function error code handling. It can be triggered from a remote source, but
should be only from a trusted peer, as it expected that calls going
through lcr are authenticated by user or IP address.

This vulnerability was reported from an user in the Netherlands to us, thanks 
as well for the bug report.


So far we are not aware of any public exploits of this errors. But as already 
mentioned, we advise you to update your Kamailio servers to the latest stable 
release as soon as possible, especially as the tmx vulnerability will reported 
to more security lists later today.


Please address any detailed technical questions related to the two bugs to the 
developer list at sr-...@lists.kamailio.org .

In case of confidential remarks related to this or other security issues, 
please address them to the Kamailio Management at managem...@kamailio.org .


Best regards,

Henning Westerholt
Kamailio Project


[1] https://lists.kamailio.org/pipermail/sr-users/2018-March/100672.html

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

[SR-Users] Select last URI from Record-Route

[Ilie Soltanici]

Hi,

Try $(hdr(Record-Route)[-1]), to extract URI only you can
use: $(hdr(Record-Route)[0]{nameaddr.uri})
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users