sr-users December 2003

sr-users@lists.kamailio.org

108 participants
257 discussions

[Serusers] Do these SIP dumps look right ("group" locations entry) ?

by Jim Burwell

Hi, I was having some problems with calls to what I call "group" locations entries. These are entries where users enter their own SIP address for a particular location entry. The desired behavior is that when someone calls this "group" user, multiple other users phones will ring, and if not answered, voice mail will be called for the original "group" callee user. This doesn't seem difficult, but turns out to be a little tricky if the users enter the more logical, flexible, and user friendly "sip:user@samedomain" style addresses instead of "sip:user@ip:port". Obviously, requiring possibly non technical end users to enter the IP:port of all their phones for these group users is unacceptable. Using these domain style "indirect" entries is far nicer, since SER ultimately simply looks up all the users' registered phones in the locations table transparently. Using "sip:user@samedomain" style locations destinations causes these calls to fork back through SER a second time (spiraling back through SER) for each destination. This is where I ran into a problem as far as voice mail was concerned. When each branch of this call (each separate destination in the destination set) was forked back through SER, if the particular user in any given branch was a member of the voice mail group, a voice mail timeout would be set for each, ultimately resulting in a separate call to the voice mail system for each user, for the same call! This caused mass confusion in SER and the voice mail system, resulting in a failed voice mail call, for obvious reasons. The solution was to make sure that in this special case, that only the original "group" user gets queued for a voice mail timeout, and any other branches spiraling back through SER did not cause voice mail to be set up. Unfortunately, there's no easy way that I could figure out to test for this condition in ser.cfg, since these forked branches look just like normal calls to these users (which would be proper to set up a voice mail timeout for). The solution I came up with was to require users to use a special prefix, "g+", when entering their SIP URIs into the group locations entries, marking them for special treatment. The ser.cfg then simply looks for URIs that have the prefix "g+", and if present, makes sure that no voice mail failure_route is set up for these branches. Right before the locations lookup is done, the "g+" prefix is stripped off, and the branch proceeds to call the users phone(s) normally. Pretty simple, user friendly, and requires no special external script, etc, to be called. Viola! It worked. But with some misgivings. This solution actually worked in all my testing. However, I'm troubled by some of the SIP dumps of these calls I've examined. Particularly, I noted how for whatever reason, there seems to be multiple repeated/redundant "408 time out" messages sent back and forth between SER and the phones. Also, for whatever reason, the caller's phone sends repeated ACKs, which get routed to the voice mail system, even after it has answered and is already talking to the VM system. Do these traces look right ? Am I just being paranoid ? Please advise! (ser.cfg and traces attached as ZIP file. Sorry! It would be too big for the list otherwise!) - Jim -- +---------------------------------------------------------------------------+ | Jim Burwell - Sr. Systems/Network/Security Engineer, JSBC | +---------------------------------------------------------------------------+ | "I never let my schooling get in the way of my education." - Mark Twain | | "UNIX was never designed to keep people from doing stupid things, because | | that policy would also keep them from doing clever things." - Doug Gwyn | | "Cool is only three letters away from Fool" - Mike Muir, Suicyco | | "..Government in its best state is but a necessary evil; in its worst | | state an intolerable one.." - Thomas Paine, "Common Sense" (1776) | +---------------------------------------------------------------------------+ | Email: jimb(a)jsbc.cc ICQ UIN: 1695089 | +---------------------------------------------------------------------------+ | Reply problems ? Turn off the "sign" function in email prog. Blame MS. | +---------------------------------------------------------------------------+

20 years, 10 months

[Serusers] Test SER and commands for diagnostics

by Shirley Toh

Hi, Like to check does anyone know how to specifically know that SER is being configure properly, is there anyway to test. I am running on Linux 9.0, cannot use the command ngrep and sipsak to do any diagnostics. Please kindly advice. Regards, Shirley

20 years, 10 months

[Serusers] NAT types and rtpproxy

by radan

Hi !! Can I use rtpproxy with all types of NAT (full cone, restricted cone, port restricted cone and symmetric) ? Regards Andrzej

20 years, 10 months

Re: [Serusers] Sipsak Question

by Jiri Kuthan

I think that should be definitely done and it is already on Nils's to-do list. -jiri At 05:39 AM 12/30/2003, Wasik, Paul wrote: >Hi all, > >I'm having a little trouble with Sipsak when the Sipsak host is separated >from the SER proxy by a SIP aware PIX firewall using PAT. I'm running it on >a Windows XP machine with cygwin. > >I'm using "sipsak-0.8.6.exe -T -s sip:960@192.168.100.10". > >Everything works fine if I bypass the firewall. The problem I seem to have >is I think with the UDP port that Sipsak listens for a response on. For >instance it sends from a UDP source port of for example 1055 to the SIP >destination port of 5060. But it seems that Sipsak is listening on UDP port >1054 (source port -1) for the reply. I'm running Ethereal on the same PC as >Sipsak and I see the replies coming back correctly on port 1055. But since >Sipsak seems to be listening on port 1054 the application does not see the >replies from my SIP proxy. > >Is there any way to control the port that sipsak listens for replies on and >is it actually listening on UDP send port -1 for replies? > >Thanks, > >Paul > > > >DISCLAIMER > >The information in this e-mail and its attachments may be confidential. >If you are not the intended recipient, you must not read, use or disseminate >that information. If you have recieved this e-mail in error, please notify >us and destroy it immediately. > >Whilst we try to eliminate any viruses or other harmful code or device from >our emails or attachments, it is your responsibility to protect your system >and we do not accept responsibility for any that may remain. We may monitor >or access any e-mails sent to us. > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/

20 years, 10 months

RE: [Serusers] 400 Table 'aliases' not found in memory

by Klaus Darilion

after if (uri == myself) { regards, klaus -----Original Message----- From: Xiuyi Huang [mailto:xiuyi@acedsl.com] Sent: Tue 30.12.2003 22:17 To: serusers(a)lists.iptel.org Cc: Subject: [Serusers] 400 Table 'aliases' not found in memory where should I put the line of lookup("aliases"); _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

20 years, 10 months

[Serusers] 400 Table 'aliases' not found in memory

by Xiuyi Huang

where should I put the line of lookup("aliases");

20 years, 10 months

[Serusers] Sipsak Question

by Wasik, Paul

Hi all, I'm having a little trouble with Sipsak when the Sipsak host is separated from the SER proxy by a SIP aware PIX firewall using PAT. I'm running it on a Windows XP machine with cygwin. I'm using "sipsak-0.8.6.exe -T -s sip:960@192.168.100.10". Everything works fine if I bypass the firewall. The problem I seem to have is I think with the UDP port that Sipsak listens for a response on. For instance it sends from a UDP source port of for example 1055 to the SIP destination port of 5060. But it seems that Sipsak is listening on UDP port 1054 (source port -1) for the reply. I'm running Ethereal on the same PC as Sipsak and I see the replies coming back correctly on port 1055. But since Sipsak seems to be listening on port 1054 the application does not see the replies from my SIP proxy. Is there any way to control the port that sipsak listens for replies on and is it actually listening on UDP send port -1 for replies? Thanks, Paul DISCLAIMER The information in this e-mail and its attachments may be confidential. If you are not the intended recipient, you must not read, use or disseminate that information. If you have recieved this e-mail in error, please notify us and destroy it immediately. Whilst we try to eliminate any viruses or other harmful code or device from our emails or attachments, it is your responsibility to protect your system and we do not accept responsibility for any that may remain. We may monitor or access any e-mails sent to us.

20 years, 10 months

[Serusers] SQL Accounting - Problems

by Darren Nay

Hey All, I am trying to get SQL accounting to work within SER, but I am having a problem. The data is not being saved into the database. I've got the SER configured to use accounting. I've compiled the "acc" module with SQL support, and I believe that everything should be working.. However, I am getting the following errors in debug mode.. stateless - initializing 0(5814) Warning: uac does not spread accross the whole hash table Maxfwd module- initializing acc - initializing 0(5814) mod_init(): Database connection opened successfuly textops - initializing 0(5814) auth_db:mod_init(): Database connection opened successfuly 0(0) INFO: udp_init: SO_RCVBUF is initially 8192 0(0) INFO: udp_init: SO_RCVBUF is finally 262144 2(5816) INFO: fifo process starting: 5816 2(5816) SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... 2(5816) WARNING: no fifo_db_url given - fifo DB commands disabled! This below is what I get when I make a call... 0(5814) BUG:tm:register_tmcb: no transaction found 0(5814) ERROR:acc:acc_onreq: cannot register additional callbacks 0(5814) BUG:tm:register_tmcb: no transaction found 0(5814) ERROR:acc:acc_onreq: cannot register additional callbacks My call processing is working perfectly, but the accounting transactions (call records) are not being saved into the database in the "acc" table. Also, my userloc registrations are being saved to the database in the "locations" table, and so I know that there isn't a problem with my mysql.so module. The database connectivity seems to be fine. I have attached me ser.cfg as well. If anyone knows why I am getting these errors, and why my accounting isn't being saved to the "acc" table in the database then I would very much appreciate the help! Thanks! Darren Nay - dnay(a)libertyisp.com

20 years, 10 months

RE: [Serusers] nathelper / calling UAs behind symmetric NATs

by Klaus Darilion

It is not necessary to use 2 tables. You could also use the nat_flag as described in http://lists.iptel.org/pipermail/serusers/2003-December/004412.html regards, Klaus > -----Original Message----- > From: Thilo Salmon [mailto:salmon@netzquadrat.de] > Sent: Monday, December 29, 2003 4:53 PM > To: serusers(a)lists.iptel.org > Subject: [Serusers] nathelper / calling UAs behind symmetric NATs > > > Hi, > > I am trying to force incoming calls destined for a UA behind > a symmetric > NAT through rtpproxy. In order to distinguish between those agents > behind a NAT and those out in the open, I saved their location in two > different tables upon registration. It now appears that even though I > set db_mode to '1' to force usrloc to immediately write-back all data > to the db, ser remembers a successful registration in the regular > location tables. > > A REGISTER request is immediately written into my NAT tables while the > regular tables follows only a little later. When I call the UA in > question ser will find the agent in my regular location table. When I > manually delete the UA entry from the location table (and > restart ser!) > my configuration will force the rtp stream just as expected. > > Can anybody enlighten my whether this is a bug or a feature? Also I > would be very interested in learning how to handle UAs behind > symmetric > NATs or how to keep state learned at registration time. > > I attached parts of my configuration hoping to clarify what > I am trying > to do. > > Thilo > > P.S.: this is ser 0.8.12 > > if (method=="REGISTER") { > if ("header indicates symmetric NAT") { > save("natlocation"); > } else { > save("location"); > }; > }; > > [...] > > if ((method==INVITE)) { > if(lookup("location")) { > xlog("L_ERR", "UA found in > 'location'\n"); > } > else { > if(lookup("natlocation")) { > xlog("L_ERR", "UA found in > 'natlocation'\n"); > force_rtp_proxy(); > t_on_reply("2"); > } else { > sl_send_reply("404", "Not > Found"); > break; > }; > }; > }; > > [...] > > onreply_route[2] { > if (status=~"2[0-9][0-9]"){ > xlog("L_ERR", "forcing rtp stream back from NATed > UA through localhost\n"); > force_rport(); > force_rtp_proxy(); > }; > } > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > >

20 years, 10 months

[Serusers] mysql module failing to load on solaris 9 -- SOLVED

by Samy Touati

Hi, The issue I posted about an unresolved symbol, has been solved. The math library needed to be included as part of the mysql module build. Samy. Original message Hi, I compiled ser 0.8.12 (release from cvs) on solaris 9, and I noticed that by default mysql is never compiled. I forced its compilation, and then I installed it manually in the runtime modules directory. When I run ser with the -c argument, it gives me this error message: 0(18375) loading module /usr/local/lib/ser/modules/mysql.so 0(18375) ERROR: load_module: could not open module </usr/local/lib/ser/modules/mysql.so>: ld.so.1: ./ser: fatal: relocation error: file /usr/local/lib/ser/modules/mysql.so: symbol floor: referenced symbol not found 0(18375) parse error (50,13-49): failed to load module All other modules loaded ok. Here's more info on my config: # ./ser -V version: ser 0.8.12-tcp_nonb (sparc64/solaris) flags: STATS:Off, USE_IPV6, USE_TCP, DISABLE_NAGLE, DNS_IP_HACK, SHM_MEM, SHM_MMAP, PKG_MALLOC, F_MALLOC, FAST_LOCK-ADAPTIVE_WAIT ADAPTIVE_WAIT_LOOPS=1024, MAX_RECV_BUFFER_SIZE 262144, MAX_LISTEN 16, MAX_URI_SIZE 1024, BUF_SIZE 65535 @(#) $Id: main.c,v 1.168.4.1 2003/11/26 23:45:50 andrei Exp $ main.c compiled on 16:55:21 Dec 28 2003 with gcc 3.3 uname -a gives: SunOS blade 5.9 Generic sun4u sparc SUNW,Sun-Blade-100 Any idea why I'm getting this error? I ran ld.so.1 in debug mode, and I see the relocation of different symbols of mysql.so then this error. Samy.

20 years, 10 months

Jump to page:

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 December 2003