September 2011 - sr-users

Re: [SR-Users] Kamailio + rtpproxy talking to multiple carrier gateways
by Sarat C. Vemuri 05 Sep '11

05 Sep '11

Alex, Sorry about this clumsy way of replying, but I am stuck with Outlook 2010 and Exchange. You stated the problem correctly. Carrier GWs (UAS) and internal clients (UAC) cannot reach each other directly (TCP/UDP). They have to go through Kamailio and rtpproxy. I am goint to reply to Ovidiu as well with some more details. Thanks SV. ------------------------------ Message: 2 Date: Sat, 03 Sep 2011 19:12:38 -0400 From: Alex Balashov <abalashov(a)evaristesys.com> Subject: Re: [SR-Users] Kamailio + rtpproxy talking to multiple carrier gateways - some via Firewall/NAT To: sr-users(a)lists.sip-router.org Message-ID: <4E62B466.20808(a)evaristesys.com> Content-Type: text/plain; charset=windows-1252; format=flowed On 09/03/2011 05:53 PM, Sarat C. Vemuri wrote: > 3.Using request_route_preset(?publicIP?) > > The above ?mostly? works. By that I mean, the INVITE transaction is > properly passed between internal UAS and carrier SBC and the call is > setup. However, further transactions (BYE/re-INVITE) etc do not work > properly. So, far-end hangups are not working etc. So in other words, there is no interface to which Kamailio could be bound on a network that both the UAC and the UAS have direct network and transport-layer reachability to? If I understand correctly, it sounds like the fundamental problem here is that the Record-Route URI introduced by the proxy in handling the initial INVITE request has to be conserved in all subsequent requests and replies. It is a requirement to use the same route set in sequential (in-dialog) requests such as reinvites or BYEs. It is also mandatory for the UAS to copy the received Record-Route into the final reply (i.e. 200 OK). The problem is that you then have to choose the network address in the Record-Route. If either the UAC or the UAS cannot directly reach it, your problem arises. Is this an accurate statement of the problem? I wanted to verify before continuing. -- Alex Balashov - Principal Evariste Systems LLC 260 Peachtree Street NW Suite 2200 Atlanta, GA 30303 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

1 0

SIP Analysis & Testing tools
by Vladimir Broz 05 Sep '11

05 Sep '11

Hi, for sake of Vaclav's courage, let me introduce the "SIP Analysis & Testing tools". This is a set of very powerful utilities that may help you to do SIP call flows analysis. It can do SIP dialogs and transactions matching and analysis in large pcaps, create pretty call flow diagrams, check and verify SIP message content (headers, parameters,..) and many more.... It's available on: https://github.com/vkubart/sipat For more details, please ask Vaclav Kubart (vaclav.kubart(a)iptel.org) SIP Analysis & Testing tools ============================ This project offers set of tools for testing SIP. Dependencies (ubuntu packages) ============ libosip2-dev libpcap-dev libxml2-dev xsltproc cfanal ====== Call flow analyzer able to draw call flows from PCAP and verify callflows against given definition. Usage: cfanal -r captured-traffic.pcap -a 10.38.14.73=uac -a 10.38.14.74:5062=uas -print-cf drawing.cf cf2svg drawing.cf drawing.svg svg2png drawing.svg drawing.png callflow_diagrams ================= XSL template for painting call flow diagrams. ..... Thank you Vaclav a lot! -Vlada

4 4

question
by Allen D. Ford 05 Sep '11

05 Sep '11

Where are the instructions for this gui Im trying to setup a sip load balancer and rtp proxy for nating "Success is not measured by the positions you reach in life but by the obstacles you overcome -B.T.W" [Description: Description: Description: Description: Description: cyford]<http://www.cyfordtechnologies.com/>Director Of Technology Allen D. Ford 4290-106 Bells Ferry Road, Suite 20 , Kennesaw , GA 30144 Tel: 404-424-8270: Fax: 404-424-8271 Email: allen(a)cyfordtechnologies.com<mailto:allen@cyfordtechnologies.com> Web Address: http://www.cyfordtechnologies.com <http://www.cyfordtechnologies.com/> LinkedIn: http://www.linkedin.com/in/cyford FaceBook: http://www.facebook.com/profile.php?id=100002260975450 NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please destroy all copies of the original message and notify the sender so that our address record can be corrected. Thank you

2 1

10 Years SER - Awards
by Daniel-Constantin Mierla 05 Sep '11

05 Sep '11

Hello, a surprise part of 10 Years SER Conference was granting *special* awards to the people attending the event that had a major contribution in the management and development of SER/Kamailio to date. Most of them are well known in the community, but not all of them. Hope you like them, it proved to be a very entertaining moment. Here is the pdf with the awards: * http://asipto.com/u/48 The plan is to extend it with the other people in our community as ideas with award titles pop up. Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

1 0

10 Years SER - Follow UP
by Daniel-Constantin Mierla 05 Sep '11

05 Sep '11

Hello, first I want to thank to all participants at 10 Years SER event in Berlin last Friday. We spent great time, at least I did! We accepted 50 visiting participants to match the maximum capacity of the conference room, being full booked about 2 weeks before. Just few people didn't show up and didn't inform us at all in advance, which was a pity over all since several persons that registered later were not accepted, thus some of them could have attended. Folks at Fokus working with SER/Kamailio joined us and we had probably one of the very few occasions so far to get so dense knowledge of SIP/VoIP in the same place, making a day of interesting presentations and open discussions. Accompanied by nice weather in Berlin, the evening at Playa Paradiso on river Spree offered a great place for continuing the technical and mufti-cultural debates (I could count attendees from about 15 countries (including Brazil!)). Many thanks again to our sponsors for free drinks and food at this event: Sipgate (http://www.sipgate.de) Amooma (http://www.amooma.de) NG-Voice (http://www.ng-voice.com) Asipto (http://www.asipto.com) Frafos (http://www.frafos.com) and Fokus Institute (http://www.fokus.fraunhofer.de) I will upload the presentations soon and send an update here -- there were 15 talks, covering from technical concepts to business matters and open source philosophy. Therefore if you were a speaker and see this message, please send the pdf slides to me. Do not forget, you can join the next party for this celebration this week in Vienna, details at: * http://sip-router.org/10-years-ser-vienna/ Meanwhile, be sure you start/continue testing the upcoming release v3.2.0, we have to be sure it is stable to release it and start a new development cycle in the near future, to be able to present new features at the 11th celebration :-) . Here is a step by step guide to pull the code from GIT and install: * http://www.kamailio.org/dokuwiki/doku.php/install:kamailio-devel-from-git Cheers, Daniel -- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda

2 1

tls + tcp problems
by MÉSZÁROS Mihály 05 Sep '11

05 Sep '11

Hi, I am experiencing two problem: First: I am experiencing that tls read buffer overflow, if i use default value of tcp_rd_buf_size If i doubled the size of read buffer and i use tcp_rd_buf_size=8192 then the problem seems to be solved. Second: I am experiencing that TLS connection is dropped by sip proxy very frequently! And i think the tcp connection shouldn't dropped! So my guess is that TLS communication is not restarting the timeout counters! So in every 2 minutes the sip-router is restarting the TCP connection with tcp RST. like this: Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [tcp_main.c:4304]: tcp_main: entering timer for 0xac537c74 (ticks=446299809, ti meout=446299809 (0 s), wr_timeout=0 (240541717 s)), write queue: 0 bytes Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [tcp_main.c:4346]: tcp_main: timeout for 0xac537c74 Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [io_wait.h:617]: DBG: io_watch_del (0x824cf80, 48, -1, 0x10) fd_no=41 called Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: tls [tls_server.c:597]: Closing SSL connection 0xac4a0374 Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [ip_addr.c:247]: tcpconn_new: new tcp connection: 10.10.10.10 Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [tcp_main.c:1081]: tcpconn_new: on port 36142, type 3 Sep 5 11:28:48 hal /usr/sbin/kamailio[8129]: DEBUG: <core> [tcp_main.c:1382]: tcpconn_add: hashes: 2473:3781:3367, 5 This second problem is not solved and very urgent for me. Any help suggestion is highly appreciated! Thanks, Misi

2 1

Carrier module for kamailio
by Mino Haluz 05 Sep '11

05 Sep '11

Hi, I need a module which could allow me to send traffic to various carriers and it has to support some important features. So some basic ones: - possibility to re-route the call in case the original route fails - peak/offpeak conditions (time-based) - route traffic according to prefix I found LCR and carrierroute module, but it does not have peak/offpeak feature. Correct me if I am wrong..

2 1

new developer: Sven Knoblich
by Henning Westerholt 05 Sep '11

05 Sep '11

Hi all, I'm happy to announce a new developer for the sip-router project: Sven Knoblich. Sven is an experienced C/C++ developer in our offices in Karlsruhe and since about a year part of the team that develops our VoIP backend services. Past contributions of him were the CDR based accounting extensions in the acc module and several other bugfixes and extensions for the dialog module. He'll maintain in the future this new acc and dialog functionality and also other code contributed from us. Best regards, Henning -- Henning Westerholt - Head of IT Operations Internet Access & Communications 1&1 Internet AG, Brauerstraße 48, 76135 Karlsruhe, Germany

3 2

Pass all rtp to RTPProxy
by Stas Bakulin 05 Sep '11

05 Sep '11

Hello! What is it right way to pass all rtp traffic through RTPProxy? How this can be configured in Kamailio? Stas Bakulin ---------------------------------------------------------------------- ogion(a)kvant-telecom.ru | www.kvant-telecom.ru Tel: +7 473 233 0330 (128)

2 1

Kamailio + rtpproxy talking to multiple carrier gateways - some via Firewall/NAT
by Sarat C. Vemuri 03 Sep '11

03 Sep '11

We are trying to configure Kamailio (3.1.x) as a "boarder proxy" where it acts as the front for various carrier gateways so that internal UACs and UASs are unaware of the carrier gateways. Let me try to present a clear picture of our setup. 1. Kamailio has several NICs (physical or vlan). Each on a different subnet. One subnet is internal/has routes for internal. Other subnets are private connections to carriers or a route to public Internet. 2. All of these subnets are non-routable from Internet. In addition , the carrier private connections are not routable internally. 3. Connection to public internet is via a FW/NAT (one-to-one NAT), which maps to one of the interfaces. 4. All internal UAC/UAS connect on the internal subnet. 5. We are using RTPProxy (at least one instance per carrier) to relay media between internal and carrier subnets We are able to make this setup up work great except for one scenario. One of the carriers is only reachable via public Internet. Due to security requirements, our Kamailio cannot have a public IP address and must use FW/NAT. I guess this scenario is "Proxy behind NAT" and not really encouraged. But I would like to see if there is a way to make this work. We cannot use the "advertised_address" since it changes the IP for every "route". We were able to get this mostly working by doing the following 1. mhomed=1 2. Small patch in the rtpproxy module so that force_rtp_proxy actually uses the IP address passed (public IP). 3. Using request_route_preset("publicIP") The above "mostly" works. By that I mean, the INVITE transaction is properly passed between internal UAS and carrier SBC and the call is setup. However, further transactions (BYE/re-INVITE) etc do not work properly. So, far-end hangups are not working etc. I've searched various archives of this and other SER lists looking to see if anyone was able to get this scenario working, but couldn't find a definitive answer. Most of them point to using "advertised_address". So, and ideas on how to make "Proxy behind NAT" work without using advertised_address? Am I wasting my time? Thanks in advance for any help you can offer. SV.

3 2