sr-users February 2010

sr-users@lists.kamailio.org

59 participants
109 discussions

[Kamailio-Users] PCRE Regex / Transformations Bug?

by Brandon Armstead

Hello, I'm attempting to use the following in Kamailio: $(hdr(from){re.subst,/(.*?);(.*)/\1/}) --- however it does not match / replace, with this from header sample: From: <sip:714364XXXX@XX.XX.XX.XX ;pstn-params=808282808882;cpc=unknown>;tag=gK0b53f6d9 However if this is fully pcre compatible, then I am a bit lost as I've checked the results in php, perl, and python produces: From: <sip:714364XXXX@XX.XX.XX.XX (expected result) However, Kamailio does not match / replace / etc using the following: xlog("L_INFO", "Test From Header Regex: $(hdr(from){re.subst,/(.*?);(.*)/\1/})"); Code Samples / Regex Pattern Replacements: PHP: http://codepad.org/CUttQH1r Perl: http://codepad.org/ZfAO4X5v Python: http://codepad.org/T14SYWkZ Any comments / help / etc is always appreciated, look forward to hearing back from you all! Sincerely, Brandon Armstead

14 years

[Kamailio-Users] Exotic case (but real) in which RtpProxy doesn't work

by Iñaki Baz Castillo

Hi, I've a problem with an Alcatel PBX in the way it performs transference: - Alcatel (behind NAT) sends INVITE to 111 and Kamailio forces RtpProxy. Let's assume the selected UDP port for RtpProxy is 1000. - Alcatel sends INVITE to 222 and Kamailio forces RtpProxy. Let's assume the selected UDP port for RtpProxy is 2000. Then Alcatel performs the transference as follows: - It sends a re-INVITE for 111 to Kamailio by setting the SDP to the IP or RtpProxy and port 2000. - It also sends a re-INVITE for 222 to Kamailio by setting the SDP to the IP or RtpProxy and port 1000. This is, Alcatel wants that the provider (me) sends the RTP to itself, while mantaining the original SIP dialogs established (so it's ok at signalling level, but at RTP level it cannot work as RtpProxy shoud send RTP to itself). I'm thinking on how to solve it but find no solution. Any suggestion? Thanks. -- Iñaki Baz Castillo <ibc(a)aliax.net>

14 years

[Kamailio-Users] new module: embedded lua

by Daniel-Constantin Mierla

Hello, few weeks ago I uploaded a new module named app_lua, providing functionality to execute Lua (http://www.lua.org) scripts in your configuration file. Lua is small and fast, therefore fits very well in a sip proxy environment. It has a lot of extensions, so when you cannot do something with existing cfg functions, check this one as well. The readme and the api are available at: http://sip-router.org/wiki/api/lua/devel http://sip-router.org/docbook/sip-router/branch/master/modules/app_lua/app_… The API will be enhanced during this development cycle, your feedback will help a lot in this direction. By now you get access to pseudo-variables, sip headers, logging functions and sl module. For new comers in community, if you are a Perl fan, then you can use the perl module in a similar way. Also, another module was uploaded recently, app_python, allowing to write python extensions. Module and API for Python are not yet documented, but I think this is not a barrier for a true Python fan, actually I hope will be a motivation to contribute the docs :-) Cheers, Daniel -- Daniel-Constantin Mierla SIP Server Professional Solutions * http://www.asipto.com/

14 years

[Serusers] ReTransmission of CANCELs on 0.9.7

by rupert.organ＠bt.com

Hi All, Has anyone come up against an issue on 0.9.6 / 0.9.7 whereby a SIP App Server, delivers a CANCEL to the SER. The SER proxies the CANCELs to all the forked endpoints. At the same time it sends "200 Cancelling" back to the SIP App server...(this suppresses CANCEL retransmission from the SIP App server). If one of the CANCELs from the SER to the SIP UA gets lost....the phone keeps ringing. There is no CANCEL retransmission on the SER !!! There is CANCEL retransmission on the SIP App, but when it sends SER replies "no pending branches" Ideally want the SER do CANCEL retransmissions. I understand the timers were rewritten in 0.10.x but this is not hardened version like 0.9.6....any suggestions? Thanks in advance Rupert

14 years

[Kamailio-Users] What is the best module for routing INVITE based on DID in R-URI?

by Geoffrey Mina

Hello, I am putting up a Kamailio server which will do nothing but route INVITE requests from my upstream carrier to individual offices on my side. The office locations will NOT be registered SIP UAs, but other Kamailio proxy servers. What I want to have is a database of DIDs associated with a forwarding IP:Port and/or SRV records. 5555551212 ==> 1.2.3.4:5060 5555551213 ==> 1.2.3.5:5060 etc. Any guidance on what the best approach to achieving my goal would be much appreciated. Thanks, Geoff

14 years, 1 month

[Serusers] Need a way to substitute SIP Response Code 504 for something else

by Frank Durda IV

There is a commercial switch vendor who has recently decided to make two changes that combined are quite evil: 1, They decided to devivate from RFC 3398 and when a given call INVITE timer expire (any of the SS7 ones, plus the SIP ones, including any limit specified in the INVITE itself), instead of translating the ISUP Release Cause 102 into a SIP Response Code of 504 (Gateway Timeout), they send out a 503 (Service Unavailable) instead. (503 is commonly used in low-cost carriers and the commercial equipment they use to trigger a route-advance, where the call doesn't end but is relaunched via another slightly more expensive route/carrier who perhaps can get the call to the destination. Some of these low-cost outfits may retry the same call with five or six carriers before reluctantly sending to the local access tandem which is usually the most expensive choice, but almost certain to work. This probably isn't what the inventors of the 503 code had in mind, but that is how it is used. A minority use 404 the same way.) 2. The same vendor implemented an automatic "Address Reach" testing mechanism for outbound calls. This thing means that when sending a call to a distant switch, if a single or small number of calls are returned from that distant switch with a SIP Response Code of 504 from the destination, the sending switch will take that destination switch completely out of route ("blacklist") and not send any calls at all to that destination until the blacklist is manually reset. So a result that applies to one call is fatal to all subsequent calls. This also means that if you sent the INVITE Expires timer to a value less than the number of seconds the calling party is willing to let the called number ring (called party doesn't have voice mail or it doesn't pick up for several rings), you trigger a 504 and bingo, you have killed the route between those two switches. So your own choices for how long to wait on ring-back for a call dictate how quickly it could kill the entire route for that call. Now, the two changes taken together are also somewhat convienent because this equipment maker just happened to make it impossible for their own equipment to ever return a 504 and do can never trip off their own booby-trap. So in a way what these two changes effectively create a not-our-hardware-detector, triggering route failures only when in contact with RFC-compliant equipment made by somebody else. I think that behavior is anti-competitive, and probably illegal in quite a few countries (notably the EU), but that is what exists at the moment. This creation started getting deployed in the past few months. So, to get around this nonsense, I need a way in SER to detect that a 504 has come in and change it to something else before sending it on. I won't quibble about the "proxies can't forward a 503", so I won't try that. I would like to turn the 504 into a 404, which is better than having route get pulled all over the place. Now, the last time (a year or so ago) I asked about trying to change a SIP Response Code in SER, the suggested ser.cfg "fix" created all sorts of strange warnings in the logs about timers expiring and I was told to not worry about that. Well, it seemed to cause a lot more problems than just warnings like memory leaks or cores caused by something, so I ended up having to hard-code the translation I wanted into the SER source code and not use rules in ser.cfg to do this. I'm writing now to (A) alert people about what this major brand switch maker is doing with regard to 504s so you will recognize it if you encounter it, but also (B) to see if maybe has a more elegant way to change SIP Responses via the ser.cfg file has emerged. The obvious things like subst subst_uri don't appear to work, obviously busily editing the non-existent INVITE method message and ignoring the reply message. Using a reply/drop combination to generate a new reply and kill the real one doesn't seem to work either. As I recall it ends up sending the response specified in the reply, and then passing the original response as well. "drop" apparently doesn't kill it completely and I suspect reply is really meant to be used only during handling of the method messages, and not the response messages. Suggestions appreciated.

14 years, 2 months

[Kamailio-Users] Kamailio and SIP <-> XMPP gateway

by Even André Fiskvik

Hi. I've just started looking at kamailio, and I'm experimenting a bit with configuring a SIP <-> XMPP gateway with it using the pua_xmpp module. The configuration part hasn't beed straight-forward, but I think I'm starting to get somewhere. Both kamailio and XMPP/Jabber are new technologies for me serverside, so I don't have a great deal of experience with either. In short, what I'm trying to accomplish at this stage is: - Have CounterPath eyeBeam/Bria to register to my kamailio server - Have Aastra 6755i register to my kamailio server - Connect an XMPP client to my XMPP server - The CounterPath eyeBeam/Bria, Aastra and the XMPP client should all be able to see each others presence - The CounterPath eyeBeam/Bria should be able to IM other eyeBeams/Brias - The CounterPath eyeBeam/bria should be able to IM the XMPP clients and the other way around Reading through various earlier discussion though, I've found an issue that I wonder wether has been solved or not. In some mailing-lists I saw that only text/plain MESSAGEs was supported through the xmpp gateway, is this still true? If that's the case, is there any way to get CounterPath eyeBeam/Bria to work in the decribed scenario? As to my knowledge it can only send text/html ? Could anyone with a good knowledge of Kamailio and the various modules pua_xmpp, xmpp, pua, pua_bla comment on this kind of setup is at all possible with kamailio and it's current state? Is there any way I can verify that opensips connects to the XMPP server correctly? I tried connecting FreeSWITCH to my XMPP server (Openfire) in component mode, and it would show up connected in Openfire's administration GUI, however I can not see the same when I try to configure kamailio. If anyone has experience with this setup and have another XMPP server they have tested it with, I would also want to try to swap Openfire with that (given they also have some guidance on XMPP server configuration). Best regards, Even André Fiskvik

14 years, 2 months

[Kamailio-Users] remove parameter

by Elgar Onel

Dear friends, how to remove parameters from INVITE sip address? tia, e.

14 years, 2 months

[Kamailio-Users] ratelimit enhancements

by Daniel-Constantin Mierla

Hi Marius, since you did some updates to this module, I am opening for debate some needed enhancements I did during 3.0 testing phase and want to get opinions how to get in the code repo. Practically is a new module I named for now ratelimit2 and my last idea is to get it named pipelimit in the trunk. The reason for a new module are some major changes. The module uses the same algorithm but its core is overhaul. - definitions of pipes are loaded from database - there can be unlimited number of pipes - pipes are identified by string names - should be possible to reload pipes at runtime (iirc, not yet in) - new pipes can be added at runtime - functions accept variables to identify the pipe Since I never used queues from this module and haven't spent time to understand the concept behind, this functionality is completely missing. The old module might be good to keep in place, probably many people are using it in this form. So, proposals? What is the way to go on? Common code (algorithms) can be made lib at some point. Cheers, Daniel -- Daniel-Constantin Mierla * http://www.asipto.com/

14 years, 2 months

[Kamailio-Users] tracking new features

by Daniel-Constantin Mierla

Hello, a reminder for developers to write a short note for each new feature either to NEWS file in source tree or to wiki page: http://sip-router.org/wiki/features/new-in-devel Makes life much easier when the next major release is going to happen and help people to spot quickly what new features are already available in devel branch, hopefully attracting some of them to go for it and test. Now the wiki page is updated with most of NEWS content for 3.1. Thanks, Daniel -- Daniel-Constantin Mierla Kamailio SIP Router Masterclass, Berlin, March 22-26, 2010 * http://www.asipto.com/index.php/sip-router-masterclass/

14 years, 2 months

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 February 2010