sr-users March 2008

sr-users@lists.kamailio.org

169 participants
237 discussions

[OpenSER-Users] nat_uac_test("31") not enough to detect with some consumer voip passthrough routers

by Mike Fedyk

Hi, Some of our customers have been connecting behind NAT routers that mangle the sip headers but don't keep the ports open. I've added checks on the source port to catch this case. Has anyone done something similar or better? It'd be nice if this could be added as a flag to nat_uac_test() if it is a common test and there isn't already a better way. Here is the code I've used to handle my registers. I need to do more testing once I can get some of these routers in my lab to see how this affects call processing, not just registering. Mike if (!search("^Contact:\ +\*") && nat_uac_test("7")) { xlog("L_INFO", "M=$rm RURI=$ru F=$fu IP=$si:$sp CS=$cs route2: matched nat_uac_test7\n"); xlog("L_NOTICE", "M=$rm RURI=$ru F=$fu IP=$si:$sp CS=$cs route2: setbflag(6)\n"); setbflag(6); xlog("L_NOTICE", "M=$rm RURI=$ru F=$fu IP=$si:$sp CS=$cs route2: fix_natted_register()\n"); fix_nated_register(); #xlog("L_INFO", "M=$rm RURI=$ru F=$fu IP=$si:$sp CS=$cs route2: force_rport()\n"); #force_rport(); }; #Some NAT devices modify SIP headers to but do not keep the port mappings open, also some UAs detect report the #public IP address. In both cases we need nat ping. Exceptions for default ports. These ports if used as #source ports can be assumed to be at the very least port forwarded. if (!isbflagset(6) && $sp != '5060' && $sp != '5061') { xlog("L_NOTICE", "M=$rm RURI=$ru F=$fu IP=$si:$sp CS=$cs route2: matched !isbflagset(6) && ($sp != '5060' && $sp != '5061')\n"); setbflag(6); };

16 years, 7 months

[OpenSER-Users] Branch/transaction flags not being inherited by BYE?

by Dan-Cristian Bogos

Hi All, I have noticed something strange in the version I am running, cannot find the branch/transaction (tried them both) flags in the BYE messages (one app: end_media_session if previously used). Is that a known issue? In the INVITE and 200 OK the flags are there. My version: openser -V version: openser 1.3.1-tls (i386/linux) flags: STATS: Off, USE_IPV6, USE_TCP, USE_TLS, DISABLE_NAGLE, USE_MCAST, 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 poll method support: poll, epoll_lt, epoll_et, sigio_rt, select. svnrevision: 2:3938M @(#) $Id: main.c 3590 2008-01-28 17:46:56Z bogdan_iancu $ main.c compiled on 19:06:15 Mar 19 2008 with gcc 4.1.2 Ta, DanB

16 years, 7 months

[OpenSER-Users] mailing lists domain migration completed

by Daniel-Constantin Mierla

Hello, a bit later than previously announced, all mailing lists hosted by openser project work only with domain 'lists.openser.org', the alternative available in the past ('openser.org') has been disabled. You should get a mail delivery error if you use the old domain -- resend to list_name(a)lists.openser.org Cheers, Daniel

16 years, 7 months

[Serusers] SER performance bottleneck ?

by fang, tian

Hi dear friends, We tried to benchmarking IPtel SER 0.9.6 on Intel xeon CPU based computer recently,but we met a problem about poort performance.For example on a computer configured with Intel 2*sossaman CPU (four cores)+2G ddr2-400 memory+100M Ethernet card, we didn't configure any database,and registered with only 1-2 users,and we use SIPP 3.0 as the call generator ,but we can only see about 3,000 calls per second for a very simply built-in scenario in SIPP(UAC+UAS),and the CPU idle percentage is about 70-80%.if we tried to increase the call rate ,we got failure calls. We tried to enlarge the memory to 768M for SER,and limited the ser processes number on each port from 8 to 4,and we also made some improvement on config.h & Makefile.defs,but didn't get big improvement on performance . If anybody could help me on this,I will appreciate a lot. Thanks Fang tian.

16 years, 7 months

Re: [OpenSER-Users] LCR Gateway Priority....

by Douglas Garstang

>Douglas Garstang writes: > >> Juha, not sure I understand you. It sounds like your suggesting >> exactly the scenario I described in my post, which really seems like >> a less than ideal what to do it. It means a lot of unecessary rows in >> the lcr table. > >if you need to add those rows by hand (i.e., you don't have any >management system) then check if carrierroute module could be a better >match for you. > >-- juha Juha, I spent some time trying to understand and get the carrierroutefunctionality working today, and it looks like it doesn't solve myproblem either. It appears that the default carrier cannot be changed during a call,which is no good. If we assumed that the domain was our carrier, thenit might be ok because we can call lc_rewrite_uri to switch domains,but once we've selected a new carrier, the gateways are selected basedon the 'prob' column in the db. This also isn't what we need. We needmore control than that. The LCR module actually works better. It the gatways had a priority, we'd be happy! I'm surprised no one has written a better module for this. In the realworld, you have multiple POPs, your carriers also have multiple POP's,multiple gateways. In the event you get a failure with one carrier, youprobably want to switch to the next cheapest carrier, not anothergateway within the same carrier (as it will probably just fail again).When selecting a carrier gateway, you need to choose the best POP touse before you select the trunk. Doug. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs

16 years, 7 months

Re: [OpenSER-Users] LCR... Too many entries

by Douglas Garstang

> >Douglas Garstang writes: > >> Ok, can someone please tell me why 4999 LCR entries is too many? >> What's the limit? Is it hard coded in the OpenSER source? Why? > >there is a constant in lcr_mod.h that tells how many lcr entries cached >lcr table can hold: > >#define MAX_QUERY_SIZE 512 > >you can increase its value, but as i have said, lcr module was not >designed for the kind of inter-operator application that you have. Ok... what about carrierroute? Are there are docs or examples available besides the very limited module specs at openser.org? It seems like if you want to change carriers you have to hard code it in cr_tree_rewrite_uri(). Wouldn't a next_carrier() type function make more sense? Doug. ____________________________________________________________________________________ Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

16 years, 7 months

Re: [Serusers] SER2.0 xml body size in NOTIFY

by Vaclav Kubart

Hi Pravin, no, there is no way how to tell SER which information propagate in NOTIFYs and which not. I still think that it is problem on your user agent which doesn't publish/unpublish information correctly. I have seen similar behaviour when a client was ignoring SIP-Etag returned by presence server in PUBLISH response. The same SIP-Etag should be used in all consequnt PUBLISHes from that user agent (see RFC 3903 for details). with regards, Vaclav On Po, bře 31, 2008 at 12:19:48 +0530, pravin.swami(a)wipro.com wrote: > HI... Vaclav , Thanks for reply . > > The problem statement still coming when user changes its state > Online/offline/away . Is there any configurable way in ser presence > > Regards, > pravin > -----Original Message----- > From: Vaclav Kubart [mailto:vaclav.kubart@iptel.org] > Sent: Monday, March 31, 2008 11:55 AM > To: Pravin Sidram swami (WT01 - MCE-Mobile Devices) > Cc: serusers(a)lists.iptel.org > Subject: Re: [Serusers] SER2.0 xml body size in NOTIFY > > Hi, > it seems to me that your PUA doesn't 'unpublish' its presence document when it > goes down. > > SER has to put all known information about presentity into NOTIFY - it can't > decide itself to send some data and some not. > > Vaclav > > On Pá, bře 28, 2008 at 09:36:42 +0530, pravin.swami(a)wipro.com wrote: > > Hi, > > > > > > > > I am facing a problem with growing size of XML body in NOTIFY > > request that carries presence information. > > > > The situation I have is: > > > > 1. PUA1 & PUA2 are two presence user agents subscribed to SER (2.0) > > presence server. > > > > 2. PUA2 comes online. PUA1 gets a NOTIFY. > > > > 3. PUA2 goes down & comes online again. PUA2 gets a NOTIFY with bigger > > XML body than step 2. > > > > 4. Step 3 is repeated many times. The NOTIFY that reaches PUA2 keeps on > > growing in size. > > > > > > > > Is there a way to configure SER server to restrict the size of XML body > > it sends in the NOTIFY request? > > > > Please help us come out of this problem. > > > > > > > > Regards, > > > > -Pravin > > > > > > > > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > > > www.wipro.com > > > > > _______________________________________________ > > Serusers mailing list > > Serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. > > WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. > > www.wipro.com

16 years, 7 months

[Serusers] SER2.0 xml body size in NOTIFY

by pravin.swami＠wipro.com

Hi, I am facing a problem with growing size of XML body in NOTIFY request that carries presence information. The situation I have is: 1. PUA1 & PUA2 are two presence user agents subscribed to SER (2.0) presence server. 2. PUA2 comes online. PUA1 gets a NOTIFY. 3. PUA2 goes down & comes online again. PUA2 gets a NOTIFY with bigger XML body than step 2. 4. Step 3 is repeated many times. The NOTIFY that reaches PUA2 keeps on growing in size. Is there a way to configure SER server to restrict the size of XML body it sends in the NOTIFY request? Please help us come out of this problem. Regards, -Pravin The information contained in this electronic message and any attachments to this message are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you are not the intended recipient, you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately and destroy all copies of this message and any attachments. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. www.wipro.com

16 years, 7 months

[Serusers] Help with attended (consultative) call transfer problem

by Steven C. Blair

Hello: We have been having persistent problems with consultative (attended) call transfer and I'd like to ask the list for some input. We have three Cisco 2821 gateways each with two PRIs connecting to Verizon Centrex service. The route advance sequence defined by Verizon results in all calls entering our VoIP environment entering via gateway #1. If no channels exist calls fail over to gateway #2 and finally #3. For load balancing purposes our SER 0.9.7-pre3 proxy will send outbound calls to gateway #3, then #2 and finally #1. We are using Cisco 79x0 phones running SIP load 7.3. All other types of calls including blind transfers work. Call transfers in which both call legs traverse the same gateway work. Only transfers where each call leg traverses different gateways fail. Given the inbound and outbound routing described above it is easy to see how most transfers fail. From a protocol perspective the transfer follows RFCs. I have ethereal traces if anyone needs them. Cisco has worked on this problem and is now suspecting that a transfer will only work if both call legs traverse the same gateway. It is unclear if this is technically correct, a configuration issue in our gateway or a mistake. To further complicate the issue calls from the PSTN, through a gateway to an IP phone which is transfers to another IP phone on the same proxy work. Failures only happen when the second call leg is to the PSTN and traverse a different gateway. Has anyone on this list seen this issue or have any input whatsoever? Thanks,Steve Senior Network Engineer, Information Systems and Computing Networking and Telecommunications , Suite 221A /6228 University of Pennsylvania Voice:215-573-8396 FAX:215-898-9348

16 years, 7 months

[Serusers] Path header field

by Ladislav Andel

Hi, does SER support Path header field as described in RFC3327? Thanks, Lada

16 years, 7 months

← Newer
1
2
3
4
5
6
7
...
24
Older →

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 March 2008