high.all!
i'm wondering if there is any support of uaCSTA in openser (planned)?
i'm just working on the integration of asterisk (*) environment to OCS 2007
environment, having openSER in the middle (mainly for TCP/UDP translation
and smoothing out the protocol deficienes on both sides). in this setup the
* having the openSER in front is talking to the OCS (and vice versa) via the
OCS mediation server, which is moreorless sending standard SIP messages,
which enables normal softphone (integration to *) of the office
communicator. this configuration is already working...
now i'm planning to go for the CTI integration, where there is no OCS
mediation server in between OCS and openSER, doing the translation of
SIP/CSTA to SIP. i'm thinking about using openSER for this task, that's why
i'm looking for a CSTA module or perl programm, which is capable of this
functionality.
afaik for the CTI communication there isn't the full complexity of CSTA
needed, just a subset mainly for call setup and call clearing.
anyone having experience on this topic?
thx & cheers
-hugo
Great Ideas for Small Devices
Hugo Koblmueller
Senior Staff Engineer Software Development COMNEON electronic
technology GmbH & Co. OHG
Freistaedter Strasse 400
4040 Linz
Austria
hugo.koblmueller(a)comneon.com
tel:
fax:
mobile:
Skype ID: +43 (5) 1777 - 15730
<http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%285%2
9+1777+%2D+15730&Email=hugo(a)koblmueller.com>
+43 (5) 1777 - 15810
+43 (676) 82051280
<http://www.plaxo.com/click_to_call?lang=en&src=jj_signature&To=%2B43+%28676
%29+82051280&Email=hugo(a)koblmueller.com>
drhookson
Want to always have my latest info?
<https://www.plaxo.com/add_me?u=21475050628&src=client_sig_212_1_banner_join
&invite=1&lang=en> Want a signature like
<http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig&lang=en>
this?
I'm running into a problem with rtpproxy on this point,
quoting from the README:
- - - - - - - - - - -
- after the session has been created, the proxy listens on the port it has
allocated for that session and waits for receiving at least one UDP
packet from each of two parties participating in the call. Once such
packet is received, the proxy fills one of two ip:port structures
associated with each call with source ip:port of that packet. When both
structures are filled in, the proxy starts relaying UDP packets between
parties;
- - - - - - - - - - -
However, a number of clients frequently fail to emit any audio
when originating a call until they hear something from the
TDM gateway, such as ring-back or the called party answering.
So although rtpproxy is receiving a stream of audio, such as
a voice mail menu robot, the calling party can't hear any of
it unless they happen to make some noise or randomly and blindly
press a DTMF key. This seems to be made worse on links with
silence suppression, so there is no background noise to
trigger two-way audio. This is being encountered between Class 4
carriers, so we don't have the option to get someone to
adjust their phone/PBX settings or have them breathe heavier.
Is there a setting adjustment to get rtpproxy to just pass
the RTP packets from directed calling and called sources
even if one party hasn't happened to make noise yet?
I personally don't understand why this requirement for
seeing audio from both sides before starting the flow in
either direction if audio starts coming in even exists.
It seems to have no benefit but is bound to cause this
deadly embrace problem in many situations that may be
beyond the control of the owners of the equipment
passing traffic along to the site where rtpproxy is in
use.
Suggestions? Fix? I have looked at the latest snapshot
of rtpproxy and the README is unchanged since 1.1 so
apparently this behavior is still the same.
Thanks in advance!
Hi, maybe this question is a bit off-topic so I'm sorry for that.
My question is about SIP providers using OpenSer that associate PSTN numbers
to their local clients (SIP accounts):
Usually the client must register to OpenSer in order to receive calls. Then it
will appear in location table with "Contact=sip:clientX@IP".
Suppose clientX has two PSTN numbers associated in a ENUM entry:
+34999000111
+34999000222
When anyone in PSTN world calls to +34999000222 the call will arrive to the
OpenSer from a gateway in an INVITE like:
INVITE sip:+34999000222@gateway SIP/2.0
To: <sip:+34999000222@gateway>
The OpenSer will do the lookup in location table and finally send this INVITE
to the clientX:
INVITE sip:clientX@IP_clientX SIP/2.0
To: <sip:+34999000222@gateway>
The info about the called PSTN number is just available in "To" header, so a
way to get different behaviour for each associated PSTN number is
matching "To" URI.
Is common to do it? which other alternatives are there?
Thanks for any comment. Regards.
--
Iñaki Baz Castillo
ibc(a)in.ilimit.es
I currently have three Asterisk servers in my environment. None of them
speak to each other just yet. The idea is to install Kamailio and be able to
load balance/distribute SIP calls to any of the three asterisk boxes. If an
entire box plug gets pulled, the operation continues. If a Kamailio box
gets the plug pulled (and due to limited resources, I plan at first to run
kamailio on all three of the asterisk boxes), the operation will continue.
Does anyone have good documentation or insight in order to facilitate this
sort of setup?
Thanks.
Hi,
I was wondering if anyone has used "substr()" function from TEXTOPS in "onreply_route" block. This function works fine in "route" and "branch_route" blocks. However, it creates duplicate fields (instead of substituting) when being used in "onreply_route" blocks.
I need to modify FROM field in "onreply_route" block. As far as I know, "uac_replace_from()" function works only in request_route block, so my only option is to use "substr()".
Thanks,
Alex R
_________________________________________________________________
Proud to be a PC? Show the world. Download the “I’m a PC” Messenger themepack now.
hthttp://clk.atdmt.com/MRT/go/119642558/direct/01/
I have motivated the creation of a port of kamailio to OpenBSD, the
port creates binary packages, which can then be added via the pkg_add
command.
I could definitely use input and testing of this port from the
kamailio community, if you are interested in running kamailio on
OpenBSD, I could use your help!
We also needed to create a port of radiusclient to support kamailio.
Both ports are attached to the messages appended below.
Don
Begin forwarded message:
> From: Don Jackson <don.jackson(a)gmail.com>
> Date: November 18, 2008 11:16:22 AM PST
> To: ports(a)openbsd.org
> Subject: NEW: telephony/kamailio-1.4.2 (kamailio used to be called
> OpenSER)
>
>
> Tested on 4.4/amd64, definitely interested in more testing
>
> $ cat DESCR-main
>
> KAMAILIO (OpenSER) is a mature and flexible open source SIP server
> (RFC3261).
> It can be used on systems with limitted resources as well as on
> carrier grade
> servers, scaling to up to thousands call setups per second. It is
> written in
> pure C for Unix/Linux-like systems with architecture specific
> optimizations to
> offer high performances. It is customizable, being able to feature
> as fast load
> balancer; SIP server flavours: registrar, location server, proxy
> server,
> redirect server; gateway to SMS/XMPP; or advanced VoIP application
> server.
>
>
Begin forwarded message:
> From: Don Jackson <don.jackson(a)gmail.com>
> Date: November 18, 2008 11:11:53 AM PST
> To: ports(a)openbsd.org
> Subject: NEW: net/radiusclient-ng-0.5.6
>
>
> This port is needed for the kamailio/openser port (see subsequent
> email)
>
> Tested on 4.4/amd64, definitely interested in more testing.
>
> $ cat pkg/DESCR
>
> Purpose of this project is to build portable, easy-to-use and standard
> compliant library suitable for developing free and commercial software
> that need support for a RADIUS protocol (RFCs 2138 and 2139).
>
>
>
>
Hi, it doesn't make sense:
xlog("L_INFO","--- time pre http: $Tf - $Ts\n");
http_query("/test1.html",
"r_uri=$(ru{s.escape.param})&f_uri=$(fu{s.escape.param})",
"$var(result)");
xlog("L_INFO","--- time post http: $Tf - $Ts\n");
I always get:
--- time pre http: Mon Nov 24 14:37:25 2008 - 1227533845
--- time post http: Mon Nov 24 14:37:25 2008 - 1227533845
Of course it's just impossible that the http query takes 0.000 seconds.
I could use 'benchmark' module fot this stuf, but I wonder why $Tf returns the
same value in any place of the script. Maybe it is just computed at the
script start for each message?
Thanks.
--
Iñaki Baz Castillo
Jeroen van Bemmel wrote:
> Frank,
>
> RFC3261 specifically specifies that proxies should convert response code
> 503 into 500:
>
> A proxy which receives a 503 (Service Unavailable) response
> SHOULD NOT forward it upstream unless it can determine that any
> subsequent requests it might proxy will also generate a 503.
> In other words, forwarding a 503 means that the proxy knows it
> cannot service any requests, not just the one for the Request-
> URI in the request which generated the 503. If the only
> response that was received is a 503, the proxy SHOULD generate
> a 500 response and forward that upstream.
>
> So SER is behaving in accordance with the standard. There might be a
> configuration option to turn this off?
Well, yes and no. Thanks for pointing out this item in the RFC which
I missed, but if the RFC action is honored, then SER should have
emitted "500 Server Internal Error" which is in the RFC, and
not the hybrid and made-up "500 Service Unavailable", which is
not in the RFC. So, I think SER is wrong at least on that point.
(Personally I think SIP desperately needs at least 20 additional
defined Response Codes so we can all quit using the existing
not-entirely-inappropriate values to cover real-life situations,
but right now the book says that's all the codes that we've all
got to work with. When you see a dozen SS7 release codes all
map to the same SIP Response Codes, you don't have nearly enough
SIP Response Codes, but I digress.)
That said, our SER server knows the given condition sent from
a paired PSTN switch is permanent, eg the SIP caller can't
call this number via our network now, tomorrow or next week
because of who you they or whom their provider is (or what
they failed to buy), so in this situation returning 503 all
the way out of our network is correct behavior (as stated in
the RFC), and doing so allows the upstream entity to click
over to the next preferred carrier that might reach that
destination.
We have found that many SIP providers simply blindly lob all
calls at the cheapest carrier and if a given call bounces,
repeat that action with the next-cheapest carrier, and the
next until they finally resort to a Tandem that will take
anything, but will also be the most expensive way to route
the call. Nearly all require us to send them back a 503
(a few want us to send 502 back instead) to say back to them
"not via here, try next door". Deplorable and this method
certainly causes slow call set-up times, but that is what
quite a few of these outfits are doing.
So, our SER must send them back a 503 and not a 500 in this
situation. If I explicitly state one in a reply rule, will that
override this default behavior, or will some deeper part of SER
veto even a sl_reply("503", "Service Unavailable"); added to the
onreply_route? If so, where is this piece of source code, so
that I may break this well-intended but undesired behavior?
El Jueves, 27 de Noviembre de 2008, Daniel Serrano escribió:
> Dear all,
>
> I am using SER as IM server and I found that the SER use the contact
> field to storage the user's location in the memory for future requests.
> I noted this using the command "serctl alias show" and checking some
> traces.
> Since I'm using a NAT scenario I'd like to use the UDP port that my
> SER server receives during the registration instead of the contact
> field port to reach the users after their registration. Is there any
> way to do this?
"rport" does it, but the client must indicate support of "rport" by
adding ";rport" parameter to its Via header.
Anyway, *SER can force it by using "force_rport()".
--
Iñaki Baz Castillo
Hi all,
I notice a thing about PDT module.
If you try to put in the table two entry with the same destination
domain at the load of the parameter is reported an error of duplication:
Nov 28 09:32:23 [5169] ERROR:pdt:pdt_load_db: sdomain [*]: prefix
[04610202] or domain <tnn.multivoce.tnnet.it> duplicated
entry of the table
id | sdomain | prefix | domain
----+---------+----------+--------------------------
1 | * | * | intercom.tnnet.it
4 | * | 04610200 | tsm.multivoce.tnnet.it
2 | * | 04610201 | tnn.multivoce.tnnet.it
3 | * | 04610202 | tnn.multivoce.tnnet.it
Is this mean that the prefix must be only one for a single domain.
This is a limition where I have a single domain that manage multiple
prefix not consecutive.
Did I understand right?
Matteo
--
====================================
Matteo Piazza
Trentino Network s.r.l. a Socio Unico
matteo.piazza(a)trentinonetwork.it
Via Gilli, 2 - 38100 TRENTO
Tel (+39) 0461.020224
====================================