sr-users

sr-users@lists.kamailio.org

42 participants
37519 discussions

Regarding multi user chat in Kamailio IMS server
by MadhuManjushaAripirala 07 Apr '15

07 Apr '15

Hello all, I have RCS based client. I would like to implement MUC(multi chat user) in existing Kamailio IMS Server. Please help me to input the procedure.Is it really possible to do it ? Please share me URL for any existing "C" source code which I can directly imbibe into Kamailio IMS serve -- View this message in context: http://sip-router.1086192.n5.nabble.com/Regarding-multi-user-chat-in-Kamail… Sent from the Users mailing list archive at Nabble.com.

2 4

flag f in search_hf() is not working for me
by schwatzi＠web.de 07 Apr '15

07 Apr '15

Hi. I think there is a bug in function search_hf_f() in textops.c Here is what I do if ( method == SUBSCRIBE ) { if ( !search_hf("Event", "call-completion", "f") ) { sl_send_reply("489","Bad Event"); exit; } } But here is a SUBSCRIBE that do pass the proxy. SUBSCRIBE sip:101@192.168.1.50 SIP/2.0 Via: SIP/2.0/UDP 77.10.66.72:59793;branch=z9hG4bKPj.O5IXVtDsImPNfCGnDkvj91INsEfvZsm Max-Forwards: 70 From: <sip:101@192.168.1.50>;tag=8-cXkrmwx5WGSIAYgYaXW0oTTsEAEM1S To: <sip:101@192.168.1.50> Contact: <sip:101@192.168.1.8:59793;ob> Call-ID: O12dPIx7Wiih2b.o36UFmMdXr6RE-8Jl CSeq: 24359 SUBSCRIBE Route: <sip:192.168.1.50;transport=udp;lr> Event: message-summary Expires: 3600 Supported: replaces, 100rel, timer, norefersub Accept: application/simple-message-summary Allow-Events: presence, message-summary, refer User-Agent: CSipSimple_mako-21/r2457 Content-Length: 0 As you can see the Event header doesn't contain "call-completition". Looking at function search_hf_f() i saw that if nothing is found value -1 will be returned. if there is the match then 1 is returned. (see line 2779 and 2797) But in line 2782 the function will return 1 instead of -1 index 50a6f07..a945937 100644 --- a/modules/textops/textops.c +++ b/modules/textops/textops.c @@ -2779,7 +2779,7 @@ static int search_hf_f(struct sip_msg* msg, char* str_hf, char* re, char *flags) return 1; } else { if(flags!=NULL && *flags=='f') - return 1; + return -1; } } else { hfl = hf; I am no programmer so it's possible that I misunderstood something. greetz Paolo

2 1

GSM SMS service
by Raj Roy Ghandhi 07 Apr '15

07 Apr '15

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.

2 1

Regarding IMS/RCS complaint clients for Kamailio IMS/RCS server
by MadhuManjushaAripirala 07 Apr '15

07 Apr '15

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.

3 6

Fwd: INVITE routing issue when using Private IP (RFC1918) network
by pslack14 06 Apr '15

06 Apr '15

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

1 0

Ip Address
by badican c-tin 05 Apr '15

05 Apr '15

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

1 0

Re: [SR-Users] SIP messages over UDP with sizes over MTU
by Yufei Tao 03 Apr '15

03 Apr '15

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

2 1

Kamailio v4.2.4 Released
by Daniel-Constantin Mierla 02 Apr '15

02 Apr '15

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

1 0

Kamailio coredump when "INVITE" enter in failure route
by José Seabra 02 Apr '15

02 Apr '15

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

2 4

rtpengine documentation error for forced rtpproxying?
by Daniel Tryba 02 Apr '15

02 Apr '15

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

2 4

Jump to page:

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