[SR-Users] sip digest authentication
Hello dears
I’m trying to setup Kamailio with sip digest authentication scheme by using
the following configuration from s-cscf side :
modparam("ims_auth", "registration_default_algorithm", "HSS-Selected")
and the result was as following :
1. when the register message passed form the s-cscf to the hss and in the
diameter trace I found the
“SIP-AUTHENTICATION-SCHEME” in the MAR request as “Digest-MD5”
1. After that the HSS send MAA message with
“DIAMETER-ERROR-AUTH-SCHEME-NOT-SUPPORTED”
2. S-cscf replay with the message “Forbidden – privet identity not found
(Authorization : username)”
So based on that could any one tell where was my mistake or how can I setup
Kamailio with SIP-DIGEST scheme
Thanks
___
Kamailio (SER) - Users Mailing List
sr-users@lists.kamailio.org
https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] Randomizing t_load_contacts() with same q value?
I'm looking for a way to randomize the contacts for serial forking if they have the same q value (so instead of doing parallel forking to those targets). Without taking the q value into account I could do something with the defined contacts_avp before calling t_next_contacts(). But I have no idea how to randomize and serialize the branches with the same q value after calling t_next_contacts(). Any ideas? ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Monitoring Dispatcher
Hello, On 07.06.18 10:04, Daniel-Constantin Mierla wrote: > Hello, > > [...] > > For the future, I can add an rpc command to dump those numbers directly > from dispatcher module when using with algorithm 10. just implemented the feature in master branch -- the active dialogs load should be printed in the rpc output for each destination (RUNTIME => DLGLOAD field). Can you test and report back if it gives what you expect? If you want to test with older versions and backport the patch locally, the commit adding it is: - https://github.com/kamailio/kamailio/commit/513a176394247a3378ee218bf9df611da7296061 Cheers, Daniel > > Cheers, > Daniel > > On 07.06.18 09:04, Tim Bowyer wrote: >> Thanks for the prompt reply Alex! >> >> Trying to get my head around the best way to use the module. >> By the looks I need to statically create profiles which will be used as >> counting groups. >> Since each destination is dynamically created thus named with a fairly >> random ID, I can't see how this could work. >> >> Have tried using variables but I get a heap of errors. The process will >> only start if I use static profile names. >> >> Is there another sneaky way to get around this? When a new container is >> spun up, a new entry is added to the dispatcher table and the dispatcher >> reloaded. >> Likewise to trigger a container to start draining calls we remove from >> dispatcher then reload before waiting for all calls to finish and stop the >> container. >> >> Cheers, >> >> Tim Bowyer >> >> >> -Original Message- >> From: sr-users On Behalf Of Alex >> Balashov >> Sent: Thursday, 7 June 2018 10:42 AM >> To: Kamailio (SER) - Users Mailing List >> Subject: Re: [SR-Users] Monitoring Dispatcher >> >> It sounds like the dialog module might be your best bet. >> >> On June 6, 2018 10:40:38 PM EDT, Tim Bowyer wrote: >>> Hi All, >>> >>> Currently trying to work out the best way to keep track of how many >>> calls are being sent to any given dispatcher destination. >>> I remember being able to do this years ago with the load balancer >>> module in OpenSIPS: opensipsctl fifo lb_list. >>> >>> Dispatching algorithm '10' seems to be the best fit for my >>> requirements, as I'm essentially wanting to send calls to a large >>> quantity of FreeSwitch docker containers acting as fax receiving nodes. >>> Equal weight, just filling them in some balanced fashion. >>> >>> Any hints or ideas would be much appreciated! >>> >>> Kind regards, >>> >>> Tim Bowyer >> -- Alex >> >> -- >> Sent via mobile, please forgive typos and brevity. >> >> ___ >> 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 -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- 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] removing not update packaging scripts
Hello, I merged it, thanks! I guess now all obsoleted rpm specs are removed. Only oracle linux is separate, not being on OBS. Cheers, Daniel On 07.06.18 12:00, Sergey Safarov wrote: > Hello > I created PR to remove not updated CentOS packaging files > (https://github.com/kamailio/kamailio/pull/1555/files) > Now CentOS packaging is located > at https://github.com/kamailio/kamailio/tree/master/pkg/kamailio/obs > Is there anyone considers it necessary to leave a legacy packaging > scripts for CentOS > > Sergey > > > > > > ___ > 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 (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
[SR-Users] removing not update packaging scripts
Hello I created PR to remove not updated CentOS packaging files ( https://github.com/kamailio/kamailio/pull/1555/files) Now CentOS packaging is located at https://github.com/kamailio/kamailio/tree/master/pkg/kamailio/obs Is there anyone considers it necessary to leave a legacy packaging scripts for CentOS Sergey ___ Kamailio (SER) - Users Mailing List sr-users@lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users
Re: [SR-Users] Monitoring Dispatcher
Hello, do you need to have the counter per exact address in the dispatcher? Or you want to have it per IP (address) of FreeSwitch? If you just need the number of the calls, I would go with htable module, having two options here: a) store in table items (callid, srcipaddr, like $sht(acalls=>$ci) = $si;) when getting 200OK for INVITE, delete the item by callid when BYE is received ($sht(acalls=>$ci) = $null). This would require dumping the entire hash table via rpc and count by value. You can set some auto expires value to the max call lifetime you allow on your service b) store the counter per ip addrress, so on 200OK you do $shtinc(acalls=>$si). Based on direction (see rr module for how to detect the direction), you have to decremented it on BYE based either on source IP or next hop IP. On this option, you have to be careful with cross BYEs (caller and callee hanging up at the same time, resulting in two BYEs crossing kamailio for same call) -- you can use another hash table to store that counter was decremented based on call-id, with the item stored for short time, like auto expires 2 minutes. The internal htable module can be replaced with a redis storage by using ndb_redis. For the future, I can add an rpc command to dump those numbers directly from dispatcher module when using with algorithm 10. Cheers, Daniel On 07.06.18 09:04, Tim Bowyer wrote: > Thanks for the prompt reply Alex! > > Trying to get my head around the best way to use the module. > By the looks I need to statically create profiles which will be used as > counting groups. > Since each destination is dynamically created thus named with a fairly random > ID, I can't see how this could work. > > Have tried using variables but I get a heap of errors. The process will only > start if I use static profile names. > > Is there another sneaky way to get around this? When a new container is spun > up, a new entry is added to the dispatcher table and the dispatcher reloaded. > Likewise to trigger a container to start draining calls we remove from > dispatcher then reload before waiting for all calls to finish and stop the > container. > > Cheers, > > Tim Bowyer > > > -Original Message- > From: sr-users On Behalf Of Alex > Balashov > Sent: Thursday, 7 June 2018 10:42 AM > To: Kamailio (SER) - Users Mailing List > Subject: Re: [SR-Users] Monitoring Dispatcher > > It sounds like the dialog module might be your best bet. > > On June 6, 2018 10:40:38 PM EDT, Tim Bowyer wrote: >> Hi All, >> >> Currently trying to work out the best way to keep track of how many >> calls are being sent to any given dispatcher destination. >> I remember being able to do this years ago with the load balancer >> module in OpenSIPS: opensipsctl fifo lb_list. >> >> Dispatching algorithm '10' seems to be the best fit for my >> requirements, as I'm essentially wanting to send calls to a large >> quantity of FreeSwitch docker containers acting as fax receiving nodes. >> Equal weight, just filling them in some balanced fashion. >> >> Any hints or ideas would be much appreciated! >> >> Kind regards, >> >> Tim Bowyer > > -- Alex > > -- > Sent via mobile, please forgive typos and brevity. > > ___ > 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 -- Daniel-Constantin Mierla -- www.asipto.com www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio World Conference -- 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] Monitoring Dispatcher
Thanks for the prompt reply Alex! Trying to get my head around the best way to use the module. By the looks I need to statically create profiles which will be used as counting groups. Since each destination is dynamically created thus named with a fairly random ID, I can't see how this could work. Have tried using variables but I get a heap of errors. The process will only start if I use static profile names. Is there another sneaky way to get around this? When a new container is spun up, a new entry is added to the dispatcher table and the dispatcher reloaded. Likewise to trigger a container to start draining calls we remove from dispatcher then reload before waiting for all calls to finish and stop the container. Cheers, Tim Bowyer -Original Message- From: sr-users On Behalf Of Alex Balashov Sent: Thursday, 7 June 2018 10:42 AM To: Kamailio (SER) - Users Mailing List Subject: Re: [SR-Users] Monitoring Dispatcher It sounds like the dialog module might be your best bet. On June 6, 2018 10:40:38 PM EDT, Tim Bowyer wrote: >Hi All, > >Currently trying to work out the best way to keep track of how many >calls are being sent to any given dispatcher destination. >I remember being able to do this years ago with the load balancer >module in OpenSIPS: opensipsctl fifo lb_list. > >Dispatching algorithm '10' seems to be the best fit for my >requirements, as I'm essentially wanting to send calls to a large >quantity of FreeSwitch docker containers acting as fax receiving nodes. >Equal weight, just filling them in some balanced fashion. > >Any hints or ideas would be much appreciated! > >Kind regards, > >Tim Bowyer -- Alex -- Sent via mobile, please forgive typos and brevity. ___ 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
