Hello,
By looking at this section from the link
http://www.voip-info.org/wiki-Asterisk+SIP+NAT+solutions
9. Asterisk inside a NAT, client inside ANOTHER NAT
In this case, we need a middle man to even find each
other, an outbound SIP proxy that handles the SIP
transaction and is reachable by all parties. To get
media streams from point to point we need another
middle man, a media server. Asterisk could be that
media server, that could add media codec conversion.
Portaone's rtpproxy works together with SIP Express
router as a media server in this situation.
Could anyone share the configuration on how to do this
? I could only succeed if I put on port forwarding on
the UA's end.
Regards, C.K
In case of failure, i wan't to be able to forward the call to another destination.
I want to use an exec_dset to obtain the new number to call.
failure_route[1] {
# forwarding failed -- try again at another destination
exec_dset('some script to obtain new number');
# if this alternative destination fails too, proceed to ...
t_relay();
}
It don't seem to work here. Is it something logical to do this ? What would be the better way ?
thanks
You may start two stances of free-radius listening on different ports
on same host. The configuration files can be read from two different
directories where you can set separated tables (in sql.conf)
>>>>>>>>>
Hi,
It is more of a freeradius question... I have one
freeradius server getting accounting data from both
cisco gateway and ser. The data is saved in a backend
mysql database. Is it possible to send ser data to one
table and cisco data to another table?
Thanks,
Richard
Hi,
It is more of a freeradius question... I have one
freeradius server getting accounting data from both
cisco gateway and ser. The data is saved in a backend
mysql database. Is it possible to send ser data to one
table and cisco data to another table?
Thanks,
Richard
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hello Matt,I'm having the same problem as you are (i'm using ser 0.8.12).Please advise if know what is source of this problem.ThanksRi Liang------------------------So.. did anyone have any ideas as to what I may be doing wrong?
Matt Hess wrote:
> I want to send an updated uri to the exec'd script but beyond 2 updates
> to the uri ser seems to fail to update the uri..
>
> so when the failure route keeps being called the last number it had just
> tried is sent but that doesn't seem to happen and I'm wondering if this
> is a bug in ser as it would seem so.. to me at least.
>
> Say the hunt number is dialed.. route(2) is called.. which calls the
> script.. the hunt number is sent properly to the script and the script
> returns the first number in the hunt properly.. (06 in my example). Now
> if that number is busy ser drops to the failure_route[2] and 06 is sent
> back to the script and the script returns 07.. ok now if that number is
> busy failure_route[2] should be called again. But instead of sending 07
> to the the script as the number last dialed (or current uri) ser sends
> 06 again to the script which to me seems like an incorrect behavior..?
>
>
> Kapil Dhawan wrote:
>
>> could you pls explain ..how are you implementing call hunting.....well
>> i am also implementing SER and need same feature by this time i am
>> writning it in module...do u have any other possibility....
>>
>>
>>> From: Matt Hess <mhess at livewirenet.com>
>>> To: serusers at iptel.org
>>> Subject: [Serusers] hunt groups?
>>> Date: Sat, 14 Feb 2004 12:01:04 -0700
>>>
>>> I'm trying to do hunt groups in ser..
>>>
>>> I've come to the conclusion that to do multiple hunt groups I need to
>>> call an external script that replies with the next uri to call when
>>> it looks at the current one being sent to it.. ie:
>>> sent returned
>>> 3039930010 3039930006
>>> 3039930006 3039930007
>>> 3039930007 3039930008
>>> 3039930008 3039930006
>>>
>>> However on entering the failure route I have found that the current
>>> uri is not being updated to reflect the one it has received.. so ser
>>> keeps looping on the first 2 numbers in the hunt..
>>>
>>> here are my route blocks..
>>>
>>> route[2] {
>>> log(1, "LOG: entered hunt route");
>>> t_on_failure("2");
>>> exec_dset("/usr/local/ser/huntgroup.pl");
>>> append_branch();
>>> t_relay();
>>> }
>>>
>>> failure_route[2] {
>>> log(1, "LOG: Hit failure_route 2");
>>> t_on_failure("2");
>>> exec_dset("/usr/local/ser/huntgroup.pl");
>>> append_branch();
>>> t_relay();
>>> }
>>>
>>> so on the example above it routes to the first 06 and 07 numbers
>>> properly but when I would think 07 would be the uri sent to the perl
>>> script an environment check sees that 06 is still being sent as the
>>> $SIP_USER
>>>
>>> any ideas as to what I need to do?
>>>
>>>
>>>
>>> _______________________________________________
>>> Serusers mailing list
>>> Serusers at iptel.org
>>> http://lists.iptel.org/mailman/listinfo/serusers
>>
>>
>>
>> _________________________________________________________________
>> Masterpieces made affordable! Buy art prints.
>> http://go.msnserver.com/IN/42736.asp MSN Shopping.
>
>
> _______________________________________________
> Serusers mailing list
> Serusers at iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
--------------------------------------------------------------------------------
a.. Previous message: [Serusers] hunt groups?
b.. Next message: [Serusers] UAs not respecting Record Route
c.. Messages sorted by: [ date ] [ thread ] [ subject ] [ author
Hello,
There is new version of the MediaProxy software available. To upgrade
your installation download it from:
http://mediaproxy.ag-projects.com/mediaproxy-1.2.0.tar.gz
Changes from version 1.1.0 to 1.2.0
-----------------------------------
- Increased to 50 the number of maximum generated calls by one instance
of
rtpgenerator.py
- Fixed regular expresion to correctly identify older Grandstream ATA
adaptors in the web page showing media sessions.
- Write call duration in any situation. It will be overwritten later by
ser if everything goes well with the call, but if not we still have
the
call duration.
- Made the dispatcher to save the existing sessions on exit and restore
them
(if available) on start. This avoids problems if the dispatcher is
restarted
while there are running media sessions.
- Media type information is now received from the ser module (it is
problematic to be determined from the payload type).
- If updating an accounting record doesn't modify anything, retry the
query
with to_tag='n/a' and call_duration=0. This will update accounting
entries
added by a failed request (such as a canceled one or one that did
timeout)
- Added some more IP ranges to the non-public network classes
- Only allow 0.0.0.0 to put a call on hold after the session was
started (both
parties have sent their contact information with an INVITE and an OK).
This fixes some Xten weirdness where the phone had sent 0.0.0.0 as
the contact
IP address from the first INVITE request.
- Added ability to add media streams to a conversation on the fly (used
mostly
by Video SIP clients).
- Correctly handle a RTP payload of 13 (Confort noise). This fixes some
cases
where for certain phones the codec for the call was shown as
Unknown(13)
instead of the real codec (seen with Cisco ATA 186).
Hello everybody,
Its name is Bill4tel, a powerful product of Sunline Communication, from the group Amitelo,
Bill4Tell works fine with Asterisk, GNU-Gatekeeper, SER of Iptel and all
other softswitches on the market that generate a CDR file.
You can see its funcltionalities in the page :
http://www.sunlinegroup.com/pageID_1526872.html
The power of Bill4Tell is:
- it does not need the FreeRadius and / or any otherRadius programs to rum,
it is simply independent
- We can make changes as the customer wants to.
Have a look at the license pricing for Bill4Tell:
http://www.sunlinegroup.com/bill4tellpricing.html
Best Regards,
Soumaya
---------------------------------
Créez gratuitement votre Yahoo! Mail avec 100 Mo de stockage !
Créez votre Yahoo! Mail
Le nouveau Yahoo! Messenger est arrivé ! Découvrez toutes les nouveautés pour dialoguer instantanément avec vos amis.Téléchargez GRATUITEMENT ici !
A good alternative with postgres for external actions that might incur
large delays is to use a trigger that simply touches a file in the file
system. A very low-overhead program can watch for a change in the file
timestamp and perform an action. This watcher program can check the
file on a few seconds delay giving much better responsiveness than is
typical of cron or database job scheduling, and the workload on the
database only runs as needed, not every minute.
This also has the advantage (or disadvantage) of transferring the
action to a different security and execution realm. Ie, the operation
now runs as the uid of the watcher program and with the watcher
program's permissions, scheduler-priority, and enviroment, rather than
as the postgres user.
However, as Greg mentioned, we have implemented the code to match
INVITE to BYE. This has not had substantantial stress testing but
certainly operates with no measurable load at >20 calls per minute.
Matching performance is not an issue even with six-figure call
histories. Good indexing completely resolves this for probably any
size, but almost certainly for eight-figure sizes. That's because you
are only ever concerned with the currently active set of calls (those
with no hangup time recorded yet).
The two biggest problems we have encountered are:
BYEs are not reliable. They are initiated solely by the UA, so
even with a completely reliable network, BYEs will go missing
if the user powers down or disconnects their system before
hanging up.
call_ids are not reliable. They are also created by the UA,
and UAs have bugs. Even major vendors have released firmware
that does not produce unique call_ids.
For the most part, these problems can be banged on until they go away.
For the former you could do probing from the proxy to confirm calls are
still in progress. This is still a problem. What if the UA simply
ignores the probe? Then the proxy fakes a BYE to close the call but
the call (the RTP path) is still operating and the caller is now
talking for free. Instead, we use multiple accounting sources for
calls we are actually billing for and for SIP<->SIP we just ignore the
problem because we're not billing that path.
The latter can be resolved using internally generated IDs among a realm
of cooperating proxies, but this is an impossible dream in any mixed
vendor world, and implies all SIP routing must be done through the
realm, which may also be undesirable or unattainable.
Currently we use call_id/fromtag/totag as a key which seems reliable
for most UA vendors and is consistent with the RFC. We also detect
attempts to reuse keys. Currently these are just logged but they will
probably eventually trigger call rejection and might even get to UA mfg
+ firmware version blocking if we start to encounter widespread flaws.
The objective of the latter is to get the manufacturer to take notice.
Andrew Fullford
--
Email: andy(a)addabrand.com
Web: www.addabrand.com
> Cc: <mikep(a)pch.net> <mikep(a)pch.net>,
> Michael Shuler <mike(a)bwsys.net>,
> 'serusers(a)lists.iptel.org' <serusers(a)lists.iptel.org>,
> 'Addabrand Support' <support(a)addabrand.com>
> From: Greg Fausak <greg(a)addabrand.com>
> Subject: Re: [Serusers] Why Transactional Accounting?
> Date: Thu, 12 Aug 2004 09:27:41 -0500
> To: "Arne Scheffer" <arne.scheffer(a)ritstele.com>
>
> Hi Guys,
>
> <soapbox>
> OK, I have to say that I am opinionated about databases. I've been
> working with databases since before Oracle (I actually worked at
> Britton Lee in Los Gatos California, they manufactured a database
> machine).
> Anyway...
>
> Postgres is a serious database engine. When we first starting using
> SER I wrote the postgres backend because it had many characteristics
> that I prefer over the then available mysql engine. I have written
> large
> scale database applications, and I have had the opportunity to
> port applications that were melting on mysql to postgres.
>
> Most databases are administration heavy, postgres is no exception.
> They must be indexed, profiled, analyzed and vacuumed to maintain good
> performance.
>
> For this application, we use:
>
> syslog pushing accounting information to various capturing syslogd's.
> A sweeper that reaps syslog information and populates the postgres
> database.
>
> The customer's call information is live and viewable up to the 6 second
> mark.
> Call INVITE/BYE matcher only has to deal with 'current call' records,
> that is, those
> that haven't been matched. Now, granted, we haven't had a real big
> load (yet), so
> I don't know if it will scale. But, I believe it will.
>
> We don't use triggers either. I think they would work fine but
> they make ad-hoc database changes a bit harder.
> </soapbox>
>
> ---greg
>
>
>
> On Aug 12, 2004, at 2:52 AM, Arne Scheffer wrote:
>
> > Mike,
> >
> > In a high load situation I would not use a trigger. From experience
> > you can encounter big billing delays when you start using complex
> > billing. Most DB's see the trigger as part of your insert action and
> > will not reply to the application that performed the INSERT until the
> > trigger has finished. This means your SER may have to wait for a few
> > seconds to know if the insert was OK (serious performance impact).
> >
> > Now may say a few seconds why ?
> > just take into account you have a number port database with 2M records
> > which you need to scan to see if the number is ported. Can take a
> > second very easily :(
> >
> > I would advise using a JOB on your SQL server (supported by Oracle &
> > MSSQL, Postgres does not support it I think) which runs every minute.
> > You still have the load on the server but SER will not be delayed by
> > TRIGGER.
> >
> > Arne.
> >
> >
> >
> > -----Original Message-----
> > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org]On
> > Behalf Of Michael Przybylski
> > Sent: donderdag 12 augustus 2004 8:32
> > To: Michael Shuler
> > Cc: serusers(a)lists.iptel.org
> > Subject: Re: [Serusers] Why Transactional Accounting?
> >
> >
> > SER seems to support postgresql as an accounting backend, and
> > postgresql
> > support "triggers."
> >
> > This is a synthesis of only a cursory look at the SER source tree and
> > postgresql docs on triggers, but it looks like you can do the
> > following:
> >
> > 1.) Set up SER to use postgresql as it's accounting backend.
> > 2.) Create an extra table with the fields you would like to see in your
> > "real world records."
> > 3.) Create trigger to corelate INVITES and BYEs and insert a row into
> > your
> > "real world records" table every time it notices that a BYE has been
> > inserted into the transactional accounting table.
> >
> > This is still extra CPU load that will hurt your scalability but it's
> > fairly elegant and an experienced PostgreSQL user/admin should be able
> > to
> > crate it up pretty quickly.
> >
> > Finally, I'd bet that a 2-way or 4-way opteron-based database server
> > would
> > hold up to a pretty substantial call volume, even while running that
> > trigger.
> >
> > Best regards,
> > Mike Przybylski
> >
> > On Thu, 12 Aug 2004, Michael Shuler wrote:
> >
> >> At first it seemed like a really good idea then the more I looked at
> >> real
> >> world records I realized that to generate a bill for a customer would
> >> require quite bit of work on MySQL's part to match up the INVITE's
> >> and the
> >> BYE's and then calc the difference in the times. This causes a bit
> >> of a
> >> problem for me because I like my customers to be able to see their CDR
> >> records live. Which really isn't much unless you look at it from a
> >> 100,000
> >> user perspective. I would either have to beat up my SQL server every
> >> time
> >> they look at their records (or my customer service employees look at
> >> them or
> >> even when the biller generates their bill) or run a cron job that
> >> runs every
> >> so often to convert the data to a single record with a start time and
> >> a
> >> duration and store it in another table. The cron idea isn't too
> >> efficient
> >> because of wasting disk space and rewriting a lot of the same data
> >> twice.
> >>
> >> This then leads me to ask why the SER acc module wasn't setup to
> >> generate an
> >> initial start record identical to the INVITE message that it already
> >> does
> >> that would be marked as "in progress"? Then when a BYE is received
> >> with a
> >> matching Call-ID you find the original INVITE record, change its
> >> status to
> >> "done" and populate a duration field. Any ideas why this can't be
> >> done
> >> without affecting SER's scalability? :)
> >>
> >> Thanks!
> >>
> >> ----------------------------------------
> >>
> >> Michael Shuler, C.E.O.
> >> BitWise Systems, Inc.
> >> 682 High Point Lane
> >> East Peoria, IL 61611
> >> Office: (217) 585-0357
> >> Cell: (309) 657-6365
> >> Fax: (309) 213-3500
> >> E-Mail: mike(a)bwsys.net
> >> Customer Service: (877) 976-0711
> >>
> >> _______________________________________________
> >> 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
> >
> >
> Greg Fausak
> www.AddaBrand.com
> (US) 469-546-1265
>
I want to my sems run ivr with test.pl
I edit the sems.conf. Am I right??
ivr_script_path=/usr/local/sipums/scripts/
ivr_script_file=test.pl
And I try sems -E -D 0 I have this error message
could someone how to solve it??And should I recompile plug-in/ivr??
interp is 135218192
filename is /usr/local/sipums/scripts/test.pl
Can't locate Telephony/CTPort.pm in @INC (@INC contains:
/usr/local/openums/lib /usr/lib/perl5/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/5.8.0 /usr/lib/perl5/site_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/site_perl/5.8.0 /usr/lib/perl5/site_perl
/usr/lib/perl5/vendor_perl/5.8.0/i386-linux-thread-multi
/usr/lib/perl5/vendor_perl/5.8.0 /usr/lib/perl5/vendor_perl .) at
/usr/local/openums/lib/OpenUMS/Mwi.pm line 49.
BEGIN failed--compilation aborted at /usr/local/openums/lib/OpenUMS/Mwi.pm
line 49.
Compilation failed in require at /usr/local/sipums/scripts/test.pl line 24.
BEGIN failed--compilation aborted at /usr/local/sipums/scripts/test.pl line 24.
Hello,
Hope anyone can help me. Why is it that when I look on the log, there
are some calls that are marked call answered,
even if those calls haven't been answered on the other side. Meaning
there's a complete INVITE,ACK,BYE but there was really no one who there
to answer on the other side.
Some clients are complaining, why would we bill them for such calls,
when there was really no one answering on the other side. What should I
do to be able to identify what really are the complete calls and what
are not. Thank You
Regards,
Ronald