sr-users October 2017

sr-users@lists.kamailio.org

78 participants
108 discussions

[CFP] FOSDEM 2018, RTC devroom, speakers, volunteers neeeded

by FOSDEM RTC Team

FOSDEM is one of the world's premier meetings of free software developers, with over five thousand people attending each year. FOSDEM 2018 takes place 3-4 February 2018 in Brussels, Belgium. https://fosdem.org This email contains information about: - Real-Time Communications dev-room and lounge, - speaking opportunities, - volunteering in the dev-room and lounge, - related events around FOSDEM, including the XMPP summit, - social events (the legendary FOSDEM Beer Night and Saturday night dinners provide endless networking opportunities), - the Planet aggregation sites for RTC blogs Call for participation - Real Time Communications (RTC) ======================================================= The Real-Time dev-room and Real-Time lounge is about all things involving real-time communication, including: XMPP, SIP, WebRTC, telephony, mobile VoIP, codecs, peer-to-peer, privacy and encryption. The dev-room is a successor to the previous XMPP and telephony dev-rooms. We are looking for speakers for the dev-room and volunteers and participants for the tables in the Real-Time lounge. The dev-room is only on Sunday, 4th of February 2018. The lounge will be present for both days. To discuss the dev-room and lounge, please join the FSFE-sponsored Free RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc To be kept aware of major developments in Free RTC, without being on the discussion list, please join the Free-RTC Announce list: http://lists.freertc.org/mailman/listinfo/announce Speaking opportunities ---------------------- Note: if you used FOSDEM Pentabarf before, please use the same account/username Real-Time Communications dev-room: deadline 23:59 UTC on 30th of November. Please use the Pentabarf system to submit a talk proposal for the dev-room. On the "General" tab, please look for the "Track" option and choose "Real Time Communications devroom". https://penta.fosdem.org/submission/FOSDEM18/ Other dev-rooms and lightning talks: some speakers may find their topic is in the scope of more than one dev-room. It is encouraged to apply to more than one dev-room and also consider proposing a lightning talk, but please be kind enough to tell us if you do this by filling out the notes in the form. You can find the full list of dev-rooms at https://www.fosdem.org/2018/schedule/tracks/ and apply for a lightning talk at https://fosdem.org/submit Main track: the deadline for main track presentations is 23:59 UTC 3rd of November. Leading developers in the Real-Time Communications field are encouraged to consider submitting a presentation to the main track at https://fosdem.org/submit First-time speaking? -------------------- FOSDEM dev-rooms are a welcoming environment for people who have never given a talk before. Please feel free to contact the dev-room administrators personally if you would like to ask any questions about it. Submission guidelines --------------------- The Pentabarf system will ask for many of the essential details. Please remember to re-use your account from previous years if you have one. In the "Submission notes", please tell us about: - the purpose of your talk - any other talk applications (dev-rooms, lightning talks, main track) - availability constraints and special needs You can use HTML and links in your bio, abstract and description. If you maintain a blog, please consider providing us with the URL of a feed with posts tagged for your RTC-related work. We will be looking for relevance to the conference and dev-room themes, presentations aimed at developers of free and open source software about RTC-related topics. Please feel free to suggest a duration between 20 minutes and 55 minutes but note that the final decision on talk durations will be made by the dev-room administrators based on the number of received proposals. As the two previous dev-rooms have been combined into one, we may decide to give shorter slots than in previous years so that more speakers can participate. Please note FOSDEM aims to record and live-stream all talks. The CC-BY license is used. Volunteers needed ================= To make the dev-room and lounge run successfully, we are looking for volunteers: - FOSDEM provides video recording equipment and live streaming, volunteers are needed to assist in this - organizing one or more restaurant bookings (dependending upon number of participants) for the evening of Saturday, 3rd of February - participation in the Real-Time lounge - helping attract sponsorship funds for the dev-room to pay for the Saturday night dinner and any other expenses - circulating this Call for Participation to other mailing lists Related events - XMPP and RTC summits ===================================== The XMPP Standards Foundation (XSF) has traditionally held a summit in the days before FOSDEM. There is discussion about a similar summit taking place on the 2nd of February 2018 http://wiki.xmpp.org/web/Summit_22 - please join the mailing list for details: http://mail.jabber.org/mailman/listinfo/summit Social events and dinners ========================= The traditional FOSDEM beer night occurs on Friday, 2nd of February. On Saturday night, there are usually dinners associated with each of the dev-rooms. Most restaurants in Brussels are not so large so these dinners have space constraints and reservations are essential. Please subscribe to the Free-RTC mailing list for further details about the Saturday night dinner options and how you can register for a seat: https://lists.fsfe.org/mailman/listinfo/free-rtc Spread the word and discuss =========================== If you know of any mailing lists where this CfP would be relevant, please forward this email. If this dev-room excites you, please blog or microblog about it, especially if you are submitting a talk. If you regularly blog about RTC topics, please send details about your blog to the planet site administrators: All projects http://planet.freertc.org planet(a)freertc.org XMPP http://planet.jabber.org ralphm(a)ik.nu SIP http://planet.sip5060.net planet(a)sip5060.net (Español) http://planet.sip5060.net/es/ planet(a)sip5060.net Please also link to the Planet sites from your own blog or web site as this helps everybody in the free real-time communications community. Contact ======= For any private queries, contact us directly using the address fosdem-rtc-admin(a)freertc.org and for any other queries please ask on the Free-RTC mailing list: https://lists.fsfe.org/mailman/listinfo/free-rtc The dev-room administration team: Saúl Ibarra Corretgé <saghul(a)gmail.com> Iain R. Learmonth <irl(a)debian.org> Ralph Meijer <ralphm(a)ik.nu> Daniel-Constantin Mierla <miconda(a)gmail.com> Daniel Pocock <daniel(a)pocock.pro>

6 years, 6 months

Problems with AAR over Rx Interface

by Ron McLeod

When a LTE handset client attempts to REGISTER with the IMS, an AAR is sent from the P-CSCF to the PCRF to establish a dedicated bearer for SIP signaling (as well as request notifications for certain access network event). There are a couple of problems with the flow descriptions, and I was hoping that someone could confirm that these are actual issues before I start working on a fix. 1. The "in" and "out" directions seem reversed. "in" corresponds to the uplink (UE to network), and "out" corresponds to the downlink (network to UE). In the AAR sent to the PCRF, the "in" description indicates the traffic "from" the UE, rather than "to" the UE. There is a similar problem with the "out" description. A fix would involve reversing "in" and "out". 2. The IP address and port number for the UE side are correct (in my case the UE has been allocated 172.25.152.195, and the client is using port 37843), but the network side is specified as IP address 127.0.0.1 and port number is the same as the open used by the client (in my case the P-CSCF has an IP address of 172.25.152.20 and a port number of 4060). I see in the source code that the P-CSCF address is hard-coded to "127.0.0.1". A fix would involve either using the actual UE-facing IP address and port number for the P-CSCF or wildcards. Another option would be to not try and setup a dedicated bearer for SIP signaling, and just use the default bearer (there shouldn't be anything else other than signaling-related traffic on the default bearer anyway). The access network HSS would specify that the default bearer was created with the appropriate parameters (QCI=5, AM, etc.). This is the network message flow: 172.25.152.195 -> pcscf.core.ims1.test SIP 999 Request: REGISTER sip:provider1.test (fetch bindings) | pcscf.core.ims1.test -> 172.25.152.195 SIP 359 Status: 100 Trying (0 bindings) | pcscf.core.ims1.test -> pcrf.ims1.test DIAMETER 762 cmd=AARequest(265) flags=RP-- appl=3GPP Rx(16777236) h2h=28fe20b1 e2e=fe338ed9 pcrf.ims1.test -> pcscf.core.ims1.test DIAMETER 198 cmd=AAAnswer(265) flags=-P-- appl=3GPP Rx(16777236) h2h=2 e2e=13 pcscf.core.ims1.test -> 172.25.152.195 SIP 410 Status: 408 Request Timeout (0 bindings) | This is the DIAMETER AAR message: Diameter Protocol Version: 0x01 Length: 696 Flags: 0xc0, Request, Proxyable Command Code: 265 AA ApplicationId: 3GPP Rx (16777236) Hop-by-Hop Identifier: 0x28fe20b1 End-to-End Identifier: 0xfe338ed9 AVP: Session-Id(263) l=40 f=-M- val=pcscf.core.ims1.test;548405219;1 AVP: Origin-Host(264) l=28 f=-M- val=pcscf.core.ims1.test AVP: Origin-Realm(296) l=22 f=-M- val=provider1.test AVP: Auth-Application-Id(258) l=12 f=-M- val=3GPP Rx (16777236) AVP: Vendor-Specific-Application-Id(260) l=32 f=-M- AVP: Destination-Realm(283) l=22 f=-M- val=core.ims1.test AVP: Subscription-Id(443) l=52 f=-M- AVP: Media-Component-Description(517) l=304 f=VM- vnd=TGPP AVP Code: 517 Media-Component-Description AVP Flags: 0xc0 AVP Length: 304 AVP Vendor Id: 3GPP (10415) Media-Component-Description: 00000206c0000010000028af0000000100000207c00000bc... AVP: Media-Component-Number(518) l=16 f=VM- vnd=TGPP val=1 AVP: Media-Sub-Component(519) l=188 f=VM- vnd=TGPP AVP Code: 519 Media-Sub-Component AVP Flags: 0xc0 AVP Length: 188 AVP Vendor Id: 3GPP (10415) Media-Sub-Component: 000001fdc0000010000028af00000001000001fbc0000046... AVP: Flow-Number(509) l=16 f=VM- vnd=TGPP val=1 AVP: Flow-Description(507) l=70 f=VM- vnd=TGPP val=permit out ip from 172.25.152.195 37843 to 127.0.0.1 37843 AVP: Flow-Description(507) l=69 f=VM- vnd=TGPP val=permit in ip from 127.0.0.1 37843 to 172.25.152.195 37843 AVP: Flow-Usage(512) l=16 f=VM- vnd=TGPP val=AF_SIGNALLING (2) AVP: Media-Type(520) l=16 f=VM- vnd=TGPP val=CONTROL (4) AVP: Codec-Data(524) l=28 f=VM- vnd=TGPP val=downlink\noffer\n AVP: Codec-Data(524) l=27 f=VM- vnd=TGPP val=uplink\nanswer\n AVP: Flow-Status(511) l=16 f=VM- vnd=TGPP val=ENABLED (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=CHARGING_CORRELATION_EXCHANGE (1) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_LOSS_OF_BEARER (2) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RECOVERY_OF_BEARER (3) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_RELEASE_OF_BEARER (4) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=INDICATION_OF_ESTABLISHMENT_OF_BEARER (now void) (5) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=IP-CAN_CHANGE (6) AVP: Specific-Action(513) l=16 f=VM- vnd=TGPP val=ACCESS_NETWORK_INFO_REPORT (12) AVP: Framed-IP-Address(8) l=12 f=-M- val=172.25.152.195 AVP: Authorization-Lifetime(291) l=12 f=-M- val=7200 AVP: Auth-Grace-Period(276) l=12 f=-M- val=0 AVP: Session-Timeout(27) l=12 f=-M- val=7200

6 years, 6 months

Problem removing headers from FAILURE_ROUTE

by Joel Serrano

Hi all, I have the following scenario: Client -> Kamailio (adds X-CallSource hdr) -> Media Server -> Kamailio (removes all "X-" headers) -> Carrier Carrier doesn't get any X- headers. All works. Now for example, if the media server replies with a non-OK status, like: Client -> Kamailio (adds X-CallSource hdr) <-> Media Server (480 Temporarily Unavailable) Kamailio (in failure_route, removes all "X-" headers) -> External Voicemail Service External Voicemail Service gets the X- headers. Basically, on the first example, it is a regular call, all handled from request route. On the second example, call goes to media server, media server replies with a 480, reaches kamailio's failure route, in there we run the same remove_hf_re. In the captures I can see that the X-CallSource header (added at the very beginning) is still there. I have tried different combinations in the failure route: a) Tried removing exactly the header: remove_hf("X-CallSource") b) Tried removing any X- header: remove_hf_re("X-") Those didn't work, then I tried: c) append_hf("X-CallSource: Test") remove_hf("X-CallSource") The result was now two X-CallSource headers, the add worked, the remove didn't. I thought maybe "msg_apply_changes()" could help, but it isn't valid inside failure_route. So what is the deal here? Am I doing something completely wrong or is it just that you cannot remove headers (but you can add) in failure route? According to the doc: https://www.kamailio.org/docs/modules/devel/modules/textops.html#textops.f.… -----> This function can be used from ANY_ROUTE. OS: Debian 8 Kamailio: 4.4.5 (installed from deb repo) # kamailio -v version: kamailio 4.4.5 (x86_64/linux) flags: STATS: Off, USE_TCP, USE_TLS, USE_SCTP, TLS_HOOKS, DISABLE_NAGLE, USE_MCAST, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, Q_MALLOC, F_MALLOC, TLSF_MALLOC, DBG_SR_MEMORY, USE_FUTEX, FAST_LOCK-ADAPTIVE_WAIT, USE_DNS_CACHE, USE_DNS_FAILOVER, USE_NAPTR, USE_DST_BLACKLIST, HAVE_RESOLV_RES ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535, DEFAULT PKG_SIZE 8MB poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. id: unknown compiled with gcc 4.9.2 Any suggestions? Thanks Joel.

6 years, 6 months

Re: [SR-Users] Touching Base / Question

by Maxim Sobolev

len = snprintf(cmd->buf_t, sizeof(cmd->buf_t), "%d %lu %lu %lu %lu\n", ttl, pst[0].npkts_in, pst[1].npkts_in, pcnts.nrelayed, pcnts.ndropped) Those are: remaining session TTL in seconds, number of packets received from side A, number of packets received from side B, overall number of packets relayed in both directions (A->B, B->A) for directions, and number of packets dropped due to remote address not being known yet. There is actually a newer version of that command in the RTPproxy, which provides access to these and number of other per-session statistics collected by the analysis code, such as: rtpa_nsent rtpa_nrcvd rtpa_ndups rtpa_nlost rtpa_perrs The command to fetch those is for example: Q[v] %%CALLID%% %%TOTAG%% %%FROMTAG%% rtpa_nsent rtpa_nrcvd rtpa_ndups rtpa_nlost rtpa_perrs Full list is here: https://github.com/sippy/rtpproxy/blob/master/src/rtpp_command_query.c It would be good to get those implemented in the Kamailio as well. I would also probably hook up jitter values into that list. -Max On Mon, Oct 2, 2017 at 10:09 AM, Michael Mavroudis <michael(a)voicetel.com> wrote: > I'm sorry I should had added those details. I'm referring to: > > https://kamailio.org/docs/modules/4.3.x/modules/rtpproxy.html > > <https://kamailio.org/docs/modules/4.3.x/modules/rtpproxy.html> > I found a snippet at: > > http://git.sip-router.org/cgi-bin/gitweb.cgi/sip-router/?a=c > ommitdiff;h=85ee107929a80b54d47eaabef6f25d7b2f0659e7 > > There is 5 values but I'm not sure what they represent. I've also asked > Daniel so you may be hearing for him as well. > > On Sep 29, 2017 3:51 PM, "Maxim Sobolev" <sobomax(a)sippysoft.com> wrote: > >> Hi, Michael, I am not sure about October, have some other travel plans >> that are not very compatible with being in Orlando. With regards to the rtpstat, >> which counters are you using specifically? >> >> -Max >> >> On Thu, Sep 28, 2017 at 12:42 PM, Michael Mavroudis <michael(a)voicetel.com >> > wrote: >> >>> Hi, >>> >>> Hope all is well. Are you going to be in Orlando for Astricon? If not >>> I'm guessing Europe again. >>> >>> I've got a quick question for you? >>> >>> What are the contents of the psuedo var: $rtpstat >>> >>> I started calculating MOS scores and passing them to freeswitch but my >>> calculation isn't quite right. I'm thinking it's because I'm calculating >>> based on the wrong vars. Any help is greatly appreciated. >>> -- >>> Michael J. Mavroudis >>> >>> [image: VoiceTel] <http://goo.gl/yXuqFz> >>> >>> 630 Fifth Avenue >>> <https://maps.google.com/?q=630+Fifth+Avenue+New+York,+NY+10111&entry=gmail&…> >>> New York, NY 10111 >>> <https://maps.google.com/?q=630+Fifth+Avenue+New+York,+NY+10111&entry=gmail&…> >>> >>> M: (917) 426-9000 >>> W: (212) 942-7400 >>> >> >> >> >> -- >> Maksym Sobolyev >> Sippy Software, Inc. >> Internet Telephony (VoIP) Experts >> Tel (Canada): +1-778-783-0474 <%28778%29%20783-0474> >> Tel (Toll-Free): +1-855-747-7779 <%28855%29%20747-7779> >> Fax: +1-866-857-6942 <%28866%29%20857-6942> >> Web: http://www.sippysoft.com >> MSN: sales(a)sippysoft.com >> Skype: SippySoft >> > -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts Tel (Canada): +1-778-783-0474 Tel (Toll-Free): +1-855-747-7779 Fax: +1-866-857-6942 Web: http://www.sippysoft.com MSN: sales(a)sippysoft.com Skype: SippySoft

6 years, 6 months

Development for Kamailio v5.1 series is frozen

by Daniel-Constantin Mierla

Hello, short note to mark the freezing of development for Kamailio v5.1 series. For few weeks, please do not push new features in the master branch. Once the branch 5.1 is created (expected to happen in 3-4 weeks from now), the master branch becomes again open for new feature. Meanwhile the focus has to be on testing current code. Work on related tools (e.g., kamctl) or documentation can still be done as well as getting the new modules in 5.1 in good shape, plus adding exports to kemi interface (which should not interfere with old code). The entire testing phase is expected to be 4 to 6 weeks, then the release of v5.1.0 -- likely by end of November should be out. Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training, Nov 13-15, 2017, in Berlin - www.asipto.com Kamailio World Conference - www.kamailioworld.com

6 years, 6 months

Roadmap to Kamailio v5.1

by Daniel-Constantin Mierla

Hello, being discussed at the previous IRC devel meeting before the summer, it's time to plan the preparation for next major release, respectively Kamailio 5.1 series. As an initial proposal, a timeline can be: - Mon, Oct 16, 2017 - freeze the development - in 3-4 weeks after that, create the branch 5.1 - 2-3 weeks after, do the release of v5.1.0 That means more or less by end of November we will have first version of 5.1 series. There are still 4 weeks of development, hopefully enough to get ongoing work finished. I know from github tracker that there are people working on redis support for usrloc. I will focus on exporting more functions to kemi, right now should be around 60%, by freeze should be more than 80% (likely that means all of what most of people use these days, because there are some modules that I guess are not much used). Maybe one or two modules will be pushed as well from my side. I think we should also do an IRC devel meeting to try to sync better on this. Maybe by mid of next week, I will send another email shortly. Should anyone have more details to add or adjust the proposal, do not hesitate to reply to mailing list! Cheers, Daniel -- Daniel-Constantin Mierla www.twitter.com/miconda -- www.linkedin.com/in/miconda Kamailio Advanced Training - www.asipto.com Kamailio World Conference - www.kamailioworld.com

6 years, 6 months

Having kamailio bind to a VRF device

by George Diamantopoulos

Hello, I have a use case where I need to have kamailio bind to a VRF device. The configuration in question is similar to the example below, where eth1 is a slave to the VRF-lite device: +----------+ +-------------------+ | eth0 | | vrf-green | | 1.1.1.1 | | 127.0.0.1 | +----------+ +-------------------+ | +----------+ | eth1 | | 2.2.2.2 | +----------+ Both the main routing table and "vrf-green" routing table have a default route. What I need to be able to do is have kamailio bind to both interfaces: listen=eth0:5060 listen=vrf-green:5060 And additionally be able to use force_send_socket to select an interface, for example: force_send_socket(udp:2.2.2.2:5060); However, I can't get this to work. The above configuration fails because there is no listen directive for 2.2.2.2. Also, kamailio doesn't process packets received on the VRF with the above listen directives, it behaves as if it doesn't listen on 2.2.2.2 indeed. In addition using either of the below: listen=udp:2.2.2.2:5060 or listen=eth1:5060 fails with an error upon starting kamailio. According to the kernel documentation: Applications that are to work within a VRF need to bind their socket to the VRF device: setsockopt(sd, SOL_SOCKET, SO_BINDTODEVICE, dev, strlen(dev)+1); or to specify the output device using cmsg and IP_PKTINFO. The question is, is VRF useable with kamailio right now? Or is development needed? Thanks! BR, George

6 years, 6 months

rtcp-mux policy for RTPengine module

by Yuriy Gorlichenko

Hi all! Some time ago Chromium browser sets rtcpMuxPolicy: required by default (soon on Chrome 58) It means that webRTC based clients not accepts a=rtcp:31757 And uses for RTP and RTCP multiplexing at one port Main trouble that i found: calls between original SIP client and webRTC client (SIP client is initiator of call) When sip client sends invite it has a=rtcp:33445 Means it wants 2 different prots for RTCP and RTP As expected for this case webRTC client says 488 Not accessible here instead of 200 resonse I suppose rtpengine module should hept to handle it but i can not find any key how to do it I added form rtpengine_manage() rtcp-mux-offer and rtcp-mux-accept but it only adds "a=rtcp-mux" But not removes a=rtcp and ice cadidate prepeared for it. Suppose removing a=rtcp:12345 will gives just an issue for RTP session. Does rtpengine module have some keys for resole this issue?

6 years, 6 months

It does not log any route. Clean installation

by Bruno Henrique Gomes Gouvêa

Hello, I am doing some tests with version 4.2.3 (installed of RPM centos 7 packages) in a clean installation, I have a kamailio running in production already configured and working, but I would like to start a totally clean configuration to learn more about kamailio. I am using the configuration file that comes in the default installation (kamailio-basic.cfg) just by adding a log on the main route. I kept the log in messages file and increased the verbosity as below, and when i send any package (INVITE or REGISTER) I assume that the log or xlog lines should be displayed in file, but no. I see the packets arriving via tcpdump, and netstat shows that port 5060 is being listened by kamailio, but I have nothing else besides the initialization information (and the debug of MYSQL querys when activated unrelated to INVITE or REGISTRY packets). Am I doing something wrong? *Configs **Log :* ### LOG Levels: 3 = DBG, 2 = INFO, 1 = NOTICE, 0 = WARN, -1 = ERR #! ifdef WITH_DEBUG debug = 4 log_stderror = no #! else debug = 4 log_stderror = no #! endif memdbg = 5 memlog = 5 log_facility = LOG_LOCAL0 *Main route log test:* request_route { log ("Log main request TEST"); xlog ("Log main request TEST 2"); # not displayed route (REQINIT); */var/log/messages:* Oct 5 23:39:12 pabxmodelo kamailio: Stopping kamailio: [ OK ] Oct 5 23:39:12 pabxmodelo systemd: Starting SYSV: Kamailio is a fast, reliable and flexible SIP Server.... Oct 5 23:39:13 pabxmodelo kamailio: INFO: <core> [tcp_main.c:4745]: init_tcp(): using epoll_lt as the io watch method (auto detected) Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: rr [../outbound/api.h:54]: ob_load_api(): Failed to import bind_ob Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: rr [rr_mod.c:160]: mod_init(): outbound module not available Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: usrloc [hslot.c:53]: ul_init_locks(): locks array size 1024 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:175]: probe_max_receive_buffer(): SO_RCVBUF is initially 212992 Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30050]: INFO: <core> [udp_server.c:225]: probe_max_receive_buffer(): SO_RCVBUF is finally 425984 Oct 5 23:39:13 pabxmodelo kamailio: Starting kamailio: Oct 5 23:39:13 pabxmodelo /usr/sbin/kamailio[30070]: INFO: ctl [io_listener.c:225]: io_listen_loop(): io_listen_loop: using epoll_lt io watch method (config) Oct 5 23:39:13 pabxmodelo systemd: Started SYSV: Kamailio is a fast, reliable and flexible SIP Server.. Oct 5 23:39:13 pabxmodelo kamailio: [ OK ] -------------------------------------------- Bruno H. G. Gouvêa ---

6 years, 6 months

Re: [SR-Users] DIAMETER over SCTP for Rx and Cx Interfaces

by Carsten Bock

Hi, I am working on an update, to support SCTP for the CDP module. At the moment, I have an incomplete prototype, which binds to the Kamailio sockets (so any protocol Kamailio supports) to send/receive Diameter messages. I plan to finish it after my holiday, so I might have a full working prototype for TADsummit in Lisbon mid November. Thanks, Carsten Am 13.10.2017 14:00 schrieb "Ron McLeod" <ron.kamailio(a)mcleodnet.com>: I would like to connect Kamailio to a PCRF (Rx interface) and HSS (Cx interface) using DIAMETER over SCTP. Is this currently supported? If it is, are there any notes on how to configure this? If not, and there are plans to develop this, I would like to get involved in testing. Thanks. _______________________________________________ Kamailio (SER) - Users Mailing List sr-users(a)lists.kamailio.org https://lists.kamailio.org/cgi-bin/mailman/listinfo/sr-users

6 years, 6 months

← Newer
1
...
4
5
6
7
8
9
10
11
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 October 2017