Hello
My name is Mauricio Viveros, I'm a Colombian programmer.
I'm implementing VoIP system in a little company, so I'm installed OPENSER with
POSTGRES module but when I try to run openser I get dis error message:
Feb 27 01:05:53 [7788] DBG:core:find_cmd_export_t: found <sl_reply_error>(0)
in module sl [/usr/local/lib/openser/modules/]
Feb 27 01:05:53 [7788] CRITICAL:core:yyerror: parse error in config file,
line 376, column 2-6: syntax error
Feb 27 01:05:53 [7788] CRITICAL:core:yyerror: parse error in config file,
line 376, column 2-6:
Feb 27 01:05:53 [7788] ERROR:core:main: bad config file (2 errors)
to see all trace, see the attached file openser_error_message.txt
I attached too the config files: openser.cfg y openserctlrc
I hope that you can help me with this problem.
Thank you very much.
Mauricio Viveros
Programmer
Cali-Colombia
hello friends,
I start openSER there are no errors (i.e. the auth_diameter module
loads), but the DISC client complains that the peer is unknown. Both
SER and the DISC client are running on the same machine, so I added
aaa://localhost as a peer, but that does not seem to help.
Openser can not communicate with diameter client.
Regards,
Dilip
Hi,
This is to summarize my opinions about FC* distro use.
IMHO, I think FC* is best selection as it contains many more fixes
than does the older CENTOS (based on 5). I have deployed several
hundred FC* boxes in VoIP applications. This is over 10,000 active
ports without "Enterprise" stability issues.
IMHO this project needs the quickest path to the Enterprise community
regardless of the OS/distro used.
I suppose the ultimate question is who is our target? Ourselves,
naturally. However, I suggest our target is not the bankers or
major corporations with lots of rules and procedures. That group
will never adopt SER until they have a commercial-grade support
system to advise their IT folks what to do for every question they may have.
IMHO our initial target is those early adopters who are trying to
create new businesses in telecomm or consulting-on-telecom. We want
them to have a solid core that they can leverage into their new
appliances and specialized applications.
The early adopters are risk-takers (This means us as well!) They
demand an open box in which they can face the SIP world with some
assurance of standards compliance while at the same time they can
face their clients with something better, faster, cheaper, and
innovative enough to get paid well for their efforts.
Making a technology "buy - in" decision at any point in time is only
a check point - not a final resting place. IMHO, we are better off
selecting an OS/distro effort that has a large share of both early
adopters and long term commercial support - - - so long as it meets
our current and future technical **AND** target market
requirements. Research confirms that the RH/FC community is the
largest community with name recognition and respect among both the
"geek-innovator" community as well as the Enterprise community.
..mike..
Hi,
I'm pretty familiar with the asterisk, but have only little
understanding of SER/OpenSER. I read through some cookbooks and found
some things that might help, but I just want to ensure that I'm on the
right track before investing a lot of time into it. I have an asterisk
running that terminates currently against one (SIP) carrier. We are
noticing that the carrier has an increasing rate of short outtages and
want a more redundant solution. Currently we have two more carriers and
have to switch manually which was fine for the testing period. Now I'd
like to route automatically. The routing decision should be based on a
least cost basis, for each number the cheapest route shall be used. But
if a route is not working properly, mostly these are 5XX Messages, the
second cheapest route shall be used. Can I do this failover aspect with
OpenSER/LCR too?
Is the LCR Module the right point to start, as I have not seen failover
strategies?
There are some questions left which are more detailed - if a carrier
shows to fail often, I just want a few calls routed to that carrier, to
determine if its working again.
Is there any chance to include network/packet information into the
decision too, like roundtrip times, jitter etc?
Hopefully someone can help me find the best solution...
regards,
Knud
Hi, sometimes I need to forward a message to a SIP UAS that just speaks UDP
(for example a PSTN gateway), so if I recevie an INVITE from a TCP client I
must use:
t_relay("udp:gateway:5060")
since the following would fail:
$rd = "gateway";
t_relay();
The problem is that this second approach is more flexible and it can be used
in block routes, being them independent fo the final destination (set
prevously with asignements like "$rd = gateway").
A solution for this could be allow $rP:
$rP - reference to transport protocol of R-URI
so I could do:
$rP = "UDP";
$rd = "gateway";
t_relay();
But unfortunatelly $rP is no writeable:
http://www.openser.org/dokuwiki/doku.php/core-cookbook:1.3.x#assignment
Another solution could be if "force_send_socket" function would allow setting
**just** the protocol type, but it doesn't allow it.
So there is no solution excepting making dirty the script and setting all the
destination (protocol:ip:port) using "t_relay(protocol:ip:port)".
Why $rP is no writeable?
Thanks.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
Raju,
Thanks for testing it, now I am working in making it more secure.
Regards,
Gonzalo.
> Gonzalo,
>
> Thanks!! It works very well esp. we have few clients
> behind DSL which is unstable and the connectivity is
> remarkably improved.
>
> Good contribution to mediaproxy.
>
> regards,
>
> Raju
> --- "Gonzalo J. Sambucaro"
> <gonzalo.sambucaro(a)mslc.com.ar> wrote:
>
>> Raju,
>> please replase the file rtphandler.py.
>>
>> Regards,
>> Gonzalo.
>>
>> > Hi Gonzalo,
>> >
>> > Can you please let me know how I can try out this
>> > addition. I am currently using Mediaproxy 1.9.1
>> along
>> > with openser-tls-1.1.1.
>> >
>> >
>> > Please do let me know where I can get this patch.
>> >
>> > regards,
>> >
>> > Raju
>> > --- "Gonzalo J. Sambucaro"
>> > <gonzalo.sambucaro(a)mslc.com.ar> wrote:
>> >
>> >> Andreas,
>> >> our local ISP´s are disconnecting DSL
>> lines
>> >> more ofthen but it
>> >> renews the IP almost instantaneously.
>> >>
>> >> Regards,
>> >> Gonzalo.
>> >>
>> >> > Hello,
>> >> > nice feature, i know the problem, because our
>> >> local ISP´s are
>> >> > disconnecting DSL lines every 8 hours.
>> >> > But the DSL line needs nearly 8 seconds, to be
>> up
>> >> and running again(PPP
>> >> > dialup), if i can´t hear my
>> >> > partner for a few seconds i will disconnect the
>> >> line and redial, my
>> >> > opinion.
>> >> >
>> >> > Same in mobile environments, when the handover
>> >> doesn´t work, saying
>> >> > "hello? - hello?" -> hangup ->
>> >> > redial.
>> >> >
>> >> > But i´m willing to try, leave me a note, where
>> i
>> >> can download your
>> >> > version.
>> >> >
>> >> > regards,
>> >> > Andreas M.
>> >> >
>> >> >
>> >> >
>> >> > Gonzalo J. Sambucaro schrieb:
>> >> >> Folks,
>> >> >> I developed a new feature in the Media
>> >> Proxy project of
>> >> >> AG-Proyect.
>> >> >> With this new feature the Media Proxy Server
>> is
>> >> now able to manage the
>> >> >> problem of the NAT IP change in an established
>> >> call. It is
>> >> >> currently in production and working without
>> any
>> >> problem.
>> >> >>
>> >> >> Somebody wants to test it?
>> >> >>
>> >> >> I would like to know what to do to make this
>> >> feature available to
>> >> >> everybody. Does anybody know?
>> >> >>
>> >> >> Regards,
>> >> >>
>> >> >> ------------------------------
>> >> >>
>> >> >> Details:
>> >> >> -------
>> >> >> Supose that there is an established rtp
>> >> connection between two
>> >> >> endpoints and the media proxy is in the middle
>> >> doing the relay of
>> >> >> the rtp streams, let´s say
>> >> >>
>> >> >> (MP = mediaproxy)
>> >> >>
>> >> >> EP A <--------->[NAT with IP1]<-----------> MP
>> >> <--------------------> EP
>> >> >> B
>> >> >>
>> >> >> EP A sends rtp to MP_IP:MP_PORT passing
>> through
>> >> the NAT box.
>> >> >> EP B sends rtp to MP_IP:MP_PORT without
>> passing
>> >> through a NAT box.
>> >> >>
>> >> >> The MP know that the caller =
>> NAT_IP1:NAT_PORT1,
>> >> and the called =
>> >> >> EP_B_IP:EP_B_PORT
>> >> >>
>> >> >> Now, supose that the NAT box change their
>> PUBLIC
>> >> IP from IP1 to IP2, so
>> >> >> this escenary
>> >> >>
>> >> >> EP A <------->[NAT with IP1]<---------> MP
>> >> <-------------> EP B
>> >> >>
>> >> >> will change to this
>> >> >>
>> >> >> EP A <------->[NAT with IP2]<---------> MP
>> >> <--------------> EP B
>> >> >>
>> >> >> so the MP should detect that change of IPs and
>> >> continue relaying the rtp
>> >> >> streams but now to IP2:PORT2 instead of
>> >> IP1:PORT1.
>> >> >>
>> >> >> Well, that was the situation y have
>> experienced.
>> >> >>
>> >> >> To fix this, I developed this solution,
>> changing
>> >> rtphandler.py file:
>> >> >>
>> >> >> 1) When the first rtp packet of a source
>> arrives,
>> >> save the SSRC field in
>> >> >> the MP.
>> >> >> - Save the SSRC of the caller.
>> >> >> - Save the SSRC of the called.
>> >> >>
>> >> >> 2) If arrives a rtp packet with unknown source
>> IP
>> >> but with the same SSRC
>> >> >> field of some of the two streams, updates the
>> >> binding (with the new IP
>> >> >> detected) between the caller and the MP or
>> >> between the called and the MP
>> >> >> according to the field SSRC previously saved.
>> >> >>
>> >> >> Note: SSRC (RFC 3550 RTP), (from the rfc:
>> "The
>> >> SSRC identifier carried
>> >> >> in
>> >> >> the RTP header and in various fields of RTCP
>> >> packets is a random 32-bit
>> >> >> number that is required to be globally unique
>> >> within an RTP session ")
>> >> >>
>> >> >> --------------------------------
>> >> >>
>> >> >
>> >> > --
>> >> > g,
>> >> > Andreas M.
>> >> >
>> >> > _______________________________________________
>> >> > Users mailing list
>> >> > Users(a)lists.openser.org
>> >> >
>> >>
>> >
>>
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>> >> >
>> >>
>> >>
>> >> --
>> >> Gonzalo J. Sambucaro
>> >> Ingeniería de Software
>> >> Tel: +54-341-4230504
>> >> MSLC
>> >> gonzalo.sambucaro(a)mslc.com.ar
>> >> www.mslc.com.ar
>> >> Ocampo y Esmeralda - Vivero de Empresas de Base
>> >> Tecnológica
>> >> Ciudad Universitaria Rosario UNR, CCT CONICET
>> >> Rosario - Santa Fé - Argentina
>> >>
>> >>
>> >> _______________________________________________
>> >> Users mailing list
>> >> Users(a)lists.openser.org
>> >>
>> >
>>
> http://lists.openser.org/cgi-bin/mailman/listinfo/users
>> >>
>> >
>> >
>>
>>
>> --
>> Gonzalo J. Sambucaro
>>
> === message truncated ===>
>> '''
>> Handle media stream relaying and provide control
>> ports to receive and
>> process requests from SER (SIP Express Router) or
>> the proxydispatcher.
>>
>> Copyright 2003-2005 Dan Pascu
>> '''
>>
>> import asyncore
>> import socket
>> import sys, os, grp, errno, traceback, atexit
>> import time
>> import struct
>> import re
>> import weakref
>>
>> from utilities import *
>> from datatypes import *
>> from version import release
>> from request import Request, InvalidRequestError
>> from configuration import readSettings,
>> ConfigSection, Boolean, dumpSection
>>
>>
>> class ProxyConfig(ConfigSection):
>> _dataTypes = {'socket': ControlSocket,
>> 'proxyIP': IPAddress,
>> 'portRange': PortRange,
>> 'TOS': HexNumber,
>> 'listen': NetworkAddress,
>> 'allow': NetworkRangeList}
>> socket = '/var/run/mediaproxy.sock'
>> group = 'openser'
>> proxyIP = thisHostIP ## defined in utilities
>> portRange = (60000, 65000)
>> TOS = 0xb8
>> listen = None
>> allow = None
>> idleTimeout = 60
>> holdTimeout = 60*60
>> forceClose = 0
>>
>>
>> ## We use this to overwrite some of the settings
>> above on a local basis if needed
>> readSettings('MediaProxy', ProxyConfig)
>> #dumpSection(ProxyConfig)
>>
>> if ProxyConfig.allow and NetworkRange('Any') not in
>> ProxyConfig.allow:
>> ## Always add ourselves to the accept list
>> myself = NetworkRange('127.0.0.1')
>> if myself not in ProxyConfig.allow:
>> ProxyConfig.allow.append(myself)
>>
>> maxDataSize = 8*1024
>>
>> try:
>> from accounting import accounting, StopRecord,
>> StopRecordSerializer, QueuedItemProcessingThread
>> except ImportError:
>> warning("accounting is enabled but the
>> accounting module is missing. accounting is not
>> available!")
>> accounting = Null()
>> dispatcher = Null()
>> class StopRecord(object):
>> def __new__(typ, *args, **kwargs):
>> return None
>> else:
>> class
>> DispatcherNotifyThread(QueuedItemProcessingThread):
>> '''
>> Notify the proxydispatcher of calls that did
>> timeout and provide
>> the dispatcher with the accounting
>> information for them.
>> '''
>> def __init__(self):
>>
>> QueuedItemProcessingThread.__init__(self,
>> name='DispatcherNotify',
>> file='.dispatcher-notify.dat')
>>
>> def process(self, record):
>> address = record['dispatcher']
>> expires = record['expires']
>> del record['dispatcher'],
>> record['expires']
>>
>> msg = 'timeout %s %s\n' % (record['id'],
>> StopRecordSerializer().dump(record))
>>
>> s = socket.socket(socket.AF_INET,
>> socket.SOCK_STREAM)
>> try:
>> s.settimeout(5)
>> except AttributeError:
>> pass
>> try:
>> start = time.time()
>> try:
>> s.connect(address)
>> s.send(msg)
>> result =
>> s.recv(maxDataSize).strip()
>> except (socket.error,
>> socket.gaierror, socket.herror, socket.timeout),
>> why:
>> try: motive =
>> why[1]
>> except IndexError: motive = why
>> now = time.time()
>> if now < expires:
>> warning("couldn't notify
>> dispatcher at %s (%s). will retry later." %
>> (address[0], motive))
>> record['dispatcher'] =
>> address
>> record['expires'] = expires
>> # eventually use a different
>> queue only for failures
>> delay = 1
>> duration = now - start
>> if duration < delay:
>>
>> time.sleep(delay-duration)
>> self.put(record) ## put back
>> in the queue and process later
>> else:
>> error("couldn't notify
>> dispatcher at %s (%s). giving up." % (address[0],
>> motive))
>> # eventually log the record
>> to syslog or a file
>> return
>> if result.lower() == 'ok':
>> info("notified dispatcher at %s
>> about expired session %s" % (address[0],
>> record['id']))
>> elif result.lower() == 'not found':
>> info("session %s already closed
>> by the dispatcher at %s" % (record['id'],
>> address[0]))
>> else:
>> error("failed to notify
>> dispatcher at %s (returned `%s')." % (address[0],
>> result))
>> # eventually log the record to
>> syslog or a file
>> finally:
>> s.close()
>>
>> def notify(self, session):
>> if not session.dispatcher:
>> return ## no dispatcher to notify.
>> record = StopRecord(session)
>> record['dispatcher'] =
>> session.dispatcher
>> record['expires'] = time.time() + 3600
>> ## try for an hour
>> self.put(record)
>>
>> dispatcher = DispatcherNotifyThread()
>> dispatcher.start()
>>
>> ## Internal state of mediaproxy (DON'T TOUCH!!!)
>>
>> ## A few shortcuts, for faster access
>> proxyIP = ProxyConfig.proxyIP
>> minPort = ProxyConfig.portRange[0]
>> maxPort = ProxyConfig.portRange[1]
>> crtPort = minPort
>>
>> Sessions = {}
>>
>> ## For computing traffic through mediaproxy
>> byteBucket = [0, 0, 0]
>> Traffic = [0, 0, 0]
>>
>> ## Non public networks. This includes RFC1918
>> networks, localnet (127.0.0.0/8),
>> ## broadcast networks (224.0.0.0/4) and 0.0.0.0/8
>> nonPublicNetworks = [
>> {'name': '0.0.0.0', 'value': 0x00000000L,
>> 'mask': 0xff000000L},
>> {'name': '10.0.0.0', 'value': 0x0a000000L,
>> 'mask': 0xff000000L},
>> {'name': '127.0.0.0', 'value': 0x7f000000L,
>> 'mask': 0xff000000L},
>> {'name': '172.16.0.0', 'value': 0xac100000L,
>> 'mask': 0xfff00000L},
>> {'name': '192.168.0.0', 'value': 0xc0a80000L,
>> 'mask': 0xffff0000L},
>> {'name': '224.0.0.0', 'value': 0xe0000000L,
>> 'mask': 0xf0000000L}
>> ]
>>
>> rtpPayloads = {
>>
> === message truncated ===
>
>
--
Gonzalo J. Sambucaro
Ingeniería de Software
Tel: +54-341-4230504
MSLC
gonzalo.sambucaro(a)mslc.com.ar
www.mslc.com.ar
Ocampo y Esmeralda - Vivero de Empresas de Base Tecnológica
Ciudad Universitaria Rosario UNR, CCT CONICET
Rosario - Santa Fé - Argentina
At 03:42 AM 2/29/2008, samuel wrote:
>I can't recall right now whehter we have discussed the option of
>creating in parallel a vmware/xen image so people can start using it
>in their favorite virtual solution...more things for the future (?)
We discussed. Conclusion was future options , not first out of the gate.
On Tuesday 26 February 2008, Ovidiu Sas wrote:
> Can you update the README file with the structure of the table?
> Also a "Database setup" section would help a lot.
Hi Ovidiu,
the README was updated with some informations about the database setup. Please
let me know if you have some other suggestions.
Cheers,
Henning
Yes, it is .
Thiago Maluf wrote:
> Is it there available this parameter in Openser 1.2.X?
>
> On 2/29/08, Bogdan-Andrei Iancu <bogdan(a)voice-system.ro> wrote:
>
>> Hi Thiago,
>>
>> You just have to disable the dns_blacklist support in openser if your
>> Asterisk GW is not compliant from reply codes point of view.
>>
>> Set :
>> disable_dns_blacklist = yes
>> in your script
>>
>> Regards
>> Bogdan
>>
>> Thiago Maluf wrote:
>>
>>> Hi List,
>>> In my environment I have one OpenSER and one gateway Asterisk.
>>> The Gateway work send the call to PSTN or H.323 World.
>>> Then when I send one call to Asterisk and the my E1 link is out, it
>>> send to OpenSER one 503 Response!
>>> After it, every calll during 4 minutes Openser don't send the call to
>>> Asterisk. Then I don't send call to H.323 world for example.
>>> I read this page http://www.mail-archive.com/users@openser.org/msg11839.html
>>> And I believe that I would possible to change this time to 0 minutes.
>>> But I am reading this code section and I don't find where I make this change.
>>> Would someone help me?
>>> thanks in advanced.
>>> Thiago
>>>
>>>
>>>
>>
>
>
>