Hi,
I am having problems troubleshooting a problem I am experiencing with my SER configuration. I have ser 0.8.14 running with rtpproxy and nathelper enabled. I have two phones on the same subnet behind nat and I would like to make a call between the two. I want to invoke rtpproxy for this as they both have private address [I know this isnt the most efficient way as theyre both on the same subnet but I can worry about that later].
When I ring from the phone 1 (2092) to phone 2 (2093), 2092 can hear voice but 2093 cant. When 2093 ring 2092, theres no audio. These phones are Grandstream BT100s. They have been configured to listen on different SIP and RTP ports.
2092: SIP Port: 5060
2092: RTP Port: 5004
2093: SIP Port: 5061
2093: RTP Port: 5005
I have included my ser.cfg file the messages received on my SER server (using ngrep SIP-q)in an attachment. I can confirm that my rtpproxy is working (originally I thought it wasnt) by using strace d <rtpproxy pid> -f F. I can see a signal being returned.
Any help would be appreciated or advise as to how I can proceed troubleshooting.
Kindest Regards,
Vivienne.
Send instant messages to your online friends http://uk.messenger.yahoo.com
[...]
Binding '497','sip:497@192.168.0.136:5060' has expired
[...]
Any ideas how to stop sipphones making theese logs ?
--
Pozdrawiam,
Wojciech Ziniewicz
Optocomp sp.z.o.o, www.optocomp.pl
mailto: wojtekz(a)optocomp.pl
+48(0)691031535
Hello:
I am getting the 'ul_add: flags expected' error with v0.9.0 and
serctl. There is
some chatter in the archives about the perm column in the subscriber table
but it is unclear to me if this is how to fix the problem? Any ideas?
Thanks,Steve
--
ISC Network Engineering
The University of Pennsylvania
3401 Walnut Street, Suite 221A
Philadelphia, PA 19104
voice: 215-573-8396
215-746-8001
fax: 215-898-9348
sip:blairs@upenn.edu
Forwarding a call from Asterisk to Microsoft Live Communication Server 2005
via SER (to translate from UDP to TCP), I get a 'one-way' communication
(WMessenger user can hear voice but PSTN phone user cannot).
Running SER in debug mode, I found:
DEBUG: RFC3261 transaction matching failed
DEBUG: t_lookup_request: no transaction found
Searching Google, I found that this is a known bug in Asterisk.
I upgraded to 1.0.7 (Debian unstable) but bug is still present.
Peraphs, Asterisk mailing-list would be a better choice for this message but
anyway can someone confirm this?
Thanks
Domenico Viggiani
I installed the following from the onsip site. I did "tar -zxvf
ser-0.9.etcetc" in the /usr/local directory and then ran the scripts.
Do I start ser now by doing /usr/local/sbin/serctl start. I am still
getting the error /var/run/ser.pid does not exist when I do that.
Could someone let me know a command how to delete all ser files from
my computer and then confirm that I should unzip the ser 0.9.0 source
file in the /usr/local directory.
Thanks a million,
Aisling.
>---- Original Message ----
>From: greger(a)teigre.com
>To: ashling.odriscoll(a)cit.ie
>Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>Date: Wed, 30 Mar 2005 07:46:06 +0200
>
>>Aisling,
>>
>>We have now also posted a complete 0.9.0 source package on
>>http://www.onsip.org/. It comes with a simple script that will
>compile and
>>install most of the modules (including cpl) either to the default
>directory
>>/usr/local/*/ser or to a directory of your choice. The package was
>created
>>as a part of the "Getting Started" effort to support speedy upstart
>of a
>>full SER installation.
>>
>>Regards,
>>Greger
>>
>>Java Rockx wrote:
>>> Great. Now you need to compile the mysql support module.
>>>
>>> You can get a full how-to at http://www.onsip.org
>>>
>>> Just register and download the "Getting Started" document. This
>should
>>> be enough to get your using the mysql module.
>>>
>>> As for cpl but I suspect that it simply isn't complied by default.
>>>
>>> You can compile it by changing to your ser source directory and
>doing
>>> this:
>>>
>>> make exclude_modules="" modules
>>>
>>> Then copy the <ser-source>/modules/cpl-c/*.so to
>>> /usr/loca/lib/ser/modules
>>>
>>> Regards,
>>> Paul
>>>
>>>
>>> On Tue, 29 Mar 2005 17:34:38 +0100, Aisling O'Driscoll
>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>> I have deleted all the "modules" directories from my system other
>>>> than /usr/local/lib/ser. However /usr/local/lib/ser doesnt
>contain
>>>> modules such as mysql.so, cpl-c.so etc. Is this normal?? If it is
>>>> then what how do I check these modules out cvs?. I have
>downloaded
>>>> the latest SER source code and made the SER binaries 2 more times
>>>> (according the onsip document) to make sure I running the most
>>>> up-to-date code.
>>>>
>>>> I apologise for lack of linx knowledge and very much appreciate
>the
>>>> help I have been given so far.
>>>>
>>>> Aisling.
>>>>>
>>>>> ---- Original Message ----
>>>>> From: javarockx(a)gmail.com
>>>>> To: ashling.odriscoll(a)cit.ie
>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>> Date: Tue, 29 Mar 2005 10:19:52 -0500
>>>>>
>>>>>> Again, this sounds like you've got more than one version of ser
>on
>>>>> your system.
>>>>>>
>>>>>> I don't know where 0.8.14 kept it's modules but you can find
>other
>>>>> ser
>>>>>> modules (and remove them).
>>>>>>
>>>>>> to find them do this as root
>>>>>>
>>>>>> find / -name mysql.so
>>>>>>
>>>>>> you may find more than ser modules with this but it should spit
>out
>>>>>> the directory that 0.8.14 used.
>>>>>>
>>>>>> ser-0.9 keeps its modules in /usr/local/lib/ser
>>>>>>
>>>>>> Regards,
>>>>>> Paul
>>>>>>
>>>>>>
>>>>>> On Tue, 29 Mar 2005 15:53:56 +0100, Aisling O'Driscoll
>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>> Yes that was it. Thanks. I promise I'm nearly there!I replaced
>the
>>>>>>> default script with the ser.cfg I was running with 0.8.14. I
>am
>>>>>>> getting two mismatch errors with the script though:
>>>>>>>
>>>>>>> ERROR: module version mismatch for
>>>>>>> /usr/local/lib/ser/modules/mysql.so; core: ser 0.9.1
>(i386/linux);
>>>>>>> module ser 0.9.0 (i386/linux).
>>>>>>> Its the same for the cpl module.
>>>>>>>
>>>>>>> Can I run a command to update the modules only? Also I'm a bit
>>>>>>> confused if the mysql database that I was using with 0.8.14 is
>>>>> still
>>>>>>> valid? Do I have create new tables (ser_mysql.sh create etc)is
>the
>>>>>>> current database sufficient?
>>>>>>>
>>>>>>> Many thanks,
>>>>>>> Aisling.
>>>>>>>
>>>>>>>>
>>>>>>>> ---- Original Message ----
>>>>>>>> From: greger(a)teigre.com
>>>>>>>> To: javarockx(a)gmail.com, ashling.odriscoll(a)cit.ie,
>>>>> serusers(a)iptel.org
>>>>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>>>>> Date: Tue, 29 Mar 2005 16:29:49 +0200
>>>>>>>>
>>>>>>>>> This is the default ser.cfg problem: Remove the
>>>>>>>>> force_send_socket line with reference to the smaug server.
>>>>>>>>> I thought this was changed in CVS (a test cfg file was
>>>>>>>>> committed to cvs in an error).
>>>>>>>>> g-)
>>>>>>>>>
>>>>>>>>> Java Rockx wrote:
>>>>>>>>>> your ser.cfg is in /usr/local/etc/ser
>>>>>>>>>>
>>>>>>>>>> I've not seen your ser.cfg file - so I can't really say.
>>>>>>>>>>
>>>>>>>>>> Regards,
>>>>>>>>>> Paul
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Tue, 29 Mar 2005 15:10:30 +0100, Aisling O'Driscoll
>>>>>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>>>>>> Thanks,I've made that change. Any idea about why SER wont
>>>>>>>>>>> start? The following error is in /varlog/messages:
>>>>>>>>>>>
>>>>>>>>>>> /usr/local/sbin/ser[7966]: ERROR: fix_actions:
>>>>> force_send_socket:
>>>>>>>>>>> could not resolvbe smaug.
>>>>>>>>>>>
>>>>>>>>>>> Also where is my new ser.cfg stored. My old one is in
>>>>> etc/ser.
>>>>>>>>>>>
>>>>>>>>>>> Thanks,
>>>>>>>>>>> Aisling
>>>>>>>>>>>
>>>>>>>>>>> ---- Original Message ----
>>>>>>>>>>> From: javarockx(a)gmail.com
>>>>>>>>>>> To: ashling.odriscoll(a)cit.ie
>>>>>>>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>>>>>>>> Date: Tue, 29 Mar 2005 09:08:24 -0500
>>>>>>>>>>>
>>>>>>>>>>>> your PATH should actually be
>>>>>>>>>>>>
>>>>>>>>>>>> PATH=$PATH:/usr/local/sbin:.
>>>>>>>>>>>>
>>>>>>>>>>>> Regards,
>>>>>>>>>>>> Paul
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue, 29 Mar 2005 14:36:56 +0100, Aisling O'Driscoll
>>>>>>>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>>>>>>>> Thanks for the replies so far - Everyone has been very
>>>>>>>>>>>>> helpful. I have one final question. I deleted the "ser"
>>>>>>>>>>>>> directory from
>>>>>>>>>>>> /usr/sbin
>>>>>>>>>>>>> as suggested. I am using Suse Linux 9.0 so then I
>modified
>>>>> the
>>>>>>>>>>>>> "profile" file in the /etc directory with the following:
>>>>>>>>>>>>>
>>>>>>>>>>>>> PATH="$PATH:/usr/local/sbin/ser:."
>>>>>>>>>>>>>
>>>>>>>>>>>>> Then I carried out the cvs instructions from the iptel
>site
>>>>> (as
>>>>>>>>>>>>> detailed at end of this mail) to install SER 0.9.1. When
>I
>>>>>>>>>>>>> run "ser -V" I now see that SER has been updated.
>However
>>>>>>>>>>>>> when I run /usr/local/sbin/serctl start to start SER. I
>get
>>>>>>>>>>>>> an error:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Starting SER: PID file /var/run/ser.pid does not exist
>--
>>>>>>>>>>>>> SER start failed.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I used to start SER using /etc/init.d/ser start. That
>also
>>>>>>>> doesn't
>>>>>>>>>>>>> work. What could be wrong? Also where is my new ser.cfg
>>>>>>>>>>>>> file stored? My old one is still in /etc/ser.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks again.
>>>>>>>>>>>>> Aisling.
>>>>>>>>>>>>>
>>>>>>>>>>>>> cd /usr/src
>>>>>>>>>>>>> export
>>>>> CVSROOT=:pserver:anonymous@cvs.berlios.de:/cvsroot/ser
>>>>>>>>>>>>> cvs login
>>>>>>>>>>>>> [enter for password]
>>>>>>>>>>>>> "cvs co -r rel_0_9_0 sip_router" from onsip site.
>>>>>>>>>>>>> cd sip_router
>>>>>>>>>>>>> make all
>>>>>>>>>>>>> make install
>>>>>>>>>>>>>
>>>>>>>>>>>>>> ---- Original Message ----
>>>>>>>>>>>>>> From: javarockx(a)gmail.com
>>>>>>>>>>>>>> To: ashling.odriscoll(a)cit.ie
>>>>>>>>>>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>>>>>>>>>>> Date: Tue, 29 Mar 2005 08:07:35 -0500
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Each linux user has an environment variable called
>PATH.
>>>>> You
>>>>>>>> can
>>>>>>>>>>>> set
>>>>>>>>>>>>>>> your path in the .bash_profile (assuming a redhat
>linux
>>>>>>>> distro).
>>>>>>>>>>>>>>> Consult your linux distro for setting environment
>>>>> variables.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On most you can just do this:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> export PATH=$PATH:/usr/local/sbin/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But this will only be for you current logged in
>session.
>>>>> When
>>>>>>>> you
>>>>>>>>>>>>>> exit
>>>>>>>>>>>>>>> the bash shell this setting will be lost.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Tue, 29 Mar 2005 13:50:18 +0100, Aisling O'Driscoll
>>>>>>>>>>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>>>>>>>>>>> Apologies if this is a ridculous question where will
>I
>>>>> find
>>>>>>>> the
>>>>>>>>>>>>>> $PATH
>>>>>>>>>>>>>>>> variable?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks,
>>>>>>>>>>>>>>>> Aisling
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ---- Original Message ----
>>>>>>>>>>>>>>>>> From: javarockx(a)gmail.com
>>>>>>>>>>>>>>>>> To: ashling.odriscoll(a)cit.ie, serusers(a)iptel.org
>>>>>>>>>>>>>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>>>>>>>>>>>>>> Date: Tue, 29 Mar 2005 07:49:44 -0500
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> it looks like you have two copies of ser on your
>>>>> machine.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> You should complete remove /usr/sbin/ser and make
>sure
>>>>>>>>>>>>>>>>>> /usr/local/sbin/ser is in your $PATH.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Tue, 29 Mar 2005 13:43:56 +0100, Aisling
>O'Driscoll
>>>>>>>>>>>>>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> When I type "which ser". I get /usr/sbin/ser. How
>can
>>>>> I
>>>>>>>>>>>>>>>>>>> proceed from here?. Thank you for the reply.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Aisling.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> ---- Original Message ----
>>>>>>>>>>>>>>>>>>> From: javarockx(a)gmail.com
>>>>>>>>>>>>>>>>>>> To: ashling.odriscoll(a)cit.ie
>>>>>>>>>>>>>>>>>>> Subject: Re: [Serusers] SER 0.8.14 to 0.9.0
>>>>>>>>>>>>>>>>>>> Date: Tue, 29 Mar 2005 06:46:20 -0500
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Aisling,
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It seems like one of the following is true:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 1) you're somehow mixing 0.8.14 source code with
>>>>> 0.9.1
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> 2) you have more than one copy of ser installed
>on
>>>>> your
>>>>>>>>>>>>>>>>>>>> system. If you
>>>>>>>>>>>>>>>>>>>> type "which ser" does it point to
>>>>> /usr/local/sbin/ser ??
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Regards,
>>>>>>>>>>>>>>>>>>>> Paul
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Tue, 29 Mar 2005 09:55:06 +0100, Aisling
>>>>> O'Driscoll
>>>>>>>>>>>>>>>>>>>> <ashling.odriscoll(a)cit.ie> wrote:
>>>>>>>>>>>>>>>>>>>>> Hello,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> I am still trying to change my SER version from
>>>>>>>>>>>>>>>>>>>>> 0.8.14 to
>>>>>>>>>>>>>>>>>>>>> 0.9.0. I have
>>>>>>>>>>>>>>>>>>>>> followed the instructions at the following link
>and
>>>>>>>> also
>>>>>>>>>>>> on
>>>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>>>>> onsip
>>>>>>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>>>>>> http://www.iptel.org/ser/cvs/
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> However when I run ser -V, I still see that I'm
>>>>> running
>>>>>>>>>>>>>>>>>>>>> 0.8.14. I've given an exact detail of what i do
>>>>>>>>>>>>>>>>>>>>> below and can someone
>>>>>>>>>>>>>> PLEASE
>>>>>>>>>>>>>>>>>>>>> PLEASE point out the mistake. Thank you.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> cd /usr/src
>>>>>>>>>>>>>>>>>>>>> export
>>>>>>>>>>>>>> CVSROOT=:pserver:anonymous@cvs.berlios.de:/cvsroot/ser
>>>>>>>>>>>>>>>>>>>>> cvs login
>>>>>>>>>>>>>>>>>>>>> [enter for password]
>>>>>>>>>>>>>>>>>>>>> Here I've tried both "cvs co sip_router" for
>>>>> unstable
>>>>>>>>>>>>>>>>>>>>> version and "cvs co -r rel_0_9_0 sip_router"
>from
>>>>> onsip
>>>>>>>>>>>>>>>>>>>>> site.
>>>>>>>>>>>>>>>>>>>>> cd sip_router
>>>>>>>>>>>>>>>>>>>>> make all
>>>>>>>>>>>>>>>>>>>>> make install
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> It says every file is updated but I still run
>the
>>>>>>>>>>>>>>>>>>>>> same stable version. I've killed all ser
>processes
>>>>>>>>>>>>>>>>>>>>> before running this command (killall ser)
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Please let me know what Im doing wrong,
>>>>>>>>>>>>>>>>>>>>> Aisling.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> The above electronic mail transmission is
>>>>> confidential
>>>>>>>>>>>> and
>>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>>>>> only for the person to whom it is addressed. Its
>>>>>>>> contents
>>>>>>>>>>>>>>>>>>>> may be protected by legal and/or professional
>>>>> privilege.
>>>>>>>>>>>>>>>>>>>> Should it be received by you in error please
>contact
>>>>> the
>>>>>>>>>>>>>>>>>>>> sender at the
>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>>>>> quoted email address. Any unauthorised form of
>>>>>>>>>>>> reproduction
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> message is strictly prohibited. The Institute
>does
>>>>> not
>>>>>>>>>>>>>>>>>>>> guarantee the security of any information
>>>>> electronically
>>>>>>>>>>>>>>>>>>>> transmitted and is not liable if the information
>>>>>>>> contained
>>>>>>>>>>>>>>>>>>>> in this communication
>>>>>>>>>>>> is
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> proper and complete record of the message as
>>>>>>>>>>>>>>>>>>>> transmitted by the sender nor for any delay in
>its
>>>>>>>>>>>>>>>>>>>> receipt.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> Serusers mailing list
>>>>>>>>>>>>>>>>>>>>> Serusers(a)iptel.org
>>>>>>>>>>>>>>>>>>>>> http://mail.iptel.org/mailman/listinfo/serusers
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> The above electronic mail transmission is
>>>>> confidential
>>>>>>>> and
>>>>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>>>>> only for the person to whom it is addressed. Its
>>>>>>>> contents
>>>>>>>>>>>>>>>>>>>> may be protected by legal and/or professional
>>>>> privilege.
>>>>>>>>>>>>>>>>>>>> Should it be received by you in error please
>contact
>>>>> the
>>>>>>>>>>>>>>>>>>>> sender at the
>>>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>>>>> quoted email address. Any unauthorised form of
>>>>>>>>>>>> reproduction
>>>>>>>>>>>>>> of
>>>>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>>>>> message is strictly prohibited. The Institute
>does
>>>>> not
>>>>>>>>>>>>>>>>>>>> guarantee the security of any information
>>>>> electronically
>>>>>>>>>>>>>>>>>>>> transmitted and is not liable if the information
>>>>>>>> contained
>>>>>>>>>>>>>>>>>>>> in this communication
>>>>>>>>>>>> is
>>>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> a
>>>>>>>>>>>>>>>>>>>> proper and complete record of the message as
>>>>>>>>>>>>>>>>>>>> transmitted by the sender nor for any delay in
>its
>>>>>>>>>>>>>>>>>>>> receipt.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> The above electronic mail transmission is
>>>>> confidential
>>>>>>>> and
>>>>>>>>>>>>>>>>> intended only for the person to whom it is
>addressed.
>>>>>>>>>>>>>>>>> Its contents may be protected by legal and/or
>>>>>>>>>>>>>>>>> professional
>>>>> privilege.
>>>>>>>>>>>>>>>>> Should it be received by you in error please contact
>>>>> the
>>>>>>>>>>>>>>>>> sender at the
>>>>>>>>>>>> above
>>>>>>>>>>>>>>>>> quoted email address. Any unauthorised form of
>>>>> reproduction
>>>>>>>> of
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> message is strictly prohibited. The Institute does
>not
>>>>>>>>>>>>>>>>> guarantee the security of any information
>>>>> electronically
>>>>>>>>>>>>>>>>> transmitted and is
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> liable if the information contained in this
>>>>>>>>>>>>>>>>> communication is not a proper and complete record of
>>>>>>>>>>>>>>>>> the message as
>>>>>>>> transmitted
>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The above electronic mail transmission is
>confidential
>>>>> and
>>>>>>>>>>>>>> intended
>>>>>>>>>>>>>>>>> only for the person to whom it is addressed. Its
>>>>> contents
>>>>>>>> may
>>>>>>>>>>>> be
>>>>>>>>>>>>>>>>> protected by legal and/or professional privilege.
>>>>>>>>>>>>>>>>> Should it be received by you in error please contact
>>>>>>>>>>>>>>>>> the sender at the above quoted email address. Any
>>>>>>>>>>>>>>>>> unauthorised form of
>>>>> reproduction
>>>>>>>> of
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>>>>> message is strictly prohibited. The Institute does
>not
>>>>>>>>>>>>>>>>> guarantee the security of any information
>>>>> electronically
>>>>>>>>>>>>>>>>> transmitted and is
>>>>>>>>>>>> not
>>>>>>>>>>>>>>>>> liable if the information contained in this
>>>>>>>>>>>>>>>>> communication is not a proper and complete record of
>>>>>>>>>>>>>>>>> the message as
>>>>>>>> transmitted
>>>>>>>>>>>>>>>>> by
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The above electronic mail transmission is
>confidential
>>>>> and
>>>>>>>>>>>>>> intended only for the person to whom it is addressed.
>Its
>>>>>>>> contents
>>>>>>>>>>>>>> may be protected by legal and/or professional
>privilege.
>>>>>>>>>>>>>> Should it be received by you in error please contact
>the
>>>>>>>>>>>>>> sender at the
>>>>>>>> above
>>>>>>>>>>>>>> quoted email address. Any unauthorised form of
>>>>>>>>>>>>>> reproduction of this message is strictly prohibited.
>The
>>>>>>>>>>>>>> Institute does not guarantee the security of any
>>>>>>>>>>>>>> information electronically transmitted and is not
>liable
>>>>>>>>>>>>>> if the information contained in this communication is
>not
>>>>>>>>>>>>>> a proper and complete record of the message as
>transmitted
>>>>>>>>>>>>>> by the sender nor for any delay in its receipt.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The above electronic mail transmission is confidential
>>>>> and
>>>>>>>>>>>> intended
>>>>>>>>>>>>>> only for the person to whom it is addressed. Its
>contents
>>>>>>>>>>>>>> may be protected by legal and/or professional
>privilege.
>>>>>>>>>>>>>> Should
>>>>> it be
>>>>>>>>>>>>>> received by you in error please contact the sender at
>the
>>>>>>>> above
>>>>>>>>>>>>>> quoted email address. Any unauthorised form of
>>>>>>>>>>>>>> reproduction of this message is strictly prohibited.
>The
>>>>>>>>>>>>>> Institute does not guarantee the security of any
>>>>>>>>>>>>>> information electronically transmitted and is not
>liable
>>>>>>>>>>>>>> if the information contained in this communication is
>not
>>>>>>>>>>>>>> a proper and complete record of the message as
>transmitted
>>>>>>>>>>>>>> by the sender nor for any delay in its receipt.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>>
>>>>>>>>>>>>> The above electronic mail transmission is confidential
>and
>>>>>>>> intended
>>>>>>>>>>>> only for the person to whom it is addressed. Its contents
>>>>> may be
>>>>>>>>>>>> protected by legal and/or professional privilege. Should
>it
>>>>> be
>>>>>>>>>>>> received by you in error please contact the sender at the
>>>>> above
>>>>>>>>>>>> quoted email address. Any unauthorised form of
>reproduction
>>>>>>>>>>>> of this message is strictly prohibited. The Institute
>does
>>>>>>>>>>>> not guarantee the security of any information
>electronically
>>>>>>>>>>>> transmitted and is not liable if the information
>contained
>>>>>>>>>>>> in this communication is not a proper and complete record
>of
>>>>>>>>>>>> the message as transmitted by
>>>>> the
>>>>>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> -------------------Legal
>>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>>
>>>>>>>>>>>> The above electronic mail transmission is confidential
>and
>>>>>>>> intended
>>>>>>>>>>>> only for the person to whom it is addressed. Its contents
>>>>> may be
>>>>>>>>>>>> protected by legal and/or professional privilege. Should
>it
>>>>> be
>>>>>>>>>>>> received by you in error please contact the sender at the
>>>>> above
>>>>>>>>>>>> quoted email address. Any unauthorised form of
>reproduction
>>>>>>>>>>>> of this message is strictly prohibited. The Institute
>does
>>>>>>>>>>>> not guarantee the security of any information
>electronically
>>>>>>>>>>>> transmitted and is not liable if the information
>contained
>>>>>>>>>>>> in this communication is not a proper and complete record
>of
>>>>>>>>>>>> the message as transmitted by
>>>>> the
>>>>>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> -------------------Legal
>>>>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>>>
>>>>>>>>>>> The above electronic mail transmission is confidential and
>>>>>>>> intended
>>>>>>>>>>> only for the person to whom it is addressed. Its contents
>may
>>>>> be
>>>>>>>>>>> protected by legal and/or professional privilege. Should
>it
>>>>> be
>>>>>>>>>>> received by you in error please contact the sender at the
>>>>> above
>>>>>>>>>>> quoted email address. Any unauthorised form of
>reproduction
>>>>>>>>>>> of this message is strictly prohibited. The Institute does
>>>>>>>>>>> not guarantee the security of any information
>electronically
>>>>>>>>>>> transmitted and is
>>>>> not
>>>>>>>>>>> liable if the information contained in this communication
>is
>>>>>>>>>>> not a proper and complete record of the message as
>>>>>>>>>>> transmitted by
>>>>> the
>>>>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> Serusers mailing list
>>>>>>>>>> Serusers(a)iptel.org
>>>>>>>>>> http://mail.iptel.org/mailman/listinfo/serusers
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> -------------------Legal
>>>>>>>> Disclaimer---------------------------------------
>>>>>>>>>
>>>>>>>>> The above electronic mail transmission is confidential and
>>>>> intended
>>>>>>>> only for the person to whom it is addressed. Its contents may
>be
>>>>>>>> protected by legal and/or professional privilege. Should it
>be
>>>>>>>> received by you in error please contact the sender at the
>above
>>>>>>>> quoted email address. Any unauthorised form of reproduction
>of
>>>>> this
>>>>>>>> message is strictly prohibited. The Institute does not
>guarantee
>>>>> the
>>>>>>>> security of any information electronically transmitted and is
>not
>>>>>>>> liable if the information contained in this communication is
>not
>>>>> a
>>>>>>>> proper and complete record of the message as transmitted by
>the
>>>>>>>> sender nor for any delay in its receipt.
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>>> -------------------Legal
>>>>> Disclaimer---------------------------------------
>>>>>>>
>>>>>>> The above electronic mail transmission is confidential and
>>>>> intended only for the person to whom it is addressed. Its
>contents
>>>>> may be protected by legal and/or professional privilege. Should
>it
>>>>> be received by you in error please contact the sender at the
>above
>>>>> quoted email address. Any unauthorised form of reproduction of
>this
>>>>> message is strictly prohibited. The Institute does not guarantee
>the
>>>>> security of any information electronically transmitted and is
>not
>>>>> liable if the information contained in this communication is not
>a
>>>>> proper and complete record of the message as transmitted by the
>>>>> sender nor for any delay in its receipt.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> -------------------Legal
>>>>> Disclaimer---------------------------------------
>>>>>>
>>>>>> The above electronic mail transmission is confidential and
>intended
>>>>> only for the person to whom it is addressed. Its contents may be
>>>>> protected by legal and/or professional privilege. Should it be
>>>>> received by you in error please contact the sender at the above
>>>>> quoted email address. Any unauthorised form of reproduction of
>this
>>>>> message is strictly prohibited. The Institute does not guarantee
>the
>>>>> security of any information electronically transmitted and is
>not
>>>>> liable if the information contained in this communication is not
>a
>>>>> proper and complete record of the message as transmitted by the
>>>>> sender nor for any delay in its receipt.
>>>>>>
>>>>>>
>>>>
>>>> -------------------Legal
>>>> Disclaimer---------------------------------------
>>>>
>>>> The above electronic mail transmission is confidential and
>intended
>>>> only for the person to whom it is addressed. Its contents may be
>>>> protected by legal and/or professional privilege. Should it be
>>>> received by you in error please contact the sender at the above
>>>> quoted email address. Any unauthorised form of reproduction of
>this
>>>> message is strictly prohibited. The Institute does not guarantee
>the
>>>> security of any information electronically transmitted and is not
>>>> liable if the information contained in this communication is not
>a
>>>> proper and complete record of the message as transmitted by the
>>>> sender nor for any delay in its receipt.
>>
>>
>>-------------------Legal
>Disclaimer---------------------------------------
>>
>>The above electronic mail transmission is confidential and intended
>only for the person to whom it is addressed. Its contents may be
>protected by legal and/or professional privilege. Should it be
>received by you in error please contact the sender at the above
>quoted email address. Any unauthorised form of reproduction of this
>message is strictly prohibited. The Institute does not guarantee the
>security of any information electronically transmitted and is not
>liable if the information contained in this communication is not a
>proper and complete record of the message as transmitted by the
>sender nor for any delay in its receipt.
-------------------Legal Disclaimer---------------------------------------
The above electronic mail transmission is confidential and intended only for the person to whom it is addressed. Its contents may be protected by legal and/or professional privilege. Should it be received by you in error please contact the sender at the above quoted email address. Any unauthorised form of reproduction of this message is strictly prohibited. The Institute does not guarantee the security of any information electronically transmitted and is not liable if the information contained in this communication is not a proper and complete record of the message as transmitted by the sender nor for any delay in its receipt.
Hi all...
now i have the following scenario:
I want to forward calls with an 8 as prefix to a PSTN Gateway but
when i place a call to i.e. 8004912345678 i get a busy-tone on my
VoIP Phone and the call gets canceled.
My ser.cfg is configured out, so that i can say "theoretly it have to
do" :-)
I've installed a RTPProxy too. I've took the rtpproxy from ser-cvs.
The connection between ser and rtp is ethablished when i start the ser.
On the PSTN-Gateway i can see, when i place a call, that a request comes
to the Gateway but it isn't the IP-Address of my ser but the IP-Address
of my VoIP Phone
and this IP-Address isn't allowed to connect to the PSTN-Gateway.
Also, when i reconfigure the PSTN-Gateway so that the Phone-IP-Address
is allowed to connect
then i get a busy-tone on my phone, but the PSTN Phone rings. When i
took the PSTN-Phone i hear
nothing and my VoIP-Phone doesn't ring again.
Can anyone help me ? :-(
I become crazy with it - i work now 2 weeks on this Problem :-(
Here is my ser.cfg for reference:
---
#
# $Id: ser.cfg,v 1.21.2.1 2003/07/30 16:46:18 andrei Exp $
#
# simple quick-start config script
#
# ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd)
#fork=yes
#log_stderror=no # (cmd line: -E)
# Uncomment these lines to enter debugging mode
debug=7
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"
alias="terralink.de" # myself=terralink.de
alias="siiip.terralink.de" # myself=siiip.terralink.de
alias="217.9.16.13" # myself
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database
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"
# Uncomment this if you want digest authentication
# mysql.so must be loaded !
loadmodule "/usr/local/lib/ser/modules/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_radius.so"
#loadmodule "/usr/local/lib/ser/modules/acc.so"
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
loadmodule "/usr/local/lib/ser/modules/xlog.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
modparam("usrloc", "db_url", "mysql://ser:ser@localhost/ser")
#modparam("usrloc", "db_mode", 0)
modparam("usrloc", "db_mode", 2)
# -- auth params --
#modparam("auth_db", "db_url", "sql://ser:ser@localhost/ser")
#modparam("auth_db", "calculate_ha1", yes)
#modparam("auth_db", "password_column", "password")
modparam("auth_radius", "radius_config",
"/usr/local/etc/radiusclient/radiusclient.conf")
# -- rr params --
modparam("rr", "enable_full_lr", 1)
# -- acc params --
#modparam("acc", "log_level", 1)
#modparam("acc", "log_flag", 1 )
#modparam("acc", "log_missed_flag", 3)
#modparam("acc", "radius_config",
"/usr/local/etc/radiusclient/radiusclient.conf")
#modparam("acc", "radius_flag", 1)
#modparam("acc", "radius_missed_flag", 3)
# -- nat params --
modparam("nathelper", "natping_interval", 10)
modparam("nathelper","rtpproxy_sock", "/var/run/rtpproxy.sock")
# ------------------------- request routing logic -------------------
# main routing logic
route{
# zu viele Hops ?
if (!mf_process_maxfwd_header("10")) {
sl_send_reply("483","Too Many Hops");
break;
};
# nachricht zu lang ?
if ( msg:len > max_len ) {
sl_send_reply("513", "Message too big");
break;
};
# we record-route all messages -- to make sure that
# subsequent messages will go through our proxy; that's
# particularly good if upstream and downstream entities
# use different transport protocol
record_route();
# loose-route processing
if (loose_route()) { t_relay(); break; };
# labeled all transaction for accounting
setflag(1);
#if (!lookup("location")) {
# # call invitations to off-line users are reported using the
# # acc_request action; to avoid duplicate reports on request
# # retransmissions, request is processed statefuly
(t_newtran,
# # t_reply)
# if ((method=="INVITE" || method=="ACK") && t_newtran() ) {
# t_reply("404", "Not Found");
# #acc_request("404 Not Found");
# break;
# };
# # all other requests to off-line users are simply replied
# # statelessly and no reports are issued
# #sl_send_reply("404", "Not Found");
# #break;
#} else {
# # user on-line; report on failed transactions; mark the
# # transaction for reporting using the same number as
# # configured above; if the call is really missed, a report
# # will be issued
# setflag(3);
# # forward to user's current destination
# t_relay();
# break;
#};
# if the request is for other domain use UsrLoc
# (in case, it does not work, use the following command
# with proper names and addresses in it)
if (uri==myself) {
rewritehost("siiip.terralink.de");
#xlog("L_DBG", "time [%Tf] method <%rm> r-uri <%ru> from
<%fu> contact <%ct>\n");
if (method=="REGISTER") { route(1); break; };
if (method=="INVITE") {
fix_nated_contact();
record_route();
force_rtp_proxy();
if (uri=~"^sip:(.+)?@(.+)?") { route(3); break; }
#else { break; };
}
lookup("aliases");
# native SIP destinations are handled using our USRLOC DB
if (!lookup("location")) {
#if (!lookup("location") || !lookup("aliases")) {
sl_send_reply("404", "Not Found");
break;
};
};
# forward to current uri now; use stateful forwarding; that
# works reliably even if we forward from TCP to UDP
if (!t_relay()) {
sl_reply_error();
};
}
route[1] {
#xlog("L_DBG", "Hier registriert sich jemand !\n");
if (!radius_www_authorize("")) {
www_challenge("", "0");
break;
};
save("location");
break;
}
#route[2] {
#xlog("L_DBG", "Hier will jemand intern telefonieren !\n");
#}
route[3] {
#xlog("L_DBG", "Hier will jemand extern telefonieren !\n");
#strip(1);
#rewritehostport("217.9.16.13:5060");
rewritehostport("217.9.21.6:5060");
#forward( 217.9.16.11, 5060 );
append_branch("sip:sip@217.9.16.13");
#t_relay_to_udp("217.9.21.6", "5060");
if (!t_relay_to_udp("217.9.21.6", "5060")) {
sl_reply_error();
break;
};
}
If a client come through STUN and behind NAT,
SER dont need to do anything to handle NAT.
correct me pls, if I am wrong.
How ser will figure it out that whether a client is coming through STUN or
not?
Thanks,
Mohammad
--------------------------------------------------------------------
mail2web - Check your email from the web at
http://mail2web.com/ .
Hi,tesastac
I tried all the versions that provide libmysqlclient.so.10, such as MySQL-shared-3.23.54-1.i386,MySQL-shared-3.23.53a-1.i386,MySQL-shared-3.23.49a-1.i386 and MySQL-shared-3.23.47-1.i386. But this error still appeared.
======= 2005-03-30 22:37:08 您在来信中写道：=======
>I met this error when I set up MySQL-shared-3.23.54a-1.i386 (to set up
>libmysqlclient for mysql support). This error appeared and I couldn't start
>the httpd service again.I'm trying to solve now..
>
>
>----- Original Message -----
>From: "ljzhang" <xueyou38(a)163.com>
>To: "Serusers" <Serusers(a)iptel.org>
>Sent: Wednesday, March 30, 2005 5:24 PM
>Subject: [Serusers] Load mysql.so ERROR!!
>
>
>> Hi,
>>
>> I uncomment the line of ser.cfg:
>> loadmodule "/usr/lib/ser/modules/mysql.so"
>>
>> But when I start ser, I met the following error:
>>
>> ERROR: load_module: could not open module </usr/lib/ser/modules/mysql.so>:
>> /usr/lib/libmysqlclient.so.10: symbol errno, version GLIBC_2.0 not defined
>> in
>> file libc.so.6 with link time reference?
>>
>> Can you tell me why?
>>
>> Note:
>> libmysqlclient.so.10 is provided by MySQL-shared-3.23.54a-1.i386
>> MySQL version is 4.0.12
>>
>> Thanks a lot.
>>
>>
>>
>> jenny
>> xueyou38(a)163.com
>> 2005-03-30
>>
>
>
>--------------------------------------------------------------------------------
>
>
>> _______________________________________________
>> Serusers mailing list
>> Serusers(a)iptel.org
>> http://mail.iptel.org/mailman/listinfo/serusers
>>
= = = = = = = = = = = = = = = = = = = =
致
礼！
ljzhang
xueyou38(a)163.com
2005-03-31
Hi everyone!
I want to implement an ENUM query in my routing block with comfort. I
want ENUM queries always to be done because VoIP-Calls are cheaper than
PSTN-routed ones.
I want to let the user request e.g. "sip:089123456@mydomain.org" and the
script should query for "6.5.4.3.2.1.9.8.9.4.e164.arpa" (I'm in munich
(prefix 089), germany (prefix +49); a single zero indicates long
distance calls, two zeros indicate international calls, local calls
don't have leading zeros)
The idea is to complete the requested uri to be a e164 address and then
start a query
The logic should be like:
if (uri_is_e164) {
if (do_enum_query)
t_relay;
} else if (uri =~ "sip:0[1-9][0-9]{1,14}@.*") {
# national call
replace "leading 0" with "+49";
if (do_enum_query)
t_relay;
} else if (uri =~ "sip:00[1-9][0-9]{1,13}@.*") {
# international call
replace "leading 00" with "+";
if (do_enum_query)
t_relay;
}
I don't get the hang of those textops functions because sometimes they
work and sometimes they don't, especially after other modules have been
changing the uri.
In addition, if one of those enum-queries fails, the uri should be
reverted to the original one (with "0" or "00").
How would the correct ser.cfg-script look like?
Alex Mack
