sr-users February 2005

sr-users@lists.kamailio.org

215 participants
467 discussions

Re: [Serusers] Manipulate from_uri
by Charles Wang 27 Feb '05

27 Feb '05

Dear Paul: I am a new user of SER sip. And would you please tell me an explain about what the RPID is?? I want to control the call to PSTN with B2BUA of vovida or Asterisk. Best Regard Charles On Wed, 23 Feb 2005 10:33:26 -0500, Java Rockx <javarockx(a)gmail.com> wrote: > Vitaly, > > I believe you are correct that RPID is only helpful during SIP->PSTN calls. > > I'm not real familiar with B2BUA, but if I were to introduce one in to > my system, does that mean I need to have all the RTP traffic pass > through my network as well, or does the B2BUA only deal with SIP > messaging? > > Regards, > Paul > > On Wed, 23 Feb 2005 10:14:18 -0500, Vitaly Nikolaev > <vitaly(a)voipsonic.com> wrote: > > > > The answer is B2BUA > > > > There actually two ways, > > > > First is b2bua which is nice (for me ok.. I like it :) > > > > Second if you assign the CallerID number to device.. the real callerid, (for > > example in my network we use some fake numbers into devices and then change > > it do real callerid (did) in b2bua), then some devices, for example SIPURA, > > can send Anonymous as name in From and Contact and some GWs, will use it and > > hide callerid on outgoing call. > > > > And third: > > > > And there are also Remote-Party-Id: field in SIP that partially supported by > > SER and supported by most of GW and carriers, and that is probably RIGHT way > > to do that. > > > > When PSTN GW sends call to outside of ur network, it no just skip callerid, > > u can do it but it is wrong, it make it private, so usual ppl will not see > > it but for example 911 and some toll free subscriber will see. That right > > way and that how everybody should do cli blocking. > > > > What is wrong in this method is that if you call goes from SIP to SIP and > > you use as me fake CLI on devices, customers will see fake numbers because > > as far as I know SIP devices does not support RPID (please correct me if I > > am wrong) so in my case I will have to use combination of N1 and N3.. > > > > > > -----Original Message----- > > From: serusers-bounces(a)iptel.org [mailto:serusers-bounces@lists.iptel.org] On > > Behalf Of Java Rockx > > Sent: Wednesday, February 23, 2005 7:20 AM > > To: Klaus Darilion > > Cc: serusers(a)lists.iptel.org > > Subject: Re: [Serusers] Manipulate from_uri > > > > Klaus, > > > > I realize that RFC3261 says do not modify the From header, however, my > > question is this; > > > > When making SIP-to-SIP calls between two subscribers on the same SIP > > proxy, how can one implement Caller ID Block when RPID is not usually > > honored by SIP UAs - since this is really for PSTN gateways? > > > > It seems that altering the From header in this case is the only > > option. Have I missed something? > > > > Regards, > > Paul > > > > On Wed, 23 Feb 2005 12:00:14 +0100, Klaus Darilion > > <klaus.mailinglists(a)pernau.at> wrote: > > > Hi Mik! > > > > > > Do not modify the From: or To: URI - this is not allowed (RFC 3261) and > > > will cause problems. > > > > > > regards, > > > klaus > > > > > > Mik Cheez wrote: > > > > Since I'm able to modify the URI for relaying, I would assume there > > > > would be a way to modify the FROM_URI as well. Has anyone managed to do > > > > this with SER acting as a proxy? Any other possible avenues to modify > > > > the CALLID? > > > > > > > > Best regards > > > > > > > > _______________________________________________ > > > > Serusers mailing list > > > > serusers(a)lists.iptel.org > > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > > > > > > > > _______________________________________________ > > > Serusers mailing list > > > serusers(a)lists.iptel.org > > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > > _______________________________________________ > > Serusers mailing list > > serusers(a)lists.iptel.org > > http://lists.iptel.org/mailman/listinfo/serusers > > > > > > _______________________________________________ > Serusers mailing list > serusers(a)lists.iptel.org > http://lists.iptel.org/mailman/listinfo/serusers >

5 12

[Serusers] nat, symmetric /asymmetric UA....clarification needed
by Iqbal 27 Feb '05

27 Feb '05

Hi Just trying to debug why some calls work and other dont, I have 2 setups, in both the UA is xlite , and is natted in both cases...however the routers differ in each case. Now I am running mediaproxy, when I debug ser, in one setups the contact header which is displayed using xlog, shows the external IP address of the router, in the other it does not, this happens after I have passed the fix_contact setting in ser.cfg. The one where it is fixed , allows me to listen to voicemail prompt from asterisk without any problems, the other...no sound. The clarification I need is this.. 1. Mediaproxy solves symmetric NAT problems with ease..Y/N ? 2. For asymmetric stuff you need to add the clients to sip/rtp-asymmetric files Y/N ? 3 If Yes the the client in this case is xlite...which is not really the asymmetric part, its the router in the middle is it not ? 4. If I place slite in the file, will it not then affect the symmetric xlite also. Now if all this fails, can I on the xlite...which seems to be behind the asymmetric setup, use STUN server, if yes, then the mediaproxy I guess will not get called, or should it.....or is it better to map the port/pathsin the router itself. As a last question, if I wanted to determine what type of NATting a device did, or I needed to debug a customers setup, whats the easiest way tks Iqbal

2 3

[Serusers] [Serdev] LCR module with gateway prefix
by Juha Heinanen 27 Feb '05

27 Feb '05

Raymond Chen writes: > Anyway to put the PSTN gateway prefix into gw table? no. gw table contains properties of gateways and routing info is in lcr table. -- juha

2 1

[Serusers] LCR module with gateway prefix
by Raymond Chen 27 Feb '05

27 Feb '05

Dear Juha, Anyway to put the PSTN gateway prefix into gw table? Thanks Raymond

1 0

[Serusers] bad udp packet? why!
by jiangjp 26 Feb '05

26 Feb '05

I installed the ser in Redhat 9.0. I use ngrep to capture the packet.Sometime I got the bad UDP packet send from ser. The following is an example(210.192.101.193 is the ser installed), before MESSAGE sip there are illeagal chars (maybe due to the udp size limit?): U 210.192.101.193:80 -> 218.25.90.134:31500 19036@0:1480 .P{.....MESSAGE sip:lumy1314@218.25.90.134:31500 SIP/2.0..Call-ID: 0f9 ffc6b4dbc35dd8cf153975330c83e@210.192.101.20..CSeq: 1 MESSAGE..From: " miphone" <sip:multichat@sip.miphone.cn:20000;transport=udp>;tag=160203 74..To: <sip:lumy1314@dododoo.com>..Via: SIP/2.0/UDP 210.192.101.193:8 0;branch=z9hG4bKacb8.7ed584b7.0..Via: SIP/2.0/UDP 210.192.101.20:20000 ;branch=z9hG4bK42e5063b387e084e01f8119c4491d60e..Max-Forwards: 69..Con tent-Type: text/x-miphone-multichat..Content-Length: 995..P-hint: usrl oc applied....<?xml version="1.0" encoding="UTF-8"?>.<miphone>.<comman d type="add user">.<from>sip:server</from>.<to>lumy1314(a)dododoo.com</t o>.<commandcontent>.<roomid>38563504</roomid>.<sipaddr>hxl(a)email.com.c n</sipaddr>.<name>tuhxl-1</name>.<sex>...</sex>.<age>4</age>.<imageid> 99999</imageid><location></location>.<userauthority>2</userauthority>. <userspeakstatus>NO</userspeakstatus>.<uservideostatus>NO</uservideost atus>.<audioaddr>61.149.14.202</audioaddr>.<audioport>28904</audioport >.<videoaddr>61.149.14.202</videoaddr>.<videoport>28914</videoport>.<n attype>1</nattype>.<firewalladdr></firewalladdr>.<localvideoaddr>61.14 9.14.202</localvideoaddr>.<localvideoport>28914</localvideoport>.<loca laudioaddr>61.149.14.202</localaudioaddr>.<localaudioport>28904</local audioport>.<nowuserlist>.<user>hxl(a)email.com.cn</user>.<user>tuhxl@mip hone.com.tv</user>.<user>bug(a)miphone.com.tv</user>.<user>lumy1314@dodo doo.com</user>.<user>czl(a)dododoo.com</user>.</nowuserlist>.</commandco ntent>.</c

2 1

[Serusers] lookup not finding local users
by Glenn Dalgliesh 26 Feb '05

26 Feb '05

I don't seem to be able to get a match when I send a call from my gw to ser registered user. Debug indicates that user Not found in usrloc even though the database shows the users registered. I am able to make out bound calls the gw just fine. If anyone can shed some light in it it would be great. Thanks ============================================================================ ================================= mysql> select * from location; +----------+--------+------------------------+----------+------------------- --+-------+----------------------------------+------+----------------+------ -----+-------+-------+----------------------------+ | username | domain | contact | received | expires | q | callid | cseq | last_modified | replicate | state | flags | user_agent | +----------+--------+------------------------+----------+------------------- --+-------+----------------------------------+------+----------------+------ -----+-------+-------+----------------------------+ | 9901 | | sip:9901@69.250.205.31 | NULL | 2005-02-26 03:31:09 | -1.00 | e5201b3819008718(a)192.168.199.102 | 107 | 20050226033016 | 0 | 0 | 0 | Grandstream BT100 1.0.5.11 | +----------+--------+------------------------+----------+------------------- --+-------+----------------------------------+------+----------------+------ -----+-------+-------+----------------------------+ 1 row in set (0.01 sec) ====debugt output====================================================================== ========================= 20(18672) parse_headers: flags=256 20(18672) find_first_route: No Route headers found 20(18672) loose_route: There is no Route HF 20(18672) lookup(): '9901' Not found in usrloc ============================================================================ ================================= U 69.19.88.16:5060 -> 69.19.88.19:5060 INVITE sip:9901@69.19.88.19 SIP/2.0..Via: SIP/2.0/UDP 69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD" <sip:4103532264 @69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>..Contact: <sip:4103532264@69.19.88.16>..Call-ID: 745bcf587074e77d4a8118dc212 ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent: Asterisk PBX..Date: Sat, 26 Feb 2005 08:41:01 GMT..Allow: INVITE, ACK, CANCEL, OPTIONS , BYE, REFER..Content-Type: application/sdp..Content-Length: 240....v=0..o=root 11581 11581 IN IP4 69.19.88.16..s=session..c=IN IP4 66. 159.88.16..t=0 0..m=audio 14934 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone-event/8000..a=fmtp:1 01 0-16..a=silenceSupp:off - - - -.. # U 69.19.88.19:5060 -> 69.19.88.16:5060 SIP/2.0 100 trying -- your call is important to us..Via: SIP/2.0/UDP 69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD" < sip:4103532264@69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>..Call-ID: 745bcf587074e77d4a8118dc212ccba7@69.19.88.16..CSeq: 102 INVITE..Server: Sip EXpress router (0.9.0 (i386/linux))..Content-Length: 0..Warning: 392 69.19.88.19:5060 "Noisy feedback tells: p id=18682 req_src_ip=69.19.88.16 req_src_port=5060 in_uri=sip:9901@69.19.88.19 out_uri=sip:9901@69.19.88.16:5060 via_cnt==1".... # U 69.19.88.19:5060 -> 69.19.88.16:5060 INVITE sip:9901@69.19.88.16:5060 SIP/2.0..Max-Forwards: 10..Record-Route: <sip:69.19.88.19;ftag=as149fbe93;lr=on>..Via: SIP/2.0/UDP 66 .159.88.19;branch=z9hG4bK96c9.80b8ddd7.0..Via: SIP/2.0/UDP 69.19.88.16:5060;branch=z9hG4bK2fb13d17..From: "Cell Phone MD" <sip:410353 2264(a)69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>..Contact: <sip:4103532264@69.19.88.16>..Call-ID: 745bcf587074e77d4a8118d c212ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent: Asterisk PBX..Date: Sat, 26 Feb 2005 08:41:01 GMT..Allow: INVITE, ACK, CANCEL, OPT IONS, BYE, REFER..Content-Type: application/sdp..Content-Length: 240..P-hint: GATEWAY....v=0..o=root 11581 11581 IN IP4 69.19.88.16..s= session..c=IN IP4 69.19.88.16..t=0 0..m=audio 14934 RTP/AVP 0 8 101..a=rtpmap:0 PCMU/8000..a=rtpmap:8 PCMA/8000..a=rtpmap:101 telephone -event/8000..a=fmtp:101 0-16..a=silenceSupp:off - - - -.. # U 69.19.88.16:5060 -> 69.19.88.19:5060 SIP/2.0 482 Loop Detected..Via: SIP/2.0/UDP 69.19.88.19;branch=z9hG4bK96c9.80b8ddd7.0..Via: SIP/2.0/UDP 69.19.88.16:5060;branch=z9hG4b K2fb13d17..From: "Cell Phone MD" <sip:4103532264@69.19.88.16>;tag=as149fbe93..To: <sip:9901@69.19.88.19>;tag=as149fbe93..Call-ID: 74 5bcf587074e77d4a8118dc212ccba7@69.19.88.16..CSeq: 102 INVITE..User-Agent: Asterisk PBX..Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER ..Contact: <sip:4103532264@69.19.88.16>..Content-Length: 0.... ==ser.cfg=================================================================== ======================================== # # $Id: serconf.sh,v 1.3 2003/11/03 13:03:58 janakj Exp $ # # autogenerated SER configuration # # user: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) # system: Linux baltodb.popdial.com 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23 EST 2005 i686 i686 i386 GNU/Linux # date: Sat Feb 26 02:57:50 EST 2005 # # ----------- global configuration parameters ------------------------ /* debug=4 fork=yes port=5060 log_stderror=no memlog=5 */ mhomed=yes fifo="/tmp/ser_fifo" alias=baltodb.popdial.com # uncomment to override config values for test # /* debug=4 # debug level (cmd line: -ddd) fork=yes port=5060 log_stderror=yes # (cmd line: -E) fifo="/tmp/ser_fifox" # */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) children=16 # if changing fifo mode to a more restrictive value, put # decimal value in there, e.g. dec(rw|rw|rw)=dec(666)=438 #fifo_mode=438 # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/mysql.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/textops.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/group.so" loadmodule "/usr/local/lib/ser/modules/msilo.so" loadmodule "/usr/local/lib/ser/modules/enum.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" # ----------------- setting module-specific parameters --------------- # all DB urls here #modparam("usrloc|acc|auth_db|group|msilo|uri", "db_url","mysql://ser:heslo@localhost/ser") modparam("usrloc|acc|auth_db|group|msilo|uri_db", "db_url","mysql://ser:heslo@localhost/ser") # -- usrloc params -- /* 0 -- dont use mysql, 1 -- write_through, 2--write_back */ modparam("usrloc", "db_mode", 2) modparam("usrloc", "timer_interval", 10) # -- auth params -- modparam("auth_db", "calculate_ha1", yes) #modparam("auth_db", "user_column", "user_id") modparam("auth_db", "password_column", "password") modparam("auth", "nonce_expire", 300) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # -- acc params -- # that is the flag for which we will account -- don't forget to modparam("acc", "db_flag", 1 ) modparam("acc", "db_missed_flag", 3 ) # -- tm params -- modparam("tm", "fr_timer", 20 ) modparam("tm", "fr_inv_timer", 90 ) modparam("tm", "wt_timer", 20 ) # -- msilo params modparam("msilo", "registrar", "sip:registrar@baltodb.popdial.com") # -- enum params -- # modparam("enum", "domain_suffix", "e164.arpa.") # ------------------------- request routing logic ------------------- # main routing logic route{ /* ********* ROUTINE CHECKS ********************************** */ # filter too old messages if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Alas Too Many Hops"); break; }; #if (len_gt( max_len )) { if ( msg:len > max_len ) { sl_send_reply("513", "Message too large sorry"); break; }; # Make sure that requests dont advertise addresses # from private IP space (RFC1918) in Contact HF # (note: does not match with folded lines) if (search("^(Contact|m): .*(a)(192\.168\.|10\.|172\.16)")) { # allow RR-ed requests, as these may indicate that # a NAT-enabled proxy takes care of it; unless it is # a REGISTER if ((method=="REGISTER" || ! search("^Record-Route:")) && !( src_ip==192.168.0.0/16 || src_ip==10.0.0.0/8 || src_ip==172.16.0.0/12 )) { log("LOG: Someone trying to register from private IP again\n"); sl_send_reply("479", "We dont accept private IP contacts" ); break; }; }; # anti-spam -- if somene claims to belong to our domain in From, # challenge him (skip REGISTERs -- we will chalenge them later) if (search("(From|F):.*(baltodb\.popdial\.com|66\.159\.88\.19)")) { # invites forwarded to other domains, like FWD may cause subsequent # request to come from there but have iptel in From -> verify # only INVITEs (ignore FIFO/UAC's requests, i.e. src_ip==myself) if (method=="INVITE" & !(src_ip==69.19.88.19)) { if (!(proxy_authorize( "baltodb.popdial.com" /* realm */, "subscriber" /* table name */ ))) { proxy_challenge("baltodb.popdial.com" /* realm */, "0" /* no-qop */); break; }; # to maintain outside credibility of our proxy, we enforce # username in From to equal digest username; user with # "john.doe" id could advertise "bill.gates" in From otherwise; if (!check_from()) { log("LOG: From Cheating attempt in INVITE\n"); sl_send_reply("403", "That is ugly -- use From=id next time (OB)"); break; }; # we better don't consume credentials -- some requests may be # spiraled through our server (sfo@iptel->7141@iptel) and the # subsequent iteration may challenge too, for example because of # iptel claim in From; UACs then give up because they # already submitted credentials for the given realm #consume_credentials(); }; # INVITEs claiming to come from our domain } else if (method=="INVITE" && !(uri=~"[@:\.](baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*" # ... and we serve our gateway too if present | uri=~"@66\.159\.88\.16([;:].*)*" )) { #the INVITE neither claims to come from our domain nor is it targeted to it # -> junk it sl_send_reply("403", "No relaying"); break; }; /* ********* RR ********************************** */ # to be safe, record route everything; UAs may use different # transport protocols and need to have SER in path record_route(); # if route forces us to forward to some explicit destination, # do so; check however first that a cheater didn't preload # a gateway destination to bypass PSTN ACLs if (loose_route()) { if (uri=~"sip:[+0-9]+@66\.159\.88\.16") { # it is gateway -- proceed to ACLs route(3); break; }; # route HF determined next hop; forward there append_hf("P-hint: rr-enforced\r\n"); t_relay(); break; }; /* ********* check for requests targeted out of our domain... ******* */ # sign of our domain: there is '@' (username) or : (nothing) in # front of our domain name ; ('.' is not there -- we handle all # xxx.iptel.org as outbound hosts);if none of these cases matches, # proceed with processing of outbound requests in route[2] if (!(uri=~"[@:](sip[\.)?(baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*" | uri=~"@66\.159\.88\.16([;:].*)*")) { route(2); break; }; /* ************ requests for our domain ********** */ /* now, the request is for sure for our domain */ # registers always MUST be authenticated to # avoid stealing incoming calls if (method=="REGISTER") { # Make sure that user's dont register infinite loops # (note: does not match with folded lines) if (search("^(Contact|m): .*(a)(baltodb\.popdial\.com|66\.159\.88\.19)")) { log(1, "LOG: alert: someone trying to set aor==contact\n"); sl_send_reply("476", "No Server Address in Contacts Allowed" ); break; }; if (search("^(Contact|m): .*66\.159\.88\.16")) { log(1, "LOG: alert: protected contacts\n"); sl_send_reply("476", "No Server Address in Contacts Allowed" ); break; }; if (!www_authorize( "baltodb.popdial.com" /* realm */, "subscriber" /* table name */ )) { # challenge if none or invalid credentials www_challenge( "baltodb.popdial.com" /* realm */, "0" /* no qop -- some phones can't deal with it */); break; }; # prohibit attempts to grab someone else's To address # using valid credentials; if (!check_to()) { log("LOG: To Cheating attempt\n"); sl_send_reply("403", "That is ugly -- use To=id in REGISTERs"); break; }; # it is an authenticated request, update Contact database now if (!save("location")) { sl_reply_error(); }; m_dump(); break; }; # some UACs might be fooled by Contacts our UACs generate to make MSN # happy (web-im, e.g.) -- tell its urneachable if (uri=~"sip:daemon@" ) { sl_send_reply("410", "daemon is gone"); break; }; # is this an ENUM destination (leading +?)? give it a try, if the lookup # doesn't change URI, just continue if (uri=~"sip:\+[0-9]+@") { if (!enum_query("voice")) { # if parameter empty, it defaults to "e2u+sip" enum_query(""); # E2U+sip }; } else { # aliases (take precedences over PSTN number; provisioning interface # is set up to assinge aliases beginning with 8) lookup("aliases"); }; # check again, if it is still for our domain after aliases are resolved if (!(uri=~"[@:](sip[\.)?(baltodb\.popdial\.com|66\.159\.88\.19)([;:].*)*" | uri=~"@66\.159\.88\.16([;:].*)*")) { route(5); break; }; # now check if it's about PSTN destinations through our gateway; # note that 8.... is exempted for numerical non-gw destinations if (uri=~"sip:\+?[0-79][0-9]*@.*") { route(3); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { # handle user which was not found ... route(4); break; }; # check whether some inventive user has uploaded gateway # contacts to UsrLoc to bypass our authorization logic if (uri=~"sip:[+0-9]+@66\.159\.88\.16") { # it is gateway -- proceed to ACLs route(3); break; }; /* ... and also report on missed calls ... */ setflag(3); # we now know we may, we know where, let it go out now! append_hf("P-hint: USRLOC\r\n"); if (!t_relay()) { sl_reply_error(); break; }; } #------------------- OUTBOUND ---------------------------------------- # routing logic for outbound requests targeted out of our domain # (keep in mind messages to our users can end up here too: for example, # an INVITE may be UsrLoc-ed, then the other party uses outbound # proxy with r-uri=the usr_loced addredd (typically IP)) route[2] { append_hf("P-hint: OUTBOUND\r\n"); t_relay(); } #------- ALIASED OUTBOUND -------------------------------------------- # routing logic for inbound requests aliased outbound; unlike # with real outbound requests we do not force authentication # as these calls are server by our server and we do not want # to disqualify unathenticated request originatiors from other # domains route[5] { append_hf("P-hint: ALIASED-OUTBOUND\r\n"); t_relay(); } #----------------- PSTN ---------------------------------------------- # logic for calls to the PSTN route[3] { # turn accounting on setflag(1); /* require all who call PSTN to be members of the "int" group; apply ACLs only to INVITEs -- we don't need to protect other requests, as they don't imply charges; also it could cause troubles when a call comes in via PSTN and goes to a party that can't authenticate (voicemail, other domain) -- BYEs would fail then; exempt Cisco gateway from authentication by IP address -- it does not support digest */ if (method=="INVITE" && (!src_ip==69.19.88.16)) { if (!proxy_authorize( "baltodb.popdial.com" /* realm */, "subscriber" /* table name */)) { proxy_challenge( "baltodb.popdial.com" /* realm */, "0" /* no qop */ ); break; }; # let's check from=id ... avoids accounting confusion if (method=="INVITE" & !check_from()) { log("LOG: From Cheating attempt\n"); sl_send_reply("403", "That is ugly -- use From=id next time (gw)"); break; }; if(!is_user_in("credentials", "int")) { sl_send_reply("403", "NO PSTN Privileges..."); break; }; consume_credentials(); }; # INVITE to authorized PSTN # if you have passed through all the checks, let your call go to GW! rewritehostport("69.19.88.16:5060"); # snom conditioner if (method=="INVITE" && search("User-Agent: snom")) { replace("100rel, ", ""); }; append_hf("P-hint: GATEWAY\r\n"); # use UDP to guarantee well-known sender port (TCP ephemeral) t_relay_to_udp("69.19.88.16","5060"); } /* *********** handling of unavailable user ******************* */ route[4] { /**/ # message store if (method=="MESSAGE") { t_newtran(); if (m_store("0")) { t_reply("202", "Accepted for Later Delivery"); } else { t_reply("503", "Service Unavailable"); }; break; }; /**/ # non-Voip -- just send "off-line" if (!(method=="INVITE" || method=="ACK" || method=="CANCEL")) { sl_send_reply("404", "Not Found"); break; }; # voicemail subscribers ... t_newtran(); t_reply("404", "Not Found"); # we account missed incoming calls; previous statteful processing # guarantees that retransmissions are not accounted if (method=="INVITE") { acc_db_request("404 missed call", "missed_calls"); }; }

1 0

[Serusers] ser 0.9 startup problems
by Glenn Dalgliesh 26 Feb '05

26 Feb '05

I am getting the following errors when starting ser. I am sure it is something in my config but I can't track it down. This was a fresh install(no previous ver of ser on this machine.) I have include below the first section on my config. Just let me know if any one need the complete config Thanks Feb 25 18:54:11 baltodb ser[32594]: Maxfwd module- initializing Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is initially 110592 Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is finally 262142 Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is initially 110592 Feb 25 18:54:11 baltodb ser[32594]: INFO: udp_init: SO_RCVBUF is finally 262142 Feb 25 18:54:11 baltodb ser[32604]: INFO: fifo process starting: 32604 Feb 25 18:54:11 baltodb ser[32604]: SER: open_uac_fifo: fifo server up at /tmp/ser_fifo... Feb 25 18:54:11 baltodb ser[32604]: WARNING: no fifo_db_url given - fifo DB commands disabled! Feb 25 18:54:11 baltodb ser[32711]: new_connection(): Too many connections Feb 25 18:54:11 baltodb ser[32711]: db_init(): Could not create a connection Feb 25 18:54:11 baltodb ser[32711]: ERROR: uridb_db_bind: unable to connect to the database Feb 25 18:54:11 baltodb ser[32711]: init_mod_child(): Error while initializing module uri_db Feb 25 18:54:11 baltodb ser[32711]: init_children failed Feb 25 18:54:11 baltodb ser[32604]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32607]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32613]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32616]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32619]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32620]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32623]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32626]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32629]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32632]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32635]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32641]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32644]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32610]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32636]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32647]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32650]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32653]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32655]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32664]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32662]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32667]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32670]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32656]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32673]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32675]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32683]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32684]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32676]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32685]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32686]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32687]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32688]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32695]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32697]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32698]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32699]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32700]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32701]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32709]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32702]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32710]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32724]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32725]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32712]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32713]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32714]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32722]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32723]: INFO: signal 15 received Feb 25 18:54:11 baltodb ser[32726]: INFO: signal 15 received Feb 25 18:54:12 baltodb ser[32594]: BUG: qm_free: freeing already freed pointer, first free: ms_msg_list.c: msg_list_free(162) - aborting # # $Id: serconf.sh,v 1.3 2003/11/03 13:03:58 janakj Exp $ # # autogenerated SER configuration # # user: uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel) # system: Linux baltodb.popvox.com 2.6.10-1.760_FC3 #1 Wed Feb 2 00:14:23 EST 2005 i686 i686 i386 GNU/Linux # date: Thu Feb 24 15:51:05 EST 2005 # # ----------- global configuration parameters ------------------------ debug=3 fork=yes port=5060 log_stderror=no memlog=5 mhomed=yes fifo="/tmp/ser_fifo" alias=popvox.com # uncomment to override config values for test /* debug=3 # debug level (cmd line: -ddd) fork=no port=5068 log_stderror=yes # (cmd line: -E) fifo="/tmp/ser_fifox" */ check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) children=16 # if changing fifo mode to a more restrictive value, put # decimal value in there, e.g. dec(rw|rw|rw)=dec(666)=438 #fifo_mode=438 # ------------------ module loading ---------------------------------- loadmodule "/usr/local/lib/ser/modules/tm.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/acc.so" loadmodule "/usr/local/lib/ser/modules/rr.so" loadmodule "/usr/local/lib/ser/modules/maxfwd.so" loadmodule "/usr/local/lib/ser/modules/mysql.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/textops.so" loadmodule "/usr/local/lib/ser/modules/uri.so" loadmodule "/usr/local/lib/ser/modules/group.so" loadmodule "/usr/local/lib/ser/modules/msilo.so" loadmodule "/usr/local/lib/ser/modules/enum.so" loadmodule "/usr/local/lib/ser/modules/uri_db.so" # ----------------- setting module-specific parameters --------------- # all DB urls here modparam("usrloc|acc|auth_db|group|msilo", "db_url","mysql://ser:heslo@localhost/ser") # -- usrloc params -- /* 0 -- dont use mysql, 1 -- write_through, 2--write_back */ modparam("usrloc", "db_mode", 2) modparam("usrloc", "timer_interval", 10) # -- auth params -- modparam("auth_db", "calculate_ha1", yes) #modparam("auth_db", "user_column", "user_id") modparam("auth_db", "password_column", "password") modparam("auth", "nonce_expire", 300) # -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1) # -- acc params -- # that is the flag for which we will account -- don't forget to modparam("acc", "db_flag", 1 ) modparam("acc", "db_missed_flag", 3 ) # -- tm params -- modparam("tm", "fr_timer", 20 ) modparam("tm", "fr_inv_timer", 90 ) modparam("tm", "wt_timer", 20 ) # -- msilo params modparam("msilo", "registrar", "sip:registrar@popvox.com") # -- enum params -- # modparam("enum", "domain_suffix", "e164.arpa.") # ------------------------- request routing logic ------------------- # main routing logic

2 2

[Serusers] METHOD<null>
by Iqbal 26 Feb '05

26 Feb '05

Hi This doesnt seem to be a standard SIP method, is there any reason I would be getting this in my logs, it always seems to come from the called party..in this case being xlite Iqbal

3 3

[Serusers] contact header fix
by Iqbal 26 Feb '05

26 Feb '05

Hi When I use fix_contact with the mediaproxy module, should not the contact which is displayed using xlog namely %ct change Iqbal

2 2

[Serusers] UDP packet is bad?
by xiahong 26 Feb '05

26 Feb '05

1 0

← Newer
1
2
3
4
5
6
7
8
9
...
47
Older →

Jump to page:

2026

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