sr-users

sr-users@lists.kamailio.org

38 participants
37302 discussions

by jaime.gill＠orange.co.uk

Is anybody aware of any SIP ALG developed or being developed for linux/freebsd? Jaime PS: If nobody is looking at the FCP client side for SER, I would like to contribute in my spare time. Please let me know where should I start and may be I could give it a try. Jiri Kuthan <jiri(a)iptel.org> on 08/01/2003 21:39:20 To: Jaime GILL/EN/HTLUK@HTLUK serusers(a)lists.iptel.org cc: Subject: Re: [Serusers] FCP support in SER This piece of work is stalling for some reasons. First, the gentlemen who was supposed to integrate an FCP client silently stepped away from this assignment. FCP server on linux is working. The other problem with FCP is there are no real standards. I was expecting the Midcom WG in the IETF to come up with one. Instead, it spent two years with doing things whose use I very strongly doubt. If there is any volunteer on this mailing list who would wish to complete or create the FCP client module, we will be glad to provide guidance. Users willing to traverse NATs may consider STUN/UPnP or ALGs as an alternative solution. Users willing to traverse firewalls may need to use an ALG or VPN technology. Unfortunately, NAT/FWs break too many things and there is no one-size-fits-it-all solution addressing all scenarios. -Jiri At 06:14 PM 1/8/2003, jaime.gill(a)orange.co.uk wrote: >Hi, > >I am wondering if this is the right place to ask, but here it goes. > >Is the SER software going to incorporate the client side of FCP (Firewall >Control Protcol) as a module at some point? > >Regards, > >Jaime > > > >******************************************************************************* >Important. >Confidentiality: This communication is intended for the above-named person and >may be confidential and/or legally privileged. Any opinions expressed in this >communication are not necessarily those of the company. If it has come to you >in error you must take no action based on it, nor must you copy or show it to >anyone; please delete/destroy and inform the sender immediately. > >Monitoring/Viruses >Orange may monitor all incoming and outgoing emails in line with current >legislation. Although we have taken steps to ensure that this email and >attachments are free from any virus, we advise that in keeping with good >computing practice the recipient should ensure they are actually virus free. > >Orange PCS Limited is a subsidiary of Orange SA and is registered in England No >2178917, with its address at St James Court, Great Park Road, Almondsbury Park, >Bradley Stoke, Bristol BS32 4QJ. >******************************************************************************* > >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers -- Jiri Kuthan http://iptel.org/~jiri/ _______________________________________________ Serusers mailing list serusers(a)lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 10 months

[Serusers] Problems compiling radius_acc module

by Claudio Thorell dos Santos

Hello, I'm trying to compile the radius_acc modude but have run into the following error: ###### make[1]: Entering directory `/home/cthorell/ser-0.8.10/modules/radius_acc' gcc -fPIC -DPIC -O9 -funroll-loops -Wcast-align -Wall -m486 -malign-loops=4 -DNAME='"ser"' -DVERSION='"0.8.10"' -DARCH='"i386"' -DOS='"linux"' -DCOMPILER='"gcc 2.95"' -D__CPU_i386 -DCFG_DIR='"/usr/local/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DDNS_IP_HACK -DUSE_IPV6 -DDBG_QM_MALLOC -DFAST_LOCK -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -c acc.c -o acc.o acc.c:38: radiusclient.h: File not found make[1]: *** [acc.o] Error 1 make[1]: Leaving directory `/home/cthorell/ser-0.8.10/modules/radius_acc' ###### I can't find radiusclient.h either on ser-0.8.10 or freeradius-0.8.1 directories. Where can I find this file? Thanks, Claudio

21 years, 10 months

[Serusers] ser up and running, now on to voice mail / conferencing

by Michael Graff

I got SER up and running with a whopping total of three "domains" being served on the same server. It was mostly painless, if missing some features I'd like to have seen (more on that in later messages.) What open source products are people using for voice mail, voice menu prompts (press 1 for sales, press 2 for the executative restroom) and for conference calls (which include PSTN calls as well as IP phones)? --Michael

21 years, 10 months

[Serusers] SIP Symmetric Response support in SER

by Maxim Sobolev

Hi, Are there any plans to add SIP Symmetric Response support (http://www.iptel.org/info/players/ietf/firewall/nat/draft-ietf-sip-symmetri…) into SER, so that it would be possible to use compliant UAs behind NATs with SER being on a public IP? The idea is simple: when the SIP packet is received from UA, the server checks if an empty `rport' parameter is present in the first Via field, and if yes then compares IP:PORT in the first Via header with the actual IP:PORT this request came from, and adds `received' and `rport' parameters into the header if either doesn't match before forwarding request further. Then, when replying or forwarding the request, the server checks if any of received or rport is present and uses it instead of the UA-provided values in corresponding Via header. Please let me know if there are work in progress on this, so that I will not have to reinvent the wheel. Thanks! -Maxim

21 years, 10 months

[Serusers] FCP support in SER

by jaime.gill＠orange.co.uk

Hi, I am wondering if this is the right place to ask, but here it goes. Is the SER software going to incorporate the client side of FCP (Firewall Control Protcol) as a module at some point? Regards, Jaime ******************************************************************************* Important. Confidentiality: This communication is intended for the above-named person and may be confidential and/or legally privileged. Any opinions expressed in this communication are not necessarily those of the company. If it has come to you in error you must take no action based on it, nor must you copy or show it to anyone; please delete/destroy and inform the sender immediately. Monitoring/Viruses Orange may monitor all incoming and outgoing emails in line with current legislation. Although we have taken steps to ensure that this email and attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free. Orange PCS Limited is a subsidiary of Orange SA and is registered in England No 2178917, with its address at St James Court, Great Park Road, Almondsbury Park, Bradley Stoke, Bristol BS32 4QJ. *******************************************************************************

21 years, 10 months

[Serusers] acc problem

by Joe_chen

hi, i have met the same problem with acc. i can get the invite message for accounting,but i can't get the bye message, i also capture the udp packages on ser server, i use MSN for UA, i find the sip messeges like: invite,100 trying,180 ringing ,200 ok(for invite),but when i hangup, there are not bye message, it's like sending bye message from UA to UA directly,while not going throug ser server,so there is not BYE message for accounting, is it true? how to get the bye message for accounting? please help. my ser.cfg is like: .. loadmodule "/usr/local/lib/ser/modules/mysql.so" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/acc.so" #loadmodule "/usr/local/lib/ser/modules/auth.so" loadmodule "/usr/local/lib/ser/modules/print.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" .. modparam("acc", "db_url","sql://ser:heslo@localhost/ser") modparam("acc","report_ack",1) modparam("acc","log_level",1) modparam("acc", "acc_flag", 1 ) modparam("acc", "missed_flag", 3 ) # -- tm params -- modparam("tm", "fr_timer", 10 ) modparam("tm", "fr_inv_timer", 20 ) modparam("tm", "wt_timer", 10 ) .. route{ # initial sanity checks -- messages with # max_forwars==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Message too big"); break; }; # Do strict routing if pre-loaded route headers present rewriteFromRoute(); # if the request is for other domain use UsrLoc # (in case, it does not work, use the following command # with proper names and addresses in it) if (uri==myself) { if (method=="REGISTER") { # Uncomment this if you want to use digest authentication # if (!www_authorize("192.168.139.125", "subscriber")) { # www_challenge("192.168.139.125", "0"); # break; # }; save("location"); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; # set for accounting (the same value as in acc_flag!) if (method=="INVITE" || method=="BYE"){ setflag(1); # ... and also report on missed calls ... note that reporting # on missed calls is mutually exclusive with silent C timer # setflag(3); }; # forward to current uri now if (!t_relay()) { sl_reply_error(); }; } thanks!

21 years, 10 months

[Serusers] Problems compiling SER with radius support

by Maxim Sobolev

Dear Sirs, Our company is currently evaluating several freely available SIP proxy/registrars to extend our VoIP billing engine, which currently only supports H323, to support SIP as well. We found SER to be one of the best for our needs: speed, documentation, flexibility - everything is great. Hovewer, since our billing engine uses Radius for AAA, we need to get Radius modules working. Unfortunately, we can't compile radius modules with virgin radiusclient 0.3.2 as suggested in documentation - it seems that some SIP-specific changes need to be applied to radiusclient headers, see the following log: gcc -fPIC -DPIC -pipe -O -mpreferred-stack-boundary=2 -march=pentium2 -funroll-loops -Wcast-align -Wall -minline-all-stringops -malign-double -falign-loops -DNAME='"ser"' -DVERSION='"0.8.10"' -DARCH='"i386"' -DOS='"freebsd"' -DCOMPILER='"gcc 3.2"' -D__CPU_i386 -DCFG_DIR='"/usr/local/etc/ser/"' -DPKG_MALLOC -DSHM_MEM -DSHM_MMAP -DADAPTIVE_WAIT -DADAPTIVE_WAIT_LOOPS=1024 -DDNS_IP_HACK -DUSE_IPV6 -DDBG_QM_MALLOC -DFAST_LOCK -DHAVE_GETHOSTBYNAME2 -DHAVE_UNION_SEMUN -DHAVE_SCHED_YIELD -DHAVE_SOCKADDR_SA_LEN -I/usr/local/include -c acc.c -o acc.o acc.c: In function `radius_log_reply': acc.c:125: `PW_SIP_METHOD' undeclared (first use in this function) acc.c:125: (Each undeclared identifier is reported only once acc.c:125: for each function it appears in.) acc.c:136: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function) acc.c:156: `PW_SIP_FROM_TAG' undeclared (first use in this function) acc.c:189: `PW_SIP_TO_TAG' undeclared (first use in this function) acc.c:213: `PW_SIP_CSEQ' undeclared (first use in this function) acc.c:288: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function) acc.c: In function `radius_log_ack': acc.c:434: `PW_SIP_METHOD' undeclared (first use in this function) acc.c:442: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function) acc.c:461: `PW_SIP_FROM_TAG' undeclared (first use in this function) acc.c:491: `PW_SIP_TO_TAG' undeclared (first use in this function) acc.c:514: `PW_SIP_CSEQ' undeclared (first use in this function) acc.c:588: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function) acc.c: In function `rad_acc_request': acc.c:733: `PW_SIP_METHOD' undeclared (first use in this function) acc.c:744: `PW_SIP_RESPONSE_CODE' undeclared (first use in this function) acc.c:764: `PW_SIP_FROM_TAG' undeclared (first use in this function) acc.c:797: `PW_SIP_TO_TAG' undeclared (first use in this function) acc.c:821: `PW_SIP_CSEQ' undeclared (first use in this function) acc.c:904: `PW_SIP_TRANSLATED_REQ_URI' undeclared (first use in this function) Would you be so kind to provide us with your changes for radiusclient or point out where that modified version can be downloaded? Thank you in advance! On a separate note I would like to ask you to let me know if there is any progress on pre-paid module discussed on this list recently. Since we will also need this functionality, perhaps we can team-up to implement it. Sincerely, Maxim Sobolev PortaOne Ltd

21 years, 10 months

Re: [Serusers] acc question.

by lgfausak＠august.net

I really hate answering my own question :-) > } else if(method=="BYE") { > setflag(1); > forward(uri:host, uri:port); I changed this to t_relay() and then I get the BYE ACC output in the syslog file. This explains something else (I think). Sometimes the BYE would work, sometimes it would not make it all the way to the other device (either the PSTN gateway or the UA). That is probably because forward() simply bounces the packet via UDP and the UDP can fail ??? t_relay() retries?? Does this make sense? ---greg > >Hi, > >I am trying to create a basic script for routing calls to and from >the PSTN. I have experimented with many scripts over the last month, >this included script is an example. I can use a UA on my >laptop called 'estara' and REGISTER with my ser sip server. >I can make a phone call (INVITE) to the PSTN. I can hang up the call >from either end (BYE) and everything seems to work well. > >I am trying to get accounting working. I see the call acceptance >record in my syslog file: > >Jan 7 00:21:09 build ser[3507]: ACC: transaction answered: method=INVITE, i-uri=sip:92143357976@build.august.net, o-uri=sip:2143357976@64.90.42.16:5060, call_id= 847b3d22-131d-46b0-abcb-dc8e6a9f32b5(a)192.168.100.100, from= greg <sip:1107@build.august.net>;tag=3a7b9c52, code=200 > >However, I can't get the 'BYE' event to record the transaction to the >syslog file. The 'BYE' event is bouncing through my SIP server. >Can someone give me a hint? > >Thank you, >---greg >Greg Fausak > >Included file----example.cfg---------------------------------------- >debug=1 # debug level (cmd line: -dddddddddd) >fork=yes >log_stderror=no # (cmd line: -E) >check_via=no # (cmd. line: -v) >dns=no # (cmd. line: -r) >rev_dns=no # (cmd. line: -R) >port=5060 >children=4 >fifo="/tmp/ser_fifo" > >loadmodule "/usr/local/lib/ser/modules/sl.so" >loadmodule "/usr/local/lib/ser/modules/tm.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/usrloc.so" >loadmodule "/usr/local/lib/ser/modules/registrar.so" >modparam("acc", "log_level", 1) >modparam("acc", "acc_flag", 1 ) > >route{ > # filter too old messages > if (!mf_process_maxfwd_header("10")) { > log("LOG: Too many hops\n"); > sl_send_reply("483","Too Many Hops"); > break; > }; > if (len_gt( max_len )) { > sl_send_reply("513", "Wow -- Message too large"); > break; > }; > > /* ********* RR ********************************** */ > > /* Do strict routing if route headers present */ > rewriteFromRoute(); > /* record-route INVITEs -- all subsequent requests must visit us */ > if (method=="INVITE") { > addRecordRoute(); > } else if (method=="REGISTER") { > log("here is a register"); > save("location"); > break; > }; > > # now check if it really is a PSTN destination which should be handled > # by our gateway; if not, and the request is an invitation, drop it -- > # we cannot terminate it in PSTN; relay non-INVITE requests -- it may > # be for example BYEs sent by gateway to call originator > if (!uri=~"sip:9[2-9][0-9]{9}@.*") { > if (method=="INVITE") { > sl_send_reply("403", "Call cannot be served here"); > } else if(method=="BYE") { > setflag(1); > forward(uri:host, uri:port); > } else { > forward(uri:host, uri:port); > }; > break; > }; > > # account completed transactions via syslog > setflag(1); > > strip(1); > > > rewritehostport("64.90.42.16:5060"); > > # forward the request now > if (!t_relay()) { > sl_reply_error(); > break; > }; >} >_______________________________________________ >Serusers mailing list >serusers(a)lists.iptel.org >http://lists.iptel.org/mailman/listinfo/serusers >

21 years, 10 months

[Serusers] qm_malloc problem

by Joe_chen

hi, i have a problem about qm_malloc. my ser has been running correctly before sevral days. but on the day before yesterday it doesn't work suddenly, in the debug mode, the output informations are: .. 0(1114) find_export: found <~db_insert> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(1114) find_export: found <~db_delete> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(1114) find_export: found <~db_update> in module mysql [/usr/local/lib/ser/modules/mysql.so] 0(1114) qm_malloc(0x80adf80, 24) called from dbase.c: db_init(266) 0(1114) qm_malloc(0x80adf80, 24) returns address 0x80b43d0 on 0 -th hit 0(1114) qm_malloc(0x80adf80, 30) called from dbase.c: connect_db(69) 0(1114) qm_malloc(0x80adf80, 32) returns address 0x80b4418 on 0 -th hit 0(1114) qm_malloc(0x80adf80, 544) called from dbase.c: connect_db(89) 0(1114) qm_malloc(0x80adf80, 544) returns address 0x80b4468 on 0 -th hit 0(1114) qm_free(0x80adf80, 0x80b4418), called from dbase.c: connect_db(106) 0(1114) qm_free: freeing block alloc'ed from dbase.c: connect_db(69) 0(1114) mod_init(): Database connection opened successfuly Maxfwd module- initializing rr - initializing 0(1114) TM - initializing... 0(1114) DEBUG: register_fifo_cmd: new command (t_uac) registered 0(1114) DEBUG: register_fifo_cmd: new command (t_uac_from) registered 0(1114) DEBUG: register_fifo_cmd: new command (t_hash) registered 0(1114) qm_malloc(0x4212f000, 1572864) called from h_table.c: init_hash_table(276) 0(1114) qm_malloc(0x4212f000, 1572864) returns address 0x421354b8 on 0 -th hit 0(1114) DEBUG: lock_initialize: lock initialization started 0(1114) qm_malloc(0x4212f000, 16) called from lock.c: lock_initialize(169) 0(1114) qm_malloc(0x4212f000, 16) returns address 0x422b54e8 on 0 -th hit 0(1114) qm_malloc(0x4212f000, 448) called from timer.c: tm_init_timers(484) 0(1114) qm_malloc(0x4212f000, 448) returns address 0x422b5528 on 0 -th hit 0(1114) qm_malloc(0x4212f000, 40) called from t_stats.c: init_tm_stats(110) 0(1114) qm_malloc(0x4212f000, 40) returns address 0x422b5718 on 0 -th hit 0(1114) qm_malloc(0x4212f000, 12) called from t_stats.c: init_tm_stats(118) 0(1114) qm_malloc(0x4212f000, 12) returns address 0x422b5770 on 0 -th hit .. stateless - initializing 0(1114) qm_malloc(0x4212f000, 320) called from sl_stats.c: init_sl_stats(128) 0(1114) qm_malloc(0x4212f000, 320) returns address 0x422b5824 on 0 -th hit 0(1114) DEBUG: register_fifo_cmd: new command (sl_stats) registered 0(1114) DEBUG: MD5 calculated: d907c037823644515dfe0ede38ca9976 0(1114) qm_malloc(0x4212f000, 4) called from sl_funcs.c: sl_startup(65) 0(1114) qm_malloc(0x4212f000, 4) returns address 0x422b5994 on 0 -th hit mysql - initializing 0(1114) qm_malloc(0x4212f000, 396) called from main.c: main(1363) 0(1114) qm_malloc(0x4212f000, 396) returns address 0x422b59c8 on 0 -th hit 0(0) fixing /usr/local/lib/ser/modules/maxfwd.so mf_process_maxfwd_header 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/sl.so sl_send_reply 0(0) fixing /usr/local/lib/ser/modules/rr.so rewriteFromRoute 0(0) fixing /usr/local/lib/ser/modules/registrar.so save 0(0) qm_malloc(0x4212f000, 16) called from dlist.c: new_dlist(87) 0(0) qm_malloc(0x4212f000, 16) returns address 0x422b5b84 on 0 -th hit ... 0(0) qm_malloc(0x80adf80, 96) called from db_row.c: convert_row(49) 0(0) qm_malloc(0x80adf80, 96) returns address 0x80b47cc on 0 -th hit 0(0) qm_malloc(0x80adf80, 96) called from db_row.c: convert_row(49) 0(0) qm_malloc(0x80adf80, 96) returns address 0x80b485c on 0 -th hit Segmentation fault it seems that ser can't allocate memory by qm_malloc function. what's wrong with it? i have tried to reinstall my linux8.0 OS, but the problem is still existed. please help me! thanks! regards,Joe_chen

21 years, 10 months

[Serusers] acc question.

by lgfausak＠august.net

Hi, I am trying to create a basic script for routing calls to and from the PSTN. I have experimented with many scripts over the last month, this included script is an example. I can use a UA on my laptop called 'estara' and REGISTER with my ser sip server. I can make a phone call (INVITE) to the PSTN. I can hang up the call from either end (BYE) and everything seems to work well. I am trying to get accounting working. I see the call acceptance record in my syslog file: Jan 7 00:21:09 build ser[3507]: ACC: transaction answered: method=INVITE, i-uri=sip:92143357976@build.august.net, o-uri=sip:2143357976@64.90.42.16:5060, call_id= 847b3d22-131d-46b0-abcb-dc8e6a9f32b5(a)192.168.100.100, from= greg <sip:1107@build.august.net>;tag=3a7b9c52, code=200 However, I can't get the 'BYE' event to record the transaction to the syslog file. The 'BYE' event is bouncing through my SIP server. Can someone give me a hint? Thank you, ---greg Greg Fausak Included file----example.cfg---------------------------------------- debug=1 # debug level (cmd line: -dddddddddd) fork=yes log_stderror=no # (cmd line: -E) check_via=no # (cmd. line: -v) dns=no # (cmd. line: -r) rev_dns=no # (cmd. line: -R) port=5060 children=4 fifo="/tmp/ser_fifo" loadmodule "/usr/local/lib/ser/modules/sl.so" loadmodule "/usr/local/lib/ser/modules/tm.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/usrloc.so" loadmodule "/usr/local/lib/ser/modules/registrar.so" modparam("acc", "log_level", 1) modparam("acc", "acc_flag", 1 ) route{ # filter too old messages if (!mf_process_maxfwd_header("10")) { log("LOG: Too many hops\n"); sl_send_reply("483","Too Many Hops"); break; }; if (len_gt( max_len )) { sl_send_reply("513", "Wow -- Message too large"); break; }; /* ********* RR ********************************** */ /* Do strict routing if route headers present */ rewriteFromRoute(); /* record-route INVITEs -- all subsequent requests must visit us */ if (method=="INVITE") { addRecordRoute(); } else if (method=="REGISTER") { log("here is a register"); save("location"); break; }; # now check if it really is a PSTN destination which should be handled # by our gateway; if not, and the request is an invitation, drop it -- # we cannot terminate it in PSTN; relay non-INVITE requests -- it may # be for example BYEs sent by gateway to call originator if (!uri=~"sip:9[2-9][0-9]{9}@.*") { if (method=="INVITE") { sl_send_reply("403", "Call cannot be served here"); } else if(method=="BYE") { setflag(1); forward(uri:host, uri:port); } else { forward(uri:host, uri:port); }; break; }; # account completed transactions via syslog setflag(1); strip(1); rewritehostport("64.90.42.16:5060"); # forward the request now if (!t_relay()) { sl_reply_error(); break; }; }

21 years, 10 months

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