sr-users

sr-users@lists.kamailio.org

13 participants
37464 discussions

[OpenSER-Users] Branch/transaction flags not being inherited by BYE?
by Dan-Cristian Bogos 31 Mar '08

31 Mar '08

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

2 2

[OpenSER-Users] mailing lists domain migration completed
by Daniel-Constantin Mierla 31 Mar '08

31 Mar '08

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

3 2

[Serusers] SER performance bottleneck ?
by fang, tian 31 Mar '08

31 Mar '08

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.

4 4

Re: [OpenSER-Users] LCR Gateway Priority....
by Douglas Garstang 31 Mar '08

31 Mar '08

>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

5 5

Re: [OpenSER-Users] LCR... Too many entries
by Douglas Garstang 31 Mar '08

31 Mar '08

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

2 1

Re: [Serusers] SER2.0 xml body size in NOTIFY
by Vaclav Kubart 31 Mar '08

31 Mar '08

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

1 0

[Serusers] SER2.0 xml body size in NOTIFY
by pravin.swami＠wipro.com 31 Mar '08

31 Mar '08

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

3 2

[Serusers] Help with attended (consultative) call transfer problem
by Steven C. Blair 30 Mar '08

30 Mar '08

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

2 2

[Serusers] Path header field
by Ladislav Andel 30 Mar '08

30 Mar '08

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

3 2

[Serusers] Need way to specify SOURCE IP address on packets of SIP messages being emitted by SER
by Frank Durda IV 30 Mar '08

30 Mar '08

I have a problem that I thought SER could solve but now that I need it, the method isn't obvious. First, as an example, let's say I have three independent organizations running Asterisk boxes, which send me the SIP and RTP audio for calls. Let's call them Company A Asterisk box at 31.1.2.3 Company B Asterisk box at 42.4.5.6 Company C Asterisk box at 53.7.8.9 So they are one side of the SER box all communicating SIP to a single interface. On the other side is a TDM PSTN switch capable of accepting SIP calls. The PSTN switch has exactly one IP address, which we will call 101.2.3.4. Inside the PSTN switch, for calls originating in TDM headed to SIP, a "Route List" directs calls for a given trunk group (everything is visualized in TDM terms even if the terms don't really apply) to a specific IP address, where the SIP INVITE should go for this call. In the case of a SIP to TDM call, when an INVITE comes in, the PSTN switch looks through that list of Routes that point to IP addresses and when it finds an IP address match, it knows which trunk group to associate with this call for billing. This also acts as a simple friend/foe mechanism, because if there is no route pointing at your SIP source, it rejects your INVITES. So, if Company A, B and C were communicating directly with the PSTN switch (no SER), you would simply need three trunk groups where each IP address pointed directly to the Asterisk boxes at those companies, like this: TGN SIP IP 1111 -> 31.1.2.3 2222 -> 42.4.5.6 3333 -> 53.7.8.9 and all would be well. However, when you insert a SER box between those the Asterisk boxes belonging to those companies and the PSTN switch, problems arise. I originally decided to address the issue by establishing two groups of three IP addresses, one set that the Asterisk servers would individually send their INVITEs to, and three that the PSTN switch could send its INVITES to. SER already supports the idea of listening on numerous IP addresses, so that was easy (although the documentation for "listen" and "alias" is weak and a code review was needed to determine what alias actually did, something other than what the "alias" option of an ifconfig command does...). Anyway, we have a setup like this: interface interface interface em1 on SER em0 on SER sig0 on PSTN 10.1.0.0/16 10.2.0.0/16 101.2.3.0/28 Company A 31.1.2.3 ---- 10.1.2.3 SER 10.2.0.1 ---- 101.2.3.4 Company B 42.4.5.6 ---- 10.1.5.6 SER 10.2.0.2 ---- 101.2.3.4 Company C 53.7.8.9 ---- 10.1.8.9 SER 10.2.0.3 ---- 101.2.3.4 Inside the ser.cfg, it is simple enough to rewrite the "host address" (where you want the packet to go) to reflect the new destination once that is determined, and for TDM to SIP calls work okay from the perspective of the PSTN switch, but then it really never cared whether the SER box was there or not. As long as the PSTN switch knows who to bill, it is vaguely happy. To accomplish that, the routes inside the PSTN switch were altered to point to the SIP IP addresses that the PSTN switch would have contact with, as in: TGN SIP IP 1111 -> 10.2.0.1 2222 -> 10.2.0.2 3333 -> 10.2.0.3 (Changing the IPs in the PSTN switch turns out to be a non-trivial operation.) The more serious problem arises with a call going SIP to TDM, because when the SER box sends a packet on to the PSTN box at 101.2.3.4, it needs to also re-write the SOURCE IP of the packet to reflect the appropriate IP address on the em0 interface, not just the first IP address that is discovered on the interface. What it does right now is send everything out under the first IP address listed on that interface, usually 10.2.0.1, so calls fail to set up properly as the replies go back to company A even if coming from company B or C. Is there a function in SER that lets you set the right address to use on outgoing packets? As all of the IP addresses that would be used are in fact ones set on that interface, it should be just a question of setting the right one, but I haven't found a function for ser.cfg or loadable module that clearly states that it will do this. So in summary, when Company B sends an INVITE to 10.1.5.6 from their 42.4.5.6 system, I need to have SER send an invite to 101.2.3.4 from 10.2.0.2 and never any other address that happens to be on that same interface. And when the reply to the INVITE comes to 10.2.0.2 from 101.2.3.4, I need SER to forward it on to 42.4.5.6 from 10.1.5.6. Note that while I am showing an example with three companies, there will be dozens, even hundreds of unique IPs involved here, hence the enormous netblocks set aside for each interface on the SER box. I'm certainly open to alternative methods to get SER to alter the headers of the packets it forwards exactly as needed, but keep in mind that I have basically zero control over how the PSTN switch does things, and it has exactly one IP address (three actually, but one does all the SIP work) that you send to and it originates from, yet is keenly interested in where packets it receives came from (for billing purposes) so you can't expect any help from the PSTN switch side. So is there a function callable from ser.cfg to force set the SOURCE IP address on SIP messages on a message by message basis? We are currently using ser-0.9.6. Thanks for your assistance, Frank Durda

3 4

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