sr-users June 2005

sr-users@lists.kamailio.org

241 participants
595 discussions

by Rosario Pingaro

Hi I am implementing voice mail using ser and sems, ser 0.9.2 and latesr sems from cvs. I have the failure_route[x] to activate the voicemail also when i get an invite timeoute for my users. failure_route[1] { revert_uri(); rewritehostport("xxx.xxx.xxx.xxx:5090"); append_branch(); t_relay_to_udp("xxx.xxx.xxx.xxx", "5090"); } I don't have any problem when i try to leave a voice mail for an "user". On the "alias" the voicemail works fine when the user is offline, but when it is online and get a timeout sems respond with a 404 no email address for user the fact that the voicemail works on alias when it is off line push me to think the problem is into the failure_route. But I don't know what to add to get it working. Any help is welcome. Thanks Rosario

19 years, 3 months

[Serusers] sipath, ser on openwrt

by Klaus Darilion

Hi all! I just found this project: http://sipath.sourceforge.net/ It uses ser+rtpproxy as outboundproxy on openwrt. Looks like the modified the code - the REGISTER will be stored locally, the contact will be re-written and the REGISTER will be forwarded to the real proxy. regards, klaus

19 years, 3 months

[Users] CVS head

by Bogdan-Andrei Iancu

Hi folks, the CVS head now is up-to-date. All new changes (from 0.9.0 to head) from SER were integrated into OpenSER cvs head. LCR and UAC modules are also there. Feel free to give it a try. now the CVS head is ready for forward developing :) bogdan

19 years, 3 months

RE: [Serusers] OpenSER release

by Giudice, Salvatore

I would have to agree with you. The ser module documentation is definitely in the 'abysmal' category, although it has improved somewhat in the last 18 months. For example, at least some documentation on modules like registrar now tell you that the save function returns a 200 ok. To the best of my recollection, this sort of detail wasn't there 18 months ago. If openser can produce decent docs, I can see it getting much broader support. -----Original Message----- From: Kristin Galway [mailto:klgalway@yahoo.com] Sent: Wednesday, June 15, 2005 7:31 PM To: info(a)beeplove.com; greger(a)teigre.com; Giudice, Salvatore; serdev(a)lists.iptel.org; serusers(a)lists.iptel.org Subject: Re: [Serusers] OpenSER release This is my first posting to this list but I have been following for about 5 months now. I began to use SER back in February and have used versions from 0.8.14 to cvs versions and have seen plenty of changes here and there. The biggest thing that really troubles me is the almost non-existent documentation for the modules. There has been more than one occasion where I have run into problems to check the documentation to find no mention of moving things from one module to another, or other things such as new features and what not. Most times I have to dig through the source code to actually find information. The sum of this all is that if the fork of OpenSER is going to present itself as a moving package, with up-to-date documention and more so, not having to wait months upon months for a request or a fix to occur. If OpenSER has that intention then I am all for supporting it and using the code. Just because the current code works for some, does not mean that the rest of us users have to wait for something to happen. Kristin Chapter 2. Developer's Guide To be done. _________________________________________________________ Chapter 3. Frequently Asked Questions 3.1. What is the meaning of life ? 3.1. What is the meaning of life ? 42 --- "m36828253-1(a)imap.1and1.com" <m36828253-1(a)imap.1and1.com> wrote: > Why the bug tracking page in a different website. > Why not under iptel.org ? > > Mohammad > > > Original Message: > ----------------- > From: Greger V. Teigre greger(a)teigre.com > Date: Wed, 15 Jun 2005 21:03:21 +0200 > To: Salvatore.Giudice(a)FMR.COM, serdev(a)lists.iptel.org, > serusers(a)lists.iptel.org > Subject: Re: [Serusers] OpenSER release > > > I completely agree with you. I have been told that > there was an attempt at > introducing a bug-tracking system earlier, but that > it has been difficult. > Anyhow, in setting up policies and procedures around > the experimental > directory, we have decided that usage of > http://bugs.sip-router.org will be > mandatory. Hopefully recent, better integration > between the bug tracking > system and the CVS will make it more convenient to > use also for other CVS > modules (however, I don't have a say there). > g-) > > Giudice, Salvatore wrote: > > I am not an advocate for either ser or openser, > but I would like to > > comment. > > > > Is openser going to be equipped with a > forum/ticket system where > > people can document bugs, feature requests, etc > (non-configuration > > issues)? > > > > This is just my observation and you may not agree, > but I believe this > > project could be much better maintained if it used > a more structured > > ticketing style system to manage development > issues instead of the > > current mailing lists. In my experience, mailing > lists like this > > foster a terrible user experience where many > development issues can > > go on without response. > > > > Ideally, if there was a mailing list to address > user issues and > > ticketing system like the one Digium uses to > manage Asterisk, I think > > everyone would benefit by being better informed > and ser would > > ultimately be a better product for it. How many > people out there feel > > that their issues have fallen through the cracks > in the past couple > > years? > > > > -----Original Message----- > > From: Daniel-Constantin Mierla > [mailto:daniel@voice-system.ro] > > Sent: Wednesday, June 15, 2005 4:28 AM > > To: Andrei Pelinescu-Onciul > > Cc: SER developer mailing list; serusers; > users(a)openser.org; > > devel(a)openser.org > > Subject: Re: [Serusers] OpenSER release > > > > On 06/14/05 23:21, Andrei Pelinescu-Onciul wrote: > > > >> On Jun 14, 2005 at 22:48, Daniel-Constantin > Mierla > > <daniel(a)voice-system.ro> wrote: > >> > >> [...] > >> > >> > >>> It is your opinion, but I repeat myself, that > the SER code > >>> maintained by us will go further -- I don't > think that someone can > >>> claim that we didn't do the job for our code > (the only discrepancy > >>> is some last-minute adds in xlog (to print avps) > - will be > >>> committed on unstable very soon > > > >>> with the new color patch). The cvs was created > just to ease the > >>> maintainance. The patches would be a nightmare. > >>> > >>> > >> > >> Maybe I've misunderstood you: is this only a > parallel "stabilized" > >> version + some features or is it a full fork (do > you intend to fork > >> unstable also)? > >> > >> > > It is fork for the code that we changed (acc > module, usrloc module > > ...), > > > > in the future may be other that they do not find > the path in SER. We > > will maintain and upgrade our part of code from > SER continuously. > > > >> I have no problem with another stable version, > what worries me is > >> fragmenting the development for unstable (which > is the place where > >> major changes are made). > >> > >> > > I see no fragmenting there -- the situation is the > same for SER as it > > was before. For example, there is no fragment for > acc module, it will > > be > > > > maintained by who did it till now, adding what he > considers necessary > > there. But we came to meet a lot of requests of > why the acc patch is > > not > > > > included in the CVS (it was fully backward > compatible and had new > > features requested by many SER users) and we want > to promote _more > > open_ > > > > approach to contributions to all parts of code. > The acc patch was sent > > on November 1, 2004. No real response (neither > negative, nor positive) > > from maintainer to the submission since then ... > are you aware of a > > good > > > > reason?!?! ... should we wait just about (or more) > half an year for > > each > > > > contribution?!? I will not do that anymore!!! > > > > Daniel > > > >> > >> Andrei > >> > >> > >> > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers > __________________________________ Discover Yahoo! Stay in touch with email, IM, photo sharing and more. Check it out! http://discover.yahoo.com/stayintouch.html

19 years, 3 months

RE: [Serusers] Re: [Serdev] openser/ser - avoiding forks

by Giudice, Salvatore

So 31 submitted patches/feature requests were basically ignored in the past year and a half? How can this situation be improved? Is there going to be a commitment to monitor this new ticketing system? How many patches and more feature requests will need to be reconciled 18 months from now? -----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: Wednesday, June 15, 2005 8:57 PM To: Andrei Pelinescu-Onciul Cc: serdev(a)lists.iptel.org; serusers(a)lists.iptel.org Subject: [Serusers] Re: [Serdev] openser/ser - avoiding forks Hello, I am trying to reconcile patches and improvement suggestions that have been left unanswered on the mailing lists. I went through serusers and serdev mailing list archives from the beginning of 2004 till now. I was mainly focusing on submitted patches and non-trivial feature requests. Below is a list of issues that I was able to find in the mailing list archives. Given the number of messages that were sent to the lists in the last year I am pretty sure that the list below will miss many suggestions. If you submitted a patch or improvement and it was neither accepted nor rejected, and it is still relevant, please resubmit your proposal to serdev(a)lists.iptel.org mailing list or (preferably) create an issue in the bug tracking system at: http://bugs.sip-router.org Please re-submit also improvements sent in individual messages to developers. Summary ------- When it comes to accepting improvements, there surely is space for improvements but the situation, in my opinion, is not as bad as it may seem from the recent discussions. Properly reported bugs get usualy fixed quickly. The more detailed description the faster the fix, so I think there are no big problems with that. The list at the end of this message contains patches and feature requests that I was able to find in the archives. From the list the following issues have not yet been closed: 1, 4, 7, 18, 19, 21, 22, 23, 24, 25, 30, 31 And from those only 1, 4, 18, 21, 22, 25, 31 contained patches that have been left unanswered. That 7 patches which still need to be processed. The following patches have in my opinion low importance: 1 - date header in REGISTER replies 18 - radius fix for acc 21 - check_to for digest credentials without database The following patches can be classified as important: 4 - AVP support in acc 22 - transactional auth replies 25 - Free TLS 31 - Xten improvements of pa In addition to that there are the following improvement suggestions which did not contain any patches: 7, 19, 23, 24 So I was able to find 4 important and 3 less important patches that were not integrated in the last 1.5 year from the 31 items below. Also I created issues in the bug tracking system for all items below that are not yet closed. The winner among them in terms of e-mail volume is free TLS, of course. Jan. PS: Code back-porting is another issue and is not covered here. ------------------------------------------------------------------------ ------ SERUSERS - 2004 --------------- 1) Date Header in REGISTER responses Feature request by TeleSIP, I have a patch for that already from Robert Sanders which will be integrated Status: OPEN Bug: SER-30 2) PA interoperability with RTC, patch submitted by Klaus Darilion, integrated by Jamey HICKS Status: CLOSED 3) branch=0 problem reported on 16 Jul 2004, closed by Jiri as "not a bug" Status: CLOSED 4) AVP patch for acc module, submitted by Ramona on 31 Oct 2004 Status: OPEN Bug: SER-31 SERDEV - 2004 ------------- 5) Video - related patch for nathelper, integrated by Maxim Status: CLOSED 6) fix_nated_contact for nathelper (replied by Maxim) Status: CLOSED 7) 16 Apr 2004 Juha proposed adding npdi and pstn URI parameters (no patches) Status: OPEN Bug: SER-32 8) Maxim submitted patch adding PIDs of all processes into the pid file, resolved by another means Status: CLOSED 9) 20 Apr. 2004 Alexander Mayhofer submitted patch for rtpproxy, commited by Maxim Status: CLOSED 10) Test for realm in auth_radius too tight, reported by Cesar Hernandez, fixed by Jan Status: CLOSED 11) 23 Apr 2004 Multicast support patch, commited by Andrei Status: CLOSED 12) 24 Apr 2004 Postgres patch by Alexander Mayhofer, in CVS Status: CLOSED 13) max_expires patch submitted by Jamey Hicks, in CVS Status: CLOSED 14) start/stop commands fro SEMS into serctl by Klaus Darilion, rejected. Status: CLOSED 15) 30 Jun 2004 User agent support in xlog module by Alexander Mayhofer, in cvs Status: CLOSED 16) 7 Jul 2004 Patch for configurable user agent string by Maxim, resolved by other means Status: CLOSED 17) 21 Jul 2004 Patch for storing user agent string in location table, commited by Maxim Status: CLOSED 18) 21 Jul 2004 Radius-related patch for acc module Status: OPEN Bug: SER-33 19) 2 Oct 2004 Escaped uri characters are not interpreted properly, no patch Status: DEFERED Bug: SER-34 20) 27 Oct 2004 Mysql_ping patch by Dan Pascu, in cvs Status: CLOSED 21) 10 Nov 2004 uri_db patch to make it possible to use check_to and check_from without database (submitted by Marian Dumitru). Status: OPEN Bug: SER-35 22) 25 Dec 2004 Maxim's patch to make it possible send transactional replies from authentication modules Status: OPEN Bug: SER-36 23) Additional header fields requested by Juha (server, refer-to) Status: OPEN Bug: SER-37 SERUSERS - 2005 --------------- 24) feature request route("string") Status: DEFERED Bug: SER-38 25) Free TLS Status: OPEN Bug: SER-39 26) 19 Apr 2005 branch=0 in ACK problem, rejected by Jiri Status: CLOSED 27) 20 Apr 2005 mysql_ping patch for 0.8.14, not important enough to be commited to 0.8.14 Status: CLOSED 28) Backport of radius auth changes from unstable to stable, rejected Status: CLOSED SERDEV - 2005 ------------- 29) Transaction replies in auth modules (by Maxim) Status: OPEN Bug: SER-36 30) NAT support in usrloc and registrar, partially done Status: OPEN Bug: SER-40 31) RFC3265,RFC3903 support in pa, I could not find the patch Status: OPEN Bug: SER-41 _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers

19 years, 3 months

RE: [Serusers] OpenSER release

by Giudice, Salvatore

Maybe extending the documentation with a Wiki would prove effective without putting too much responsibility on any one maintainer's shoulders. This would also cut down on the number of repeat questions on the SER user's list. -----Original Message----- From: Maxim Sobolev [mailto:sobomax@portaone.com] Sent: Thursday, June 16, 2005 4:30 AM To: Alberto Cruz Cc: Greger V. Teigre; SER developer mailing list; Giudice, Salvatore; serusers Subject: Re: [Serusers] OpenSER release On Wed, Jun 15, 2005 at 10:57:06PM -0500, Alberto Cruz wrote: > And what about documentation? When was the last time that Administration > Guide was updated? And what about the Modules documentation? Are you volunteering? -Maxim

19 years, 3 months

[Serusers] storing voice messages

by Llanos Serna García-Conde

Hi all, I'm using SEMS and it works fine. I know it stores the voices messages in /tmp directory for a very short time before sending them to the e-mail addresses. I would like to store them permanently, how can I do that? Thanks for your help, Llanos

19 years, 3 months

[Users] RE: [Serusers] OpenSER release

by Giudice, Salvatore

Policy is only as good as its communication to the people it applies to. Besides the initial announcement, how many times was this site publicized in the mailing list or enforced as standard practice to have patches added to the project? -----Original Message----- From: Jan Janak [mailto:jan@iptel.org] Sent: Wednesday, June 15, 2005 9:08 PM To: info(a)beeplove.com Cc: Giudice, Salvatore; daniel(a)voice-system.ro; andrei(a)iptel.org; serdev(a)iptel.org; serusers(a)iptel.org; devel(a)openser.org; users(a)openser.org Subject: Re: [Serusers] OpenSER release There is such a bug tracking system running at http://bugs.sip-router.org It is powered by Jira and is quite easy to use. I announced it to serdev mailing list some time ago but there seemed to be no interest, from core developers only myself and Andrei created accounts. I was using it for a while and I find it easy to use and convenient. Jan. On 15-06-2005 14:24, info(a)beeplove.com wrote: > I agree with you. > We should have proper bug tracking system, including feature request. > > MOhammad > > > > Original Message: > ----------------- > From: Giudice, Salvatore Salvatore.Giudice(a)FMR.COM > Date: Wed, 15 Jun 2005 14:12:15 -0400 > To: daniel(a)voice-system.ro, andrei(a)iptel.org, serdev(a)iptel.org, > serusers(a)iptel.org, devel(a)openser.org, users(a)openser.org > Subject: RE: [Serusers] OpenSER release > > > I am not an advocate for either ser or openser, but I would like to > comment. > > Is openser going to be equipped with a forum/ticket system where people > can document bugs, feature requests, etc (non-configuration issues)? > > This is just my observation and you may not agree, but I believe this > project could be much better maintained if it used a more structured > ticketing style system to manage development issues instead of the > current mailing lists. In my experience, mailing lists like this foster > a terrible user experience where many development issues can go on > without response. > > Ideally, if there was a mailing list to address user issues and > ticketing system like the one Digium uses to manage Asterisk, I think > everyone would benefit by being better informed and ser would ultimately > be a better product for it. How many people out there feel that their > issues have fallen through the cracks in the past couple years? > > -----Original Message----- > From: Daniel-Constantin Mierla [mailto:daniel@voice-system.ro] > Sent: Wednesday, June 15, 2005 4:28 AM > To: Andrei Pelinescu-Onciul > Cc: SER developer mailing list; serusers; users(a)openser.org; > devel(a)openser.org > Subject: Re: [Serusers] OpenSER release > > On 06/14/05 23:21, Andrei Pelinescu-Onciul wrote: > > >On Jun 14, 2005 at 22:48, Daniel-Constantin Mierla > <daniel(a)voice-system.ro> wrote: > > > >[...] > > > > > >>It is your opinion, but I repeat myself, that the SER code maintained > by > >>us will go further -- I don't think that someone can claim that we > >>didn't do the job for our code (the only discrepancy is some > last-minute > >>adds in xlog (to print avps) - will be committed on unstable very soon > > >>with the new color patch). The cvs was created just to ease the > >>maintainance. The patches would be a nightmare. > >> > >> > > > >Maybe I've misunderstood you: is this only a parallel "stabilized" > >version + some features or is it a full fork (do you intend to fork > >unstable also)? > > > > > It is fork for the code that we changed (acc module, usrloc module ...), > > in the future may be other that they do not find the path in SER. We > will maintain and upgrade our part of code from SER continuously. > > >I have no problem with another stable version, what worries me is > >fragmenting the development for unstable (which is the place where > major > >changes are made). > > > > > I see no fragmenting there -- the situation is the same for SER as it > was before. For example, there is no fragment for acc module, it will be > > maintained by who did it till now, adding what he considers necessary > there. But we came to meet a lot of requests of why the acc patch is not > > included in the CVS (it was fully backward compatible and had new > features requested by many SER users) and we want to promote _more open_ > > approach to contributions to all parts of code. The acc patch was sent > on November 1, 2004. No real response (neither negative, nor positive) > from maintainer to the submission since then ... are you aware of a good > > reason?!?! ... should we wait just about (or more) half an year for each > > contribution?!? I will not do that anymore!!! > > Daniel > > > > >Andrei > > > > > > > > _______________________________________________ > Serusers mailing list > Serusers(a)iptel.org > http://mail.iptel.org/mailman/listinfo/serusers > > _______________________________________________ > Serusers mailing list > Serusers(a)iptel.org > http://mail.iptel.org/mailman/listinfo/serusers > > -------------------------------------------------------------------- > mail2web - Check your email from the web at > http://mail2web.com/ . > > > _______________________________________________ > Serusers mailing list > Serusers(a)iptel.org > http://mail.iptel.org/mailman/listinfo/serusers

19 years, 3 months

[Serusers] Problem on pthread and dtmf

by Nicky

Dear all, 1. Please help, when i run sems -E i experienced this error, what can be the caused of it:~ ~~11352) ERROR: start (AmThread.cpp:73): pthread create failed with code 12 2. There is signal of DTMF which is not pressed but is being send to the server, please see below for the log. Please advice what can be the caused and problem. Thank you in advance. ~~(4395) DEBUG: isdn_audio_eval_dtmf_relative (IvrDtmfDetector.cpp:349): Posting D TMF 0: 5 (5) (4395) DEBUG: postEvent (AmEventQueue.cpp:47): AmEventQueue: trying to post even t (4395) DEBUG: postEvent (AmEventQueue.cpp:55): AmEventQueue: event posted (4395) DEBUG: processEvents (AmEventQueue.cpp:68): before processing event (4395) DEBUG: process (IvrPython.cpp:988): IvrPython processing event... (4395) DEBUG: process (IvrPython.cpp:991): IvrDialog processing event... (4395) DEBUG: onDTMFEvent (IvrPython.cpp:1130): IvrPython::onDTMFEvent(): callin g onDTMFCallback key is 5... (4395) DEBUG: ivrEmptyMediaQueue (IvrPython.cpp:102): IVR: emptying media queue . (4395) DEBUG: IvrMediaEvent (IvrEvents.cpp:31): New Media Event: 1, (4395) DEBUG: postEvent (AmEventQueue.cpp:47): AmEventQueue: trying to post even t (4395) DEBUG: postEvent (AmEventQueue.cpp:55): AmEventQueue: event posted (4395) DEBUG: ivrStopRecording (IvrPython.cpp:132): IVR: stop recording. best regards, nicky

19 years, 3 months

[Serusers] MediaProxy NO sound

by TCCHAN

Dear All, I apologize for asking a repeated question. I tried ser 0.8.14 and 0.9 to work with mediaproxy. I could setup call but there are silence. I did try to bypass the proxydispatcher modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy.sock") #modparam("mediaproxy", "mediaproxy_socket","/var/run/proxydispatcher.sock") and the result is the same. I have been stuck for days. Thanks in advenced for any help available. Regards, TC Chan The proxydispatcher dump the following: [root@ser mediaproxy]# ./proxydispatcher.py --no-fork Listening for commands on local socket `/var/run/proxydispatcher.sock' Default mediaproxy server is on `/var/run/mediaproxy.sock' command request fe5a6f36-c6092310(a)192.228.118.240 192.228.118.240:18278:audio 210.187.111.86 219.94.42.174 remote 210.187.111.86 remote Sipura/SPA2000-2.0.13(g) info=from:01548900@219.94.42.174,to:01548901@219.94.42.174,fromtag:d9170fe31e4cbe8o0,totag: forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '127.0.0.1 35000' command execution time: 16.89 ms command lookup fe5a6f36-c6092310(a)192.228.118.240 192.228.118.240:18280:audio 210.187.111.86 219.94.42.174 remote 219.94.42.174 unknown Sipura/SPA2000-2.0.13(g) info=from:01548900@219.94.42.174,to:01548901@219.94.42.174,fromtag:d9170fe31e4cbe8o0,totag:8f2251e89d625018i1 forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '127.0.0.1 35000' command execution time: 3.92 ms After a long while .......... command delete fe5a6f36-c6092310(a)192.228.118.240 info= forwarding to mediaproxy on /var/run/mediaproxy.sock: got: '' command execution time: 2.53 ms While Mediaproxy dump the following: [root@ser mediaproxy]# ./mediaproxy.py --no-fork Listening for commands on local socket `/var/run/mediaproxy.sock' Listening for remote commands is disabled Using IP address `127.0.0.1' for the RTP/RTCP proxy command request fe5a6f36-c6092310(a)192.228.118.240 192.228.118.240:18278:audio 210.187.111.86 219.94.42.174 remote 210.187.111.86 remote Sipura/SPA2000-2.0.13(g) info=from:01548900@219.94.42.174,to:01548901@219.94.42.174,fromtag:d9170fe31e4cbe8o0,totag:,dispatcher session fe5a6f36-c6092310(a)192.228.118.240: started. listening on 127.0.0.1:35000 command execution time: 11.72 ms command lookup fe5a6f36-c6092310(a)192.228.118.240 192.228.118.240:18280:audio 210.187.111.86 219.94.42.174 remote 219.94.42.174 unknown Sipura/SPA2000-2.0.13(g) info=from:01548900@219.94.42.174,to:01548901@219.94.42.174,fromtag:d9170fe31e4cbe8o0,totag:8f2251e89d625018i1,dispatcher command execution time: 1.32 ms command status command execution time: 0.36 ms session fe5a6f36-c6092310(a)192.228.118.240: 0/0/0 packets, 0/0/0 bytes (caller/called/relayed) session fe5a6f36-c6092310(a)192.228.118.240: ended (did timeout). command status command execution time: 0.18 ms command delete fe5a6f36-c6092310(a)192.228.118.240 info=dispatcher command execution time: 0.24 ms Session dump the following: ./[root@ser mediaproxy]# ./sessions.py Caller Via Called Status Duration Codec Type Traffic ------------------------------------------------------------------------------------------------------------ 192.228.118.240:18278 - 127.0.0.1:35000 - 192.228.118.240:18280 inactive 0'04" Unknown Audio 0/0/0 Total traffic: 0bps/0bps/0bps (in1/in2/out) Session count: 1 [root@ser mediaproxy]# ./sessions.py No RTP sessions My ser script is as follow: #debug=3 #fork=no #log_stderror=yes check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) #port=5060 #children=4 fifo="/tmp/ser_fifo" # ------------------ module loading ---------------------------------- #loadmodule "/usr/local/lib/ser/modules/nathelper.so" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/xlog.so" loadmodule "/usr/local/lib/ser/modules/exec.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/group.so" loadmodule "/usr/local/lib/ser/modules/textops.so" #loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/domain.so" loadmodule "/usr/local/lib/ser/modules/mediaproxy.so" #---------------------------------------------------------------------- # mediaproxy modparam("mediaproxy", "natping_interval", 60) #modparam("mediaproxy", "mediaproxy_socket", "/var/run/mediaproxy.sock") modparam("mediaproxy", "mediaproxy_socket", "/var/run/proxydispatcher.sock") modparam("registrar", "nat_flag", 2) #---------------------------------------------------------------------- #---------------------------------------------------------------------- # uri #modparam("uri", "db_url", "sql://root:heslo@localhost/ser") #modparam("uri", "uri_table", "subscriber") #---------------------------------------------------------------------- #---------------------------------------------------------------------- # TCN: no forking #modparam("registrar","desc_time_order",1) #modparam("usrloc","desc_time_order",1) #modparam("registrar","append_branches",0) #----------------------------------------------------------------------- # ----------------- setting module-specific parameters --------------- modparam("usrloc", "db_mode", 1) #modparam("usrloc", "db_mode", 2) #------------------------------------------------------------------------------------- #TCN: To chnage the database loc to remote PC change the following lines #grep -r 'db_url' sersrc review that the following modules need to be changed: # group,vm,usrloc,uri,domain,jabber,auth_db,pdt,acc,msilo #modparam("auth_db", "db_url", "sql://root:heslo@219.94.42.174/ser") #modparam("usrloc", "db_url", "sql://root:heslo@219.94.42.174/ser") #modparam("group", "db_url", "sql://root:heslo@219.94.42.174/ser") modparam("acc", "db_url", "mysql://root:heslo@localhost/ser") modparam("auth_db", "db_url", "mysql://root:heslo@localhost/ser") modparam("usrloc", "db_url", "mysql://root:heslo@localhost/ser") modparam("group", "db_url", "mysql://root:heslo@localhost/ser") #------------------------------------------------------------------------------------- modparam("auth_db", "calculate_ha1", yes) modparam("auth_db", "password_column", "password") modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 30 ) ################### NAT ##################### # We will you flag 6 to mark NATed contacts #modparam("registrar", "nat_flag", 6) # Enable NAT pinging #modparam("nathelper", "natping_interval", 3) # Ping only contacts that are known to be # behind NAT #modparam("nathelper", "ping_nated_only", 1) ############################################## #---------------------------------------------------------------------- # accounting #modparam("acc", "log_flag", 2) #modparam("acc", "db_flag", 2) #---------------------------------------------------------------------- alias="redtone" alias="redtone.sip" alias="redtone.sip.com" alias="redtone.sip.com.my" # ------------------------- request routing logic ------------------- route { # initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); xlog ("L_ERR","-----------------------------------------------------------------\r\n\r\n\r\n\r\n"); break; }; if ( msg:len > max_len ) { sl_send_reply("513", "Message too Large"); xlog ("L_ERR","-----------------------------------------------------------------\r\n\r\n\r\n\r\n"); break; }; if (method=="REGISTER") { xlog("L_ERR","xlog %Tf: REGISTER route uri:%ru method:%rm\r\nfrom:% fu To:%tu Contact:%ct\r\n\r\n\r\n"); #if (is_from_local()) #{ xlog("L_ERR","xlog %Tf: FROM LOCAL REGISTER route uri:%ru method:%rm\r\nfrom:%fu To:%tu Contact:%ct\r\n\r\n\r\n"); # Mark as NAT'ed if (client_nat_test("3")) { #setflag(2); force_rport(); fix_contact(); }; xlog("L_ERR","xlog %Tf: start REGISTER route uri:%ru method:%rm\r \nfrom:%fu To:%tu Contact:%ct\r\n\r\n\r\n"); if (!www_authorize("redtone", "subscriber")) { xlog("L_ERR","%fu failed authentification!\r\n"); www_challenge("redtone", "0"); xlog("L_ERR","%fu failed authentification and challenge!\r\n"); xlog ("L_ERR","-----------------------------------------------------------------\r\n\r\n\r\n\r\n"); break; }; save("location"); xlog("L_ERR","username %fu location REGISTERed!\r\n"); xlog ("L_ERR","-----------------------------------------------------------------\r\n\r\n\r\n\r\n"); break; /* } else { xlog("L_ERR","This domain is not served here!\r\n"); sl_send_reply("403", "This domain is not served here"); }; */ break; }; /* if (method=="INVITE") { if (!(is_from_local() || is_uri_host_local())) { sl_send_reply("403", "Relaying is forbidden"); break; }; t_on_failure("1"); } else */ if (method == "BYE" || method == "CANCEL") { end_media_session(); }; /* if (loose_route()) { if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; # end media session for BYE and CANCEL is done above # before entering the loose route. no need to call it here t_relay(); break; }; */ # Force subsequent messages to pass trough this proxy if (method == "INVITE") { record_route(); }; if (client_nat_test("3") && !search("^Record-Route:")) { # Mark as NAT'ed force_rport(); fix_contact(); }; if (method=="INVITE") { t_on_reply("1"); }; # if (is_uri_host_local()) { if (!lookup("location")) { sl_send_reply("404", "User not found"); break; }; # }; if (method=="INVITE" || method=="ACK") { use_media_proxy(); }; if (!t_relay()) { if (method=="INVITE" || method=="ACK") { end_media_session(); }; sl_reply_error(); }; } failure_route[1] { end_media_session(); } onreply_route[1] { if (status=~"(183)|(2[0-9][0-9])") { #if (status=~"200") { if (client_nat_test("1")) { fix_contact(); }; use_media_proxy(); }; }

19 years, 3 months

← Newer
1
...
29
30
31
32
33
34
35
...
60
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 June 2005