Re: [SR-Users] Gracefully dropping all branches

2019-02-20 Thread Andreas Granig 
Hi,

Setting a message-wide flag when dropping at least one branch, and the approach 
of checking if t_relay(0x02) failed, then sending a t_reply() if that flag is 
set (otherwise a sl_reply_error()), is the most simple and elegant way, as I 
don’t have to track anything in a table. Works like charm, thanks a lot!

Best,
Andreas

> On 20.02.2019, at 12:30, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> On 20.02.19 11:58, Andreas Granig wrote:
>> Hi all,
>> 
>> I’ve a scenario where after lookup() I get multiple branches, and I want to 
>> drop some or all of them based on some filter criteria in a branch route 
>> before sending requests out. Problem is that if all branches are dropped, 
>> kamailio replies with some implicitly generated 500 server error since there 
>> are no more branches, but I want to send a 404 or 480 instead.
>> 
>> Is there a way to determine if I’m processing the last active branch (so all 
>> others have been dropped already), so I can send a graceful reply like 404 
>> or 480 instead of dropping this last branch as well if I decide I have to 
>> filter that one too?
>> 
>> I’m thinking of a hash table table or something to track and decrease the 
>> number of branches for a call, and based on a flag (whether one of the 
>> previous branches has been sent out or all have been dropped so far) either 
>> drop the last branch or reply with an error. However I’m wondering if 
>> kamailio comes with a mechanism to determine the branch state out of the box?
>> 
> At this moment I do not recall any variable or function to indicate you
> process last branch, nor to say if any other branches is active. It
> should not be hard to add something like that, though -- eventually part
> of $T() or $T_branch().
> 
> Probably you can do it now with some operations in config:
> 
>  - after lookup location you have $branch(count) saying the number of
> additional branches (besides the R-URI destination)
> 
>  - in branch_route, you have $T(branch_index) giving the index of the
> current branch
> 
> If you don't drop a branch, you can mark it via a transaction flag or
> using htable. When you get to the last branch, test if you have one
> active and if not, send your reply.
> 
> On the other hand, iirc, either t_relay() is not replying internally
> (not sure by heart right now) or there should be a way to disable
> sending internal errors from tm. Anyhow, t_relay() should return false
> when no branch is forwarded, then you can send your own reply instead of
> using sl_reply_error().
> 
> Cheers,
> Daniel
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference - May 6-8, 2019 -- www.kamailioworld.com
> Kamailio Advanced Training - Mar 4-6, 2019 in Berlin; Mar 25-27, 2019, in 
> Washington, DC, USA -- www.asipto.com
> 


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

[SR-Users] Gracefully dropping all branches

2019-02-20 Thread Andreas Granig 
Hi all,

I’ve a scenario where after lookup() I get multiple branches, and I want to 
drop some or all of them based on some filter criteria in a branch route before 
sending requests out. Problem is that if all branches are dropped, kamailio 
replies with some implicitly generated 500 server error since there are no more 
branches, but I want to send a 404 or 480 instead.

Is there a way to determine if I’m processing the last active branch (so all 
others have been dropped already), so I can send a graceful reply like 404 or 
480 instead of dropping this last branch as well if I decide I have to filter 
that one too?

I’m thinking of a hash table table or something to track and decrease the 
number of branches for a call, and based on a flag (whether one of the previous 
branches has been sent out or all have been dropped so far) either drop the 
last branch or reply with an error. However I’m wondering if kamailio comes 
with a mechanism to determine the branch state out of the box?

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

Re: [SR-Users] presence/mwi issue

2018-11-28 Thread Andreas Granig 
Hi Daniel,

This commit indeed fixed the issue, thanks for pointing it out! From my point 
of view, it’s fine backporting it to 5.1 to fix it there as well.

Best,
Andreas

> On 28.11.2018, at 13:45, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> ohh, I was looking at master and the commit I did seemed to be for the
> place without a guard on dialog event type.
> 
> The master branch has the one you point to already guarded, done with:
> 
>   -
> https://github.com/kamailio/kamailio/commit/6d0f8994611b50faa7ef7d1299acf0c390a2eed1
>   - https://github.com/kamailio/kamailio/pull/1453
> 
> So apparently it was overlooked when backporting to release versions of
> 5.1.x.
> 
> Can you cherry pick that commit and test? If all ok, you can push the
> backport to 5.1 branch. The master and 5.2 should be fine.
> 
> Cheers,
> Daniel
> 
> On 28.11.18 13:36, Andreas Granig wrote:
>> Hi Daniel,
>> 
>> Unfortunately that doesn’t help. Digging a bit further, it seems that the 
>> error comes from calling check_if_dialog() around line 715 in 
>> update_presentity(), so actually before entering the 
>> delete_presentity_if_dialog_id_exists() function.
>> 
>> Andreas
>> 
>>> On 28.11.2018, at 12:51, Daniel-Constantin Mierla  wrote:
>>> 
>>> Hello,
>>> 
>>> can you try with the patch from next commit:
>>> 
>>>  -
>>> https://github.com/kamailio/kamailio/commit/55c7f781be7cc40d0cd161640a47244aad60c0e7
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 28.11.18 12:34, Andreas Granig wrote:
>>>> Hi Daniel,
>>>> 
>>>> I started fresh (never tried this module before), but after googling for 
>>>> the error, I came across Juha’s post, which sounds quite familiar.
>>>> 
>>>> So I’m having a phone subscribing to message-summary of us...@example.org, 
>>>> and I have a script sending a PUBLISH in behalf of us...@example.org. This 
>>>> PUBLISH goes right into handle_publish in my config (with presence_mwi 
>>>> loaded), so nothing really special here, I believe.
>>>> 
>>>> Andreas
>>>> 
>>>>> On 28.11.2018, at 12:23, Daniel-Constantin Mierla  
>>>>> wrote:
>>>>> 
>>>>> Hello,
>>>>> 
>>>>> some clarifications in order to see where to look: you just started to
>>>>> play fresh with it and get this error? Or an old configuration that used
>>>>> to work in the past is now throwing the error?
>>>>> 
>>>>> Cheers,
>>>>> Daniel
>>>>> 
>>>>> On 28.11.18 12:13, Andreas Granig wrote:
>>>>>> Hi,
>>>>>> 
>>>>>> Currently playing with presence_mwi in kamailio 5.1, and it appears the 
>>>>>> issue reported by Juha two years ago at 
>>>>>> https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html 
>>>>>> seems to have appeared again somewhere along the way.
>>>>>> 
>>>>>> I’m sending a PUBLISH with message-summary event type, however I’m 
>>>>>> getting this error:
>>>>>> 
>>>>>> ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse 
>>>>>> xml document
>>>>>> 
>>>>>> As said in the old thread, it’s not an XML document, so it shouldn’t try 
>>>>>> to treat it as such. Any ideas?
>>>>>> 
>>>>>> Best,
>>>>>> Andreas
>>>>>> ___
>>>>>> Kamailio (SER) - Users Mailing List
>>>>>> sr-users@lists.kamailio.org
>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>>>> -- 
>>>>> Daniel-Constantin Mierla -- www.asipto.com
>>>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>>>> Kamailio World Conference -- www.kamailioworld.com
>>>>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>>>>> 
>>> -- 
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio World Conference -- www.kamailioworld.com
>>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>>> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com


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

Re: [SR-Users] presence/mwi issue

2018-11-28 Thread Andreas Granig 
Hi Daniel,

Unfortunately that doesn’t help. Digging a bit further, it seems that the error 
comes from calling check_if_dialog() around line 715 in update_presentity(), so 
actually before entering the delete_presentity_if_dialog_id_exists() function.

Andreas

> On 28.11.2018, at 12:51, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> can you try with the patch from next commit:
> 
>   -
> https://github.com/kamailio/kamailio/commit/55c7f781be7cc40d0cd161640a47244aad60c0e7
> 
> Cheers,
> Daniel
> 
> On 28.11.18 12:34, Andreas Granig wrote:
>> Hi Daniel,
>> 
>> I started fresh (never tried this module before), but after googling for the 
>> error, I came across Juha’s post, which sounds quite familiar.
>> 
>> So I’m having a phone subscribing to message-summary of us...@example.org, 
>> and I have a script sending a PUBLISH in behalf of us...@example.org. This 
>> PUBLISH goes right into handle_publish in my config (with presence_mwi 
>> loaded), so nothing really special here, I believe.
>> 
>> Andreas
>> 
>>> On 28.11.2018, at 12:23, Daniel-Constantin Mierla  wrote:
>>> 
>>> Hello,
>>> 
>>> some clarifications in order to see where to look: you just started to
>>> play fresh with it and get this error? Or an old configuration that used
>>> to work in the past is now throwing the error?
>>> 
>>> Cheers,
>>> Daniel
>>> 
>>> On 28.11.18 12:13, Andreas Granig wrote:
>>>> Hi,
>>>> 
>>>> Currently playing with presence_mwi in kamailio 5.1, and it appears the 
>>>> issue reported by Juha two years ago at 
>>>> https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html 
>>>> seems to have appeared again somewhere along the way.
>>>> 
>>>> I’m sending a PUBLISH with message-summary event type, however I’m getting 
>>>> this error:
>>>> 
>>>> ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse xml 
>>>> document
>>>> 
>>>> As said in the old thread, it’s not an XML document, so it shouldn’t try 
>>>> to treat it as such. Any ideas?
>>>> 
>>>> Best,
>>>> Andreas
>>>> ___
>>>> Kamailio (SER) - Users Mailing List
>>>> sr-users@lists.kamailio.org
>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
>>> -- 
>>> Daniel-Constantin Mierla -- www.asipto.com
>>> www.twitter.com/miconda -- www.linkedin.com/in/miconda
>>> Kamailio World Conference -- www.kamailioworld.com
>>> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
>>> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
> 


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

Re: [SR-Users] presence/mwi issue

2018-11-28 Thread Andreas Granig 
Hi Daniel,

I started fresh (never tried this module before), but after googling for the 
error, I came across Juha’s post, which sounds quite familiar.

So I’m having a phone subscribing to message-summary of us...@example.org, and 
I have a script sending a PUBLISH in behalf of us...@example.org. This PUBLISH 
goes right into handle_publish in my config (with presence_mwi loaded), so 
nothing really special here, I believe.

Andreas

> On 28.11.2018, at 12:23, Daniel-Constantin Mierla  wrote:
> 
> Hello,
> 
> some clarifications in order to see where to look: you just started to
> play fresh with it and get this error? Or an old configuration that used
> to work in the past is now throwing the error?
> 
> Cheers,
> Daniel
> 
> On 28.11.18 12:13, Andreas Granig wrote:
>> Hi,
>> 
>> Currently playing with presence_mwi in kamailio 5.1, and it appears the 
>> issue reported by Juha two years ago at 
>> https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html 
>> seems to have appeared again somewhere along the way.
>> 
>> I’m sending a PUBLISH with message-summary event type, however I’m getting 
>> this error:
>> 
>> ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse xml 
>> document
>> 
>> As said in the old thread, it’s not an XML document, so it shouldn’t try to 
>> treat it as such. Any ideas?
>> 
>> Best,
>> Andreas
>> ___
>> Kamailio (SER) - Users Mailing List
>> sr-users@lists.kamailio.org
>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
> 
> -- 
> Daniel-Constantin Mierla -- www.asipto.com
> www.twitter.com/miconda -- www.linkedin.com/in/miconda
> Kamailio World Conference -- www.kamailioworld.com
> Kamailio Advanced Training, Nov 12-14, 2018, in Berlin -- www.asipto.com
> 


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

[SR-Users] presence/mwi issue

2018-11-28 Thread Andreas Granig 
Hi,

Currently playing with presence_mwi in kamailio 5.1, and it appears the issue 
reported by Juha two years ago at 
https://lists.kamailio.org//pipermail/sr-dev/2016-September/036609.html seems 
to have appeared again somewhere along the way.

I’m sending a PUBLISH with message-summary event type, however I’m getting this 
error:

ERROR: presence [presentity.c:283]: check_if_dialog(): failed to parse xml 
document

As said in the old thread, it’s not an XML document, so it shouldn’t try to 
treat it as such. Any ideas?

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

[SR-Users] Alcatel-Lucent Enterprise acquires majority stake in Sipwise

2018-05-18 Thread Andreas Granig 
Dear community,

I'd like to inform you about Alcatel-Lucent Enterprise (ALE) acquiring a 
majority stake in Sipwise. Over the last 10 years, we at Sipwise were committed 
to contributing significant efforts to the open source telecom environment, 
resulting amongst others in the free and open source Sipwise CE soft-switch 
appliance, the rtpengine media relay, as well as major contributions to the 
Kamailio SIP proxy. Under the ALE roof, Sipwise is continuing to operate as its 
own brand, and our commitment to open source and our community components will 
be as strong as ever.

Please find the official announcement here: https://www.sipwise.com/ale-sipwise/

Best regards,
Andreas


signature.asc
Description: Message signed with OpenPGP
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

Re: [SR-Users] rtpengine transcoding benchmarks?

2018-02-27 Thread Andreas Granig 
Hi,

We've seen around 400 concurrent calls for G711<->Opus on a rather slow
12-core E5-2420@1.90GHz for some first preliminary benchmarks.

Andreas

On 2018-02-26 21:27, Brooks Bridges wrote:
> I realize the transcoding support is rather new, however has anyone run
> any real world tests on it yet?  Trying to get a sense of what the
> performance will be.
> 
>  
> 
> I’m aware that it’s forced into userspace for transcoding so it’s not
> **nearly** as efficient as the iptables module, however even if I have
> to throw a rack full of whiteboxes at it to get anywhere close to decent
> numbers that’s still going to be comparable to a lot of the commercial
> options out there right now.
> 
>  
> 
> *Brooks Bridges | *Engineering Manager
> 
> *O^1 Communications*
> 
> 4359 Town Center Boulevard, Suite 217
> 
> El Dorado Hills, California 95762
> 
> *office:*916.235.2097 |*main:*888.444., Option 2
> 
> *email:*bbrid...@o1.com  | *web:*www.o1.com
> 
> 
>  
> 
> 
> 
> ___
> 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] Using the db_redis module for integration with usrloc

2018-02-27 Thread Andreas Granig 
Hi Lucian,

Yes, it's probably worth noting in the README that for use_domain=0 the
usrdom key should be adjusted. So does it work for you now?

Eventually, I'll extend the module to ship with default key definitions
for the most common modules, however it'll take some time because it
needs an analysis of the query patterns each module performs.

Best,
Andreas

On 2018-02-23 11:05, Lucian Balaceanu wrote:
> Hello,
> 
> Just a quick note to say that I debugged the issue down to having the
> MULTIDOMAIN set to 0 and as such most probably the
> ":username,domain" should have been in my case just
> ":username".
> Also if parsing of a field in redis comes out as having errors, just
> tweak the type of value according to that field in the schema_path. I
> had problems with usrloc's  expires and last_modified which I changed
> from "int" to "string".
> 
> Thank you,
> Lucian
> 
> On 22.02.2018 12:00, Lucian Balaceanu wrote:
>> Hello Andreas,
>>
>>
>> Congratulations for adding db_redis, which I find a very interesting
>> and useful module.
>>
>> I know it is not yet in its final form, but I have tried to make a
>> REGISTER/INVITE save()/lookup() scenario by adding the db_redis
>> snippets from the README in the default Kamailio configuration (usrloc
>> db_mode=3).
>> The save() succeeds, but only a "location:entry::uloc-5a8d7eb2-6bd1-1"
>> hash and a "location:timer::0:0" set are created (I seem to miss the
>> location:usrdom). Besides this, the lookup("location") fails.
>> I guess I have made some wrong configurations? The REGISTER/INVITE
>> scenario works fine for you with only the upmentioned changes to the
>> config?
>>
>>
>> My *config* contains:
>>
>> loadmodule "db_redis.so"
>> #!define DBURL_USRLOC "redis://127.0.0.1:6379/5"
>> #!define DBURL_ACC    "redis://127.0.0.1:6379/6"
>> #!define DBURL_AUTH   "redis://127.0.0.1:6379/7"
>>
>> modparam("db_redis", "schema_path",
>> "/home/XXX/utils/kamctl/db_redis/kamailio")
>> modparam("db_redis", "keys",
>> "location=entry:ruid:username,domain:partition,keepalive")
>> modparam("db_redis", "keys", "acc=entry:callid,time_hires:callid")
>> modparam("db_redis", "keys", "subscriber=entry:username,domain")
>>
>> modparam("usrloc", "db_mode", 3)
>> modparam("usrloc", "use_domain", MULTIDOMAIN)
>> modparam("usrloc", "db_url", DBURL_USRLOC)
>>
>> The lookup("location") leads to this *log*:
>>
>> /1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:1683]: db_redis_query(): querying prefix (table)
>> 'location'//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:508]: db_redis_build_query_keys(): build query keys//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:281]: db_redis_find_query_key(): checking for existence
>> of entry key 'ruid' in query//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:332]: db_redis_find_query_key(): key 'ruid' for type
>> 'entry' not found, unable to use this type//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:534]: db_redis_build_query_keys(): no direct entry key
>> found, checking type keys//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:537]: db_redis_build_query_keys(): checking type 'usrdom'//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:281]: db_redis_find_query_key(): checking for existence
>> of entry key 'username' in query//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:291]: db_redis_find_query_key(): found key in entry key//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:119]: db_redis_val2str(): converting str value '33'
>> with len 2 to str//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:323]: db_redis_find_query_key(): entry key so far is
>> 'location:usrdom::33'//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:281]: db_redis_find_query_key(): checking for existence
>> of entry key 'domain' in query//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:332]: db_redis_find_query_key(): key 'domain' for type
>> 'usrdom' not found, unable to use this type//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:537]: db_redis_build_query_keys(): checking type 'timer'//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:281]: db_redis_find_query_key(): checking for existence
>> of entry key 'partition' in query//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:332]: db_redis_find_query_key(): key 'partition' for
>> type 'timer' not found, unable to use this type//
>> //{1 1 INVITE 1-23806@127.0.1.1}  0(23787) DEBUG: db_redis
>> [redis_dbase.c:1726]: db_redis_query(): unable to build query keys,
>> falling back to full table scan//
>> //{1 1 INVITE 1-23806@127.0.1.1}