sr-users October 2008

sr-users@lists.kamailio.org

93 participants
169 discussions

[OpenSER-Users] uaCSTA support in openser

by Hugo Koblmueller

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?

12 years, 1 month

[Serusers] Deadly embrace with rtpproxy - Is it necessary? Can it be turned off?

by Frank Durda IV

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!

14 years

[OpenSER-Users] [OT] How to handle different DID's in incoming calls for a registered client?

by Iñaki Baz Castillo

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

14 years, 1 month

[Kamailio-Users] Looking for a highly available / load balanced setup

by John D

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.

14 years, 1 month

Re: [Serusers] How can I keep SER from changing reply Response Code from 503 to 500?

by Frank Durda IV

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?

14 years, 3 months

[Kamailio-Users] Engaging rtpproxy

by Graham Wooden

Hi list, I currently don¹t proxy audio nor have any plans to for all calls, except for the "302 Redirect", where I need kamailio to become a b2bua with RTPproxy (or for the record CALEA). However, I can¹t seem to get the ³if² statement down on where ³engage_media_proxy² gets called without doing it for all outbound calls. What is the best way to identify a call that was from a SIP client that issued a 302? My last effort was: if ( uri == mysqlf && is_method("INVITE") ){ But that seemed to get every call. Any guidance would be appreciated, thanks. -graham

14 years, 4 months

[Kamailio-Users] Core dump on writing dialog profile size into script var.

by Alex Balashov

I also have another interesting problem with the aforementioned configuration (http://pastebin.com/f28051a5). When I write the dialog profile size into an AVP, it works fine. When I write it into a script var, i.e. replace $avp(S:dlg_sz) with $var(dlg_sz), it crashes: Relaying INVITE from 210.23.22.23 to sip:2122222322@210.23.22.23:5060 [D] Added new dialog for 7709600101 [ONREPLY-ROUTE 1] Provisional reply 100 received. [ONREPLY-ROUTE 1] 200 OK received for 7709600101 [ONREPLY-ROUTE 1] INVITE/200 is part of dialog for 7709600101 Segmentation fault (core dumped) GDB reveals: Program received signal SIGSEGV, Segmentation fault. 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 (gdb) where #0 0xb7e7f2f8 in strncpy () from /lib/i686/nosegneg/libc.so.6 #1 0x080a4a07 in set_var_value (var=0x8188d98, value=0xbfae5f28, flags=<value o at script_var.c:122 #2 0xb7d6c4fe in w_get_profile_size (msg=0x81902b8, profile=0xb5ede180 "\034??\ value=0x818b6b8 "@?\030\b", result=0x818b6f8 "N") at dialog.c:668 #3 0x08054f15 in do_action (a=0x818b850, msg=0x81902b8) at action.c:850 #4 0x08053ed2 in run_action_list (a=0x818b5c8, msg=0x81902b8) at action.c:138 #5 0x08056365 in do_action (a=0x818bab8, msg=0x81902b8) at action.c:722 #6 0x08053ed2 in run_action_list (a=0x818b178, msg=0x81902b8) at action.c:138 #7 0x080572c2 in run_top_route (a=0x818b178, msg=0x81902b8) at action.c:118 #8 0xb7de3a64 in reply_received (p_msg=0x81902b8) at t_reply.c:1361 #9 0x08064793 in forward_reply (msg=0x81902b8) at forward.c:507 #10 0x08090d5b in receive_msg ( buf=0x81600e0 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 215.22.22.22;branch=z9hG4 08.52.173.18\r\nVia: SIP/2.0/UDP 198.225.86.10:5060;branch=z9hG4bKragjo0207gm0dc p:208.52."..., len=814, rcv_info=0xbfae65d4) at receive.c:203 #11 0x080cccfb in udp_rcv_loop () at udp_server.c:449 #12 0x0806b78d in main (argc=1, argv=0xbfae6764) at main.c:693 It would seem to me that there is some sort of buffer overflow issue that results in the garbage seen above. Not sure that it makes a difference, but the glibc being linked against is a Xen-safe one that disables TLS functionality. This is all running inside a Xen DomU. -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

14 years, 4 months

[Kamailio-Users] [Fwd: Re: [Sip-implementors] REGISTER R-URI with port parameter]

by Alex Balashov

Does Kamailio match 'uri == myself' if the domain is the same as the canonical hostnames/aliases but the port is different than the one Kamailio knows itself to be listening on? -------- Original Message -------- Subject: Re: [Sip-implementors] REGISTER R-URI with port parameter Date: Tue, 28 Oct 2008 16:46:04 -0500 From: Dale.Worley(a)comcast.net To: sip-implementors(a)lists.cs.columbia.edu References: <00D42150952F70458C66072322F7FE2502EDA940(a)saturn2.aculab.com> <200810241652.m9OGqx6s027493(a)dragon.ariadne.com> <200810241902.43581.ibc(a)aliax.net> From: =?iso-8859-1?q?I=F1aki_Baz_Castillo?= <ibc(a)aliax.net> El Viernes, 24 de Octubre de 2008, Dale.Worley(a)comcast.net escribió: > sip:xxx@host:5060 > sip:xxx@host:15060 > sip:xxx@host:25060 > sip:xxx@host:35060 > > In that case, the request-URI of the REGISTER needs to contain the > proper port number. Well, not totally needed. A UA could construct a REGISTER like this: REGISTER sip:xxx@host SIP/2.0 and sent it to host:15060. You can't depend on that working -- It's never been settled what must happen if a SIP message arrives at a UAS which isn't the UAS that the RFC 3263 rules would send it to. It's possible that the UAS will forward it based on the request-URI. It's safer to include the port, if the destination port is not 5060. For example Twinkle does it if you set the registrar in a port different than 5060. I wouldn't depend on that working. Dale _______________________________________________ Sip-implementors mailing list Sip-implementors(a)lists.cs.columbia.edu https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors -- Alex Balashov Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671 Mobile : (+1) (706) 338-8599

14 years, 4 months

[Kamailio-Users] Passing REGISTERs up stream

by Daniel Corbe

Guys, When attempting to pass REGISTER requests up stream I get the following error messages on the console (below). This also brings up the question of "what is the best way to simply pass REGISTER requests on to an upstream registrar?" Thanks for the help. -Daniel REGISTER: NATed client, enabling NAT Oct 29 18:03:58 [48175] ERROR:tm:t_forward_nonack: no branch for forwarding Oct 29 18:03:58 [48175] ERROR:tm:w_t_relay: t_forward_nonack failed Oct 29 18:03:58 [48175] ERROR:tm:t_forward_nonack: no branch for forwarding Oct 29 18:03:58 [48175] ERROR:tm:w_t_relay: t_forward_nonack failed Oct 29 18:03:59 [48175] CRITICAL:tm:t_should_relay_response: pick_branch failed (lowest==-1) for code 401 Here's the relevant parts of my ser config; in route[1] route[1] { ... if (method == "REGISTER") { route(2); } route(1); } route[2] { # Check to see if the UAC is trying to UNREGISTER. If not test # for NAT. If NAT is present, we mark it as such before we save() # the location, that way flag 6 is always set for NATed UAs. if (!search("^Contact:[ ]*\*") && nat_uac_test("19")) { xlog("L_NOTICE", "REGISTER: NATed client, enabling NAT\n"); setflag(6); fix_nated_register(); force_rport(); }; # We must handle replies for registrations, for caching and location # tracking purposes. t_on_reply("1"); t_on_failure("1"); # Check for digest #if (radius_www_authorize("")) #{ # xlog("L_NOTICE", "REGISTER: No Digest, sending challenge\n"); # www_challenge("", "0"); # exit; #} # Digest was good if we get here #save("location"); # Relay register to porta t_relay("216.151.143.69"); } onreply_route[2] { if (status =~ "2[0-9][0-9]") { # save("location"); }; }

14 years, 4 months

[Kamailio-Users] Remote-Party-ID header

by ALAEDDINE abbech

hi all, Please, what is the role of Remote-Party-ID header? thanks

14 years, 4 months

Jump to page:

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

sr-users October 2008