sr-users

sr-users@lists.kamailio.org

42 participants
37517 discussions

Doubt parsing multipart SDP
by Albert Petit 03 Apr '17

03 Apr '17

Hi list, I am having some issues parsing multipart INVITE [1] when calling force_rtp_proxy . I tried to upgrade to Kamailio 5 to see if maybe i was using too old code but seems not the case. Log of error is: Apr 3 18:31:21 mcptt /usr/sbin/kamailio[3232]: INFO: <script>: forcing RTP proxy for INVITE message Apr 3 18:31:21 mcptt /usr/sbin/kamailio[3232]: ERROR: <core> [core/parser/parse_content.c:370]: decode_mime_type(): ERROR:decode_mime_type: parse error near in [application/vnd.3gpp.mcptt-info+xml] char[51][3] offset=16 So seems there is some issue using Content Type application/vnd.3gpp.mcptt-info+xml in a multipart SIP message But this content type is accepted at following 3GPP spec: http://www.etsi.org/deliver/etsi_ts/129100_129199/129165/13.06.00_60/ts_129… Checking implementation of parse_content.c I see ". - _ +" characters are accepted so i am not sure what is failing. I did some test and if instead of that Content-Type: application/vnd.3gpp.mcptt-info+xml i use Content-Type: application/mcptt no errors are seen in Kamailio logs and ports are replaced succesfully. So do you see something wrong on what i am doing with attached info? INVITE sip:mcpttparticipating@demo.net SIP/2.0 Record-Route: <sip:10.1.1.123:6074;transport=tcp;lr=on;ftag=i3b01a;nat=yes> Call-ID: db6b10362447354bc9819df9a9046ecb(a)10.1.1.222 CSeq: 1 INVITE From: <sip:blue1@demo.net>;tag=i3b01a To: <sip:ccw@demo.net;poc-group=blues> Via: SIP/2.0/TCP 10.1.1.123:6074 ;branch=z9hG4bK15a9.1c063dec40e772152f44c026a1627082.0;i=f Via: SIP/2.0/TCP 10.1.1.222:5070 ;received=10.1.1.222;rport=55173;branch=z9hG4bK-363135-1750dc6e97437e4788f446f2d818b60a Max-Forwards: 69 Contact: <sip:blue1@10.1.1.222:55173 >;transport=tcp;+g.3gpp.mcptt;+g.3gpp.icsi-ref="urn%3Aurn-7%3A3gpp-service.ims.icsi.mcptt";isfocus Accept-Contact: *;+g.3gpp.mcptt;require;explicit Accept-Contact: *;+g.3gpp.icsi-ref="urn:urn-7:3gpp-service.ims.icsi.mcptt";require;explicit P-Preferred-Service: urn:urn-7:3gpp-service.ims.icsi.mcptt P-Preferred-Identity: <sip:blue1@demo.net> User-Agent: PoC-client/3GPP-Rel13 DemoClient/v2.03.01/BV6000/SDK23 Session-Expires: 3600 Min-SE: 90 Supported: replaces, 100rel, timer, norefersub, timer, answermode, eventlist Resource-Priority: mcpttp.5 Content-Type: multipart/mixed;boundary=gnkboundary Content-Length: 997 --gnkboundary Content-Type: application/sdp v=0 o=- 3626700268 3626700268 IN IP4 10.1.1.222 s=spimedia c=IN IP4 10.1.1.222 t=0 0 a=X-nat:0 m=audio 10002 RTP/AVP 106 a=rtcp:10003 IN IP4 10.1.1.222 i=speech a=rtpmap:106 AMR-WB/16000 a=fmtp:106 mode-change-period=1; mode-change-capability=2; mode-change-neighbor=0; max-red=0 a=sendrecv a=ptime:100 a=maxptime:400 m=application 10003 udp MCPTT a=fmtp:MCPTT mc_queueing;mc_priority=1 --gnkboundary Content-Type: application/vnd.3gpp.mcptt-info+xml <?xml version="1.0" encoding="UTF-8"?> <mcpttinfo xmlns="urn:3gpp:ns:mcpttInfo:1.0" xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance"> <mcptt-Params> <session-type>chat</session-type> <mcptt-request-uri type="Normal"> <mcpttURI>sip:ccw@demo.net;poc-group=blues</mcpttURI> </mcptt-request-uri> <mcptt-client-id type="Normal"> <mcpttURI>urn:uuid:00000000-0000-1000-8000-AABBCCDDEEFF</mcpttURI> </mcptt-client-id> </mcptt-Params> </mcpttinfo> --gnkboundary-- Thanks! Albert

2 1

Doubt about MI Datagram module in Kamailio 5
by Albert Petit 03 Apr '17

03 Apr '17

Dear list, I've recently upgraded to Kamailio 5 in order to avoid issue parsing SDP multipart bodies which think are fixed in the update ( - symbol rejected in content type) . I could upgrade without issues from my kamailio 4 dev deployment but i cannot load anymore MI_Datagram module (seems not present in Kamailio 5 , MI Datagram module i refer to: http://www.kamailio.org/docs/modules/4.3.x/modules/mi_datagram.html ) Can i use MI Datagram module still in Kamailio 5 ? Thanks Albert

3 3

Exclusive: Quitting the fast life of open-source SIP
by Alex Balashov 03 Apr '17

03 Apr '17

(Filed by UC Celeb Talk - 1 Apr 2017.) BERLIN (Tegel), GERMANY--In the now-infamous breakdown episode on the VIP tarmac at Berlin's Tegel Airport, Alex Balashov shocked the IP telecoms celebrity world last month. Shielding his eyes from the punishingly bright daylight of an overcast day in northern Germany, Balashov climbed out of his Gulfstream G650 jet, clutching a half-finished bottle of Woodford Reserve, and announced his sudden retirement from the "fast life" of open-source SIP consulting to a waiting gathering of techn business reporters. "I'm not with this 'live fast, die young' VoIP s*** anymore," he reportedly shouted, before collapsing and vomiting profusely on the red carpet. UC Celeb Talk's own Benjamin Brant sat down with Balashov in an exclusive interview to learn more about what happened, even as the telecoms industry continues to digest the shock meltdown. -- BRANT: Everyone's dying to know, what was going through you head at that moment? BALASHOV: Funny how you mention dying. I want to live to see 35, man. I can't handle the SIP biz anymore. BRANT: What do you mean? You seemed to have all the makings of an open-source SIP superstar. BALASHOV: I can't keep up with the drinks anymore, the three day-long parties, the paparazzi, always watchin' my back at ClueCon... BRANT: When'd you realise it might be time to call it? BALASHOV: I'll tell you when. It was Kamailio World '16. Man, those vodka + Club Mate drinks they pour down at Fokus are something else. They'll really get you thinking about things. BRANT: So you had a cocktail and thought better of your entire life as a SIP celebrity? The fans, the adulation, the glory? BALASHOV: When you wake up at 3 PM at the Park Inn on Alexanderplatz with a $31,000 room service bill on your AMEX, a goat wandering around, and reporters in your face, you tell me with a straight face you're not gonna take stock of your life and make some changes. BRANT: That really happened? BALASHOV: That's what I'm trying to tell you! That's Kamailio World, dude. That's the SIP software engineering culture. You wanna ITSP and WebRTC? You're gonna have to bro down! BRANT: Surely not everywhere. What about the IETF? BALASHOV: Those guys drink more than ANYONE. Have you seen the SIP Outbound RFC? BRANT: That's the work-product of an alcohol-fuelled creative orgy? BALASHOV: It's the work product of something-something. I don't know if I'm allowed to identify the uh, substance in question. BRANT: How are you going to live without the private jet? If I had a G6, I wouldn't just turn over the keys. BALASHOV: Yeah, I mean, open-source VoIP consulting has its upsides. It's a fine way to make a living. But it's just not worth it. Besides, hourly operating costs are through the roof. BRANT: But you were an icon, and quite a ladies' man too! How do you walk away from that? BALASHOV: Look man, of course women are gonna mob you when you're a SIP consulting star. That's just part of the open-source tech life in general. But it's fake, man. They don't love you. They don't want to know who you are inside. They just want you 'cause you know all about the SIP transaction state machine, loose vs. strict routing, cross-compiling Kamailio. They just got a crush on you 'cause you know presence and parallel forking race conditions. I want something real. BRANT: But that's part of the social bargain of being an open-source SIP celebrity. Didn't you once boast of having uh, lady friends, "in different geographic and non-geographic operator codes"? BALASHOV: Yeah, and that's cool, but I want to come home to a woman who loves me for me, not Mr. 3... ... 02, Moved Temporarily, but not happy necessarily. Feel me? BRANT: What happened at ClueCon? BALASHOV: You talking about the bullets Acme Packet ventilated me with? BRANT: Five of them, as I heard. BALASHOV: Well I'm still standin'. Took those shots and smiled. BRANT: I know you guys have a kind of omertà about this stuff, but I've got to ask: why? BALASHOV: I ain't worried, kids growing up in today's world need to learn the truth. They act like I was dealing transcoding licences on their block. O.G. 729. BRANT: But that wasn't what gave you a wake-up call that the SIP game is sharper than a razor blade? BALASHOV: Hell no, it wasn't their block. That fake-ass east coast channel partner crew can cash me outside howboudah? BRANT: How exclusive is Kamailio World? BALASHOV: It's one of the most exclusive clubs I've ever hit up. Lines wrapping around blocks. And the bouncers. Damn. BRANT: The bouncers? BALASHOV: Those dudes are harsh. BRANT: On a scale of 1 to Berghain, how bad is it? BALASHOV: All I know is, one time some squirrely guy in the audience asked a moderately new-blood question like, "If a Record-Route header has been added by an intermediate proxy, is it proper of a SIP User Agent to populate the Request URI of subsequent in-dialog requests with the Record-Route URI, or should it be the remote Contact?" Half the room got up like it was ready to curb-stomp that little face. Guy didn't know what he got himself into--a room full of elites. BRANT: So what happened? BALASHOV: Someone was like, "Bounce this fool! He don't know how to act." So these three muscular Kaiser Wilhelm-looking dudes--moustaches and all--in sunglasses roll up and drag this guy through the Atrium, out the doors and dump him straight out onto Anna-Louisa-Karsch-Straße. BRANT: Damn. Ejected out of the saloon. BALASHOV: Yo, that dude was dismissed from the premises. BRANT: So what do you see in your future post-SIP life? BALASHOV: I'm thinking about starting a bakery. A friend threw it out there as a way to kind of atone for all this and get straight with Jesus. Gonna bake really big cookies. You know, huge ones, like a small pizzas? But recognise--they're actually cookies. BRANT: Got any advice for those who bright young upstarts who haven't turned over a new leaf and thrown in the towel yet? BALASHOV: Come on down to Kamailio World #5, May 8-10 2017 in Berlin. You'll see your life in a new way. Registration and more information online at https://www.kamailioworld.com/k05/

2 1

Kamailio 6.0 architecture
by Olle E. Johansson 03 Apr '17

03 Apr '17

Dear Kamailians! We got news for you! The Kamailio 6.0 architecture is finalised! It's something we've been working on for a long time in the project team and you've already seen part of it in the recent Kamailio 5 release - the KEMI interface for LUA. We've realised that we have too many modules, especially all those IMS* modules. And the core is getting slimmer and slimmer. This is what we're going to do: * All RPC, EVENTAPI,AUTH, JSON, TM, HTTP_CLIENT and TLS modules will be integrated back into the core. * The EVENT API will be the core API for external modules * The rest of the functionality in the modules will have to be rewritten in LUA and maintained as separate GITHUB projects outside of the core After successfully integrating LUA into the heart of Kamailio and exposing the Kamailio API we have decided to make life more simple for the core maintainers. Maintaining well over 100 modules took too much time, and who cares about some of the stuff? Billing, least cost routing and all the other crazy stuff in modules are going away anyhow as all services will be free. Calls really wants to be free. And presence is no longer needed, we'll just tap into the mobile phones from the core to know where everyone is. The removal of the modules will take place during the month of April 2017 and a new core will raise like a Fenix from the ashes, a much larger, monolithic and complex core with new functionality that will take Kamailio to new areas, like a message bus for games, an API server for mobile yoga apps and a control plane for embedded IoT devices. "Kamailio everywhere" is the new slogan for the Kamailio project. - "We will all remember April 1st 2017 as a new start of the project" says Olle-Carsten Mierla, the new elected project leader. "From now on, Kamailio aims to be a standard part of every operating system distribution, defining the new core of the Internet.” We hope all of you join us in this effort and refrain from reporting any bugs or other disturbing issues while we rebuild the new Kamailio. /O

3 2

Re: [SR-Users] Exclusive: Quitting the fast life of open-source
by JR Richardson 01 Apr '17

01 Apr '17

Brilliant! Bravo! Bravo! Brovo! Gonna miss you Bro! Get in this neck of the woods, got some dope a$$ hooch and BBQ waitin! Peace out! JR Richardson Engineering for the Masses Chasing the Azeotrope ---------------------------------------------------------------------- Message: 1 Date: Sat, 1 Apr 2017 01:02:58 -0400 From: Alex Balashov <abalashov(a)evaristesys.com> To: sr-users(a)lists.sip-router.org Subject: [SR-Users] Exclusive: Quitting the fast life of open-source SIP BRANT: But you were an icon, and quite a ladies' man too! How do you walk away from that? BALASHOV: Look man, of course women are gonna mob you when you're a SIP consulting star. That's just part of the open-source tech life in general. But it's fake, man. They don't love you. They don't want to know who you are inside. They just want you 'cause you know all about the SIP transaction state machine, loose vs. strict routing, cross-compiling Kamailio. They just got a crush on you 'cause you know presence and parallel forking race conditions. I want something real. BRANT: But that's part of the social bargain of being an open-source SIP celebrity. Didn't you once boast of having uh, lady friends, "in different geographic and non-geographic operator codes"? BALASHOV: Yeah, and that's cool, but I want to come home to a woman who loves me for me, not Mr. 3... ... 02, Moved Temporarily, but not happy necessarily. Feel me?

1 0

Configuring Kamailio as a "VoIP traffic reflector"
by Tahiro Hashizume 31 Mar '17

31 Mar '17

Hi there, This e-mail is going to be lengthy and I hope you will not get frustrated (like I am, for different reasons described later) by reading it all from the beginning to the end since I have just warned you :P You have absolutely no need for reading the entire post unless you are crazy enough read about what I do for fun in given circumstances. Basically, I would like Kamailio and Asterisk to run on the same box in such a way that A.)Asterisk listens on eth0 (on 10.1.1.15/24 with ProxyARP enabled) for incoming SIP register requests from VoIP-ATAs B.)Kamailio listens on five IP addresses on dummyN which has 10.1.1.1N/32 (N=0-4, so dummy0 has 10.1.1.10/32, for example) making five SIP+RTP sessions to the same remote host to appear as if they are from five different hosts - so that a single instance of Asterisk running on debian may be registered (through Kamailio) on the same remote host by using five different accounts and source IP addresses. I know Asterisk alone cannot do this (even by running multiple instances of it) and that there have to be five instances of both SIP-Proxy and RTP-Proxy so that the source address can be literally spoofed. Should be simple, but so far cannot find good sources of reference. I need your advice. Thanks in advance. << Backgrounds - read only if you are curious >> The so-called frustration is when your needs are not realized due to technological limitations. I have years worth of frustration on the VoIP setup at home and that's totally NOT your fault. Written below for those who happen to be curious should sound interesting, so here is the situation I'm facing; I'm in Japan and our infrastructure is well within the definition of NGN which in my case includes a low-latency VoIP to replace the traditional PSTN. (NTT will end ISDN in 2020, copper-line PSTN in 2025, as announced so far.) The service is provided by NTT (former state-run telecom) of Japan and works on FTTH which carries: a.)PPPoE for those who wish to get IPv4&IPv6 connectivity - which for the most part is so that users get to choose their favorite ISP. b.)WAN-reachable IPv6 traffic c.)WAN-unreachable IPv4 for SIP based services (address blocks reserved and announced by AS9595) Given the fact that b.) and c.) are only applicable (optionally and respectively) to those who signed up for the native-IPv6 (we call it IPoE, oddly) service and to those who signed up for the VoIP service, it's essentially an L2 transport service for PPPoE to your ISP - very much like the way we had our phone-line and ISP (dial-up) separately signed up for in the old days (hence I call it the access-line service). I've made a switch over to VoIP-based PSTN from the copper-line in April 2011 after seeing that copper-line PSTN served no better in case of emergency like 3.11 when people want to call others to see if their loved one are okay - on the evening through the night of March 11 2011, our traditional PSTN stayed at its capacity limits while VoIP-based means of communication (incl. Skype, surprisingly) stayed intact. That was the wake-up call. Now, upon signing up for the VoIP service, the user receives a box so called HGW (stands for Home Gateway) which is very much a SIP+RTP UA on its WAN side and SIP+RTP server on LAN side (up to 5 UAs may register if the UA supports "sip session-timer"). And this HGW is being the pain that drove me to writing this e-mail - it only allows one SIP-register per IP address. Further, looking into the specs requirements for HGW published by NTT (=there's a centralized documentation for it since the designs and manufacturing of HGW is split across several companies), there's a part which basically says: "One SIP register to HGW from a UA on LAN should be able to handle (but not limited to) one data session. An UA on HGW's LAN side may support multiple-data session per SIP register(optional)." - which to me reasonably explains why my HGW only allows one SIP-register per IP address. My gyess is that the unwritten assumption here is "one sip register"="one physical phone", which is quite understandable. Regarding the fact that NTT optionally provides services like: 1.)additional phone numbers 2.)multi-data sessions(RTP for voice, for example) ...on one trunk. This, and also in accordance with the technical specs. requirements for HGW above means supporting multiple RTP sessions either terminated or originated by an Asterisk box which sits on the HGW's LAN side requires that a single instance of Asterisk on a debian box somehow uses multiple IP addresses (with or without the use of other software). The simplest way of doing this (to me) seemd like running five instances of RTP(proxy)+SIP(proxy) which will each listen on one of five IP addresses, to which the Asterisk instance in question could establish one session of SIP+RTP each. The idea seemed simple enough, but there did not seem like good selections of software years ago. I have once given up on the implementation years ago, altered the NTT-supplied HGW with a third-party product (NVR500 by YAMAHA which on its LAN behaves as a MGCP+RTP server) in order to maximize the stability of the phone system. This was due to the fact that the x86-box I was using was hardware-unstable and that the HGW's behavior was something I did not like dealing with (recently solved). I've decided to make a come-back to Asterisk recently since I recently started using hylafax running on a RasPi with RS232 modem hooked up to it but with missing support for CID since the Japanese equivalent of CID (we call it Number-Display) does not follow the Bellcore standards and the modem I use only supports Bellcore standards- going VoIP again and running iaxmodem could solve this issue. -------------------------------------------- Tahiro Hashizume Department of Electrical and Electronic Engineering at Tokyo Denki University 5 Senju-Asahi-cho Adachi-ku Tokyo, JP1208551 Japan --------------------------------------------

2 4

[SIP Transaction] Handle Cancel message
by Hai Bui Duc Ha 31 Mar '17

31 Mar '17

Hi all, I have problem when use module pusher on Kazoo. The user after receive call from pusher can not receive the Cancel message if have another people pick up this phone. I trace log and debug on Kamailio and see the Freeswitch sent Cancel message but Kamailio reply 481 - Call leg/transaction does not exist. The configure on Kamailio: default.cfg ======================================================= *route[PREPARE_INITIAL_REQUESTS]* *{* * if (is_method("CANCEL")) {* * if(t_lookup_cancel()) xlog("L_INFO","$ci|log|======== t_lookup_cancel()");* * xlog("L_INFO","$rm from $fu (IP:$si:$sp) ---CAPTURED IN MAIN---\n");* * if (t_check_trans()) {* * xlog("L_INFO","$rm from $fu (IP:$si:$sp) ---CHECK TRANS TRUE---\n");* * //xlog("L_INFO", "$ci|log|====================================");* * route(RELAY);* * } else {* * xlog("L_INFO","$rm from $fu (IP:$si:$sp) ---CHECK TRANS FALSE---\n");* * sl_send_reply("481", "Call leg/transaction does not exist");* * }* * exit();* * } else if (is_method("ACK")) {* * if (t_check_trans()) {* * route(RELAY);* * }* * exit();* * }* ======================================================= As I read on http://kamailio.org/docs/modules/4.3.x/modules/tm.html#tm.f.t_check_trans Kamailio see the cancel message not same the transaction INVITE message. INVITE message: ------------------------------------------------------------------------ INVITE sip:100@quydang.htk.cvoice SIP/2.0 Via: SIP/2.0/UDP 192.168.1.77:11000;rport;branch=z9hG4bKK9jyp8mXUZHgS Route: <sip:192.168.1.77:5060> Max-Forwards: 49 From: "02 quy" <sip:102@quydang.htk.cvoice>;tag=04K2SappeyDtj To: <sip:100@quydang.htk.cvoice> Call-ID: 19fa9228-ef95-11e6-b473-1f645951fd7b CSeq: 103030653 INVITE Contact: <sip:mod_sofia@192.168.1.77:11000> User-Agent: Anttel Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE Supported: path, replaces Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer Content-Type: application/sdp Content-Disposition: session Content-Length: 247 X-AUTH-IP: 192.168.1.141 X-AUTH-PORT: 64799 X-KAZOO-AOR: sip:100@quydang.htk.cvoice X-KAZOO-PUSHER-Token-Proxy: sip:192.168.1.77:5060 X-KAZOO-PUSHER-Token-ID: 803F0D6610AC5979C6F0513A3A4BE62E0BAF1530DC7A98C2C0DC13D784585FBE X-KAZOO-PUSHER-Token-Type: apple X-KAZOO-PUSHER-Token-App: com.htkinc X-FS-Support: update_display,send_info Remote-Party-ID: "02 quy" <sip:102@quydang.htk.cvoice >;party=calling;screen=yes;privacy=off v=0 o=FreeSWITCH 1486708670 1486708671 IN IP4 192.168.1.77 s=FreeSWITCH c=IN IP4 192.168.1.77 t=0 0 m=audio 24764 RTP/AVP 0 8 101 13 a=rtpmap:0 PCMU/8000 a=rtpmap:8 PCMA/8000 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-16 a=ptime:20 ------------------------------------------------------------------------ CANCEL message: ------------------------------------------------------------------------ CANCEL sip:100@quydang.htk.cvoice SIP/2.0 Via: SIP/2.0/UDP 192.168.1.77:11000;rport;branch=z9hG4bKK9jyp8mXUZHgS Route: <sip:192.168.1.77:5060> Max-Forwards: 49 From: "02 quy" <sip:102@quydang.htk.cvoice>;tag=04K2SappeyDtj To: <sip:100@quydang.htk.cvoice> Call-ID: 19fa9228-ef95-11e6-b473-1f645951fd7b CSeq: 103030653 CANCEL Reason: SIP;cause=200;text="Call completed elsewhere" Content-Length: 0 ------------------------------------------------------------------------ How can I know it same transaction ? We have any idea to solve this problem ? Thank for advice ! Regards, Hai Bui -- Hai Bui VoIP engineer, Cvoice team, HTK-HCM Office Mobile: +84-165-618-9876

2 9

$hep(dst_ip)
by David Villasmil 30 Mar '17

30 Mar '17

Hello guys, the merged https://github.com/kamailio/kamailio/pull/995 is not available on 5.0 and I'm wondering if/when it will be added to 5.0? Regards, David Villasmil email: david.villasmil.work(a)gmail.com phone: +34669448337 ᐧ

3 6

Adding two time prefix to $rU
by Yebe diomande Keffa 29 Mar '17

29 Mar '17

Hello I am new with kamailio, and trying to add prefix to Request URI ($rU). I use branch_route, for $rU=”prefix”+$rU, i got two time prefix adding => prefix_prefix_original$rU This is my code small code: request_route { if (is_method("INVITE")) { $var(ip1)="51.254.245.58"; $var(port1)="33"; if(!t_is_set("branch_route")) route(FWD); xlog("L_ALERT","Route FWD is executed from ip:$si to ip:$rd \n"); } exit; } route[FWD] { t_on_branch("CHECK"); t_relay(); } branch_route[CHECK] { $rd=$var(ip1); $rU=$var(port1)+$rU; xlog("L_ALERT","dst rewrited: $rU \n"); } LOG FILES : Mar 28 19:34:45 ns3033789 systemd[1]: Started LSB: Start the Kamailio SIP proxy server. Mar 28 19:34:54 ns3033789 /usr/sbin/kamailio[2859]: ALERT: <script>: dst rewrited: 3322508983432 Mar 28 19:34:54 ns3033789 /usr/sbin/kamailio[2859]: ALERT: <script>: Route FWD is executed from ip:51.254.245.57 to ip:5.135.177.203 Mar 28 19:34:54 ns3033789 /usr/sbin/kamailio[2859]: ALERT: <script>: dst rewrited: 333322508983432 Mar 28 19:34:54 ns3033789 /usr/sbin/kamailio[2859]: ALERT: <script>: Route FWD is executed from ip:5.135.177.203 to ip:51.254.245.58 Mar 28 19:35:01 ns3033789 CRON[2915]: (root) CMD (/usr/local/rtm/bin/rtm 8 > /dev/null 2> /dev/null) ^C root@ns3033789:~# May someone advise me Thank you in advance

2 1

log_custom module question
by Anonim Stefan 29 Mar '17

29 Mar '17

Hi, I'm trying some logging via UDP, using log_custom module. I've noticed that the logs are always sent through the first interface in the config "listen=" rows. Now, is there a way to listen on that interface, in order to log_udp() on it, without being able to send/receive any SIP on it? (i.e. disabling SIP capability and use it only for logging via UDP) Thank you, Stefan

2 1

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