sr-users August 2011

sr-users@lists.kamailio.org

70 participants
108 discussions

Re: [SR-Users] Using SR for Number Translation & Number Portabilty Applications
by Henning Westerholt 09 Aug '11

09 Aug '11

On Monday 08 August 2011, Yaron Nachum wrote: > I have seen the match_mode but I haven't seen how is it possible to set it > up per domain. > > I would appreciate if you could explain how. Hi Yaron, please always CC to the mailling list. Its not possible to set the match_mode per domain, its a global parameter. With regards to the domains, this was another option you could use, e.g. use domain 0 for calls without the 'D' prefix, and then domain D for calls with 'D' prefix. Best regards, Henning

1 0

Re: [SR-Users] Using SR for Number Translation & Number Portabilty Applications
by Henning Westerholt 08 Aug '11

08 Aug '11

> Yaron wrote: > Thanks for the quick response. I have already played with the sqlops - > this is an obvious way to do it. I will further investigate cr and sqlops > and decide which is best for my purposes. Hello Yaron, > I liked the idea of having several instances of SIP-ROUTERs which are > independent of each other- I understand that cr answers it. Indeed, this is one advantage of using an in-memory cache. But you probably need some more DB access on the servers for things like authentication. > I have another question - I was trying to add alpha-numeric character > into the cr prefix and it seems it is not supported. We are using 'D' prefixes > in our network in order to route between different elements in the network. > Is there a way to support it? Maybe another routing module? The cr module support also a extended matching mode, but it will be probably not really feasible with millions of routes: http://kamailio.org/docs/modules/stable/modules/carrierroute.html#id2651893 Another thing you could do is use another "domain" for the D prefix, e.g. one for the default routing, and then another one for the D case. The module support matching for the domain as well. You could maybe also use flags for matching. Other possible modules for PSTN routing are lcr and mtree. Regards, Henning

1 0

Using SR for Number Translation & Number Portabilty Applications
by Yaron Nachum 08 Aug '11

08 Aug '11

Hi Everyone, I have downloaded SR r 3.1.4 and have been playing around with it. I am considering implementing Number Translation services (1800...) and Number Portability Services on it. We have around 20K entries on the Number Translation Service and around 3M entries on the Number portability Service. The volume is around 100 caps. I have started working with the carrierroute module - it seems perfect for the Number translation Service, but I am not sure about the Number portability. I have several questions: 1. Is it possible to use this module with several millions of entries? 2. What is the impact of loading the table? Is it possible to do it during traffic hours? I have read about PDB module, but I haven't understood how to setup the PDB server. I would appreciate for any guidance. Would you recommend using the PDB module for the Number Portability or the carrierroute? Thanks.

2 1

suggested number of TCP / UDP workers for version 3.1.x
by Francesco Castellano 08 Aug '11

08 Aug '11

Dear sirs, searching on the web and in old ML threads about the suggested number of TCP and UDP workers, I just found: - for TCP children (i.e., TCP receivers, isn't it?) "As a rule of thumb, (maximum simultaneous connections)/2000 should be OK" (from doc/tcp_tunning.txt) - In general for workers (from a past thread by Henning Westerholt): "In my experience the number of children is not that important for performance, you may just choose the default size of 8." In the last post there was, moreover, a suggestion that the number of children should be chosen with respect to RAM and CPU cores (that makes sense to me). The only thing I can think about the rule of thumb above comes from the possibility that a number of processes may be unavailable in blocking operations. So my question is: - with asynchronous TCP/TLS is it safe to assume that more children than CPU cores are more or less useless? - are there other blocking operations for which the number of UDP/TCP children should be incremented above the CPU cores number? Thank you! Best regards, Francesco Castellano

2 2

Kamailio Redundant Systems
by HM Kias 08 Aug '11

08 Aug '11

Hi, Anyone tried pacemaker, heartbeat or OpenAIS for building redundant kamailio systems? Please share your experiences. Also auggest a better solution. Regards, -- HM Kias 91-9443467600

2 1

Homer Project
by Alexandr Dubovikov 05 Aug '11

05 Aug '11

Hello sr-users, I would like to present a new project called "Homer". What is Homer ? Homer is a capture solution for SIP logging. How does it work? Homer has 4 components: 1. Capture Agent 2. Capture Node 4. Capture DB 3. Web GUI. The capture agent takes your local SIP traffic and sends it to the defined capture node in HEP protocol. If you are user of FreeSWITCH or Kamailio, use build-in capture agent. In other case, you can use an external generic daemon, but only for SIP/UDP. The capture node is based on kamailio, can receive SIP traffic encapsulated in IP proto 4 (IPIP) or in HEP procotol and store it into MySQL DB. To gain access to the capture DB, download a simple webinterface (PHP based). After it you are able to do search, generate PCAP file, callflow, look at the details of SIP messages etc. Homer works in our company and easy collect ~5 M packets per hour. The patches for kamailio and some other information can be found here: http://homer.googlecode.com Beta testers are welcome :-) I'll help everybody to setup/configure Homer :-) With best regards, Alexandr

3 3

$du gets set automatically before branch_route
by Alex Hermann 05 Aug '11

05 Aug '11

Hello, while trying to upgrade from 1.5 to 3.1 i noticed that between t_relay() and branch_route, $du gets automatically set to $ru if it has not been set before. This is a change from 1.5 i could not find documentation for, so it might have been unintened. Can someone enlighten me on the purpose of this change and if there is a way to determine if $du is (was) unset other than comparing $ru to $du, wich seems a bit inefficient? Is it even guaranteed that $du gets set to $ru in every possible scenario? -- Alex Hermann

3 8

udp vs. tcp receiver processes
by Juha Heinanen 05 Aug '11

05 Aug '11

i have 8 children specified in default file and in cfg file i have: listen=192.98.101.10:5060; listen=udp:127.0.0.1:5070; listen=udp:127.0.0.1:5070; listen=tcp:127.0.0.1:5070; listen=udp:127.0.0.1:5080; listen=tcp:127.0.0.1:5080; listen=tcp:127.0.0.1:6060; that results in 8 tcp receiver processes but 3 x 8 udp receiver processes: # sip-proxy_ctl ps 30720 attendant 30721 udp receiver child=0 sock=192.98.101.10:5060 30722 udp receiver child=1 sock=192.98.101.10:5060 30723 udp receiver child=2 sock=192.98.101.10:5060 30724 udp receiver child=3 sock=192.98.101.10:5060 30725 udp receiver child=4 sock=192.98.101.10:5060 30726 udp receiver child=5 sock=192.98.101.10:5060 30727 udp receiver child=6 sock=192.98.101.10:5060 30728 udp receiver child=7 sock=192.98.101.10:5060 30729 udp receiver child=0 sock=127.0.0.1:5070 30730 udp receiver child=1 sock=127.0.0.1:5070 30731 udp receiver child=2 sock=127.0.0.1:5070 30732 udp receiver child=3 sock=127.0.0.1:5070 30733 udp receiver child=4 sock=127.0.0.1:5070 30734 udp receiver child=5 sock=127.0.0.1:5070 30735 udp receiver child=6 sock=127.0.0.1:5070 30736 udp receiver child=7 sock=127.0.0.1:5070 30738 udp receiver child=0 sock=127.0.0.1:5080 30740 udp receiver child=1 sock=127.0.0.1:5080 30752 udp receiver child=2 sock=127.0.0.1:5080 30754 udp receiver child=3 sock=127.0.0.1:5080 30755 udp receiver child=4 sock=127.0.0.1:5080 30756 udp receiver child=5 sock=127.0.0.1:5080 30758 udp receiver child=6 sock=127.0.0.1:5080 30760 udp receiver child=7 sock=127.0.0.1:5080 30761 slow timer 30763 timer 30765 ctl handler 30803 TIMER NH 30805 TIMER RT 30806 tcp receiver child=0 30808 tcp receiver child=1 30810 tcp receiver child=2 30812 tcp receiver child=3 30813 tcp receiver child=4 30844 tcp receiver child=5 30846 tcp receiver child=6 30847 tcp receiver child=7 30849 tcp main process why cannot one udp receiver process handle all listening addresses like tcp processes seem to be able to do? the above seems like waste of resources. -- juha

3 4

Kamailio on a server with different network cards
by Rocío Ruz 05 Aug '11

05 Aug '11

Hello, My server has two different network cards with different IPs. I want kamailio to use both; the network card to be used depends on the destination. My problem is that I have to add an IP in the configuration file kamailio.cfg: listen=109.239.50.67 Will Kamailio listen only to packets sent to this IP? Can I add the two IPs corresponding to my two network cards here? Thank you RR

3 5

480 Temporarily Unavailable. in kamailio 3.1.4
by hala alramli 04 Aug '11

04 Aug '11

i installed kamailio and freeswitch according to http://kb.asipto.com/freeswitch:kamailio-3.1.x-freeswitch-1.0.6d-sbc i installed also rtpproxy . i managed to create 101,102,103 and all of them registered , i am not able to make calls between them, 480 temporarily unavailable always the error . i cant find in the configuration file what cause this error. this is the track. i will be thankful for any help . Hala interface: eth0 (192.168.1.0/255.255.255.0) filter: (ip or ip6) and ( port 5060 ) match: 101 U 2011/08/04 13:16:57.351872 192.168.1.175:5060 -> 192.168.1.233:5060 INVITE sip:102@192.168.1.233 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-6eabf9b3. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 101 INVITE. Max-Forwards: 70. Contact: <sip:101@192.168.1.175:5060>. Expires: 240. User-Agent: Linksys/PAP2T-5.1.6(LS). Content-Length: 444. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura, replaces. Content-Type: application/sdp. . v=0. o=- 986176 986176 IN IP4 192.168.1.175. s=-. c=IN IP4 192.168.1.175. t=0 0. m=audio 16450 RTP/AVP 8 0 2 4 18 96 97 98 100 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:4 G723/8000. a=rtpmap:18 G729a/8000. a=rtpmap:96 G726-40/8000. a=rtpmap:97 G726-24/8000. a=rtpmap:98 G726-16/8000. a=rtpmap:100 NSE/8000. a=fmtp:100 192-193. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2011/08/04 13:16:57.352037 192.168.1.233:5060 -> 192.168.1.175:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-6eabf9b3. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>;tag=b27e1a1d33761e85846fc98f5f3a7e58.7d11. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 101 INVITE. Proxy-Authenticate: Digest realm="192.168.1.233", nonce="TjqA1U46f6liNM8a6LX5HBJ2wXEBtOIX". Server: kamailio (3.1.4 (x86_64/linux)). Content-Length: 0. . U 2011/08/04 13:16:57.370381 192.168.1.175:5060 -> 192.168.1.233:5060 ACK sip:102@192.168.1.233 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-6eabf9b3. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>;tag=b27e1a1d33761e85846fc98f5f3a7e58.7d11. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 101 ACK. Max-Forwards: 70. Contact: <sip:101@192.168.1.175:5060>. User-Agent: Linksys/PAP2T-5.1.6(LS). Content-Length: 0. . U 2011/08/04 13:16:57.380065 192.168.1.175:5060 -> 192.168.1.233:5060 INVITE sip:102@192.168.1.233 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-eab8c613. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 INVITE. Max-Forwards: 70. Proxy-Authorization: Digest username="101",realm="192.168.1.233",nonce="TjqA1U46f6liNM8a6LX5HBJ2wXEBtOIX",uri="sip:102@192.168.1.233",algorithm=MD5,response="a019828b7a7334539ffa6b668dfcfada". Contact: <sip:101@192.168.1.175:5060>. Expires: 240. User-Agent: Linksys/PAP2T-5.1.6(LS). Content-Length: 444. Allow: ACK, BYE, CANCEL, INFO, INVITE, NOTIFY, OPTIONS, REFER. Supported: x-sipura, replaces. Content-Type: application/sdp. . v=0. o=- 986176 986176 IN IP4 192.168.1.175. s=-. c=IN IP4 192.168.1.175. t=0 0. m=audio 16450 RTP/AVP 8 0 2 4 18 96 97 98 100 101. a=rtpmap:8 PCMA/8000. a=rtpmap:0 PCMU/8000. a=rtpmap:2 G726-32/8000. a=rtpmap:4 G723/8000. a=rtpmap:18 G729a/8000. a=rtpmap:96 G726-40/8000. a=rtpmap:97 G726-24/8000. a=rtpmap:98 G726-16/8000. a=rtpmap:100 NSE/8000. a=fmtp:100 192-193. a=rtpmap:101 telephone-event/8000. a=fmtp:101 0-15. a=ptime:30. a=sendrecv. U 2011/08/04 13:16:57.380329 192.168.1.233:5060 -> 192.168.1.175:5060 SIP/2.0 100 trying -- your call is important to us. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-eab8c613. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 INVITE. Server: kamailio (3.1.4 (x86_64/linux)). Content-Length: 0. . U 2011/08/04 13:16:57.488511 192.168.1.233:5060 -> 192.168.1.175:5060 SIP/2.0 480 Temporarily Unavailable. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-eab8c613. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>;tag=NDrNpDZ1g0jZe. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 INVITE. User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-5d37bc9 2011-08-03 09-05-01 -0500. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 INVITE. Server: kamailio (3.1.4 (x86_64/linux)). Content-Length: 0. . U 2011/08/04 13:16:57.488511 192.168.1.233:5060 -> 192.168.1.175:5060 SIP/2.0 480 Temporarily Unavailable. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-eab8c613. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>;tag=NDrNpDZ1g0jZe. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 INVITE. User-Agent: FreeSWITCH-mod_sofia/1.0.head-git-5d37bc9 2011-08-03 09-05-01 -0500. Accept: application/sdp. Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, UPDATE, INFO, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE. Supported: timer, precondition, path, replaces. Allow-Events: talk, hold, presence, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer. Reason: Q.850;cause=16;text="NORMAL_CLEARING". Content-Length: 0. Remote-Party-ID: "kb-102" <sip:kb-102@192.168.1.233>;party=calling;privacy=off;screen=no. . U 2011/08/04 13:16:57.502085 192.168.1.175:5060 -> 192.168.1.233:5060 ACK sip:102@192.168.1.233 SIP/2.0. Via: SIP/2.0/UDP 192.168.1.175:5060;branch=z9hG4bK-eab8c613. From: <sip:101@192.168.1.233>;tag=43c22ff96586a71ao0. To: <sip:102@192.168.1.233>;tag=NDrNpDZ1g0jZe. Call-ID: 9acd1ca5-9162c25e(a)192.168.1.175. CSeq: 102 ACK. Max-Forwards: 70. Proxy-Authorization: Digest username="101",realm="192.168.1.233",nonce="TjqA1U46f6liNM8a6LX5HBJ2wXEBtOIX",uri="sip:102@192.168.1.233",algorithm=MD5,response="a019828b7a7334539ffa6b668dfcfada". Contact: <sip:101@192.168.1.175:5060>. User-Agent: Linksys/PAP2T-5.1.6(LS). Content-Length: 0. .

2 1

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 August 2011