sr-users May 2008

sr-users@lists.kamailio.org

121 participants
202 discussions

by Santiago Gimenez Ocano

Hi, I'm using SER 2.0 rc1. Thing is I have found excelent documentation (like tm module) on iptel pages, but I couldn't find information for other modules like acc_radius. There's a web site or something where I can find this kind of help? Thanks, Santiago _________________________________________________________________ Do more with your photos with Windows Live Photo Gallery. http://www.windowslive.com/share.html?ocid=TXT_TAGLM_Wave2_photos_022008

16 years

Re: [OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail

by Sean O'Donnell

16 years

Re: [OpenSER-Users] 200 OK retransmissions on missing ACK can cause subsequent calls to fail

by Sean O'Donnell

16 years

[Serusers] SER-Server-ID, Radius Dictionary Issue

by Santiago Gimenez Ocano

Hi all, I'm trying to use acc_radius module in SER 2.0.0. But when it's loading I get this error: 0(9009) ERROR: acc: can't get code for the SER-Server-ID attribute 0(9009) init_mod(): Error while initializing module acc_radius ERROR: error while initializing modules I think this is a dictionary error, when I add the attribute I get the following message: 0(9031) ERROR: sr_module.c:887: Error while fixing parameter, AVP, SELECT, and int conversions failed I assume I'm making some mistake, but I don't know where. I don't think that is in ser.cfg and maybe is a module or dictionary problem. Can anybody help me? Thanks, Santiago _________________________________________________________________ Get your fix of news, sports, entertainment and more on MSN Mobile http://www.msnmobilefix.com/Default.aspx

16 years

Re: [Serusers] SER - Strange Calling Issues

by Arun Kumar

> > Hi ALL, > > I'm facing some strange issue with my VoIP Setup. I've configure 5 servers > : > > 1. 192.168.20.1 = SER / MediaProxy > 2. 192.168.20.2 = MySQL > 3. 192.168.20.3 = Presence > 4. 192.168.20.4 = Asterisk for PSTN with A2Billing > 5. 192.168.20.5 = Voicemail > > *First Problem:* > I've created few users on my SER and they are able to call each other > (Users are behind NAT) *but if User A calls User B and User A disconnect > call from his side the User B phone keeps on ringing until User B > disconnects the call. > > Second Problem(Only some time): > *when user dial PSTN number they hear ringing on there side but other > side has picked up the phone and they started to talk also but calling side > is still hearing the ring. > > *Third: > *Some time users complain that there calls are getting disconnect (PSTN > Calls) after 20-30 second, I feel its more related to my PSTN Provider but > how can I prove so I can tell my provider about this problem. > > Please provide your feedback. thanks in advance. > > I've attached my ser.cfg file b'coz if I'll paste message will be big so. > =================== > >

16 years

[Serusers] CANCEL doubts

by Nuno Ribeiro

Hi all, I have a doubt about the CANCEL messages and I would like to hear your opinion. The routes that should be inserted in the CANCEL message should be based int the ones that are part of the received INVITE or in the ones that are part of the transmitted INVITE? From my point of view the CANCELs should be created based in the routes of the transmitted INVITE, in order to the stateless proxies be able to route the CANCEL requests properly. The RFC says the following: 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. This is needed so that stateless proxies are able to route CANCEL requests properly. Thanks in advance, Nuno Ribeiro

16 years

[OpenSER-Users] recover from previous strict routing triggered incorrectly in ALG scenario

by Andrew Pogrebennyk

Hi, Im'm cross-posting this from OpenSER-Devel because I am not 100% sure this is a bug. I am trying to create openser configuration for proxy that connects private (VPN) network with public network. I started with a config similar to http://voipembedded.com/resources/openser_cr.cfg, added a call to force_send_socket() to send from public IP and rtpproxy/nathelper in bridge mode. As per config loose_route() is called from openser.cfg to route a sequential request within a dialog through record-routing. Now when a BYE from callee comes in, it contains two Route headers: Route: <a.b.c.d;r2=on;lr;ftag=...> where a.b.c.d is server's public IP, Route: <10.0.0.100;r2=on;lr;ftag=...> where 10.0.0.100 is a private IP and username(a)a.b.c.d in Request-URI. Take a look at loose_route(): /* * Do loose routing as defined in RFC3261 */ int loose_route(struct sip_msg* _m, char* _s1, char* _s2) { int ret; if (find_first_route(_m) != 0) { LM_DBG("There is no Route HF\n"); return -1; } if (parse_sip_msg_uri(_m)<0) { LM_ERR("failed to parse Request URI\n"); return -1; } ret = is_preloaded(_m); if (ret < 0) { return -1; } else if (ret == 1) { return after_loose(_m, 1); } else { #ifdef ENABLE_USER_CHECK if (is_myself(&_m->parsed_uri.user, &_m->parsed_uri.host, _m->parsed_uri.port_no)) { #else if (is_myself(&_m->parsed_uri.host, _m->parsed_uri.port_no)) { #endif return after_strict(_m); } else { return after_loose(_m, 0); } } } Obviously, is_myself() check passes and after_strict() is called. when after_strict() is called, it looks if the URI given in Route contains lr parameter which marks loose routers, if so this block of code is executed: { LM_DBG("Next hop: '%.*s' is loose router\n", uri.len, ZSW(uri.s)); if(get_maddr_uri(&uri, &puri)!=0) { LM_ERR("failed to check maddr\n"); return RR_ERROR; } if (set_dst_uri(_m, &uri) < 0) { LM_ERR("failed to set dst_uri\n"); return RR_ERROR; } /* Next hop is a loose router - Which means that is is not endpoint yet * In This case we have to recover from previous strict routing, that * means we have to find the last Route URI and put in in R-URI and * remove the last Route URI. */ if (rt != hdr->parsed) { /* There is a previous route uri which was 2nd uri of mine * and must be removed here */ rem_off = hdr->body.s; rem_len = rt->nameaddr.name.s - hdr->body.s; if (!del_lump(_m, rem_off - _m->buf, rem_len, 0)) { LM_ERR("failed to remove Route HF\n"); return RR_ERROR; } } res = find_rem_target(_m, &hdr, &rt, &prev); if (res < 0) { LM_ERR("searching for last Route URI failed\n"); return RR_ERROR; } else if (res > 0) { /* No remote target is an error */ return RR_ERROR; } uri = rt->nameaddr.uri; if(get_maddr_uri(&uri, 0)!=0) { LM_ERR("checking maddr failed\n"); return RR_ERROR; } if (rewrite_uri(_m, &uri) < 0) { LM_ERR("failed to rewrite R-URI\n"); return RR_ERROR; } /* The first character if uri will be either '<' when it is the * only URI in a Route header field or ',' if there is more than * one URI in the header field */ LM_DBG("The last route URI: '%.*s'\n", rt->nameaddr.uri.len, ZSW(rt->nameaddr.uri.s)); if (prev) { rem_off = prev->nameaddr.name.s + prev->len; rem_len = rt->nameaddr.name.s + rt->len - rem_off; } else { rem_off = hdr->name.s; rem_len = hdr->len; } if (!del_lump(_m, rem_off - _m->buf, rem_len, 0)) { LM_ERR("failed to remove Route HF\n"); return RR_ERROR; } } Therefore recover from previous strict routing is triggered: contents of request line is destroyed and 10.0.0.100 is put instead: Apr 15 16:16:24 vpn-proxy oser[11027]: DBG:core:rewrite_uri: rewriting Request-URI with 'sip:10.0.0.100;r2=on;lr;ftag=aa40c2a5-54fb-1810-970d-0015c5bf2da5' Apr 15 16:16:24 vpn-proxy oser[11032]: [1] Got in dialog request not catched by loose_route(): BYE sip:10.0.0.100;r2=on;lr;ftag=aa40c2a5-54fb-1810-970d-0015c5bf2da5 SIP/2.0^M Via:... And we respond with 404 to in-dialog requests not caught by loose_route(). Previous hop is SER and I don't know why OpenSER considered it a strict router. Looks like a peculiarity of ALG mode. Please advice what should I do to solve this problem. Is it a configuration issue or perhaps loose_route() should not call after_strict() in case of double record-routing? -- Thank you, Andrew Pogrebennyk

16 years

[OpenSER-Users] segfault with general protection error

by Marcello Lupo

Hi to all, today i got a segfault with general protection error openser 1.2.2 notls under Linux 2.6.16.27-0.9-smp #1 SMP Tue Feb 13 09:35:18 UTC 2007 x86_64 x86_64 x86_64 GNU/Linux. It is due to: May 8 18:29:25 voip /data/openser/sbin/openser[19569]: val2str: Destination buffer too short May 8 18:29:25 voip /data/openser/sbin/openser[19569]: print_values: Error while converting value to string May 8 18:29:25 voip /data/openser/sbin/openser[19569]: ERROR:acc:acc_db_request: Error while inserting to database May 8 18:29:26 voip /data/openser/sbin/openser[19560]: child process 19573 exited by a signal 11 May 8 18:29:27 voip /data/openser/sbin/openser[19560]: core was generated I examined the core dump and it has been caused from the same thing that happened to me on October 2007 on another installation. I already posted the question to the list without getting any response. http://lists.openser.org/pipermail/users/2007-October/013796.html I post now the new gdb trace. I'm a very beginner using gdb but like very much to know why this is happening. Core was generated by `/data/openser/sbin/openser'. Program terminated with signal 11, Segmentation fault. #0 0x00002b83e4be4150 in escape_string_for_mysql () from /usr/lib64/ libmysqlclient.so.15 (gdb) bt #0 0x00002b83e4be4150 in escape_string_for_mysql () from /usr/lib64/ libmysqlclient.so.15 #1 0x00002b83e49465d1 in val2str (_c=0x2b83e4de05a0, _v=<value optimized out>, _s=0x2b83e4a48f8d "'33301','','469','','4','','','','102 INVITE','','12.13.14.15','')", _len=0x7fffc67d7804) at val.c:316 #2 0x00002b83e4942952 in db_mysql_print_values (_c=0x6b8768, _b=0x2b83e4a48e0e "'INVITE','5ec34ebc6ad9825','as54a9f138','647f8f41f2ed74cfb28b83633bb8efdb(a)voip.test.biz ','200','OK','2008-05-08 18:29:25','sip:035123456@voip.test.biz;tag=5ec34ebc6ad9825','sip:031454647@voip "..., _l=65170, _v=<value optimized out>, _n=28) at dbase.c:145 #3 0x00002b83e4943967 in db_mysql_insert (_h=0x6b9018, _k=<value optimized out>, _v=0x2b83e65aa5c0, _n=28) at dbase.c:584 #4 0x00002b83e64956d3 in acc_db_request (rq=0x2b83e6c9dc28) at acc.c: 378 #5 0x00002b83e6497244 in tmcb_func (t=<value optimized out>, type=<value optimized out>, ps=<value optimized out>) at acc_logic.c:376 #6 0x00002b83e52958f1 in run_trans_callbacks (type=128, trans=0x2b83e7673690, req=<value optimized out>, rpl=<value optimized out>, code=<value optimized out>) at t_hooks.c:205 #7 0x00002b83e52a3e76 in relay_reply (t=0x2b83e7673690, p_msg=<value optimized out>, branch=0, msg_status=200, cancel_bitmap=0x7fffc67d7ac8) at t_reply.c:1155 #8 0x00002b83e52a5b0d in reply_received (p_msg=0x6b9138) at t_reply.c: 1388 #9 0x000000000041929e in forward_reply (msg=0x6b9138) at forward.c:489 #10 0x000000000043cbd2 in receive_msg ( buf=0x60e700 "SIP/2.0 200 OK\r\nVia: SIP/2.0/UDP 80.122.12.3;branch=z9hG4bKdd28.b33b4137.0;received=80.122.12.3\r\nVia: SIP/2.0/UDP 20.21.22.23:5060;rport=5060;branch=z9hG4bK31ffac575\r \nRecord-Route: <sip:031454647"..., len=850, rcv_info=0x7fffc67d7b90) at receive.c:195 #11 0x000000000046d45f in udp_rcv_loop () at udp_server.c:451 #12 0x0000000000428dd0 in main_loop () at main.c:834 #13 0x000000000042a899 in main (argc=<value optimized out>, argv=<value optimized out>) at main.c:1393 Thanks in advance to anyone can help me to debug this thing. Bye, Marcello

16 years

[OpenSER-Users] [OT?] voip-to-voip rating using cdrtool

by Sajith T S

Apologies if this is off-topic here, but this seemed like a good friendly place to ask. Apologies for being so naïve also... Question is, how can I get cdrtool to rate voip-to-voip calls when destination is non-numeric? As in, say, sip:holmes@example.com calls sip:watson@example.com. How do I get cdrtool to match *(a)example.com or *(a)example2.com? (FWIW, I'm just trying to see how this works... no plan of rolling out this Evil Scheme into a real world deployment.) While cdrtool has decent documentation, I wish this was a little more easy on me. Has anyone read/reviewed this book yet? http://www.packtpub.com/building-telephony-systems-with-openser/book I'm specifically interested in the "Billing with Freeradius and CDRTool" part. Thanks, Sajith. -- Don't you wish you had more energy... or less ambition? 9DB8FF06 : CB80 0BA6 7D13 B10A 6FBB D43E B4D2 28AD 9DB8 FF06

16 years

[OpenSER-Users] Privacy Question

by Helmut Kuper

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, today I found an incomming Privacy-Header Field from my PSTN-Gateway-Provider like this: Privacy: header;user;id Openser 1.4 says: May 8 11:22:25 [29986] ERROR:core:parse_privacy: invalid privacy value RFC 3323 says: Privacy-hdr = "Privacy" HCOLON priv-value *(";" priv-value) priv-value = "header" / "session" / "user" / "none" / "critical" ~ / token The values of priv-value today are restricted to the above options, ~ although further options can be defined as appropriate (see Section ~ 7). Each legitimate priv-value can appear zero or one times in a ~ Privacy header. So that means, the incomming Privacy-header is OK, doesn't it? a Bug? regards helmut -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkgiyI0ACgkQ4tZeNddg3dzbfACgjyLMZsVFW30bdTkiEJu+4pH2 XPoAnAhBEQ0IvecHApVqdOP7nSLh563x =4nWD -----END PGP SIGNATURE-----

16 years

← Newer
1
...
14
15
16
17
18
19
20
21
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 May 2008