sr-users November 2008

sr-users@lists.kamailio.org

97 participants
170 discussions

[OpenSER-Users] uaCSTA support in openser
by Hugo Koblmueller 09 Feb '11

09 Feb '11

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?

7 13

[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?
by Frank Durda IV 20 Mar '09

20 Mar '09

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!

4 15

[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?
by Iñaki Baz Castillo 27 Feb '09

27 Feb '09

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

7 17

[Kamailio-Users] Looking for a highly available / load balanced setup
by John D 11 Feb '09

11 Feb '09

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.

4 6

[Kamailio-Users] using "substr()" function from TEXTOPS in "onreply_route" block
by Alex R.S.M 08 Dec '08

08 Dec '08

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/

3 3

[Kamailio-Users] Port of kamailio to OpenBSD
by Don Jackson 05 Dec '08

05 Dec '08

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). > > > >

2 3

[Kamailio-Users] How are computed $Tf and $Ts?
by Iñaki Baz Castillo 03 Dec '08

03 Dec '08

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

2 4

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?
by Frank Durda IV 03 Dec '08

03 Dec '08

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?

5 8

Re: [Serusers] Registering port instead of contact field port
by Iñaki Baz Castillo 02 Dec '08

02 Dec '08

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

3 5

[Kamailio-Users] PDT module - multiple prefix single domain
by Matteo Piazza 02 Dec '08

02 Dec '08

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 ====================================

3 6

Jump to page:

2025

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 November 2008