sr-users June 2019

sr-users@lists.kamailio.org

63 participants
92 discussions

How reply INVITE request with 200 OK that contains SDP?
by Ali Shirvani 11 Jun '19

11 Jun '19

Hi all, I tried to implement simple announcer by using play_media function in latest rtpengine module. I implemented simple Lua script and I tried to test the implementation with simple SIPp scenario. Here is the Lua function to reply the received INVITE request. ```Lua function ksr_route_announcer() KSR.info("======= Announcer =====\n"); local u = KSR.pv.gete("$rU"); KSR.info("username is: " .. u .. "\n"); if u == "ann" then KSR.info("announcer has been called.\n"); if KSR.textops.has_body_type("application/sdp") then KSR.info("request contains SDP.\n"); KSR.tm.t_newtran(); KSR.rtpengine.rtpengine_manage0(); KSR.tm.t_reply(200, "OK"); KSR.x.exit(); end end end ``` According to kamailio logs rtpengine modified the INVITE SDP, but I want to add SDP to 200 OK response. How should I manage rtpengine to append SDP answer to the 200 OK response? The attached is the SIPp log, as you can see that last 200 OK doesn't contain SDP. Regards, Ali

2 1

Re: [SR-Users] [EXT] Re: Kamailio 5.2.2 ICSCF changing sip to tel
by Woscek, Martin W. 11 Jun '19

11 Jun '19

Daniel, Actually, the HSS is not returning the uri with the +. There are no users int the HSS database with a public ID with a + so the HSS returns the USER_UNKNOWN. Looking at the PCAP, the I-CSCF sends a diameter msg to the HSS asking for the verification the public ID of: Public-Identity: sip:+alice@ims522.irisims.org The diameter msg from HSS is returning : AVP: Experimental-Result-Code(298) l=12 f=-M- val=DIAMETER_ERROR_USER_UNKNOWN (5001) Why do we want the I-CSCF to add a + to all URI's don't start with a +? The I-CSCF is the module that is adding the +, assuming that we should be able to included Kamailio.cfg for respective modules, is there a directive or variable that I need to set? Or do I simply comment out that code? Thanks, Martin Woscek The MITRE Corp. mwoscek(a)mitre.org<mailto:mwoscek@mitre.org> Phone: 703-983-2650 FAX: 703-983-7142 From: Daniel-Constantin Mierla <miconda(a)gmail.com> Sent: Tuesday, June 11, 2019 6:22 AM To: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>; Woscek, Martin W. <mwoscek(a)mitre.org> Subject: [EXT] Re: [SR-Users] Kamailio 5.2.2 ICSCF changing sip to tel Hello, that prefix operation is done only if the r-uri username does not have +. So if you HSS is returning the r-uri with +, then all is ok, no other + is added. On the other hand, I am not sure what is the error or the issue you try to sort out. The error message is because of the xlog(...) in the config. Cheers, Daniel On 10.06.19 16:17, Woscek, Martin W. wrote: Hello all, The HSS is responding with 604 errors when the I-CSCF checks the public identity of the caller. PCAP attached. It looks like our I-CSCF is modifying the sip uri's to tel uri's (e.164-like), referenced attached PCAP: in_uri=sip:alice@ims522.irisims.org out_uri=sip:+alice@ims522.irisims.org<mailto:alice@ims522.irisims.org> syslog output: Jun 6 16:50:06 imskamailio /usr/local/sbin/kamailio[14066]: ERROR: <script>: $ru => sip:+alice@irisims.org Looking at the default (out of the box) Kamailio.cfg for I-CSCF the following script snipet is where the modification to our sip URI is happening: # ------------------------- request routing logic ------------------- # main routing logic route{ #!ifdef WITH_DEBUG xlog("I-CSCF >>>>>>>>>>>>>>>>>>>> $rm $ru ($fu => $tu ($si:$sp) to $tu, $ci)\n"); #!endif if !($rU =~ "\+.*") { prefix("+"); } Is there a I-CSCF setting directive we missed? Or should we simply comment the above? Any advice is appreciated. Thanks, Martin Woscek _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Daniel-Constantin Mierla -- www.asipto.com<http://www.asipto.com> www.twitter.com/miconda<http://www.twitter.com/miconda> -- www.linkedin.com/in/miconda<http://www.linkedin.com/in/miconda>

2 1

Relay NAP Probing
by Duarte Rocha 11 Jun '19

11 Jun '19

Greetings, I have a Kamailio as Sip Proxy between my clients and my Media gateway. I have NAPs (One per client) for clients and NAPs for the MediaGateway (One for each client). The MediaGateway probes Kamailio in order to see if it's alive and Kamailio probes clients. However, i would like for the MediaGateway to be aware of the client status. I thought of a few solutions : - When Kamailio probes a client and it fails, both NAPs (Client Side and MG side) could be set as inactive. - Automatically relay the MG probe to the client - Some scripting that reads the result of dispatcher.list and if it finds an inactive NAP, set the MG NAP as inactive too. Is there a better/simpler way to do this? I'd rather have everything on Kamailio configuration files instead of doing exatra scripting. Any opinions ? How can i achieve this? Best Regards, Duarte Rocha

2 1

Kamailio 5.2.2 ICSCF changing sip to tel
by Woscek, Martin W. 11 Jun '19

11 Jun '19

Hello all, The HSS is responding with 604 errors when the I-CSCF checks the public identity of the caller. PCAP attached. It looks like our I-CSCF is modifying the sip uri's to tel uri's (e.164-like), referenced attached PCAP: in_uri=sip:alice@ims522.irisims.org out_uri=sip:+alice@ims522.irisims.org syslog output: Jun 6 16:50:06 imskamailio /usr/local/sbin/kamailio[14066]: ERROR: <script>: $ru => sip:+alice@irisims.org Looking at the default (out of the box) Kamailio.cfg for I-CSCF the following script snipet is where the modification to our sip URI is happening: # ------------------------- request routing logic ------------------- # main routing logic route{ #!ifdef WITH_DEBUG xlog("I-CSCF >>>>>>>>>>>>>>>>>>>> $rm $ru ($fu => $tu ($si:$sp) to $tu, $ci)\n"); #!endif if !($rU =~ "\+.*") { prefix("+"); } Is there a I-CSCF setting directive we missed? Or should we simply comment the above? Any advice is appreciated. Thanks, Martin Woscek

2 1

Operations after relay
by Nicolas Breuer 11 Jun '19

11 Jun '19

Hello, I want to do some sql operations after a 200 reply, after relaying the sip packet Is it possible or sending the sip packet is the last operation permitted ?

3 3

Connect SIP Trunk to PBX
by Chad Kenealy 10 Jun '19

10 Jun '19

Hello, I hope you can help, We are trying to connect our SIP trunk to our new PBX system, however our SIP trunk provider requires a static IP to add to the endpoint. Our new PBX provider uses a range of IPs that are connected to a domain and the IPs change all the time. Is there a way of using Kamailio that we could get our Sip Trunk provider and PBX system to work together? Regards

2 1

Question about setbflag and isbflagset usage
by Володимир Іванець 07 Jun '19

07 Jun '19

Hello everyone! I'm not sure if I correctly understood the description of functions *isbflagset* and *isbflagset* so once again I'm asking for help :) Here is what I do: 1. Asterisk sends INVITE to Kamailio. Kamailio performs lookup of available contacts and then few checks in branch_route. I'm adding *setbflag("17", $T_branch_idx);* there. 2. Later in route[NATMANAGE] I added *if (isbflagset("17", $T_branch_idx)) {* and additional logic. *isbflagset* results in *true* (for same INVITE). 3. Finally one of UACs responds with 200 OK. Asterisk generates ACK packet that gets in route[NATMANAGE]. *isbflagset* results in *false*. So my question is: shouldn't *isbflagset* be *true* for ACK too since it's the same branch or I interpreted these fenctions incorrectly? Thanks a lot!

3 6

Re: [SR-Users] [EXT] Re: ICSCF mysql error
by Bao, Yin 07 Jun '19

07 Jun '19

Yes I think you are right it’s the mismatch of uri. However we don’t know which configuration resulted that mismatch. Here are a bit more details: ICSCF prepared this query: select * from impu where identity=? And it provided sip:+alice@irisims.org as the parameter for the query However the HSS impu table as well as the SIP INVITE only contains: sip:alice@irisims.org I am suspecting the additional + may be causing this mismatch. But where is the + coming from and why ICSCF add this in front of original INVITE line uri? Thanks! Yin From: sr-users <sr-users-bounces(a)lists.kamailio.org> on behalf of YASIN CANER <caner_yaso(a)hotmail.com> Reply-To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Date: Friday, June 7, 2019 at 2:47 AM To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.kamailio.org> Subject: [EXT] Re: [SR-Users] ICSCF mysql error Hello , It is a mismatch inconming uri and your uri in hss. Yasin Caner Henning Westerholt <hw(a)skalatan.de<mailto:hw@skalatan.de>> şunları yazdı (7 Haz 2019 09:28): Hello, not an expert on this particular module, but this is the internal error path from the module that probably caused this error reply: - case RC_IMS_DIAMETER_ERROR_USER_UNKNOWN, will send message with: - #define MSG_604_USER_UNKNOWN "Does not exist anywhere - HSS User Unknown" The status comes probably from the CDP module: diameter_epc_code_result.h 57: RC_EPC_DIAMETER_ERROR_USER_UNKNOWN = 5001, Maybe this helps. Henning Am 03.06.19 um 06:43 schrieb Trinh, Jenny: Hi, I’m getting the error 604 when ICSCF did a query to mysql and failed with an INVITE. Please see my attached pcap. Would appreciate any feedbacks on what might the issue. We’re using BOGHE client to register and make call with Kamailio IMS 5.2.2 May 22 09:15:10 imskamailio /usr/local/sbin/kamailio[22167]: DEBUG: <core> [core/msg_translator.c:2305]: generate_res_buf_from_sip_res(): copied size: orig:143, new: 56, rest: 630 msg=#012SIP/2.0 604 Does not exist anywhere - HSS User Unknown#015#012Via: SIP/2.0/UDP 0.0.0.0:4060;received=10.0.20.1;branch=z9hG4bK3c92.7402885f6124cf2862bde6f9458080b5.0#015#012Via: SIP/2.0/UDP 10.141.161.85:56962;received=10.141.161.85;branch=z9hG4bK594030036;rport=56962#015#012From: <sip:bob@ims522.irisims.org><mailto:sip:bob@ims522.irisims.org>;tag=594048364#015#012To: <sip:alice@ims522.irisims.org><mailto:sip:alice@ims522.irisims.org>;tag=077cecf844e3c5622044f0dc84818fc7-09fb#015#012Call-ID: 25759faf-6f50-5607-c8f9-162abbbff8cb#015#012CSeq: 19622 INVITE#015#012Server: Kamailio I-CSCF#015#012Content-Length: 0#015#012Warning: 392 10.0.20.1:5060 "Noisy feedback tells: pid=22149 req_src_ip=10.0.20.1 req_src_port=6060 in_uri=sip:alice@ims522.irisims.org<mailto:in_uri=sip:alice@ims522.irisims.org> out_uri=sip:+alice@ims522.ir<mailto:out_uri=sip:+alice@ims522.ir> Thank you _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users -- Henning Westerholt - https://skalatan.de/blog/ Kamailio services - https://skalatan.de/services _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org<mailto:sr-users@lists.kamailio.org> https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

2 1

Re: [SR-Users] Using DNS in Dispatcher for SRV Clarification [SOLVED]
by JR Richardson 07 Jun '19

07 Jun '19

Hi Federico, "use_dns_cache=on" this is on be default. "use_dns_failover=on" this is off by default, changing to "on" did the trick, auto failover to next SRV server is working quickly, as expected now. Thanks for the pointer. JR -- JR Richardson Engineering for the Masses Chasing the Azeotrope > > Hi, > if you want failover support, you need to have a couple of core dns > parameters enabled: > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#use_dns_cache > > and > > https://www.kamailio.org/wiki/cookbooks/5.2.x/core#use_dns_failover > > The latter defaults to off. > > Cheers, > > Federico > > On Thu, Jun 6, 2019 at 10:10 PM JR Richardson <jmr.richardson(a)gmail.com> > wrote: > > > Hey All, > > > > I'm in the lab testing kamailio 5.2 with DNS SRV records. The scenario > > is simple, using dispatcher with hard coded IP URIs > > [sip:10.10.10.10:5060] and also a DNS name URI [sip:sip.domain.com]. > > There are 2 SRV servers. > > > > The DNS SRV records are setup and resolving OK, during startup, > > kamailio list the DNS name in the dispatcher list. > > > > During a call scenario, when the dispatcher selects the DNS name URI > > for the next destination, the TM module takes over, resolves the > > _sip._udp.sip.domain.com for both SRV records OK and sends the call to > > the first SRV server in the list. But if I take the first SRV server > > offline, make another call, the TM module does not route to the second > > SRV server until the DNS record timeout is reached, in my lab was set > > for 300 seconds. I decreased the DNS SRV record TTL down to 5 seconds > > with same results above, but 5 seconds lapse when TM routes call to > > next SRV server. > > > > I think this is working as expected but not sure if this is by design > > so my question is, should the TM module route to another SRV server in > > the list in the event of a no response timeout or send the transaction > > back to the dispatcher to select another target? > > > > Should I play around with the TM Module parameter > > "max_noninv_lifetime" to get quicker results or it is better to have > > DNS SRV record TTL set really low? > > > > Thanks. > > > > JR

1 0

reading php script result with exec_avp
by Gertjan Wolzak 07 Jun '19

07 Jun '19

Hello Kamailions, I have the following challenge. I want to create a time dependent callerid, based on the time of a outgoing call a callerid will be set. I have a php script, that provides me an id number which relates to an cli. When I run that php script from the console, the id is shown in the console. When I run the script within the kamailio configuration, exec_avp("../script.php", "$avp(s:cliId)"); ,no output commande is saved in the avp variable. I think I am not presenting the result of the php script correctly. I have tried with an echo $variable; and with and fwrite(STDOUT, $variable); but no luck. I'm not a PHP coder so I am not surprised of the missing luck, but maybe somebody has a golden tip for me? Rgds, Gertjan

2 7

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

2025

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 June 2019