sr-users May 2020

sr-users@lists.kamailio.org

66 participants
83 discussions

by Duarte Rocha

Greetings, I have an issue where a client doesn't get the responses to the INVITE sent and as such keeps sending me retransmissions of the INVITE. While the transaction is still up, Kamailio does its job. However, when the transaction is closed Kamailio processes the request again as a first request (Doing Routing and Dispatcher operations again). In order to avoid the issue i've made the following code : // If it's the first INVITE if( is_method("INVITE") && !has_totag() ) { if(t_check_trans()) { xnotice("TRANS - INVITE Retransmission"); } else if ( is_known_dlg()) { xerr("KamTAG: INVITE in dialog without To Tag "); exit; } } Is this a good solution and still compliant with the SIP rules? Best Regards

4 years, 6 months

Problem with Teams and Kamailio and calls hangup after 6 seconds

by sip user

Hi, I'm trying to connect Teams with Kamailio. I'd configured and it works, but a few days ago, calls Teams to kamailio no works. I call from Teams and in Kamailio I see the call, ring the extensions in Kamailio, but after 6 seconds, the call hangup. I received the INVITE, I send Trying and 200 Ok, but never received ACK from Teams. Anyone knows how can I check it? I have configurated SBC in teams like https://skalatan.de/en/blog/kamailio-sbc-teams Thanks

4 years, 6 months

Issue of calls drop 32s

by Rex Lin (林昱頡)

Hi, It’s weird that the calls always drop after 32s while the callee is using public ip. Also, Server forwards ACK to itself with UDP, instead of forwarding to callee with TLS. Moreover, I cannot see “Received” in AOR as the callee finish the registration. I recognized it’s marked by nat_uac_test(“19”) and set with fix_nated_register(), the problem can be resolved. My scenario is as below, for your reference. 1.Kamailio version is 4.4.7, listening public ip. 2.Caller it’s behind NAT. 3.Clients of Linphone. Do you know the reason why it happened? Best Regards, Rex

4 years, 6 months

Kamailio 5.2.7 Released

by Henning Westerholt

Hello, Kamailio SIP Server v5.2.7 stable release is out. This is a maintenance release of the previous stable branch (5.2), that includes fixes since the release of v5.2.6. There is no change to database schema or configuration language structure that you have to do on previous installations of v5.2.x. Deployments running previous v5.2.x versions are strongly recommended to be upgraded to v5.2.7. For more details about version 5.2.7 (including links and guidelines to download the tar file or from GIT repository), visit: https://www.kamailio.org/w/2020/05/kamailio-5-2-7-released/ RPM, Debian/Ubuntu packages will be available soon as well. Many thanks to all contributing and using Kamailio! Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

4 years, 6 months

Re: [SR-Users] [sr-dev] Unable to make SIP Calls (403 Forbidden - Domain Not Served)

by Pavithra M

Hi, I have my kamailio ims with NAT and rtpproxy enabled. When i make a call from outside , rtp packets is not going. Could you please tell me how to configure NAT to get rtp packets in pcscf . On Fri, Apr 17, 2020 at 4:30 PM David Villasmil < david.villasmil.work(a)gmail.com> wrote: > It doesn’t make a lot of sense to see looping calls “connected”. If they > connect, then they’re not looping, unless there is some counter somewhere > that answers the call when it sees a loop. > > That’s very weird. > > Use sngrep and trace on ALL interfaces. > > On Fri, 17 Apr 2020 at 11:46, Pavithra M <pavimohan3096(a)gmail.com> wrote: > >> Hi, >> In Wireshark , I couldn't able to see the looping packets .In debug logs >> of pcscf , I am able to see the looping occurs . But how then the call gets >> connected . That's where I am struck . >> >> On Fri, Apr 17, 2020, 4:11 PM David Villasmil < >> david.villasmil.work(a)gmail.com> wrote: >> >>> You need to trace sip. There’s a loop somewhere. Use tshark (wireshark) >>> or sngrep or ngrep, or some similar network tracing tool. >>> >>> On Fri, 17 Apr 2020 at 11:34, Pavithra M <pavimohan3096(a)gmail.com> >>> wrote: >>> >>>> Hi , >>>> >>>> I am getting the call connected and got 200 ok from the client . But >>>> the INVITE packet goes multiple times between terminating pcscf and s-cscf >>>> and gives too many hops error .Even After that call goes perfectly fine >>>> with 200 ok message. >>>> What would be the reason . I am not getting any errors in my logs with >>>> debug log level 6 . >>>> >>>> Kindly tell me what could be the issue . >>>> >>>> >>>> >>>> >>>> On Thu, Apr 16, 2020, 2:16 PM David Villasmil < >>>> david.villasmil.work(a)gmail.com> wrote: >>>> >>>>> That usually happens when you don’t set a next hop, or destination >>>>> where the packet should go, so the packet of forwarded to the same >>>>> destination, which is the proxy again. >>>>> >>>>> On Thu, 16 Apr 2020 at 06:56, Pavithra M <pavimohan3096(a)gmail.com> >>>>> wrote: >>>>> >>>>>> Hi, >>>>>> >>>>>> I have enabled all debug logs and i traced it and I found that as you >>>>>> said it is keep on looping the invite in pcscf instead of going to other UE >>>>>> . I couldn't able to find the reason.Can you please give me some input on >>>>>> this. >>>>>> >>>>>> Debug logs of pcscf : >>>>>> 0#015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.c9499ad5ce252a99a36ad8b9b70f04d4.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a00d9260e4373806e691bfa2828ab215.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6ab08c40989814cf3726b826bdef39d2.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.e650088370f5d61c0d902d1a40fc1252.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.44a3f1c7026e2d42810722ae5c4bf942.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.54030b75c055258251ec7e6980c78c74.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9a08d87ec59a03501dcd55413ce046eb.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f36a9dba7b795e3b96df4bb6b480a688.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b49469c77e102314d82036734a413360.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.221403deba39c28c50f332a8fde22646.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.77f89368e68665c1e3ffdc1d1bea7bab.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060 >>>>>> ;branch=z9hG4bK7014.2e5981568975ea5c81876a9dded1bc08.0# >>>>>> 015#012Via: SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.19809abdb9c351fdce7e25f51e8c1754.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.ad73d18d15b6c9da96e13156a84d5522.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.fcb5555d6a683215aa989fb4254abd62.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.244b467757383234c76b1c66f98ddfe8.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.b2c353ef1d637907359822c64cb81b2a.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.d22dceb1af0320cfc769f94e0214a313.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f5e9b7f9b209c82971ae1017b9ad7d1e.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.0f2c98bc92cc799fdce0a4090b626021.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.aa8a07d89f83a26cefd74e4770aef63c.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.94c376a77d066ffe113e84465f5f5311.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.2202e658b1d8b801b14ec432bae7fabe.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.55f7d6a5d9d2a9d064cf1c6683f12eca.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.6870e53f3bc573f140d1728401dd43ae.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.a84d83df8646a75ee0d3605dcacb45ad.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.486b6fb0d17077e20f8375188a8bee75.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.bc0321f98578ab09ad615b634c4c83cd.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.9b26fda9326632abf7bdb32a33d03ab2.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.060fa4afc70848b34ede46705b90f7cb.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.56134adb7c492f7a4f03b36dfbf713f5.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.f9ccc5e81175283c9b4b56f4a2252c0f.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.3c231176b0e95b8121637df41b504f18.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.95bd5b0e0bf8c2bda906a751816a9876.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.87e0fd0a1bd044147d22052d27e07527.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.0a319c71a9a26c8afa77713d6d4ecfed.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.79:4070;branch=z9hG4bK7014.1442d975c0a393f232020916a6fbfc15.1#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.73:4080;branch=z9hG4bK7014.e35a84678ec61f7cefa8cdacb6ba92d9.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.179:4060;branch=z9hG4bK7014.cc99617f0c0f5088f45e203f6a58dd57.0#015#012Via: >>>>>> SIP/2.0/UDP 10.45.6.174:36029;received=10.45.6.174;branch=z9hG4bK-524287-1---c856c42a33d1e959;rport=36029#015#012To: >>>>>> <sip:bob@sip.example.com>;tag=8409f602ccf3f3f0da6ebceab6ff6336.aa5bd74f#015#012From: >>>>>> <sip:alice@sip.example.com;transport=UDP>;tag=cdbaae3f#015#012Call-ID: >>>>>> I-58e6z5tN3aDpmdzq1oVA..#015#012CSeq: 1 INVITE#015#012Server: TelcoSuite >>>>>> Proxy-CSCF#015#012Content-Length: 0 >>>>>> >>>>>> As you see here , continuously invite is going on looping in >>>>>> 10.45.6.179 IP which is pcscf. What could be the reason .. Kindly do the >>>>>> needful. >>>>>> >>>>>> On Wed, Apr 15, 2020, 2:19 PM David Villasmil < >>>>>> david.villasmil.work(a)gmail.com> wrote: >>>>>> >>>>>>> You should be tracing, you’re probably not, otherwise you would see >>>>>>> the server is probably forwarding the INVITE to itself (removing one hop >>>>>>> every time as it must) and thus creating a loop. >>>>>>> >>>>>>> On Wed, 15 Apr 2020 at 09:42, Pavithra M <pavimohan3096(a)gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>>> Hi , >>>>>>>> Yes , I have tried uncommenting that part . It is actually checking >>>>>>>> for hostname (sip.example.com:5060) in my scscf node. I am not >>>>>>>> sure why it is looking for sip.example.com instead of >>>>>>>> scscf.sip.example.com:4080 >>>>>>>> >>>>>>>> I have added one more alias in my scscf.cfg file .Now Domain not >>>>>>>> served issue has gone. >>>>>>>> After that I am facing 483 Too Many Hops Error. >>>>>>>> >>>>>>>> I have added scscf debug logs. >>>>>>>> >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/mem/q_malloc.c:482]: qm_free(): qm_free(0x7fc57b362010, >>>>>>>> 0x7fc57b514138), called from ims_registrar_scscf: lookup.c: lookup(225) >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/mem/q_malloc.c:526]: qm_free(): freeing frag. 0x7fc57b514100 alloc'ed >>>>>>>> from ims_registrar_scscf: lookup.c: lookup(103) >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** >>>>>>>> cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] >>>>>>>> l=1041 a=16 n=if >>>>>>>> * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/socket_info.c:628]: grep_sock_info(): checking if host==us: 10==10 && >>>>>>>> [10.45.6.75] == [10.45.6.73]* >>>>>>>> * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/socket_info.c:635]: grep_sock_info(): checking if port 4080 >>>>>>>> (advertise 0) matches port 32347* >>>>>>>> * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/forward.c:412]: check_self(): host != me* >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** >>>>>>>> cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] >>>>>>>> l=1050 a=5 n=route >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** >>>>>>>> cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] >>>>>>>> l=821 a=16 n=if >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** >>>>>>>> cfgtrace:request_route=[apply_privacy] c=[/etc/kamailio/scscf/kamailio.cfg] >>>>>>>> l=818 a=25 n=is_present_hf >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: ERROR: *** >>>>>>>> cfgtrace:request_route=[FINAL_TERM] c=[/etc/kamailio/scscf/kamailio.cfg] >>>>>>>> l=1052 a=24 n=t_relay >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm >>>>>>>> [t_lookup.c:1328]: t_newtran(): msg (0x7fc57b502a70) id=2/7139 global >>>>>>>> id=2/7139 T start=(nil) >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm >>>>>>>> [t_lookup.c:497]: t_lookup_request(): start searching: hash=38849, isACK=0 >>>>>>>> * Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm >>>>>>>> [t_lookup.c:455]: matching_3261(): RFC3261 transaction matching failed - >>>>>>>> via branch [z9hG4bK1c79.03e4ec0c2ca15f1aa14c067b33a29f10.1]* >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: tm >>>>>>>> [t_lookup.c:675]: t_lookup_request(): no transaction found >>>>>>>> Apr 15 13:59:12 tel-VirtualBox kamailio[7139]: DEBUG: <core> >>>>>>>> [core/mem/q_malloc.c:374]: qm_malloc(): qm_malloc(0x7fc57478b000, 5720) >>>>>>>> called from tm: h_table.c: build_cell(330) >>>>>>>> >>>>>>>> I am facing host is not me error . Here 10.45.6.73 -> scscf and >>>>>>>> 10.45.6.75 -> UE (bob user) >>>>>>>> I am not sure what alias it is asking for . Kindly help. >>>>>>>> >>>>>>>> On Wed, Apr 15, 2020 at 1:36 PM Pafel <pafels(a)gmail.com> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> Most likely this is because of the change. Revert back the changes >>>>>>>>> (uncomment the section I told you), turn on debug in scscf.cfg, restart all >>>>>>>>> nodes and test once again. Then have a look on the scscf logs. >>>>>>>>> >>>>>>>>> Regards, >>>>>>>>> Pavel Siderov >>>>>>>>> _______________________________________________ >>>>>>>>> Kamailio (SER) - Development Mailing List >>>>>>>>> sr-dev(a)lists.kamailio.org >>>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Kamailio (SER) - Development Mailing List >>>>>>>> sr-dev(a)lists.kamailio.org >>>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>>>>>> >>>>>>> -- >>>>>>> Regards, >>>>>>> >>>>>>> David Villasmil >>>>>>> email: david.villasmil.work(a)gmail.com >>>>>>> phone: +34669448337 >>>>>>> _______________________________________________ >>>>>>> Kamailio (SER) - Development Mailing List >>>>>>> sr-dev(a)lists.kamailio.org >>>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>>>>> >>>>>> _______________________________________________ >>>>>> Kamailio (SER) - Development Mailing List >>>>>> sr-dev(a)lists.kamailio.org >>>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>>>> >>>>> -- >>>>> Regards, >>>>> >>>>> David Villasmil >>>>> email: david.villasmil.work(a)gmail.com >>>>> phone: +34669448337 >>>>> _______________________________________________ >>>>> Kamailio (SER) - Development Mailing List >>>>> sr-dev(a)lists.kamailio.org >>>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>>> >>>> _______________________________________________ >>>> Kamailio (SER) - Development Mailing List >>>> sr-dev(a)lists.kamailio.org >>>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>>> >>> -- >>> Regards, >>> >>> David Villasmil >>> email: david.villasmil.work(a)gmail.com >>> phone: +34669448337 >>> _______________________________________________ >>> Kamailio (SER) - Development Mailing List >>> sr-dev(a)lists.kamailio.org >>> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >>> >> _______________________________________________ >> Kamailio (SER) - Development Mailing List >> sr-dev(a)lists.kamailio.org >> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >> > -- > Regards, > > David Villasmil > email: david.villasmil.work(a)gmail.com > phone: +34669448337 > _______________________________________________ > Kamailio (SER) - Development Mailing List > sr-dev(a)lists.kamailio.org > https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-dev >

4 years, 6 months

Releasing Kamailio 5.2.7

by Henning Westerholt

Hello, as discussed in the last development meeting, I am planning to release next week (likely on Wednesday 13th May) the next minor version out of branch 5.2, version 5.2.7. Backports of fixed issues from git master will be integrated as usual. If you are aware of new issues which were not yet reported, let us know (by creating an issue on the tracker). Cheers, Henning -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://gilawa.com<https://gilawa.com/>

4 years, 6 months

"kamdbctl create" scrip error "Invalid default value for 'action'"

by Вячеслав Панасов

Hi all I trying to install the test`s kamailio from repo in the new instance on the CentOS 7 with MariaDB 5.5.6 and get this ERROR message [user@testkamailio-002] # kamdbctl create MySQL password for root: INFO: test server charset INFO: creating database kamailio ... INFO: granting privileges to database kamailio ... INFO: creating standard tables into kamailio ... INFO: Core Kamailio tables succesfully created. Install presence related tables? (y/n): y INFO: creating presence tables into kamailio ... INFO: Presence tables succesfully created. Install tables for imc cpl siptrace domainpolicy carrierroute drouting userblacklist htable purple uac pipelimit mtree sca mohqueue rtpproxy rtpengine secfilter? (y/n): y INFO: creating extra tables into kamailio ... ERROR 1067 (42000) at line 1: Invalid default value for 'action' ERROR: Creating extra tables failed at secfilter! after if i try reinit i get this error [user@testkamailio-002] # kamdbctl reinit MySQL password for root: This will drop your current database and create a new one. It is recommended to first backup your database. Continue with reinit? (y/n): y INFO: Database kamailio deleted INFO: test server charset INFO: creating database kamailio ... INFO: granting privileges to database kamailio ... ERROR 1396 (HY000) at line 1: Operation CREATE USER failed for 'kamailio'@ 'localhost' ERROR 1396 (HY000) at line 1: Operation CREATE USER failed for 'kamailioro'@ 'localhost' ERROR: granting privileges to database kamailio failed! two weeks ago, the installation was successful, apparently there were some changes in the script cheers Vjacheslav Panasov

4 years, 6 months

Determine correct port in record-route if kamailio is behind NAT

by Michal Popovic

Hello, our kamailio used for sip trunk interconnections is behind NAT and our cloud provider opens random outgoing ports for outbound connections. Our record-route is set to our external address and port 5060, that is probably incorrect, but we did not had any issues. One of our partners suddenly begin sending BYEs to the port advertised in record-route instead of port from where he received call. What is a correct approach here if we are not able to determine open port behind NAT? Bye, Michal

4 years, 6 months

How to delete all values for a certain xavp index

by Sergiu Pojoga

Hi there, For some reason I can't figure this seemingly simple Subj, may be someone can help. In my particular case, trying to delete Contact[0] from the xavp storing Contacts after t_load_contacts() $xavp(tm_contacts[0]) = $null; Above results in all but the latest added value being deleted. Assigning $null to index[1] results in all but the latest 2 being delete and so on. Thanks.

4 years, 6 months

Digest authentication w/ Kamailio & Freeswitch

by Edward Romanenco

Hi! I've using a SIP setup that includes both Kamailio & Freeswitch, invites are passed from Freeswitch and relayed by Kamailio to various dispatchers, I would like to have Kamailio authenticating when Proxy Authentication is required. As I understood, this can be achieved with the help of a failure route, problem is, when I'm utilizing this method - the 407 response gets reverted back to Freeswitch, which returns the revised invite filled with the default Freeswitch username/password, how can let Kamailio handle the authentication once receiving the 407? Can I work straight without relying on a failure route, but having the Proxy Authentication header on my original invite? This is my relevant configuration - route[RELAY] { if (is_method("INVITE|BYE|SUBSCRIBE|UPDATE")) { if(!t_is_set("branch_route")) { t_on_branch("MANAGE_BRANCH"); } } if (is_method("INVITE|SUBSCRIBE|UPDATE")) { if(!t_is_set("onreply_route")) { t_on_reply("MANAGE_REPLY"); } } if (is_method("INVITE")) { if(!t_is_set("failure_route")) { t_on_failure("KAM_AUTH"); } } if (!t_relay()) { sl_reply_error(); } exit; } failure_route[KAM_AUTH] { if(t_check_status("401|407")) { $avp(auser) = "xxx"; $avp(apass) = "yyy"; t_on_failure("OUTGOING_FAILURE"); uac_auth(); t_relay(); exit; } } Edward

4 years, 6 months

← Newer
1
2
3
4
5
6
7
8
9
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users May 2020