sr-users May 2007

sr-users@lists.kamailio.org

164 participants
295 discussions

[Serusers] Computing value of the branch parameter in SER

by Andrew Pogrebennyk

Hi, Can you tell me how SER computes the value of the branch parameter or where should I look for the algorithm? Thanks in advance! -- /"\ Best regards, | andrew.pogrebennyk (at) portaone.com \ / Andrew Pogrebennyk | http://callcc.livejournal.com/ X VoIP engineer | JID: marduk (at) jabber.lafox.net / \ ASCII Ribbon Campaign | Against HTML Mail and News

17 years, 6 months

[Serusers] iptel.org - Technical board - Suggestion - REQUEST FOR FEEDBACK

by Greger V. Teigre

I believe most people by now have had time to respond to the thread where the idea and discussion from Prague around a technical board was started (April 12). Based on the feedback received, I summarize and offer the following make-it-simple suggestion: We create an iptel.org technical board (TB: 1. The board is responsible for resolving issues that is not possible to be resolve through a community consensus process, and it is allowed to take action where it finds necessary for the benefit of the iptel.org community. 2. The board is common for all iptel.org projects. 3. The board shall consist of five (5) members and the term shall be two years. 4. A board member can stay for several terms. 5. The five members shall be selected with one representative from SEMS, two from the SER developer (cvs write access) community, and two representatives for the broader iptel.org community. 6. All seruser and serdev subscribers nominate candidates, as well as vote. 7. Electable members must be contributors to iptel.org in some way and should not be controversial among subscribers. 8. Each subscriber can give his/her vote to one or more candidates, up to the number of board members (5). Process forward: People should respond with concerns and suggestions to this post. If there is consensus for changes, I will work as the editor and write up a new suggestion. Once the community can agree to the set of rules governing the board, we will proceed to nomination of candidates and then voting. g-)

17 years, 6 months

[Users] Re: Users Digest, Vol 23, Issue 97

by wangdq＠gongye.com.cn

use rtpproxy trunk tree, perhaps have no this buf. rtpproxy-0.3.0 has this problem . I use the SVN trunk . this problem not happend. 在 2007-05-01二的 16:15 +0800，users-request(a)openser.xn--org:-7z8fk634a > Send Users mailing list submissions to > users(a)openser.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://openser.org/cgi-bin/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > users-request(a)openser.org > > You can reach the person managing the list at > users-owner(a)openser.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: memory leak in presence module? (Klaus Darilion) > 2. rtpproxy CPU usage issue.. (Sajith T S) > 3. Dropped calls with OpenSER 1.1.x and Asterisk >= 1.2.14 > (Edoardo Serra) > 4. Re: Redirect the same INVITE to the SIP SERVER from Balancer? > (Alejandro Sanchez) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Apr 2007 15:34:31 +0200 > From: Klaus Darilion <klaus.mailinglists(a)pernau.at> > Subject: Re: [Users] memory leak in presence module? > To: daniel(a)voice-system.ro > Cc: "users openser.org" <users(a)openser.org> > Message-ID: <4635F067.6070006(a)pernau.at> > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > Hi! > > I tried again and it happened again: > > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7648]: > 32b24f15e52d603ba890a9729723c4b0.0167///45-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > outside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7655]: > 32b24f15e52d603ba890a9729723c4b0.7e11///14-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > outside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7648]: > 32b24f15e52d603ba890a9729723c4b0.0167///45-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > inside t_newtran > Apr 30 15:00:54 ds3000 /usr/sbin/openser[7655]: > 32b24f15e52d603ba890a9729723c4b0.7e11///14-6782(a)83.136.32.132 PUBLISH > detected, handle_publish ... > inside t_newtran > Apr 30 15:01:03 ds3000 /usr/sbin/openser[7644]: child process 7648 > exited by a signal 9 > Apr 30 15:01:08 ds3000 /usr/sbin/openser[7644]: core was not generated > Apr 30 15:01:08 ds3000 /usr/sbin/openser[7644]: INFO: terminating due to > SIGCHLD > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: Memory status (pkg): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: qm_status (0x8145960): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7657]: heap size= 1048576 > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7659]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7653]: INFO: signal 15 received > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7653]: Memory status (pkg): > Apr 30 15:01:14 ds3000 /usr/sbin/openser[7650]: INFO: signal 15 received > > > Any hints how to debug this? > > regards > klaus > > Daniel-Constantin Mierla wrote: > > Hello Klaus, > > > > On 04/30/07 13:55, Klaus Darilion wrote: > >> > >> > >> Daniel-Constantin Mierla wrote: > >>> Hello Klaus, > >>> > >>> On 04/27/07 09:27, Klaus Darilion wrote: > >>>> Hi Daniel! > >>>> > >>>> I've tried with t_release and it was running fine several hours > >>>> without leaking. But then, unfortunately openser terminated with > >>>> signal 9. I've never seen this before. > >>> > >>> signal 9 is KILL, it is very strange if it was not issued by a user > >>> or other process. > >>> > >>> We discovered the issue (tm/uac.c, line 224), ther eis flag that is > >>> kept to see if there was some operation with the transaction, but in > >>> case of handle_publish() that flag is set by TM api when sending > >>> NOTIFY. The patch is trivial, removing a line, but we have to > >>> investigate if there are some other effects -- so it may take a > >>> while. t_release() should solve meanwhile. > >> > >> Should solve the memory-leak - but the signal 9? > > It might be that it took so long to write the mem long at shut down and > > openser killed itself. If it was not due to a openser stop, then I am > > not aware of any case when signal 9 is sent unless issued by user. > > > > Cheers, > > Daniel > > > >> > >> regards > >> klaus > >> > > > > ------------------------------ > > Message: 2 > Date: Mon, 30 Apr 2007 19:43:41 +0530 > From: Sajith T S <sajithts(a)gmail.com> > Subject: [Users] rtpproxy CPU usage issue.. > To: users(a)openser.org > Message-ID: <4635F995.3020908(a)gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > Hi, > > Have any of you folks seen an abnormal CPU usage issue with rtpprpxy? > At times, "top" shows rtpproxy uses 100% CPU (sometimes 99%, sometimes > even 101%!), and it stops responding to openser. I have to restart > everything now. > > A small thread in Serdev list recommends upgrading rtpproxy to latest > in CVS: > > http://lists.iptel.org/pipermail/serdev/2006-June/007459.html > > Mine was fairly old, so I upgraded, but without much progress. What > really bugs is I don't know what triggers it. > > Backtraces suggest that this occurs in different places in rtpproxy, > before and after upgrading. > > Before upgrade: > > (gdb) where > #0 0xb7f49410 in ?? () > #1 0xbffd6d88 in ?? () > #2 0x00000076 in ?? () > #3 0xbffd2410 in ?? () > #4 0x4a8d9fd1 in sendto () from /lib/tls/libc.so.6 > #5 0x0804ac0c in main (argc=7, argv=0xbffd6e14) at main.c:1467 > > After upgrade: > > (gdb) where > #0 0xb7f0a410 in ?? () > #1 0xbfcb0258 in ?? () > #2 0xbfcadfc0 in ?? () > #3 0xbfcab8e0 in ?? () > #4 0x00bb8dd1 in recvfrom () from /lib/tls/libc.so.6 > #5 0x0804a568 in main (argc=7, argv=0xbfcb02e4) at main.c:1364 > > Any clues? Is this a known problem and is there a patch or some sort > ofworkaround? Is there anything I need to upgrade? (This is CentOS > 4.4, FWIW) Anything that should be done in openser configuration? > > Thanks much in advance. > > - Sajith. > > > > ------------------------------ > > Message: 3 > Date: Mon, 30 Apr 2007 16:27:43 +0200 > From: Edoardo Serra <edoardo.serra(a)webrainstorm.it> > Subject: [Users] Dropped calls with OpenSER 1.1.x and Asterisk >= > 1.2.14 > To: users(a)openser.org > Message-ID: <f14udl$s9t$1(a)sea.gmane.org> > Content-Type: text/plain; charset=ISO-8859-15; format=flowed > > Hi guys, > I'm having a problem about asterisk dropping calls received from OpenSER > > The problems was spotted at Asterisk users mailing lists > http://lists.digium.com/pipermail/asterisk-users/2007-April/184875.html > > Asterisk complains about an ACK not received and drops the calls. > It expects OpenSER to send an ACK back to its '200 OK' when the call is > set up > > Is that a problem OpenSER should solve ??? > > Tnx in advance > > Regards > > Edoardo Serra > WeBRainstorm S.r.l. > > > > > ------------------------------ > > Message: 4 > Date: Mon, 30 Apr 2007 10:54:17 -0500 (CDT) > From: Alejandro Sanchez <alexsc_java(a)yahoo.com.mx> > Subject: Re: [Users] Redirect the same INVITE to the SIP SERVER from > Balancer? > To: daniel(a)voice-system.ro > Cc: openser openser <users(a)openser.org> > Message-ID: <626480.1349.qm(a)web35306.mail.mud.yahoo.com> > Content-Type: text/plain; charset="iso-8859-1" > > Thank's for answer Daniel. > > In fact i think is a retransmission and i need the > balanser ask to the SipServer if the another > videotelephone B is register in every retransmision of > the INVITE. > > I send the trace where: > > -192.168.23 = Balancer (openser) > -192.168.20 = SipServer (openser) > -192.168.4 = VideoTelephone > > In this case there is not another videotelefhone. > > > Thank's > > > > > > --- Daniel-Constantin Mierla <daniel(a)voice-system.ro> > escribi: > > > Hello, > > > > if it happens in very short time, then seems to be a > > retransmission. Can > > you post a sip trace (ngrep, ethereal) taken on the > > balancer? > > > > Cheers, > > Daniel > > > > > > On 04/27/07 22:01, Alejandro Sanchez wrote: > > > Hello. > > > > > > My enviroment is the next: > > > > > > -Balancer > > > OS. Red Hat 4 up. 4 > > > Openser 1.1.1 (balance with the module dispatcher) > > > > > > -Sip Server > > > OS. Red Hat 4 up. 4 > > > Openser 1.1.1 > > > > > > > > > The actual flow is this. > > > > > > VTA B C VTB > > > ---register----> > > > ---register----> > > > <---200 OK------ > > > <----200 OK----- > > > > > > ---invite------> > > > -----invite----> > > > <-404 NotFound-- > > > --404 NotFound-- > > > <----------register--------- > > > ----register----> > > > <----200 OK------ > > > ------------ 200 OK--------> > > > ----invite-----> > > > <-404 NotFound-- > > > > > > VTA= videotelephone A > > > B= balancer (openser 1.1.1 with dispatcher module) > > > C= SipServer (openser 1.1.1) > > > VTB= video telephone B > > > > > > How you see when the VTA sends again the same > > invite, > > > the balancer(B) answer with the 404 not found but > > > without ask again to the SipServer(C), and my > > problem > > > is that VTB is late and i have to try find it in > > the > > > second invite, then in the second invite i need > > ask > > > again to the SipServer(C) if the VTB is register. > > > > > > VTA y VTB access to the IP network making a > > dial-up > > > connection. > > > > > > Why the balancer dosen't send the second invite to > > > SipServer? > > > > > > How do i get this flow? > > > > > > > > > Thank's for the Help > > > > > > > > > __________________________________________________ > > > Correo Yahoo! > > > Espacio para todos tus mensajes, antivirus y > > antispam gratis! > > > Regstrate ya - http://correo.yahoo.com.mx/ > > > > > > _______________________________________________ > > > Users mailing list > > > Users(a)openser.org > > > http://openser.org/cgi-bin/mailman/listinfo/users > > > > > > > > > > > __________________________________________________ > Correo Yahoo! > Espacio para todos tus mensajes, antivirus y antispam gratis! > Regstrate ya - http://correo.yahoo.com.mx/ >

17 years, 6 months

[Serusers] ERROR: t_reply: cannot send a t_reply to a message for which no T-state has been established

by Tuan Nguyen

Dear Gergely and everybody, When I call from UAC1 register in Auth_SER to UAC2 register in Verifer_SER i got follow error: WARNING: no fork mode 0(6759) init_tcp: using epoll_lt as the io watch method (auto detected) 0(6759) Maxfwd module- initializing 0(6759) AUTH_IDENTITY:mod_init: Private key path is missing! Authorization service is disabled 0(6759) INFO: udp_init: SO_RCVBUF is initially 107520 0(6759) INFO: udp_init: SO_RCVBUF is finally 262142 0(6759) BUG: mysql: db_init: called from the main process, ignoring... 0(6759) BUG: mysql: db_init: called from the main process, ignoring... 0(6759) BUG: mysql: db_init: called from the main process, ignoring... 0(6759) BUG: mysql: db_init: called from the main process, ignoring... 0(6759) ERROR: t_reply: cannot send a t_reply to a message for which no T-state has been established 0(6759) ERROR: t_reply: cannot send a t_reply to a message for which no T-state has been established What is T-state, how can i this problem solve? Thank for response. Tuan.

17 years, 6 months

[Serusers] verify.cfg of auth_identity module

by Tuan Nguyen

Dear Gergely, In your documentation of auth_identity, parameter of privatekey_path, certificate_path, certificate_url are belong to "Authoriter service" but in your email 24 Apr, you configure these parameter in vrfy.cfg - "Verifier service". I am confuse with this different. Can you explain this point for me? Thank for response. Tuan.

17 years, 6 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 May 2007