sr-users February 2008

sr-users@lists.kamailio.org

146 participants
260 discussions

[OpenSER-Users] OpenSER: xcap_auth.c, does it filter other conditions except action/sub-handling, like sphere and va

by KevinKinnan

My testplatform is openser+openxcap. Only using action/sub-handling as permission rules passed the test. But neither sphere and validity rules works. The file "xcap_auth.c" in presence_xml directory can't give me any clue about sphere and validity. Does openser(presence_xml) support sphere and validity as presence auth rules when fetching xcap doc from OpenXCAP server? Thank you! Kevin, _________________________________________________________________ MSN 中文网，最新时尚生活资讯，白领聚集门户。 http://cn.msn.com

16 years, 9 months

[Serusers] FW: Intercept SIP call

by roayu

Resend. _____ From: roayu Sent: Wednesday, February 20, 2008 11:21 AM To: serusers(a)lists.iptel.org Cc: roayu Subject: Intercept SIP call Hi there! Recently, I had setup a SIP environment with few sip phones, SIPphone A, SIPphone B, and SIPphone C. For instance, when SIPphone A called to SIPphone B, but B is not able to answer the call. Can SIPphone C answer A's call? I would like to know whether is SER able to have the intercept sip calls function? If yes, what module or configuration that I need to set? Thanks in advance! Best regards, RoaYu

16 years, 9 months

[Serusers] Intercept SIP call

by roayu

Hi there! Recently, I had setup a SIP environment with few sip phones, SIPphone A, SIPphone B, and SIPphone C. For instance, when SIPphone A called to SIPphone B, but B is not able to answer the call. Can SIPphone C answer A's call? I would like to know whether is SER able to have the intercept sip calls function? If yes, what module or configuration that I need to set? Thanks in advance! Best regards, RoaYu

16 years, 9 months

[Serusers] Still having problems with these ACKs (and BYEs).

by SIP

While it all works fine for our locally-registered users (and for some of our peers), I'm still having problems from some peers dialing numbers on our service. What happens is that we get an ACK (all our ACKs are set to simply relay), and that ACK bounces around inside our server for a while, then times out without ever replying -- which, after a short period of time, cancels the connection for the peer, since they don't see any ACK replies. We start with a normal ACK sent from the remote peer (198.65.166.131) to our server (22.33.44.55): U 198.65.166.131:5060 -> 22.33.44.55:5060 ACK sip:301@22.33.44.55:5060 SIP/2.0. Record-Route: <sip:198.65.166.131;ftag=j5j3wijb3t;lr>. Via: SIP/2.0/UDP 198.65.166.131;branch=0. Via: SIP/2.0/UDP 192.168.1.51:2051;received=63.95.254.25;branch=z9hG4bK-wv3vqqoh qdm9;rport=2051. Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. From: "User One" <sip:17471111111@proxy01.sipphone.com:5060>;tag=j5j3wijb3t. To: <sip:1101301@proxy01.sipphone.com;user=phone>;tag=as6c9ca1f6. Call-ID: 3c26d1cab239-obtsvl9px3gg@snom190. CSeq: 1 ACK. Max-Forwards: 16. Contact: <sip:17471111111@192.168.1.51:2051;line=ir1tukx9;nat=yes>. Content-Length: 0. P-hint: rr-enforced. P-NATed-URI: YES (1). P-RTP-Proxy: YES (1). We end up getting things that look like this: U 22.33.44.55:5060 -> 22.33.44.55:5060 ACK sip:301@22.33.44.55:5060 SIP/2.0. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:22.33.44.55;ftag=j5j3wijb3t;lr=on>. Record-Route: <sip:198.65.166.131;ftag=j5j3wijb3t;lr>. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 22.33.44.55;branch=0. Via: SIP/2.0/UDP 198.65.166.131;branch=0. Via: SIP/2.0/UDP 192.168.1.51:2051;received=63.95.254.25;branch=z9hG4bK-wv3vqqoh qdm9;rport=2051. From: "User One" <sip:17471111111@proxy01.sipphone.com:5060>;tag=j5j3wijb3t. To: <sip:1101301@proxy01.sipphone.com;user=phone>;tag=as6c9ca1f6. Call-ID: 3c26d1cab239-obtsvl9px3gg@snom190. CSeq: 1 ACK. Max-Forwards: 2. Contact: <sip:17471111111@192.168.1.51:2051;line=ir1tukx9;nat=yes>. Content-Length: 0. P-hint: rr-enforced. P-NATed-URI: YES (1). P-RTP-Proxy: YES (1). The top of that message shows that this is a message sent from our server to our server, and it just tacks on a Record-Route and a Via line one after another until it times out. Again, my ACK handler is simply: if(method=="ACK") { route(1); break; } The record route is the very basic: if(method!="REGISTER") { record_route(); }; And route[1] is just: route[1] { if (!t_relay()) { sl_reply_error(); }; } All very basic stuff (and straight from the getting started pages I think), and it mostly all works. Local users have no issues. Some peers are okay. But several of them are NOT, and I've tried everything I can think of and can't get ACKs to behave. Can someone give me a bit of a clue as to what to look at? I don't understand the reason for tacking on another RR param each time (nor do I REALLY understand why the lr=on is tacked on when this is clearly not loose-routed). Some days, I feel like I really have a handle on SER. Other days, I feel like I'm stumbling blindly. I never seem to get to a level of comfort. N.

16 years, 9 months

[OpenSER-Users] Openser 1.3 crashes with SIGNAL 10 on Solaris

by Sergio Gutierrez

Hello Everybody. Our deployment of OpenSER 1.3 is crashing repeatedly, announcing the reception of SIGNAL 10 at timer process This is the tail lines of log: Feb 17 11:47:55 [4629] WARNING:core:run_actions: null action list (rec_level=2) Feb 17 11:47:55 [4646] CRITICAL:core:receive_fd: EOF on 16 Feb 17 11:47:55 [4628] WARNING:core:run_actions: null action list (rec_level=2) Feb 17 11:47:55 [4623] INFO:core:handle_sigs: child process 4632 exited by a signal 10 Feb 17 11:47:55 [4623] INFO:core:handle_sigs: core was generated Feb 17 11:47:55 [4623] INFO:core:handle_sigs: terminating due to SIGCHLD Feb 17 11:47:55sig_us]: signal e : signa: r received ce: sig15 rec received and this is the backtrace of the core file: #0 fm_free (qm=0x14d118, p=0x30001516) at mem/f_malloc.c:333 #1 0x000be270 in db_free_columns (_r=0x189d68) at db/db_col.c:39 #2 0xfeda6bc4 in db_mysql_free_dbresult (_r=0x189d68) at res.c:191 #3 0xfeda2db4 in db_mysql_free_result (_h=0x16c658, _r=0x189d68) at dbase.c :249 #4 0xff044234 in get_all_ucontacts (buf=0x189d75, len=152445, flags=64, part_idx=0, part_max=1) at dlist.c:207 #5 0xfee35a20 in pingClients (ticks=60, param=0x0) at functions.h:45 #6 0x00084fa8 in start_timer_processes () at timer.c:275 #7 0x0002ffe8 in main (argc=1169408, argv=0x14c578) at main.c:873 Thanks in advance for any help. Best regards. Sergio Gutierrez.

16 years, 9 months

[Serusers] SIP Express Bundle ready-to-go idea, MODULE LIST?

by Mike Trest - Personal

Hi, where can I get a maximum list of 2.0.0-rc1 loadmodule commands in the correct order for a good bundled ser.cfg"? I am really frustrated trying to guess how do load for "lookup_user" and "lookup_doman" to work properly. I have the "rc1" source and the full CVS available. I have the table names correct and the MYSQL is connecting. However, I cannot get a good load module list. ..mike..

16 years, 9 months

[OpenSER-Users] anybody using group_radius module?

by jh＠tutpro.com

in the process of merging some of the radius modules, i started to wonder if anyone is really using group_radius module that provides a single function radius_is_user_in(). if i remember correctly, the module was originally written by jan to complement db based group module. i personally don't use group module, because it is more efficient to return caller's or callee's groups as reply items from authentication or radius_does_uri_exist calls. please reply to this if you use group_radius module. if no positive replies arrive, perhaps we can delete the module altogether. -- juha

16 years, 9 months

[Serusers] consultant needed for small project

by Damon Estep

Here is a brief description of what I need, please send comments to damon(a)soho-systems.com We are looking for someone to give us a "quick start" with SER. We have a "meshed" asterisk implementation with multiple servers used as registration and feature servers. Everything is 100% asterisk now. We have an asterisk server as a front end DID router that acts as a back to back user agent between the upstream carrier and feature server of the end user. When a call comes in from upstream the front end box does a database lookup (MySQL 5) to determine which feature server the user is expected to be registered on and bridges the call to the feature server. If the user is not registered voicemail or forwarding is handled by the feature server , not front end. No outbound calls are handled by the front end box, and no authentication other than trusted IP address is used by the upstream carriers. There is no need for registration knowledge on the front end box. While this is working extremely well as is, we recognize the scalability advantages that could be obtained with a true SIP proxy in the front. Here is what we would like SER to do; 1. Accept invites from two or more upstream carriers, trusted by IP address and not registered or authenticated in any other way 2. Do a database query on the MySQL 5 database to determine the IP address (or SIP URI) of the registration server the user is expected to be on. 3. Proxy the SIP signaling between the upstream carrier and the appropriate registration server. 4. Record the call record and result in a MySQL database table 5. Remain in the SIP signal path, but stay out of the RTP path. 6. Return a 404 not found when there is no database match for the DID in the database. Initial Questions; Can SER look into a custom database table for routing information on each call? Can SER act as a stateful SIP proxy without the end user registering on it? Other information; Call volume is about 25,000 inbound calls per day. We run 100% of our servers on Linux HA clusters of 2 nodes, we do not need assistance with this portion of the setup as we are very well versed in HA clustering, but it is important to know because during a failover registration state would be lost and therefore static routing based on DB queries is preferred. We have extensive Asterisk experience, no Asterisk work is required. Base OS is CentOS 4.6 SER .9.x with the MySQL module has already been loaded, but not configured Root SSH access can be provided There is NO NAT involved, the upstream, the SER box, and all asterisk feature server sue real IP addresses. Any NAT would be between the UA and the feature server, and the feature server acts as a B2BUA and handles NAT traversal. Calls would never be proxied to the UA directly, only to the feature servers. Please let me know you rate for this type of work, a rough time estimate to do only the configuration of SER (no installing required), your availability, and your past experience with similar implementation. This is for an TSP service thousands of end users, it is a mission critical implementation, so EXPERTS ONLY please. After successful testing plan on an hour or two to walk us through the config and explain the routing logic. We are in the GMT -7 mountain time zone, and English is our only spoken language. We would prefer somebody who could be available during this implementation during our regular business hours of 8AM to 6PM MST. We can pay via paypal if desired. Thanks!

16 years, 9 months

[OpenSER-Users] Interop dialog/sst - acc module to produce CDR for dialog-expired call

by Schumann Sebastian

Dear all I am looking for a possibility to somehow assure, that the accounting CDR produced will not be infinite, if a call is interrupted without sending a final BYE. I thought to do it like this: Use SST module to create certain time limit (e.g N) for a session. Use dialog module to cut dialog after certain time expired (e.g. 2N). As long as SST creates active sessions (i.e. the client is alive) the dialog does not expire, if the call is interrupted, the dialog expires worst case with 2N time accounted. The problem is, I cannot generate CDR to stop accounting for a certain call where the dialog expired. Is this possible to do in a way? Thanks for your help. Best regards Sebastian

16 years, 9 months

[OpenSER-Users] Massive "ERROR: bad header field" lead to crashing of OpenSER 1.2.X ?

by David Loh

Hi all, Recently my OpenSER log showed a lot of these error, ------------------------------------------------------------------------ Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:parse_content_length: parse ERROR near char [0][ Feb 20 22:14:47 ser ] Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:get_hdr_field: bad content_length header Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR: bad header field Feb 20 22:14:47 sip /sbin/openser[3607]: find_first_route: ERROR while parsing headers Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:parse_content_length: parse ERROR near char [0][ Feb 20 22:14:47 ser ] Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:get_hdr_field: bad content_length header Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR: bad header field Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR: build_res_buf_from_sip_req: alas, parse_headers failed Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:parse_content_length: parse ERROR near char [0][ Feb 20 22:14:47 ser ] Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR:get_hdr_field: bad content_length header Feb 20 22:14:47 sip /sbin/openser[3607]: ERROR: bad header field Feb 20 22:14:47 sip /sbin/openser[3607]: find_credentials(): ERROR while parsing headers Feb 20 22:14:47 sip /sbin/openser[3607]: pre_auth(): ERROR while looking for credentials Feb 20 22:14:47 sip /sbin/openser[3605]: ERROR:parse_content_length: parse ERROR near char [0][ ------------------------------------------------------------------------ from our past experiences, those error are most likely come from corrupted devices (or device/soft phone that send malformed/non-standard message to our SIP port). If we're continuously having this kind of errors for hours (at a rate of few thousands per hour), eventually OpenSER will not accepting new connection (REGISTER) and may just crash. Wondering if there's anything we can do on OpenSER to prevent this from happening? Thanks, David Loh

16 years, 9 months

← Newer
1
...
6
7
8
9
10
11
12
...
26
Older →

Jump to page:

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 2008