sr-users April 2015

sr-users@lists.kamailio.org

89 participants
143 discussions

by Raj Roy Ghandhi

Hi Friends, I need to send text to GSM phones from SIP client. SIPSimple text -> GSM SMS Does anybody know good SMS gateway service that I can use for this purpose. Best Regards, Roy Gandhi.

9 years

Regarding IMS/RCS complaint clients for Kamailio IMS/RCS server

by MadhuManjushaAripirala

Hello, Please let me know 1.What are the IMS and RCS based clients available to test on Kamailio IMS/RCS server? 2.On browsing for Kamailio Installation,I found below 3 different links,please suggest me which one to be followed. https://loadmultiplier.com/node/76 http://www.kamailio.org/wiki/tutorials/ims/installation-howto http://kamailio.org/wiki/install/4.2.x/git 3.From the first link above,I see there are separate steps mentioned to install CSCF nodes and HSS but where I find no information for setting up RCS AS(application server) module.Please let me know on this. Thanks & Regards, Manjusha. -- View this message in context: http://sip-router.1086192.n5.nabble.com/Regarding-IMS-RCS-complaint-clients… Sent from the Users mailing list archive at Nabble.com.

9 years

Fwd: INVITE routing issue when using Private IP (RFC1918) network

by pslack14

Hello, I have a Kamailio IMS instance setup, using different hosts for each IMS function (P-CSCF,S-CSCF,I-CSCF etc) and am able to register clients successfully. However, when Client-A tries to call Client-B (both registered to the same S-CSCF), the call is failing with the "403 Forbidden - You must register first with a S-CSCF" error. . All hosts & clients are running on the same subnet using RFC1918 IP addresses, there is no NAT involved. I've seen the same issue on both 4.2 and Master branches. I have the nathelper 'nat_uac_test' parameter set to 18. Looking at the debug prints and SIP traces, I can see that the 403 Error is being generated by the P-CSCF when it receives the INVITE from the S-CSCF (for forwarding to Client-B). Digging deeper into the debug logs, it looks like this is a result of a failed contact match - I've experimented with different values for "hashing_type", which do change the routing logic but still I see the 403 Error. Here's 2 excerpts from the debug prints for different values of hashing_type : *modparam("ims_usrloc_pcscf", ""hashing_type",hashing_type", 0) :* 2(19636) DEBUG: ims_registrar_pcscf [service_routes.c:183]: getContactP(): > Searching in usrloc for 10.133.202.17:5060 (Proto 1) 2(19636) DEBUG: ims_usrloc_pcscf [udomain.c:618]: get_pcontact_by_src(): > Trying to find contact by src with URI: [sip:*@10.133.202.17:5060] 2(19636) DEBUG: ims_usrloc_pcscf [udomain.c:465]: get_pcontact(): > Searching for contact in P-CSCF usrloc [sip:*@10.133.202.17:5060] 2(19636) DEBUG: ims_usrloc_pcscf [usrloc.c:187]: get_aor_hash(): Returning > hash slot: [1670705485] 2(19636) DEBUG: ims_registrar_pcscf [service_routes.c:186]: getContactP(): > No entry in usrloc for 10.133.202.17:5060 (Proto 1) found! 2(19636) DEBUG: ims_usrloc_pcscf [udomain.c:465]: get_pcontact(): > Searching for contact in P-CSCF usrloc [sip:john@10.133.202.61:64019 > ;transport=udp] 2(19636) DEBUG: ims_usrloc_pcscf [usrloc.c:187]: get_aor_hash(): Returning > hash slot: [397265208] 2(19636) DEBUG: ims_registrar_pcscf [service_routes.c:119]: > checkcontact(): Port 64019 (search 5060), Proto 1 (search 1), reg_state > registered (search registered) 2(19636) ERROR: *** cfgtrace:request_route=[Orig_Initial] > c=[/etc/kamailio/kamailio.cfg] l=926 a=26 n=send_reply *modparam("ims_usrloc_pcscf", ""hashing_type",hashing_type", 2) :* 1(19401) DEBUG: ims_registrar_pcscf [service_routes.c:183]: getContactP(): >> Searching in usrloc for 10.133.202.17:5060 (Proto 1) > > 1(19401) DEBUG: ims_usrloc_pcscf [udomain.c:618]: get_pcontact_by_src(): >> Trying to find contact by src with URI: [sip:*@10.133.202.17:5060] > > 1(19401) DEBUG: ims_usrloc_pcscf [udomain.c:465]: get_pcontact(): >> Searching for contact in P-CSCF usrloc [sip:*@10.133.202.17:5060] > > 1(19401) DEBUG: ims_usrloc_pcscf [usrloc.c:97]: >> get_alias_host_from_contact(): no params > > 1(19401) DEBUG: ims_usrloc_pcscf [usrloc.c:183]: get_aor_hash(): using >> host for hash [10.133.202.17] > > 1(19401) DEBUG: ims_usrloc_pcscf [usrloc.c:187]: get_aor_hash(): >> Returning hash slot: [-1564914093] > > 1(19401) DEBUG: ims_registrar_pcscf [service_routes.c:186]: >> getContactP(): No entry in usrloc for 10.133.202.17:5060 (Proto 1) found! > > 1(19401) DEBUG: ims_usrloc_pcscf [udomain.c:465]: get_pcontact(): >> Searching for contact in P-CSCF usrloc [sip:john@10.133.202.61:64013 >> ;transport=udp] > > 1(19401) DEBUG: ims_usrloc_pcscf [usrloc.c:176]: get_aor_hash(): Looks >> like this contact is natted - contact URI: [10.133.202.61] but came from >> received_host: [10.133.202.17] so will use received_host for hash > > 1(19401) DEBUG: ims_usrloc_pcscf [usrloc.c:187]: get_aor_hash(): >> Returning hash slot: [-1564914093] > > 1(19401) ERROR: *** cfgtrace:request_route=[Orig_Initial] >> c=[/etc/kamailio/kamailio.cfg] l=926 a=26 n=send_reply > > Can anyone offer any hints as to how to resolve this? I am attaching a SIP call flow - I can supply a complete Kamailio debug trace if needed. Thanks Phill

9 years

Ip Address

by badican c-tin

HelloI have a little project and I need to find the ip address from my SIP phone. How can I find my ip addres of the phone?Have you a command or a service whith this functions? Thanks for help !!!Best regards,Constantin

9 years

Re: [SR-Users] SIP messages over UDP with sizes over MTU

by Yufei Tao

Hi Daniel We don't have pike module enabled. When the problem occurred on an VIP, we observed these: * Kamailio stopped responding to any messages that were sent to the VIP, not just OPTIONS * The OPTIONS messages are not big. But the other SIP messages, e.g. some of the INVITE/OK that came from some SBCs can be big * netstat showed the Recv-Q on that VIP had a lot of bytes accumulated, while Kamailio was not seeing/reading them * Kamailio responded fine on its real IP, when I sent OPTIONS pings to it using sipsak * After restarting Kamailio it started working. But after 1 week or so the same problem happened again Since this only happened after running for 1 week or so, we didn't have any traces to show what exactly happened at the particular time when it happened. It is possible some SIP messages may have come in fragmented and some are just too big, depending on the route they came from etc. So I was wonder if it was possible that the UDP receive buffer was filled somehow with messed-up messages. Is there anyway to check this? Any suggestions where I should start looking please? Or is it generally a bad idea to use UDP when there are messages that may be too big, either fragmented or not? Since the it is running in the production environment, I'd like to get some confidence that a Kamailio upgrade will fix the problem first before I change anything there. Cheers, Yufei Date: Wed, 01 Apr 2015 16:27:44 +0200 From: Daniel-Constantin Mierla <miconda(a)gmail.com> To: "Kamailio (SER) - Users Mailing List" <sr-users(a)lists.sip-router.org > Subject: Re: [SR-Users] SIP messages over UDP with sizes over MTU Message-ID: <551C0060.3010002(a)gmail.com> Content-Type: text/plain; charset="windows-1252" Hello, first, not related to the topic you reported, I would recommend at least upgrading to latest 4.0.x, there were many fixes from v4.0.0 and there are no changes to be done to config or database -- simply deploy latest 4.0.x and restart. Back to this topic. Is all the other traffic handled apart of big OPTIONS? Do you have pike module enabled? If yes, can you double check and be sure that the SBC is not blacklisted (traffic from it should not be handled via pike_check_req()). Cheers, Daniel On 01/04/15 15:42, Yufei Tao wrote: > Hi > > We've got Kamailio (v4.0.0) connected to some SBC, which sends SIP > traffic and periodic OPTIONS pings to Kamailio's VIP. Kamailio > responds to the OPTIONS pings with OK, i.e. in the main route block: > if (is_method("OPTIONS")) > { > sl_send_reply("200","OK"); > exit; > } > > All works fine for a week or so, then Kamailio stopped responding to > the OPTIONS pings on the VIP it listens to. But it still respond to > OPTIONS pings that are sent to its real IP. The real IP is not used > for receiving/sending any traffic while only the VIP is. So it seems > that Kamailio is still working, but maybe having problems with the > receiving buffer for the VIP? > > We do see that some SIP messages sent to Kamailio's VIP are too big > (sometimes over 1500 bytes). My question is, in this case, what would > be expected to happen? Is it possible somehow the receiving buffer for > the VIP got messed up by the big UDP messages? Any one seen similar > problems? What is the suggested solution? > > We're considering moving to TCP. But since this is production > environment, I want to get some confidence that the problem we saw was > likely to have been caused by the UDP message being too large. > > Cheers, > Yufei

9 years, 1 month

Kamailio v4.2.4 Released

by Daniel-Constantin Mierla

Hello, Kamailio SIP Server v4.2.4 stable release is out. This is a maintenance release of the latest stable branch, 4.2, that includes fixes since release of v4.2.3. There is no change to database schema or configuration language structure that you have to do on installations of v4.2.x. Deployments running previous v4.x.x versions are strongly recommended to be upgraded to v4.2.4. For more details about version 4.2.4 (including links and guidelines to download the tarball or from GIT repository), visit: * http://www.kamailio.org/w/2015/04/kamailio-v4-2-4-released/ RPM, Debian/Ubuntu packages will be available soon as well. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

9 years, 1 month

Kamailio coredump when "INVITE" enter in failure route

by José Seabra

Hi there, I have noticed that my kamailio proxy, version 4.2.2 is originating core dumps. This happens when Kamailio receives an INVITE in failure route, then execute the function async_sleep(3), after that changes request uri, then it stops with following error message shown below: <core> [mem/f_malloc.c:586]: fm_free(): BUG: fm_free: bad pointer 0x7f8d26605ed8 (out of memory block!), called from <core>: parser/msg_parser.c: set_path_vector(822) - aborting Please see the attachment that contains the " gdb bt full" from core.dump originated Thank you for your attention Best Regards -- Cumprimentos José Seabra

9 years, 1 month

rtpengine documentation error for forced rtpproxying?

by Daniel Tryba

I'm looking to replace rtpproxy with rtpengine. All calls have to be forced thru rtpengine and according to the documentation the equivalent of rtpproxy_manage("f"); is rtpengine_manage("force"); But rtpenginge doesn't recognize it as a valid flag. Using the legacy rtpproxy mod it still works though. Is it a documentation failure or is a specific version of rtpengine required for forced? Apr 1 17:54:28 pisco rtpengine[3432]: Got valid command from 127.0.0.1:43193: offer - { "sdp": "v=0#015#012o=tryba 8000 8001 I N IP4 10.0.3.169#015#012s=SIP Call#015#012c=IN IP4 10.0.3.169#015#012t=0 0#015#012m=audio 5016 RTP/AVP 8 0 9 2 3 18 4 99 101 13 #015#012a=sendrecv#015#012a=rtpmap:8 PCMA/8000#015#012a=rtpmap:0 PCMU/8000#015#012a=rtpmap:9 G722/8000#015#012a=rtpmap:2 G726-3 2/8000#015#012a=rtpmap:3 GSM/8000#015#012a=rtpmap:18 G729/8000#015#012a=rtpmap:4 G723/8000#015#012a=rtpmap:99 iLBC/8000#015#012 a=fmtp:99 mode=20#015#012a=ptime:20#015#012a=rtpmap:101 telephone- event/8000#015#012a=fmtp:101 0-11#015#012", "flags": [ "force " ], "call-id": "5 ... Apr 1 17:54:28 pisco rtpengine[3432]: ... f13ffb48e98404a(a)10.0.3.169", "received-from": [ "IP4", "109.235.34.226" ], "from-tag ": "3819edfdf2df044a", "command": "offer" } Apr 1 17:54:28 pisco rtpengine[3432]: Unknown flag encountered: 'force' -- Telefoon: 088 0100 700 Sales: sales(a)pocos.nl | Service: servicedesk(a)pocos.nl http://www.pocos.nl/ | Croy 9c, 5653 LC Eindhoven | Kamer van Koophandel 17097024

9 years, 1 month

Planning to release Kamailio v4.2.4

by Daniel-Constantin Mierla

Hello, I am considering to release a new maintenance version from latest stable branch - to be v4.2.4 - next week, most likely on Thursday, April 2. If there is anything important to get in and not discussed yet, bring the topic on development mailing list. Cheers, Daniel -- Daniel-Constantin Mierla http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda Kamailio World Conference, May 27-29, 2015 Berlin, Germany - http://www.kamailioworld.com

9 years, 1 month

Recommendation for toggling MSILO m_store auto-notification reply on/off

by Anthony Messina

Using Kamailio 4.2-dev and MSILO, is it possible to "toggle" the auto- notification reply MESSAGE using something similar to the following where "$var(msilo_reply)" is emtpy at startup (or are there suggestions for a better method): modparam("msilo", "from_address", "$var(msilo_reply)") ... if(CONDITION WHERE I WANT THE AUTO-REPLY RETURNS POSITIVE) { $var(msilo_reply)="$rU(a)example.net"; } m_store($rU) ... My use case is that I would like the auto-notification reply to occur in some instances, but not others. I also do not want to create a loop where the auto-notification replies are also stored. I was originally using a simple test: if(src_ip!=myself), but I have begun to use the IMC module as well as the EXEC module and these MESSAGEs appear to originate from "myself." Looking at the MSILO documentation I see there is "extra_hdrs(string)," but this appears to be designed to add headers to dumped MESSAGEs. I was hoping there would be a way to add a custom header to the auto-notification, on which I could filter/drop generated replies earlier in the route, but it doesn't appear that this exists. My preference for the best-case scenario would be to control the generation of the auto-notification reply in the first place rather than having to add a control to detect the reply and drop it. Thanks in advance for any recommendations. -- Anthony - https://messinet.com/ - https://messinet.com/~amessina/gallery 8F89 5E72 8DF0 BCF0 10BE 9967 92DC 35DC B001 4A4E

9 years, 1 month

Jump to page:

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 April 2015