hello, I must make some change to ser code and recompile it. So, I'm searching to make some changes to pa module. i'm trying then to send an email to one client to be notified of presence of some contacts. I'm trying with ser_08.12.tar.gz can I think in other persistant changes or continue with my idea. In bith case what can I do that. I'm debutant on Ser. Can you help me. thanks in advance. Refka
On 5/25/06, serusers-request@lists.iptel.org serusers-request@lists.iptel.org wrote:
Send Serusers mailing list submissions to serusers@lists.iptel.org
To subscribe or unsubscribe via the World Wide Web, visit http://lists.iptel.org/mailman/listinfo/serusers or, via email, send a message with subject or body 'help' to serusers-request@lists.iptel.org
You can reach the person managing the list at serusers-owner@lists.iptel.org
When replying, please edit your Subject line so it is more specific than "Re: Contents of Serusers digest..."
Today's Topics:
- Re: Mediaproxy gets confused (rusl)
- Re: Hell Sir please help in SER (Andrey Kouprianov)
- How to enable Authentication (Aniruddha Vaidya)
- Re: How to enable Authentication (Andrey Kouprianov)
- Re: How to enable Authentication (Andrey Kouprianov)
- Re: How to enable Authentication (Andrey Kouprianov)
- Re: How to enable Authentication (Andrey Kouprianov)
Message: 1 Date: Thu, 25 May 2006 08:14:41 +0000 From: rusl rusl@jpfortune.org Subject: Re: [Serusers] Mediaproxy gets confused To: serusers@lists.iptel.org Message-ID: 200605250814.41731.rusl@jpfortune.org Content-Type: text/plain; charset="iso-8859-1"
Hi, just to let everyone know, I found the problem.. In mediaproxy 1.4.2, they added a new "feature" which allows the called user to change his media stream with a 183, 200 status w/ SDP. But the thing is that usually it's the caller that initiates a mediachange, so when the caller sent a 200 or 183 for media change, mediaproxy thought it was the called that had a media change, and basically connected the caller to itself by saying that the caller was the called.
I fixed it by "reversing" the functionality in mediaproxy.
On Wednesday 24. May 2006 22:04, rusl wrote:
Hi, I was wondering whether anyone has seen this strange error before. It happens intermittently, where mediaproxy gets confused as to who the "called" IP is, it thinks the caller is the called and switches back and forth.
Any ideas?
rusl..
May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 193.xxx.33.xxx:20820 (RTP) (will return to 193.xxx.33.xxx:20820) May 24 21:58:08 voice mediaproxy[15520]: session 7A99B4CF-725E-0952-8C5A-7C17443072C7@192.168.15.3: called signed in from 10.2.1.3:6622 (RTP) (will return to 10.2.1.3:6622) _______________________________________________ Serusers mailing list Serusers@lists.iptel.org http://lists.iptel.org/mailman/listinfo/serusers
Message: 2 Date: Thu, 25 May 2006 16:22:01 +0700 From: "Andrey Kouprianov" andrey.kouprianov@gmail.com Subject: [Serusers] Re: Hell Sir please help in SER To: serusers@iptel.org Message-ID: ab5f5bda0605250222wc43a773ifb9103de26a1b6d5@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Hi,
proxyIP takes only one IP address. You cannot say
proxyIP = 81.21.33.35,127.0.0.1
Instead try
proxyIP = 81.21.33.35
Then mail me if you have problem. Your ser.cfg seems like the one from getting started document. It should work just fine.
Message: 3 Date: Thu, 25 May 2006 16:03:33 +0530 From: "Aniruddha Vaidya" anir123@gmail.com Subject: [Serusers] How to enable Authentication To: Serusers@lists.iptel.org Message-ID: 7759a74d0605250333x5ae6196ekc780dc3d8d7ff064@mail.gmail.com Content-Type: text/plain; charset="iso-8859-1"
Hello All, I'm trying to enable the authentication feature in SER. But its not accepted by the server. This is my ser.cfg file.
Can you tell me whats wrong ?
# # $Id: ser.cfg,v 1.25.2.1 2005/02/18 14:30:44 andrei Exp $ # # simple quick-start config script #
# ----------- global configuration parameters ------------------------
#debug=3 # debug level (cmd line: -dddddddddd) #fork=yes #log_stderror=no # (cmd line: -E)
# Uncomment these lines to enter debugging mode #fork=no #log_stderror=yes #
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"
# ------------------ module loading ----------------------------------
# Uncomment this if you want to use SQL database 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/textops.so"
# Uncomment this if you want digest authentication # mysql.so must be loaded ! #loadmodule "/usr/local/lib/ser/modules/auth.so" #loadmodule "/usr/local/lib/ser/modules/auth_db.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
#modparam("usrloc", "db_mode", 0)
# Uncomment this if you want to use SQL database # for persistent storage and comment the previous line modparam("usrloc", "db_mode", 2)
# -- auth params -- # Uncomment if you are using auth module # modparam("auth_db", "calculate_ha1", yes) # # If you set "calculate_ha1" parameter to yes (which true in this config), # uncomment also the following parameter) # modparam("auth_db", "password_column", "password")
# -- rr params -- # add value to ;lr param to make some broken UAs happy modparam("rr", "enable_full_lr", 1)
# ------------------------- request routing logic -------------------
# main routing logic
route{
# initial sanity checks -- messages with # max_forwards==0, or excessively long requests if (!mf_process_maxfwd_header("10")) { sl_send_reply("483","Too Many Hops"); break; }; if (msg:len >= 2048 ) { sl_send_reply("513", "Message too big"); break; }; # we record-route all messages -- to make sure that # subsequent messages will go through our proxy; that's # particularly good if upstream and downstream entities # use different transport protocol if (!method=="REGISTER") record_route(); # subsequent messages withing a dialog should take the # path determined by record-routing if (loose_route()) { # mark routing logic in request append_hf("P-hint: rr-enforced\r\n"); route(1); break; }; if (!uri==myself) { # mark routing logic in request append_hf("P-hint: outbound\r\n"); route(1); break; }; # 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("<InternalSER>", "subscriber")) { www_challenge("<InternalSER>", "0"); break; };
save("location"); break; }; lookup("aliases"); if (!uri==myself) { append_hf("P-hint: outbound alias\r\n"); route(1); break; }; # native SIP destinations are handled using our USRLOC DB if (!lookup("location")) { sl_send_reply("404", "Not Found"); break; }; }; append_hf("P-hint: usrloc applied\r\n"); route(1);
}
route[1] { # send it out now; use stateful forwarding as it works reliably # even for UDP2TCP if (!t_relay()) { sl_reply_error(); }; }
Thanks, Aniruddha