[SR-Users] KEMI KSR.async Python3

[Ahmed Moubayed]

Hi,

I'm trying to use the async module from a python3 Kemi script but it
conflicts with the keyword async. Any suggestions on how it can be used? Is
there an alternative to KSR.async.route()?

Thanks,

Ahmed
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Publish XML and xpath

[Daniel-Constantin Mierla]

For sake of correctness, as I tried to figure out again searching the
web what the actual issue, the conflict seems to be with XPATH
specifications that don't define default xmlns scope, they have NULL
scope for no-prefix tags which is not the same as the default xmlns. Not
100% sure, as I didn't want to waste to much time, but looks more like
this one.

Cheers,
Daniel

On 10.02.22 16:52, Daniel-Constantin Mierla wrote:
>
> Hello,
>
> actually the problem is the mess SIMPLE RFC authors made with XML
> namespaces, by not setting and not using a prefix for them, otherwise
> the #012 is end-of-line printed by syslog as octal character.
>
> The solutions:
>
> 1) replace "xmlns=" with something else like "xyzwq=":
>
> $xml(body=>doc) = $(rb{s.replace,xmlns=,xyzwq=})
>
> and use xpath without concerning of xml namespaces prefix.
>
> 2) register a prefix for the namespace using xml_ns parameter from
> xmlops module and use that prefix in xpath expressions.
>
> See a past discussion on the mailing list:
>
>    -
> https://lists.kamailio.org/pipermail/sr-users/2010-December/066690.html
>
> Cheers,
> Daniel
>
> On 10.02.22 16:25, Igor Olhovskiy wrote:
>>
>> Hello
>>
>> Just to add, when I'm trying to dump $rb to logs, I'm getting this line
>>
>> #012> xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" 
>> entity="sip:1@dev.company">#012  > direction="recipient">#012    terminated#012  
>> #012
>>
>> So, I expect problem is in this #012 + extra spaces. Is there a way
>> to clean it up in an easy way?
>>
>> Regards,
>> Igor
>> Le 10.02.2022 à 16:01, Igor Olhovskiy a écrit :
>>>
>>> Hello,
>>>
>>> I'm trying to get state of endpoint from PUBLISH message in a most
>>> simple way using xmlops module
>>>
>>> Trying to make this
>>>
>>> $xml(body=>doc) = $rb;
>>> log("L_ERR", "$rU is now in state 
>>> $xml(body=>xpath:/dialog-info/dialog/state)\n");
>>>
>>> XML in PUBLISH itself
>>>
>>> 
>>> >> state="full" entity="sip:1@dev.company">
>>>   
>>>     confirmed
>>>   
>>> 
>>>
>>>
>>> Actual text in log is
>>>
>>> ... 

Re: [SR-Users] Fwd: CDR preserve original call direction

[Ahmed Fouad]

Thanks but this is already configured and still the same problem.

On Thu, Feb 10, 2022 at 12:47 PM Bastian Triller 
wrote:

> Check if rr module is loaded before acc and rr's parameter append_from_tag
> is set to 1.
>
>
> http://www.kamailio.net/docs/modules/5.3.x/modules/rr.html#rr.p.append_fromtag_id
> http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#idm211
>
> On Thu, Feb 10, 2022, 17:29 Ahmed Fouad  wrote:
>
>> Thanks for the reply but like I mentioned I tried to enable/disable
>> direction parameter but didn't help.
>> --
>> *From:* sr-users  on behalf of
>> Ovidiu Sas 
>> *Sent:* Thursday, February 10, 2022 12:44:39 PM
>> *To:* Kamailio (SER) - Users Mailing List 
>> *Subject:* Re: [SR-Users] Fwd: CDR preserve original call direction
>>
>>
>> Check the documentation and adjust your config accordingly:
>>
>> http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#acc.p.detect_direction
>>
>> modparam("acc", "detect_direction", 1)
>>
>> In your config is set to 0.
>>
>> Regards,
>> Ovidiu Sas
>>
>> On Wed, Feb 9, 2022 at 08:01 Ahmed Fouad  wrote:
>>
>>
>> Hi,
>>
>> I've enabled ACC and CDR logging and it's working fine for the logging
>> but I noticed something wrong in the CDR table , the call source and
>> destinations are depending on the BYE message not the initial invite dialog
>>
>> ACC table
>>
>> +-++--+-+---+---+--+--+--+
>> | id  | method | callid   | time
>>| src_ip| src_domain| src_user | dst_ouser
>>  | dst_domain   |
>>
>> +-++--+-+---+---+--+--+--+
>> | 216 | BYE| 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
>> 06:57:51 | x.x.x.x  | domain.com   |  DST_CLID |  SRC_CLID |
>> domain.com  |
>> | 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
>> 06:55:17 | x.x.x.x  | domain.com  | SRC_CLID   | DST_CLID |
>> dst_domain.com|
>>
>> The INVITE is the correct one with SRCIP x.x.x.x and domain.com but the
>> BYE reversed the order since the the DST_CLID who sent the BYE so it's now
>> logged as the source
>>
>> and the final CDR log looks like
>>
>>
>> ++--+---+--+--+-+-+--+-+---++---+-+
>> | cdr_id | src_username | src_domain| dst_username |
>> dst_domain   | call_start_time | call_end_time
>>
>>
>> ++--+---+--+--+-+-+--+-+---++---+-+
>> |195 |  DST_CLID | domain.com   |  SRC_CLID | domain.com
>>  | 2022-02-09 06:55:12 | 2022-02-09 06:57:51 |
>>
>> the CDR as shown is reversed regarding the source/dst username
>>
>> I tried to enable the direction ACC direction flag but didn't help and
>> here is my current paramters
>>
>> modparam("acc", "early_media", 0)
>> modparam("acc", "report_ack", 0)
>> modparam("acc", "report_cancels", 0)
>> modparam("acc", "detect_direction", 0)
>> modparam("acc", "log_flag", FLT_ACC)
>> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
>> modparam("acc", "cdr_enable", 1)
>> modparam("acc", "cdrs_table", "cdrs")
>>
>> Can you please advise how to configure ACC/CDR to log the CDR with the
>> correct initial INVITE call flow regardless of the BYE direction ?
>>
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
>> --
>> VoIP Embedded, Inc.
>> http://www.voipembedded.com
>> __
>> Kamailio - Users Mailing List - Non Commercial Discussions
>>   * sr-users@lists.kamailio.org
>> Important: keep the mailing list in the recipients, do not reply only to
>> the sender!
>> Edit mailing list options or unsubscribe:
>>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * 

Re: [SR-Users] Fwd: CDR preserve original call direction

[Bastian Triller]

Check if rr module is loaded before acc and rr's parameter append_from_tag
is set to 1.

http://www.kamailio.net/docs/modules/5.3.x/modules/rr.html#rr.p.append_fromtag_id
http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#idm211

On Thu, Feb 10, 2022, 17:29 Ahmed Fouad  wrote:

> Thanks for the reply but like I mentioned I tried to enable/disable
> direction parameter but didn't help.
> --
> *From:* sr-users  on behalf of
> Ovidiu Sas 
> *Sent:* Thursday, February 10, 2022 12:44:39 PM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] Fwd: CDR preserve original call direction
>
>
> Check the documentation and adjust your config accordingly:
>
> http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#acc.p.detect_direction
>
> modparam("acc", "detect_direction", 1)
>
> In your config is set to 0.
>
> Regards,
> Ovidiu Sas
>
> On Wed, Feb 9, 2022 at 08:01 Ahmed Fouad  wrote:
>
>
> Hi,
>
> I've enabled ACC and CDR logging and it's working fine for the logging but
> I noticed something wrong in the CDR table , the call source and
> destinations are depending on the BYE message not the initial invite dialog
>
> ACC table
>
> +-++--+-+---+---+--+--+--+
> | id  | method | callid   | time
>  | src_ip| src_domain| src_user | dst_ouser
>  | dst_domain   |
>
> +-++--+-+---+---+--+--+--+
> | 216 | BYE| 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:57:51 | x.x.x.x  | domain.com   |  DST_CLID |  SRC_CLID |
> domain.com  |
> | 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:55:17 | x.x.x.x  | domain.com  | SRC_CLID   | DST_CLID |
> dst_domain.com|
>
> The INVITE is the correct one with SRCIP x.x.x.x and domain.com but the
> BYE reversed the order since the the DST_CLID who sent the BYE so it's now
> logged as the source
>
> and the final CDR log looks like
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> | cdr_id | src_username | src_domain| dst_username |
> dst_domain   | call_start_time | call_end_time
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> |195 |  DST_CLID | domain.com   |  SRC_CLID | domain.com
>  | 2022-02-09 06:55:12 | 2022-02-09 06:57:51 |
>
> the CDR as shown is reversed regarding the source/dst username
>
> I tried to enable the direction ACC direction flag but didn't help and
> here is my current paramters
>
> modparam("acc", "early_media", 0)
> modparam("acc", "report_ack", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "log_flag", FLT_ACC)
> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdrs_table", "cdrs")
>
> Can you please advise how to configure ACC/CDR to log the CDR with the
> correct initial INVITE call flow regardless of the BYE direction ?
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
> --
> VoIP Embedded, Inc.
> http://www.voipembedded.com
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] REGISTER with http_async_client ?

[Federico Cabiddu]

Hi Cyril,
happy to hear that you solved the problem.
About switching back to request_route type is not possible, it has to do
with the kamailio mechanism to suspend transactions. The callback route is
always a failure route.
The solution for rtpengine is either to call rtpengine_offer explicitly or
call rtpengine_manage in a branch_route, as you are doing and it's imho
among the best practices for kamailio.

Cheers,

Federico


On Tue, Feb 8, 2022 at 10:34 AM Cyril Ramière 
wrote:

> Hi Federico,
>
> Thank you, this was the solution!
>
> You were right about trying to log $T(reply_code), this triggers the
> critical error and sends a 500 internal server error message.
> Since I was using the same xlog line across my entire code, $T(reply_code)
> was called multiple times, I didn't think it would cause such an issue
> since the documentation states that it returns 0 in the worst case.
>
> I stumbled across another issue, my rtpengine stopped working, it was due
> to the fact that the http async client (so async framework) uses a
> "failure_route" when triggering the callback route, so the first action of
> rtpengine_manage() is to DELETE the transaction if in failure_route.
>
> I moved/refactored some logic to trigger rtpengine inside a branch_route,
> but I'm wondering if there is a way after my http query is done to revert
> back to the request_route instead of the failure_route.
>
> Cheers,
>
> Cyril
>
> Le ven. 4 févr. 2022 à 10:00, Federico Cabiddu 
> a écrit :
>
>> Hi Cyril,
>> I tried your script and changing
>> sl_send_reply("200","OK");
>> with
>> send_reply("200","OK")  or t_reply("200","OK");
>> it works, a 200 OK reply is sent out.
>>
>> The message
>>
>> "CRITICAL: tmx [t_var.c:546]: pv_get_tm_reply_code(): no picked branch
>> (-1) for a final response in MODE_ONFAILURE"
>>
>> comes from trying, in the xlog call, to access $T(reply_code) where there
>> is actually no reply code for the transaction (no reply has been
>> received/generated)
>>
>> Could you try the following snippet based on http_async_client?
>>
>> request_route {
>> xlog("L_NOTICE", "ROOT - New request - M=$rm UAC-IP=$si:$sp
>> LB-IP=$tcp(c_si):$tcp(c_sp) UA='$ua' ID=$ci\n");
>>
>> if (is_method("REGISTER")){
>> xlog("L_NOTICE", "[ROOT] Got REGISTER. method=$rm -
>> code=$T(reply_code) - Destination=$ru - Origin=[$fU@$si:$sp]\n");
>> if(!is_present_hf("Authorization")){
>> xlog("L_INFO","[ROOT::REGISTER] No auth provided, sending
>> CHALLENGE for $fU ($fu) (FINAL)\n");
>> www_challenge("$td","1");
>> exit;
>> }
>> else{
>> xlog("L_INFO","[ROOT::REGISTER] Auth provided, Go to
>> AUTH_DOQUERY using http_async_client\n");
>> t_newtran();
>> http_async_query("http://127.0.0.1:8000/","AUTH_REPLY;);
>> }
>> }
>>
>> exit;
>> }
>>
>> route[AUTH_REPLY]{
>> xlog("L_NOTICE", "[AUTH_REPLY]: http_rs=$http_rs\n");
>> send_reply("200","OK");
>> exit;
>> }
>>
>> (I'm running a simple http server always replying 200 on the loopback
>> interface)
>>
>> Cheers,
>>
>> Federico
>>
>> On Thu, Feb 3, 2022 at 12:13 PM Cyril Ramière 
>> wrote:
>>
>>> Okay, so I have done that,
>>>
>>> Please find here :
>>> https://zerobin.net/?7743b78716b00c72#Jzmdq+5ZlFfZId+M/hP+52Ih0AMAMNUjeUT1cN7jL7Q=
>>>
>>> My full config (I redacted some parts like IPs and domains), with the
>>> minimal routing blocks to reproduce and the logs.
>>>
>>> If you don't mind checking it, it would be great :)
>>>
>>> Cheers,
>>>
>>> Cyril
>>>
>>> Le jeu. 3 févr. 2022 à 11:39, Federico Cabiddu <
>>> federico.cabi...@gmail.com> a écrit :
>>>
 I have to admit that even looking at the debug logs I cannot understand
 what's going on in your case.
 As said I'm running an authentication scenario very similar to yours,
 being the challenge the only difference.
 What I can suggest to further digging is to reduce your configuration
 as much as possible (e.g. I see that you are using topoh) and see if we can
 understand better what is causing the issue.

 Cheers,

 Federico


 On Thu, Feb 3, 2022 at 7:58 AM Olle E. Johansson 
 wrote:

>
>
> On 2 Feb 2022, at 23:58, Cyril Ramière 
> wrote:
>
> Hi Karsten,
>
> Thanks for the clue, unfortunately I can't use this module because the
> clients are "dumb" sip phones.
>
> The goal of my implementation is to use our application API to handle
> the login.
>
> The plan was that a sip phone sends a REGISTER, I ask the API endpoint
> if this user/password is ok to connect and allow/deny based on the reply
> and informations provided by the API.
>
> Everything is relying on the fact that I can make my HTTP call when
> handling the REGISTER, sadly for me, it doesn't work and I still can't
> figure why.
>
> Try http_client. I’ve used it a lot of time for 

Re: [SR-Users] Fwd: CDR preserve original call direction

[Ahmed Fouad]

Thanks for the reply but like I mentioned I tried to enable/disable direction 
parameter but didn't help.

From: sr-users  on behalf of Ovidiu Sas 

Sent: Thursday, February 10, 2022 12:44:39 PM
To: Kamailio (SER) - Users Mailing List 
Subject: Re: [SR-Users] Fwd: CDR preserve original call direction


Check the documentation and adjust your config accordingly:
http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#acc.p.detect_direction

modparam("acc", "detect_direction", 1)

In your config is set to 0.

Regards,
Ovidiu Sas

On Wed, Feb 9, 2022 at 08:01 Ahmed Fouad 
mailto:afo...@gmail.com>> wrote:

Hi,

I've enabled ACC and CDR logging and it's working fine for the logging but I 
noticed something wrong in the CDR table , the call source and destinations are 
depending on the BYE message not the initial invite dialog

ACC table
+-++--+-+---+---+--+--+--+
| id  | method | callid   | time| 
src_ip| src_domain| src_user | dst_ouser| 
dst_domain   |
+-++--+-+---+---+--+--+--+
| 216 | BYE| 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09 06:57:51 | 
x.x.x.x  | domain.com   |  DST_CLID |  SRC_CLID | 
domain.com  |
| 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09 06:55:17 | 
x.x.x.x  | domain.com  | SRC_CLID   | DST_CLID | 
dst_domain.com|

The INVITE is the correct one with SRCIP x.x.x.x and 
domain.com but the BYE reversed the order since the the 
DST_CLID who sent the BYE so it's now logged as the source

and the final CDR log looks like

++--+---+--+--+-+-+--+-+---++---+-+
| cdr_id | src_username | src_domain| dst_username | dst_domain 
  | call_start_time | call_end_time
++--+---+--+--+-+-+--+-+---++---+-+
|195 |  DST_CLID | domain.com   |  SRC_CLID | 
domain.com  | 2022-02-09 06:55:12 | 
2022-02-09 06:57:51 |

the CDR as shown is reversed regarding the source/dst username

I tried to enable the direction ACC direction flag but didn't help and here is 
my current paramters

modparam("acc", "early_media", 0)
modparam("acc", "report_ack", 0)
modparam("acc", "report_cancels", 0)
modparam("acc", "detect_direction", 0)
modparam("acc", "log_flag", FLT_ACC)
modparam("acc", "log_missed_flag", FLT_ACCMISSED)
modparam("acc", "cdr_enable", 1)
modparam("acc", "cdrs_table", "cdrs")

Can you please advise how to configure ACC/CDR to log the CDR with the correct 
initial INVITE call flow regardless of the BYE direction ?

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
--
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Kamailio doc request

[Alex Balashov]

No problem, you got it. ;-) 

> On Feb 10, 2022, at 9:16 AM, Mustafa Rahman  wrote:
> 
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>  * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to the 
> sender!
> Edit mailing list options or unsubscribe:
>  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

-- 
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/


__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

[SR-Users] Kamailio doc request

[Mustafa Rahman]

__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] Publish XML and xpath

[Igor Olhovskiy]

Daniel,

Many thanks!

Your "replace" solution looks more elegant than just remove the whole 
string.


Regards,
Igor

Le 10.02.2022 à 16:52, Daniel-Constantin Mierla a écrit :


Hello,

actually the problem is the mess SIMPLE RFC authors made with XML 
namespaces, by not setting and not using a prefix for them, otherwise 
the #012 is end-of-line printed by syslog as octal character.


The solutions:

1) replace "xmlns=" with something else like "xyzwq=":

$xml(body=>doc) = $(rb{s.replace,xmlns=,xyzwq=})

and use xpath without concerning of xml namespaces prefix.

2) register a prefix for the namespace using xml_ns parameter from 
xmlops module and use that prefix in xpath expressions.


See a past discussion on the mailing list:

   - 
https://lists.kamailio.org/pipermail/sr-users/2010-December/066690.html


Cheers,
Daniel

On 10.02.22 16:25, Igor Olhovskiy wrote:


Hello

Just to add, when I'm trying to dump $rb to logs, I'm getting this line

#012#012  #012    terminated#012  
#012

So, I expect problem is in this #012 + extra spaces. Is there a way 
to clean it up in an easy way?


Regards,
Igor
Le 10.02.2022 à 16:01, Igor Olhovskiy a écrit :


Hello,

I'm trying to get state of endpoint from PUBLISH message in a most 
simple way using xmlops module


Trying to make this

$xml(body=>doc) = $rb;
log("L_ERR", "$rU is now in state 
$xml(body=>xpath:/dialog-info/dialog/state)\n");

XML in PUBLISH itself



   
     confirmed
   



Actual text in log is

... 

Re: [SR-Users] Publish XML and xpath

[Igor Olhovskiy]

Hello,

Seems, there is a need to specify xmlns forcefully

As it's working when I do

$var(body) = $(rb{s.rm,xmlns="urn:ietf:params:xml:ns:dialog-info"});

So, I do need or to specify namespace or to remove this line from XML. 
But if someone can comment on this (cause XML is a world on it's own) 
I'd be really grateful.


Regards,
Igor

Le 10.02.2022 à 16:25, Igor Olhovskiy a écrit :


Hello

Just to add, when I'm trying to dump $rb to logs, I'm getting this line

#012#012  #012    terminated#012  
#012

So, I expect problem is in this #012 + extra spaces. Is there a way to 
clean it up in an easy way?


Regards,
Igor
Le 10.02.2022 à 16:01, Igor Olhovskiy a écrit :


Hello,

I'm trying to get state of endpoint from PUBLISH message in a most 
simple way using xmlops module


Trying to make this

$xml(body=>doc) = $rb;
log("L_ERR", "$rU is now in state 
$xml(body=>xpath:/dialog-info/dialog/state)\n");

XML in PUBLISH itself



   
     confirmed
   



Actual text in log is

... 

Re: [SR-Users] Publish XML and xpath

[Daniel-Constantin Mierla]

Hello,

actually the problem is the mess SIMPLE RFC authors made with XML
namespaces, by not setting and not using a prefix for them, otherwise
the #012 is end-of-line printed by syslog as octal character.

The solutions:

1) replace "xmlns=" with something else like "xyzwq=":

$xml(body=>doc) = $(rb{s.replace,xmlns=,xyzwq=})

and use xpath without concerning of xml namespaces prefix.

2) register a prefix for the namespace using xml_ns parameter from
xmlops module and use that prefix in xpath expressions.

See a past discussion on the mailing list:

   - https://lists.kamailio.org/pipermail/sr-users/2010-December/066690.html

Cheers,
Daniel

On 10.02.22 16:25, Igor Olhovskiy wrote:
>
> Hello
>
> Just to add, when I'm trying to dump $rb to logs, I'm getting this line
>
> #012 xmlns="urn:ietf:params:xml:ns:dialog-info" version="0" state="full" 
> entity="sip:1@dev.company">#012   direction="recipient">#012    terminated#012  
> #012
>
> So, I expect problem is in this #012 + extra spaces. Is there a way to
> clean it up in an easy way?
>
> Regards,
> Igor
> Le 10.02.2022 à 16:01, Igor Olhovskiy a écrit :
>>
>> Hello,
>>
>> I'm trying to get state of endpoint from PUBLISH message in a most
>> simple way using xmlops module
>>
>> Trying to make this
>>
>> $xml(body=>doc) = $rb;
>> log("L_ERR", "$rU is now in state 
>> $xml(body=>xpath:/dialog-info/dialog/state)\n");
>>
>> XML in PUBLISH itself
>>
>> 
>> > state="full" entity="sip:1@dev.company">
>>   
>>     confirmed
>>   
>> 
>>
>>
>> Actual text in log is
>>
>> ... 

Re: [SR-Users] Publish XML and xpath

[Igor Olhovskiy]

Hello

Just to add, when I'm trying to dump $rb to logs, I'm getting this line

#012#012  #012    terminated#012  
#012

So, I expect problem is in this #012 + extra spaces. Is there a way to 
clean it up in an easy way?


Regards,
Igor

Le 10.02.2022 à 16:01, Igor Olhovskiy a écrit :


Hello,

I'm trying to get state of endpoint from PUBLISH message in a most 
simple way using xmlops module


Trying to make this

$xml(body=>doc) = $rb;
log("L_ERR", "$rU is now in state 
$xml(body=>xpath:/dialog-info/dialog/state)\n");

XML in PUBLISH itself



   
     confirmed
   



Actual text in log is

... 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Daniel-Constantin Mierla]

I think it is not easy to impose any further restriction not to
distribute the sources, but one can try ... in some (many) countries
licenses and patents are not recognized or not enforced.

Cheers,
Daniel

On 10.02.22 11:47, Alex Balashov wrote:
> Come to think of it, I imagine the license has language saying that it
> cannot be superseded in part or in whole by any contradictory agreement.
>
> —
> Sent from mobile, with due apologies for brevity and errors.
>
>> On Feb 10, 2022, at 5:42 AM, Alex Balashov
>>  wrote:
>>
>>  Is it legally possible for a customer to separately contract away a
>> right that the license otherwise affords them, such as the GPL right
>> to demand source code and then turn around and distribute that source
>> code?
>>
>> I have to wonder if it’s possible in the US. It seems like it
>> shouldn’t be, but in principle, in the prevailing theme of
>> Anglo-American jurisprudence, it’s possible to contract away pretty
>> much anything, no matter how adverse to one’s interests, so long as
>> it is done “freely”.
>>
>> —
>> Sent from mobile, with due apologies for brevity and errors.
>>
>>> On Feb 10, 2022, at 2:37 AM, Henning Westerholt  wrote:
>>>
>>> 
>>>
>>> Hello,
>>>
>>>  
>>>
>>> just to add to the discussion:
>>>
>>>  
>>>
>>>   * Please have a look to the GPLv2 FAQ, many topics you’ve raised
>>> are discussed there
>>> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
>>>   * You should really consult a lawyer for this specific questions
>>>
>>>  
>>>
>>> Regarding the licence of the configuration (native script vs. KEMI)
>>> – my understanding would be that a native Kamailio cfg script would
>>> be independent of GPL as its interpreted (and practically the
>>> customer gets the “source code” anyway). But KEMI LUA code that is
>>> pre-compiled would fall under the GPL, so the customer has a right
>>> to get the source code for it. Compare e.g., to this:
>>> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>>
>>>  
>>>
>>> Cheers,
>>>
>>>  
>>>
>>> Henning
>>>
>>>  
>>>
>>> -- 
>>>
>>> Henning Westerholt – https://skalatan.de/blog/
>>> 
>>>
>>> Kamailio services – https://gilawa.com 
>>>
>>>  
>>>
>>> *From:* sr-users  *On Behalf Of
>>> *Olle E. Johansson
>>> *Sent:* Thursday, February 10, 2022 8:13 AM
>>> *To:* Kamailio (SER) - Users Mailing List 
>>> *Subject:* Re: [SR-Users] SEMS license with kamailio and rtpengine
>>>
>>>  
>>>
>>> Hi Seven!
>>>
>>> Note that many of these questions open a legal discussion that has
>>> been going on for many years. I base my answers on what I know,
>>> which may not be the full truth. Regardless, I have been involved in
>>> these kind of discussions for almost 30 years of working in open source.
>>>
>>>  
>>>
>>> First, note that there are two kind of situations to observe. One is
>>> when your application is executing in a system. The other is the
>>> license of the written source code files. 
>>>
>>>  
>>>
>>> Secondly, license and copyright are two different things. You always
>>> have the copyright to your source code.
>>>
>>>  
>>>
>>> In Kamailio there are source code files that have a different
>>> license than the rest of the files. That means that if you copy that
>>> source code and create a new product that license applies.
>>>
>>>  
>>>
>>> Kamailio as a whole is released under GPL version 2. When you run
>>> Kamailio in your server, that license applies to it all, regardless
>>> of the license of various source code files.
>>>
>>>  
>>>
>>> Also note that I base this discussion on a delivery of a system to a
>>> customer. When you run Kamailio as a service you do not deliver
>>> (according to GPL v2) and the customer doesn’t have the same rights
>>> to the source.
>>>
>>>  
>>>
>>> Also note that (as other persons has pointed out) that it’s the
>>> recipient of the binaries that has the rights, not the world. If I
>>> am not your customer, I can’t demand the source code according to
>>> the GPL. The customer that receives the code has the right to do
>>> whatever they want with it - like publishing the source on GitHub
>>> for the world to enjoy.
>>>
>>>  
>>>
>>>  
>>>
>>>
>>>
>>> 10 feb. 2022 kl. 00:16 skrev Seven Du :
>>>
>>>  
>>>
>>> I have some questions on this, e.g. on Kamailio:
>>>
>>>  
>>>
>>> 1. The core and some modules is GPL. I packaged that without
>>> change, and sell to a customer. and when the customer asks for
>>> source, I told him to download from the kamailio website, since
>>> I didn't change anything. Is that correct?
>>>
>>> How you distribute the source code to the customer is irrelevant
>>> here. Note that if you end up having to provide it on a floppy disk
>>> or a USB stick, you can charge for that according to the GPL :-)
>>>
>>>  
>>>
>>> 2. I can also host the source on my own website, with some more
>>> helper scripts for building and packaging. That should 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Daniel-Constantin Mierla]

Hello,

On 10.02.22 10:51, Henning Westerholt wrote:
>
> Hello,
>
> Just to add - your general statement “From this perspective, none of
> the config files (no matter they are native scripting, lua, python,
> javascript, etc...) are forced to be GPL, it is the decision of the
> config author what's its license.”
>
> This seems to be pretty clear to me as well, the previous discussion
> was more a question of this pre-compiled Lua files.
>
I also referred to the pre-compiled lua files (listed the other types of
configs for sake of completion). In this particular case Lua (and luac)
are anyhow distributed under MIT (iirc) and compiling a kamailio.lua
file is like:

luac kamailio.lua

There is no directly linking against any .c/.h/.o/.so file from
kamailio. Maybe it is a little stretched to say compiled in this case,
imo, I think it is more like parsing and create a binary-optimized file
that lua interpreter (or liblua functions) can load and execute faster,
it does not generate machine code, as I understand.

Further more, even if luac would be GPL, I don't think that compiling
file.lua would mean that file.lua nor the resulting file.bin will be
forced to be GPL, in that way everything compiled with GCC would be
forced to be GPL.

I found that Perl has some statement on their web page, but not sure how
much legal binding is behind it, it is stated as a personal opinion from
Larry:

  * https://dev.perl.org/licenses/

If I would try to make a rule regarding compiled/binary apps/components,
maybe I would say it like: if there is a single binary component that is
shipped and it was build from different source components of which at
least one is GPL, then sources of all these components must be
distributed under GPL due to its virality.

In Kamailio case, we have kamailio app binary and kamailio.cfg (or
kamailio.lua) shipped as separate files/components.

Obviously, ultimately a judge can have the final world, and can be from
case to case, country to county, judge to judge, ...

Cheers,
Daniel


> Cheers,
>
>  
>
> Henning
>
>  
>
>  
>
> *From:* Henning Westerholt
> *Sent:* Thursday, February 10, 2022 10:46 AM
> *To:* mico...@gmail.com; Kamailio (SER) - Users Mailing List
> 
> *Subject:* RE: [SR-Users] SEMS license with kamailio and rtpengine
>
>  
>
> Hello,
>
>  
>
> for me it’s seems to be not that clear, its open to interpretation.
> But this is more a theoretical discussion, it should be clarified from
> a lawyer.
>
> To quote from the GPL FAQ:
>
>  
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>
> “Another similar and very common case is to provide libraries with the
> interpreter which are themselves interpreted. For instance, Perl comes
> with many Perl modules[..]. These libraries and the programs that call
> them are always dynamically linked together.
>
> A consequence is that if you choose to use GPL'd Perl modules [..] in
> your program, you must release the program in a GPL-compatible way,
> regardless of the license used in the Perl [..] interpreter that the
> combined Perl [..] program will run on. “
>
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
>
> “Combining two modules means connecting them together so that they
> form a single larger program. If either part is covered by the GPL,
> the whole combination must also be released under the GPL—if you
> can't, or won't, do that, you may not combine them.
>
> [..] if the semantics of the communication are intimate enough,
> exchanging complex internal data structures, that too could be a basis
> to consider the two parts as combined into a larger program.”
>
> This seems to apply to the KEMI Lua. You execute the Kamailio (GPL)
> function in your KEMI script by some library mechanism.
>
> The Lua script and Kamailio are not using a standardized interface to
> interact together like e.g., SIP messages, it’s a custom specific one.
>
>  
>
> But if its specific enough to fall under this license restriction is
> the main point, we can probably not answer fully from our side.
>
>  
>
> Cheers,
>
>  
>
> Henning
>
>  
>
> *From:*Daniel-Constantin Mierla 
> *Sent:* Thursday, February 10, 2022 9:01 AM
> *To:* Kamailio (SER) - Users Mailing List
> ; Henning Westerholt 
> *Subject:* Re: [SR-Users] SEMS license with kamailio and rtpengine
>
>  
>
> Hello,
>
> On 10.02.22 08:36, Henning Westerholt wrote:
>
> Hello,
>
>  
>
> just to add to the discussion:
>
>  
>
> 1.   Please have a look to the GPLv2 FAQ, many topics you’ve
> raised are discussed there
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
>
> 2.   You should really consult a lawyer for this specific
> questions
>
>  
>
> Regarding the licence of the configuration (native script vs.
> KEMI) – my understanding would be that a native Kamailio cfg
> script would be independent of GPL as its interpreted (and
> practically the customer gets the “source code” 

[SR-Users] Publish XML and xpath

[Igor Olhovskiy]

Hello,

I'm trying to get state of endpoint from PUBLISH message in a most 
simple way using xmlops module


Trying to make this

$xml(body=>doc) = $rb;
log("L_ERR", "$rU is now in state 
$xml(body=>xpath:/dialog-info/dialog/state)\n");

XML in PUBLISH itself



  
    confirmed
  



Actual text in log is

... 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Alex Balashov]

Come to think of it, I imagine the license has language saying that it cannot 
be superseded in part or in whole by any contradictory agreement.

—
Sent from mobile, with due apologies for brevity and errors.

> On Feb 10, 2022, at 5:42 AM, Alex Balashov  wrote:
> 
> Is it legally possible for a customer to separately contract away a right 
> that the license otherwise affords them, such as the GPL right to demand 
> source code and then turn around and distribute that source code?
> 
> I have to wonder if it’s possible in the US. It seems like it shouldn’t be, 
> but in principle, in the prevailing theme of Anglo-American jurisprudence, 
> it’s possible to contract away pretty much anything, no matter how adverse to 
> one’s interests, so long as it is done “freely”.
> 
> —
> Sent from mobile, with due apologies for brevity and errors.
> 
>>> On Feb 10, 2022, at 2:37 AM, Henning Westerholt  wrote:
>>> 
>> 
>> Hello,
>>  
>> just to add to the discussion:
>>  
>> Please have a look to the GPLv2 FAQ, many topics you’ve raised are discussed 
>> there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
>> You should really consult a lawyer for this specific questions
>>  
>> Regarding the licence of the configuration (native script vs. KEMI) – my 
>> understanding would be that a native Kamailio cfg script would be 
>> independent of GPL as its interpreted (and practically the customer gets the 
>> “source code” anyway). But KEMI LUA code that is pre-compiled would fall 
>> under the GPL, so the customer has a right to get the source code for it. 
>> Compare e.g., to this: 
>> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>  
>> Cheers,
>>  
>> Henning
>>  
>> --
>> Henning Westerholt – https://skalatan.de/blog/
>> Kamailio services – https://gilawa.com
>>  
>> From: sr-users  On Behalf Of Olle E. 
>> Johansson
>> Sent: Thursday, February 10, 2022 8:13 AM
>> To: Kamailio (SER) - Users Mailing List 
>> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
>>  
>> Hi Seven!
>> Note that many of these questions open a legal discussion that has been 
>> going on for many years. I base my answers on what I know, which may not be 
>> the full truth. Regardless, I have been involved in these kind of 
>> discussions for almost 30 years of working in open source.
>>  
>> First, note that there are two kind of situations to observe. One is when 
>> your application is executing in a system. The other is the license of the 
>> written source code files. 
>>  
>> Secondly, license and copyright are two different things. You always have 
>> the copyright to your source code.
>>  
>> In Kamailio there are source code files that have a different license than 
>> the rest of the files. That means that if you copy that source code and 
>> create a new product that license applies.
>>  
>> Kamailio as a whole is released under GPL version 2. When you run Kamailio 
>> in your server, that license applies to it all, regardless of the license of 
>> various source code files.
>>  
>> Also note that I base this discussion on a delivery of a system to a 
>> customer. When you run Kamailio as a service you do not deliver (according 
>> to GPL v2) and the customer doesn’t have the same rights to the source.
>>  
>> Also note that (as other persons has pointed out) that it’s the recipient of 
>> the binaries that has the rights, not the world. If I am not your customer, 
>> I can’t demand the source code according to the GPL. The customer that 
>> receives the code has the right to do whatever they want with it - like 
>> publishing the source on GitHub for the world to enjoy.
>>  
>>  
>> 
>> 
>> 10 feb. 2022 kl. 00:16 skrev Seven Du :
>>  
>> I have some questions on this, e.g. on Kamailio:
>>  
>> 1. The core and some modules is GPL. I packaged that without change, and 
>> sell to a customer. and when the customer asks for source, I told him to 
>> download from the kamailio website, since I didn't change anything. Is that 
>> correct?
>> How you distribute the source code to the customer is irrelevant here. Note 
>> that if you end up having to provide it on a floppy disk or a USB stick, you 
>> can charge for that according to the GPL :-)
>> 
>>  
>> 2. I can also host the source on my own website, with some more helper 
>> scripts for building and packaging. That should be better?
>> I can’t judge if it’s better or worse, it has very little relevance to with 
>> the license. Just make sure that you include the signatures made by the 
>> Kamailio team so the customer can trace it back to the source and make sure 
>> there’s no changes.
>> 
>> 
>>  
>> 3. I write a new module, 100% code wrote from scratch, just follow the 
>> module guidelines or example code to expose/add hooks to core,  dynamically 
>> loaded into kamailio. Do I need to use GPL or can it be any license or even 
>> closed source? can I sell the standalone module in binary?
>> Your source code has to be 

Re: [SR-Users] Fwd: CDR preserve original call direction

[Ovidiu Sas]

Check the documentation and adjust your config accordingly:
http://www.kamailio.net/docs/modules/5.3.x/modules/acc.html#acc.p.detect_direction

modparam("acc", "detect_direction", 1)

In your config is set to 0.

Regards,
Ovidiu Sas

On Wed, Feb 9, 2022 at 08:01 Ahmed Fouad  wrote:

>
> Hi,
>
> I've enabled ACC and CDR logging and it's working fine for the logging but
> I noticed something wrong in the CDR table , the call source and
> destinations are depending on the BYE message not the initial invite dialog
>
> ACC table
>
> +-++--+-+---+---+--+--+--+
> | id  | method | callid   | time
>  | src_ip| src_domain| src_user | dst_ouser
>  | dst_domain   |
>
> +-++--+-+---+---+--+--+--+
> | 216 | BYE| 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:57:51 | x.x.x.x  | domain.com   |  DST_CLID |  SRC_CLID |
> domain.com  |
> | 215 | INVITE | 81fa79a0-3deb-47b6-80ab-831a78a5d46e | 2022-02-09
> 06:55:17 | x.x.x.x  | domain.com  | SRC_CLID   | DST_CLID |
> dst_domain.com|
>
> The INVITE is the correct one with SRCIP x.x.x.x and domain.com but the
> BYE reversed the order since the the DST_CLID who sent the BYE so it's now
> logged as the source
>
> and the final CDR log looks like
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> | cdr_id | src_username | src_domain| dst_username |
> dst_domain   | call_start_time | call_end_time
>
>
> ++--+---+--+--+-+-+--+-+---++---+-+
> |195 |  DST_CLID | domain.com   |  SRC_CLID | domain.com
>  | 2022-02-09 06:55:12 | 2022-02-09 06:57:51 |
>
> the CDR as shown is reversed regarding the source/dst username
>
> I tried to enable the direction ACC direction flag but didn't help and
> here is my current paramters
>
> modparam("acc", "early_media", 0)
> modparam("acc", "report_ack", 0)
> modparam("acc", "report_cancels", 0)
> modparam("acc", "detect_direction", 0)
> modparam("acc", "log_flag", FLT_ACC)
> modparam("acc", "log_missed_flag", FLT_ACCMISSED)
> modparam("acc", "cdr_enable", 1)
> modparam("acc", "cdrs_table", "cdrs")
>
> Can you please advise how to configure ACC/CDR to log the CDR with the
> correct initial INVITE call flow regardless of the BYE direction ?
>
> __
> Kamailio - Users Mailing List - Non Commercial Discussions
>   * sr-users@lists.kamailio.org
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
> Edit mailing list options or unsubscribe:
>   * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>
-- 
VoIP Embedded, Inc.
http://www.voipembedded.com
__
Kamailio - Users Mailing List - Non Commercial Discussions
  * sr-users@lists.kamailio.org
Important: keep the mailing list in the recipients, do not reply only to the 
sender!
Edit mailing list options or unsubscribe:
  * https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Alex Balashov]

Is it legally possible for a customer to separately contract away a right that 
the license otherwise affords them, such as the GPL right to demand source code 
and then turn around and distribute that source code?

I have to wonder if it’s possible in the US. It seems like it shouldn’t be, but 
in principle, in the prevailing theme of Anglo-American jurisprudence, it’s 
possible to contract away pretty much anything, no matter how adverse to one’s 
interests, so long as it is done “freely”.

—
Sent from mobile, with due apologies for brevity and errors.

> On Feb 10, 2022, at 2:37 AM, Henning Westerholt  wrote:
> 
> 
> Hello,
>  
> just to add to the discussion:
>  
> Please have a look to the GPLv2 FAQ, many topics you’ve raised are discussed 
> there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
> You should really consult a lawyer for this specific questions
>  
> Regarding the licence of the configuration (native script vs. KEMI) – my 
> understanding would be that a native Kamailio cfg script would be independent 
> of GPL as its interpreted (and practically the customer gets the “source 
> code” anyway). But KEMI LUA code that is pre-compiled would fall under the 
> GPL, so the customer has a right to get the source code for it. Compare e.g., 
> to this: 
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>  
> Cheers,
>  
> Henning
>  
> --
> Henning Westerholt – https://skalatan.de/blog/
> Kamailio services – https://gilawa.com
>  
> From: sr-users  On Behalf Of Olle E. 
> Johansson
> Sent: Thursday, February 10, 2022 8:13 AM
> To: Kamailio (SER) - Users Mailing List 
> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
>  
> Hi Seven!
> Note that many of these questions open a legal discussion that has been going 
> on for many years. I base my answers on what I know, which may not be the 
> full truth. Regardless, I have been involved in these kind of discussions for 
> almost 30 years of working in open source.
>  
> First, note that there are two kind of situations to observe. One is when 
> your application is executing in a system. The other is the license of the 
> written source code files. 
>  
> Secondly, license and copyright are two different things. You always have the 
> copyright to your source code.
>  
> In Kamailio there are source code files that have a different license than 
> the rest of the files. That means that if you copy that source code and 
> create a new product that license applies.
>  
> Kamailio as a whole is released under GPL version 2. When you run Kamailio in 
> your server, that license applies to it all, regardless of the license of 
> various source code files.
>  
> Also note that I base this discussion on a delivery of a system to a 
> customer. When you run Kamailio as a service you do not deliver (according to 
> GPL v2) and the customer doesn’t have the same rights to the source.
>  
> Also note that (as other persons has pointed out) that it’s the recipient of 
> the binaries that has the rights, not the world. If I am not your customer, I 
> can’t demand the source code according to the GPL. The customer that receives 
> the code has the right to do whatever they want with it - like publishing the 
> source on GitHub for the world to enjoy.
>  
>  
> 
> 
> 10 feb. 2022 kl. 00:16 skrev Seven Du :
>  
> I have some questions on this, e.g. on Kamailio:
>  
> 1. The core and some modules is GPL. I packaged that without change, and sell 
> to a customer. and when the customer asks for source, I told him to download 
> from the kamailio website, since I didn't change anything. Is that correct?
> How you distribute the source code to the customer is irrelevant here. Note 
> that if you end up having to provide it on a floppy disk or a USB stick, you 
> can charge for that according to the GPL :-)
> 
>  
> 2. I can also host the source on my own website, with some more helper 
> scripts for building and packaging. That should be better?
> I can’t judge if it’s better or worse, it has very little relevance to with 
> the license. Just make sure that you include the signatures made by the 
> Kamailio team so the customer can trace it back to the source and make sure 
> there’s no changes.
> 
> 
>  
> 3. I write a new module, 100% code wrote from scratch, just follow the module 
> guidelines or example code to expose/add hooks to core,  dynamically loaded 
> into kamailio. Do I need to use GPL or can it be any license or even closed 
> source? can I sell the standalone module in binary?
> Your source code has to be licensed in a license that can end up being 
> compatible with GPL. You can not have a commercial license on it, since when 
> executing it as part of Kamailio, GPL applies.
> Since your module ends up being GPL while running in a system you deliver for 
> a fee or for free to your customer, your customers has a right to the source 
> code.
>  
> 
> 
>  
> 4. my module still should be GPL since 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Henning Westerholt]

Hello,

Just to add - your general statement “From this perspective, none of the config 
files (no matter they are native scripting, lua, python, javascript, etc...) 
are forced to be GPL, it is the decision of the config author what's its 
license.”

This seems to be pretty clear to me as well, the previous discussion was more a 
question of this pre-compiled Lua files.
Cheers,

Henning


From: Henning Westerholt
Sent: Thursday, February 10, 2022 10:46 AM
To: mico...@gmail.com; Kamailio (SER) - Users Mailing List 

Subject: RE: [SR-Users] SEMS license with kamailio and rtpengine

Hello,

for me it’s seems to be not that clear, its open to interpretation. But this is 
more a theoretical discussion, it should be clarified from a lawyer.
To quote from the GPL FAQ:

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
“Another similar and very common case is to provide libraries with the 
interpreter which are themselves interpreted. For instance, Perl comes with 
many Perl modules[..]. These libraries and the programs that call them are 
always dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules [..] in your 
program, you must release the program in a GPL-compatible way, regardless of 
the license used in the Perl [..] interpreter that the combined Perl [..] 
program will run on. “
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
“Combining two modules means connecting them together so that they form a 
single larger program. If either part is covered by the GPL, the whole 
combination must also be released under the GPL—if you can't, or won't, do 
that, you may not combine them.
[..] if the semantics of the communication are intimate enough, exchanging 
complex internal data structures, that too could be a basis to consider the two 
parts as combined into a larger program.”
This seems to apply to the KEMI Lua. You execute the Kamailio (GPL) function in 
your KEMI script by some library mechanism.
The Lua script and Kamailio are not using a standardized interface to interact 
together like e.g., SIP messages, it’s a custom specific one.

But if its specific enough to fall under this license restriction is the main 
point, we can probably not answer fully from our side.

Cheers,

Henning

From: Daniel-Constantin Mierla mailto:mico...@gmail.com>>
Sent: Thursday, February 10, 2022 9:01 AM
To: Kamailio (SER) - Users Mailing List 
mailto:sr-users@lists.kamailio.org>>; Henning 
Westerholt mailto:h...@gilawa.com>>
Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine


Hello,
On 10.02.22 08:36, Henning Westerholt wrote:
Hello,

just to add to the discussion:


1.   Please have a look to the GPLv2 FAQ, many topics you’ve raised are 
discussed there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

2.   You should really consult a lawyer for this specific questions

Regarding the licence of the configuration (native script vs. KEMI) – my 
understanding would be that a native Kamailio cfg script would be independent 
of GPL as its interpreted (and practically the customer gets the “source code” 
anyway). But KEMI LUA code that is pre-compiled would fall under the GPL, so 
the customer has a right to get the source code for it. Compare e.g., to this: 
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL


I guess that the pre-compile is done by the luac, because Kamailio does not 
have such feature. Kamailio can only load a lua script (plain or pre-compiled) 
and push it as a parameter to liblua functions. In my opinion this is only 
file/data loading from kamailio point of view, definitely does not seem a 
linking/compile operation. It can be seen as something similar to reading SIP 
messages from the socket (everything is a file descriptor in unix/linux 
philosophy) and I assume nobody considers that received/sent SIP messages have 
to be GPL.

From this perspective, none of the config files (no matter they are native 
scripting, lua, python, javascript, etc...) are forced to be GPL, it is the 
decision of the config author what's its license.

Cheers,
Daniel


Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: sr-users 

 On Behalf Of Olle E. Johansson
Sent: Thursday, February 10, 2022 8:13 AM
To: Kamailio (SER) - Users Mailing List 

Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine

Hi Seven!
Note that many of these questions open a legal discussion that has been going 
on for many years. I base my answers on what I know, which may not be the full 
truth. Regardless, I have been involved in these kind of discussions for almost 
30 years of working in open source.

First, note that there are two kind of situations to observe. One is when your 
application is executing in a system. The other is the 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Henning Westerholt]

Hello,

for me it’s seems to be not that clear, its open to interpretation. But this is 
more a theoretical discussion, it should be clarified from a lawyer.
To quote from the GPL FAQ:

https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
“Another similar and very common case is to provide libraries with the 
interpreter which are themselves interpreted. For instance, Perl comes with 
many Perl modules[..]. These libraries and the programs that call them are 
always dynamically linked together.
A consequence is that if you choose to use GPL'd Perl modules [..] in your 
program, you must release the program in a GPL-compatible way, regardless of 
the license used in the Perl [..] interpreter that the combined Perl [..] 
program will run on. “
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#MereAggregation
“Combining two modules means connecting them together so that they form a 
single larger program. If either part is covered by the GPL, the whole 
combination must also be released under the GPL—if you can't, or won't, do 
that, you may not combine them.
[..] if the semantics of the communication are intimate enough, exchanging 
complex internal data structures, that too could be a basis to consider the two 
parts as combined into a larger program.”
This seems to apply to the KEMI Lua. You execute the Kamailio (GPL) function in 
your KEMI script by some library mechanism.
The Lua script and Kamailio are not using a standardized interface to interact 
together like e.g., SIP messages, it’s a custom specific one.

But if its specific enough to fall under this license restriction is the main 
point, we can probably not answer fully from our side.

Cheers,

Henning

From: Daniel-Constantin Mierla 
Sent: Thursday, February 10, 2022 9:01 AM
To: Kamailio (SER) - Users Mailing List ; Henning 
Westerholt 
Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine


Hello,
On 10.02.22 08:36, Henning Westerholt wrote:
Hello,

just to add to the discussion:


1.   Please have a look to the GPLv2 FAQ, many topics you’ve raised are 
discussed there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html

2.   You should really consult a lawyer for this specific questions

Regarding the licence of the configuration (native script vs. KEMI) – my 
understanding would be that a native Kamailio cfg script would be independent 
of GPL as its interpreted (and practically the customer gets the “source code” 
anyway). But KEMI LUA code that is pre-compiled would fall under the GPL, so 
the customer has a right to get the source code for it. Compare e.g., to this: 
https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL


I guess that the pre-compile is done by the luac, because Kamailio does not 
have such feature. Kamailio can only load a lua script (plain or pre-compiled) 
and push it as a parameter to liblua functions. In my opinion this is only 
file/data loading from kamailio point of view, definitely does not seem a 
linking/compile operation. It can be seen as something similar to reading SIP 
messages from the socket (everything is a file descriptor in unix/linux 
philosophy) and I assume nobody considers that received/sent SIP messages have 
to be GPL.

From this perspective, none of the config files (no matter they are native 
scripting, lua, python, javascript, etc...) are forced to be GPL, it is the 
decision of the config author what's its license.

Cheers,
Daniel


Cheers,

Henning

--
Henning Westerholt – https://skalatan.de/blog/
Kamailio services – https://gilawa.com

From: sr-users 

 On Behalf Of Olle E. Johansson
Sent: Thursday, February 10, 2022 8:13 AM
To: Kamailio (SER) - Users Mailing List 

Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine

Hi Seven!
Note that many of these questions open a legal discussion that has been going 
on for many years. I base my answers on what I know, which may not be the full 
truth. Regardless, I have been involved in these kind of discussions for almost 
30 years of working in open source.

First, note that there are two kind of situations to observe. One is when your 
application is executing in a system. The other is the license of the written 
source code files.

Secondly, license and copyright are two different things. You always have the 
copyright to your source code.

In Kamailio there are source code files that have a different license than the 
rest of the files. That means that if you copy that source code and create a 
new product that license applies.

Kamailio as a whole is released under GPL version 2. When you run Kamailio in 
your server, that license applies to it all, regardless of the license of 
various source code files.

Also note that I base this discussion on a delivery of a system to a customer. 
When you run Kamailio as a service you do not deliver (according 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Olle E. Johansson]

> On 10 Feb 2022, at 09:01, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> On 10.02.22 08:36, Henning Westerholt wrote:
>> Hello,
>>  
>> just to add to the discussion:
>>  
>> Please have a look to the GPLv2 FAQ, many topics you’ve raised are discussed 
>> there https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html 
>> 
>> You should really consult a lawyer for this specific questions
>>  
>> Regarding the licence of the configuration (native script vs. KEMI) – my 
>> understanding would be that a native Kamailio cfg script would be 
>> independent of GPL as its interpreted (and practically the customer gets the 
>> “source code” anyway). But KEMI LUA code that is pre-compiled would fall 
>> under the GPL, so the customer has a right to get the source code for it. 
>> Compare e.g., to 
>> this:https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>>  
>> 
>>  
> I guess that the pre-compile is done by the luac, because Kamailio does not 
> have such feature. Kamailio can only load a lua script (plain or 
> pre-compiled) and push it as a parameter to liblua functions. In my opinion 
> this is only file/data loading from kamailio point of view, definitely does 
> not seem a linking/compile operation. It can be seen as something similar to 
> reading SIP messages from the socket (everything is a file descriptor in 
> unix/linux philosophy) and I assume nobody considers that received/sent SIP 
> messages have to be GPL.
> 
> From this perspective, none of the config files (no matter they are native 
> scripting, lua, python, javascript, etc...) are forced to be GPL, it is the 
> decision of the config author what's its license.
> 
I suggest that we formally clarify this just to avoid any misunderstandings, 
much like we did in Asterisk.

/O
> Cheers,
> Daniel
> 
> 
> 
>> Cheers,
>>  
>> Henning
>>  
>> -- 
>> Henning Westerholt – https://skalatan.de/blog/ 
>> Kamailio services – https://gilawa.com 
>>  
>> From: sr-users  
>>  On Behalf Of Olle E. Johansson
>> Sent: Thursday, February 10, 2022 8:13 AM
>> To: Kamailio (SER) - Users Mailing List  
>> 
>> Subject: Re: [SR-Users] SEMS license with kamailio and rtpengine
>>  
>> Hi Seven!
>> Note that many of these questions open a legal discussion that has been 
>> going on for many years. I base my answers on what I know, which may not be 
>> the full truth. Regardless, I have been involved in these kind of 
>> discussions for almost 30 years of working in open source.
>>  
>> First, note that there are two kind of situations to observe. One is when 
>> your application is executing in a system. The other is the license of the 
>> written source code files. 
>>  
>> Secondly, license and copyright are two different things. You always have 
>> the copyright to your source code.
>>  
>> In Kamailio there are source code files that have a different license than 
>> the rest of the files. That means that if you copy that source code and 
>> create a new product that license applies.
>>  
>> Kamailio as a whole is released under GPL version 2. When you run Kamailio 
>> in your server, that license applies to it all, regardless of the license of 
>> various source code files.
>>  
>> Also note that I base this discussion on a delivery of a system to a 
>> customer. When you run Kamailio as a service you do not deliver (according 
>> to GPL v2) and the customer doesn’t have the same rights to the source.
>>  
>> Also note that (as other persons has pointed out) that it’s the recipient of 
>> the binaries that has the rights, not the world. If I am not your customer, 
>> I can’t demand the source code according to the GPL. The customer that 
>> receives the code has the right to do whatever they want with it - like 
>> publishing the source on GitHub for the world to enjoy.
>>  
>>  
>> 
>> 
>> 10 feb. 2022 kl. 00:16 skrev Seven Du > >:
>>  
>> I have some questions on this, e.g. on Kamailio:
>>  
>> 1. The core and some modules is GPL. I packaged that without change, and 
>> sell to a customer. and when the customer asks for source, I told him to 
>> download from the kamailio website, since I didn't change anything. Is that 
>> correct?
>> How you distribute the source code to the customer is irrelevant here. Note 
>> that if you end up having to provide it on a floppy disk or a USB stick, you 
>> can charge for that according to the GPL :-)
>> 
>>  
>> 2. I can also host the source on my own website, with some more helper 
>> scripts for building and packaging. That should be better?
>> I can’t judge if it’s better or worse, it has very little relevance to with 
>> the license. Just make sure that you include the signatures made by the 
>> 

Re: [SR-Users] SEMS license with kamailio and rtpengine

[Daniel-Constantin Mierla]

Hello,

On 10.02.22 08:36, Henning Westerholt wrote:
>
> Hello,
>
>  
>
> just to add to the discussion:
>
>  
>
>   * Please have a look to the GPLv2 FAQ, many topics you’ve raised are
> discussed there
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html
>   * You should really consult a lawyer for this specific questions
>
>  
>
> Regarding the licence of the configuration (native script vs. KEMI) –
> my understanding would be that a native Kamailio cfg script would be
> independent of GPL as its interpreted (and practically the customer
> gets the “source code” anyway). But KEMI LUA code that is pre-compiled
> would fall under the GPL, so the customer has a right to get the
> source code for it. Compare e.g., to this:
> https://www.gnu.org/licenses/old-licenses/gpl-2.0-faq.html#IfInterpreterIsGPL
>
>  
>
I guess that the pre-compile is done by the luac, because Kamailio does
not have such feature. Kamailio can only load a lua script (plain or
pre-compiled) and push it as a parameter to liblua functions. In my
opinion this is only file/data loading from kamailio point of view,
definitely does not seem a linking/compile operation. It can be seen as
something similar to reading SIP messages from the socket (everything is
a file descriptor in unix/linux philosophy) and I assume nobody
considers that received/sent SIP messages have to be GPL.

>From this perspective, none of the config files (no matter they are
native scripting, lua, python, javascript, etc...) are forced to be GPL,
it is the decision of the config author what's its license.

Cheers,
Daniel


> Cheers,
>
>  
>
> Henning
>
>  
>
> -- 
>
> Henning Westerholt – https://skalatan.de/blog/ 
>
> Kamailio services – https://gilawa.com 
>
>  
>
> *From:* sr-users  *On Behalf Of
> *Olle E. Johansson
> *Sent:* Thursday, February 10, 2022 8:13 AM
> *To:* Kamailio (SER) - Users Mailing List 
> *Subject:* Re: [SR-Users] SEMS license with kamailio and rtpengine
>
>  
>
> Hi Seven!
>
> Note that many of these questions open a legal discussion that has
> been going on for many years. I base my answers on what I know, which
> may not be the full truth. Regardless, I have been involved in these
> kind of discussions for almost 30 years of working in open source.
>
>  
>
> First, note that there are two kind of situations to observe. One is
> when your application is executing in a system. The other is the
> license of the written source code files. 
>
>  
>
> Secondly, license and copyright are two different things. You always
> have the copyright to your source code.
>
>  
>
> In Kamailio there are source code files that have a different license
> than the rest of the files. That means that if you copy that source
> code and create a new product that license applies.
>
>  
>
> Kamailio as a whole is released under GPL version 2. When you run
> Kamailio in your server, that license applies to it all, regardless of
> the license of various source code files.
>
>  
>
> Also note that I base this discussion on a delivery of a system to a
> customer. When you run Kamailio as a service you do not deliver
> (according to GPL v2) and the customer doesn’t have the same rights to
> the source.
>
>  
>
> Also note that (as other persons has pointed out) that it’s the
> recipient of the binaries that has the rights, not the world. If I am
> not your customer, I can’t demand the source code according to the
> GPL. The customer that receives the code has the right to do whatever
> they want with it - like publishing the source on GitHub for the world
> to enjoy.
>
>  
>
>  
>
>
>
> 10 feb. 2022 kl. 00:16 skrev Seven Du :
>
>  
>
> I have some questions on this, e.g. on Kamailio:
>
>  
>
> 1. The core and some modules is GPL. I packaged that without
> change, and sell to a customer. and when the customer asks for
> source, I told him to download from the kamailio website, since I
> didn't change anything. Is that correct?
>
> How you distribute the source code to the customer is irrelevant here.
> Note that if you end up having to provide it on a floppy disk or a USB
> stick, you can charge for that according to the GPL :-)
>
>  
>
> 2. I can also host the source on my own website, with some more
> helper scripts for building and packaging. That should be better?
>
> I can’t judge if it’s better or worse, it has very little relevance to
> with the license. Just make sure that you include the signatures made
> by the Kamailio team so the customer can trace it back to the source
> and make sure there’s no changes.
>
>
>
>  
>
> 3. I write a new module, 100% code wrote from scratch, just follow
> the module guidelines or example code to expose/add hooks to
> core,  dynamically loaded into kamailio. Do I need to use GPL or
> can it be any license or even closed source? can I sell the
> standalone module in binary?
>
> Your source code has to be