sr-users

sr-users@lists.kamailio.org

13 participants
37464 discussions

[Serusers] Which version of SER to use?
by lists＠infoway.net 08 May '07

08 May '07

We are planning on deploying a couple of SER servers and integrate them with either SEMS or Asterisk for voicemail. However, we are a bit confused as to which version of SER to go with? From what we can tell, the latest stable version is 0.9.6. However, we know of the new 0.10.X version. Reading up on the site, there is some documentation that explains a little bit of the differences and/or migration recommendations/steps. So, in an effort to keep life as simple as possible, which version should we work with? We are afraid that if we go through a learning cycle with 0.9.6 we're going to "suffer" when migrating to the new version, either because of the learning curve or because of a potential painful migration process. Any recommendations? Thanks

2 1

[Serusers] Clueless newbie question - integrating SER and Asterisk
by John Breen 08 May '07

08 May '07

Help! I've followed the SER documentation and searched the web like a mad thing and found nothing useful. I have an asterisk box here at home and want to put SER on it so I can use SIP clients out in the real world (on the other side of my firewall) to get to it. Now, I have got SER set up and the phones register fine and everything, BUT I cannot see how to get it to pass calls through to Asterisk. I'm not using Asterisk realtime or anything like that - just plain old asterisk with plain old config files. I thought I had it right, but calls are just not getting to asterisk so far as I can see. I know it must be possible, I just can't see how to do it. Regards John Breen

3 2

[Serusers] SER/PSTN Gateway conf
by flavio 08 May '07

08 May '07

Hi to all, I'm newbie for SER and I'm testing my own configuration to send/receive calls through my pstn gateway, according to follow simple scenario: Phone --> PSTN --> Gateway --> SER --> SIP Phone I send and receive calls successfully, but when Phone over PSTN hangs up SER reply to BYE message with 404 Not Found.Here is my ser.cfg: debug=3 fork=no log_stderror=yes listen=10.28.19.202 # INSERT YOUR IP ADDRESS HERE port=5060 children=4 dns=no rev_dns=no fifo="/tmp/ser_fifo" fifo_db_url="mysql://root@10.28.19.202/ser" loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/auth_db.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" loadmodule "/usr/local/lib/ser/modules/avpops.so" loadmodule "/usr/local/lib/ser/modules/permissions.so" modparam("auth_db|permissions|uri_db|usrloc", "db_url", "mysql://root@10.28.19.202/ser") modparam("auth_db", "calculate_ha1", 1) modparam("auth_db", "password_column", "password") modparam("usrloc", "db_mode", 2) modparam("rr", "enable_full_lr", 1) modparam("tm", "fr_inv_timer", 27) modparam("tm", "fr_inv_timer_avp", "inv_timeout") modparam("permissions", "db_mode", 1) modparam("permissions", "trusted_table", "trusted") modparam("permissions", "default_allow_file", "/usr/local/etc/ser/permissions.allow") modparam("permissions", "default_deny_file", "/usr/local/etc/ser/permissions.deny") route { # ----------------------------------------------------------------- # Sanity Check Section # ----------------------------------------------------------------- if (!mf_process_maxfwd_header("16")) { sl_send_reply("483", "Too Many Hops"); break; }; if (msg:len > max_len) { sl_send_reply("513", "Message Overflow"); break; }; # ----------------------------------------------------------------- # Record Route Section # ----------------------------------------------------------------- if (method!="REGISTER") { record_route(); }; # ----------------------------------------------------------------- # Loose Route Section # ----------------------------------------------------------------- if (loose_route()) { # if ((method=="INVITE" || method=="REFER") && !has_totag()) { # sl_send_reply("403", "Forbidden"); # break; # }; if (method=="INVITE") { if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); }; }; route(1); break; }; # ----------------------------------------------------------------- # Call Type Processing Section # ----------------------------------------------------------------- if (uri!=myself) { route(1); break; }; if (method=="ACK") { route(3); route(1); break; } if (method=="INVITE") { route(3); break; } else if (method=="REGISTER") { route(2); break; }; lookup("aliases"); if (uri!=myself) { route(1); break; }; if (!lookup("location")) { sl_send_reply("404", "User Not Found"); break; }; route(1); } route[1] { # ----------------------------------------------------------------- # Default Message Handler # ----------------------------------------------------------------- if (!t_relay()) { sl_reply_error(); }; } route[2] { # ----------------------------------------------------------------- # REGISTER Message Handler # ---------------------------------------------------------------- sl_send_reply("100", "Trying"); if (!www_authorize("","subscriber")) { www_challenge("","0"); break; }; if (!check_to()) { sl_send_reply("401", "Unauthorized"); break; }; consume_credentials(); if (!save("location")) { sl_reply_error(); }; } route[3] { # ----------------------------------------------------------------- # INVITE Message Handler # ----------------------------------------------------------------- if (!allow_trusted()) { if (!proxy_authorize("","subscriber")) { proxy_challenge("","0"); break; } else if (!check_from()) { sl_send_reply("403", "Use From=ID"); break; }; consume_credentials(); } lookup("aliases"); if (uri!=myself) { route(1); break; }; if (!lookup("location")) { if (uri=~"^sip:0[0-9]*@") { # calls to PSTN #strip(0); route(4); break; }; if(uri=~"^sip:3[0-9]*@") { calls to Mobile route(4); break; }; sl_send_reply("404", "User Not Found"); break; }; route(1); } route[4]{ #----------------------------------------------------------------- # PSTN Handler # ----------------------------------------------------------------- rewritehost("10.28.52.105"); # INSERT YOUR PSTN GATEWAY IP ADDRESS avp_write("i:45", "inv_timeout"); route(1); } Any suggestions about my issue? Thanks 4 all, Flavio

4 5

[Serusers] re-invite problem
by olivier.taylor 08 May '07

08 May '07

Hello, using ser 0.9.6 The following dialog is a re-invite, the re-invite is initiated by the callee after putting the call on hold. Problem is that SER answer with a 407 on the wrong port, Invite is coming from port 62907 and SER answer to port 5060. Problem doesn't occurs for the initial invite. We have tried with other Uas without problems, just having problems with this Ua (Avaya). Any idea? Best regards, Olivier U xxx.xx.xx.xx:62907 -> yy.yyy.yyy.yy:5060 INVITE sip:990099001@192.168.162.187 SIP/2.0. Via: SIP/2.0/UDP 192.168.162.181;branch=z9hG4bK309b82ccf. Max-Forwards: 70. Content-Length: 337. To: "QE-A" <sip:990099001@yy.yyy.yyy.yy>;tag=f7983fe553e1941. From: "QE-B" <sip:990099002@yy.yyy.yyy.yy>;tag=5bf8b4fb69fca84. Call-ID: 7c933d3d19bb76c396b995202b18eb97(a)yy.yyy.yyy.yy. CSeq: 567882513 INVITE. Route: <sip:990099002@yy.yyy.yyy.yy:5060;nat=yes;ftag=f7983fe553e1941;lr=on>. P-Asserted-Identity: "QE-B" <sip:990099002@yy.yyy.yyy.yy>. Allow: INVITE. Allow: CANCEL. Allow: OPTIONS. Allow: BYE. Allow: REFER. Allow: INFO. Allow: UPDATE. Content-Type: application/sdp. Contact: "QE-B" <sip:990099002@192.168.162.181>. Supported: replaces. User-Agent: NeuralX MxSF/v3.2.6.26. . v=0. o=990099002 1136076203 1136076205 IN IP4 192.168.162.181. s=-. c=IN IP4 192.168.162.181. t=0 0. a=sendonly. m=audio 20006 RTP/AVP 0 101 8 18 . a=rtpmap:0 PCMU/8000. a=rtpmap:101 telephone-event/8000. a=rtpmap:8 PCMA/8000. a=rtpmap:18 G729/8000. a=fmtp:101 0-15. a=fmtp:18 annexb=no. a=ptime:20. a=rtcp:20007 IN IP4 192.168.162.181. U yy.yyy.yyy.yy:5060 -> xxx.xx.xx.xx:5060 SIP/2.0 407 Proxy Authentication Required. Via: SIP/2.0/UDP 192.168.162.181;branch=z9hG4bK309b82ccf;received=xxx.xx.xx.xx. To: "QE-A" <sip:990099001@yy.yyy.yyy.yy>;tag=f7983fe553e1941. From: "QE-B" <sip:990099002@yy.yyy.yyy.yy>;tag=5bf8b4fb69fca84. Call-ID: 7c933d3d19bb76c396b995202b18eb97(a)yy.yyy.yyy.yy. CSeq: 567882513 INVITE. Proxy-Authenticate: Digest realm="yy.yyy.yyy.yy", nonce="463f31b81a65dee3419ce3e4bfbecc253410cbf5". Server: Sip EXpress router (0.9.6 (i386/freebsd)). Content-Length: 0. Warning: 392 yy.yyy.yyy.yy:5060 "Noisy feedback tells: pid=49990 req_src_ip=xxx.xx.xx.xx req_src_port=62907 in_uri=sip:990099001@192.168.162.187 out_uri=sip:990099001@192.168.162.187 via_cnt==1". .

2 1

RE: [Users] lcr: load_gws(): from_uri to large
by Papadopoulos Georgios 08 May '07

08 May '07

Hi Juha, Exactly this is my point, 128 should work and 129 should fail, especially since all related char buffers are allocated properly with size [MAX_FROM_URI_LEN+1] I think that the bug is here: if (from_uri.len < MAX_FROM_URI_LEN) { strncpy(from_uri_str, from_uri.s, from_uri.len); from_uri_str[from_uri.len] = '\0'; } else { LOG(L_ERR, "load_gws(): from_uri to large\n"); return -1; } It should be if (from_uri.len <= MAX_FROM_URI_LEN) George > -----Original Message----- > From: Juha Heinanen [mailto:jh@tutpro.com] > Sent: Monday, May 07, 2007 5:44 PM > To: Papadopoulos Georgios > Cc: users(a)openser.org > Subject: [Users] lcr: load_gws(): from_uri to large > > Papadopoulos Georgios writes: > > > I get the following error from lcr module > load_gws(): > from_uri to large > This happens when the rpid is exactly > 128 characters long. If I make it > 127 long it works fine. > This is on the 1.1.x branch. Has anyone else > noticed this? > > MAX_FROM_URI_LEN constant is defined as > > > #define MAX_FROM_URI_LEN 128 > > i can change that to 256. > > -- juha > Disclaimer The information in this e-mail and any attachments is confidential. It is intended solely for the attention and use of the named addressee(s). If you are not the intended recipient, or person responsible for delivering this information to the intended recipient, please notify the sender immediately. Unless you are the intended recipient or his/her representative you are not authorized to, and must not, read, copy, distribute, use or retain this message or any part of it. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses.

2 1

[Users] 2 ENUM lookups
by Joao Pereira 08 May '07

08 May '07

Hello I would like to know how to lookup to 2 ENUM trees (arpa and e164.org). I have this config: loadmodule "enum.so" modparam("enum", "domain_suffix", "e164.org.") if ( method=="INVITE" && uri=~"sip:\+[1-9][0-9]*@mydomain.com") { if(!enum_query("e164.org.")) { log(1, "log: ENUM not found :( \n"); }else{ log(1, "log: ENUM found :) \n"); if (!method=="REGISTER") record_route(); t_relay(); return; } } Thanks Regards Joao Pereira -- ______________________________________________ João Gomes Pereira FCCN Av. do Brasil, nº 101 1700-066 Lisboa tel: +351 218 440 100 - fax: +351 218 472 167 email|SIP: joao.pereira(a)fccn.pt http://www.fccn.pt ______________________________________________ --- Aviso de Confidencialidade Esta mensagem é exclusivamente destinada ao seu destinatário, podendo conter informação CONFIDENCIAL, cuja divulgação está expressamente vedada nos termos da lei. Caso tenha recepcionado indevidamente esta mensagem, solicitamos-lhe que nos comunique esse mesmo facto por esta via ou para o telefone +351 218 440 100 devendo apagar o seu conteúdo de imediato. This message is intended exclusively for its addressee. It may contain CONFIDENTIAL information protected by law. If this message has been received by error, please notify us via e-mail or by telephone +351 218 440 100 and delete it immediately. ---

3 2

Re: [Serusers] Fwd: record_route..........TCP ??
by KUMAR 07 May '07

07 May '07

Here is the message dump that i get when using TCP as transport. > > > On 5/3/07, Jiri Kuthan <jiri(a)iptel.org> wrote: > > I think you would have to send message dumps first so that [serusers] volunteers > > have material for providing an answer. > > > > -jiri > > > > At 12:07 03/05/2007, KUMAR wrote: > > >- > > >Hi all, > > >I already posted this message yet havent got any replies. I really > > >need to find this out. > > >Please anyone reply to this problem. > > > > > >I am using SER-0.9.6 and the problem i'm having is this. When using > > >the following ser.cfg, it works well when the transport UDP is used. > > >But when transport TCP is used, then it only results in one way IM, > > >only from the UA from which the INVITE is being sent. Moreover, when > > >record_route is used instead of record_route_preset, then even that > > >one way IM doesn't work. But it works well with UDP. > > > > > >Can anyone please point me as to where the problem might be?? > > >Thank you in advance. > > > > > >kumar > > > > > > > > >Content-Type: application/octet-stream; name=ser.cfg > > >X-Attachment-Id: f_f18sg2bl > > >Content-Disposition: attachment; filename="ser.cfg" > > > > > >_______________________________________________ > > >Serusers mailing list > > >Serusers(a)lists.iptel.org > > >http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > -- > > Jiri Kuthan http://iptel.org/~jiri/ > > > > > >

6 12

Re: [Users] Openser generated strange SIP packets with LCR Fallback on a second gateway
by gemalto-fw＠e-qual.fr 07 May '07

07 May '07

2 1

[Users] [openser 1.2] $fn, strange shape.
by Bodin Bruno 07 May '07

07 May '07

Hello, When I do : xlog("display name = $fn"); It show : display name = "toto titi" why it add quote ? how can I disable theses quotes ? thank

4 6

[Users] 183 early media and NATed clients
by Jeff Williams 07 May '07

07 May '07

Guys, I'm wondering what solutions there are to this problem. We have some NATed clients making outgoing calls. The NAT traversal is done using mediaproxy and works fine. However, we have a problem with 183 responses and early media ringing sounds. The problem is that before the NATed client starts sending out RTP data, mediaproxy doesn't know which IP and port to send the RTP traffic to. Some of the NETed clients don't start sending out RTP traffic until the call is connected, therefore none of the early media (ringing sounds) reaches the user - making it sound like dead air. Any ideas? Jeff

4 7

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