hi ,
I have a doubt regarding sending a request message with ACK method. In the
request line i am sending a ACK method with sip uri along with uri
parameters as "maddr and transport". What impact will it make while making a
call to PSTN number
Regards
Sudhi
Hello,
Sometimes, i got this error from mediaproxy, please advise if someone know
how to deal with this error.
It happens when i made a call, wich appears that did no got through, but
after i hang the phone, the callee begins to ring.
---------------------------------------------
-30 /usr/local/sbin/ser[978]: DEBUG: wait_handler : done
-30 proxydispatcher[29189]: ----------------------------------------
-30 proxydispatcher[29189]: Exception happened during processing of request
from
-30 proxydispatcher[29189]: Traceback (most recent call last):
-30 proxydispatcher[29189]: File
"/usr/src/build/143041-i386/install/usr/lib/python2.2/SocketServer.py", line
458, in
-30 proxydispatcher[29189]: self.finish_request(request, client_address)
-30 proxydispatcher[29189]: File
"/usr/src/build/143041-i386/install/usr/lib/python2.2/SocketServer.py", line
253, in finish_request
-30 proxydispatcher[29189]: self.RequestHandlerClass(request,
client_address, self)
-30 proxydispatcher[29189]: File
"/usr/src/build/143041-i386/install/usr/lib/python2.2/SocketServer.py", line
514, in __init__
-30 proxydispatcher[29189]: self.handle()
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/dispatcher.py", line 205, in handle
-30 proxydispatcher[29189]: result = self.execute(command)
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/dispatcher.py", line 238, in execute
-30 proxydispatcher[29189]: proxy = self.proxyFor(domain)
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/dispatcher.py", line 338, in proxyFor
-30 proxydispatcher[29189]: proxies = proxyList(domain)
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/dispatcher.py", line 294, in proxyList
-30 proxydispatcher[29189]: answers =
DNS.DnsRequest().req(name=mediaproxyrec, qtype='SRV').answers
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/external/DNS/Base.py", line 173, in req
-30 proxydispatcher[29189]: self.sendUDPRequest(server)
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/external/DNS/Base.py", line 193, in
sendUDPRequest
-30 proxydispatcher[29189]: self.response=self.processUDPReply()
-30 proxydispatcher[29189]: File
"/etc/ser/mediaproxy/modules/external/DNS/Base.py", line 89, in
processUDPReply
-30 proxydispatcher[29189]: raise DNSError, 'Timeout'
-30 proxydispatcher[29189]: DNSError: Timeout
-30 proxydispatcher[29189]: ----------------------------------------
-30 /usr/local/sbin/ser[938]: error: use_media_proxy(): empty response from
mediaproxy
-30 /usr/local/sbin/ser[938]: ------------ forward to PSTN / Flag
4 -----------
-30 /usr/local/sbin/ser[938]: DEBUG: t_addifnew: msg id=2385 , global msg
id=2383 , T on entrance=0xffffffff
-30 /usr/local/sbin/ser[938]: parse_headers: flags=-1
-30 /usr/local/sbin/ser[938]: parse_headers: flags=60
---------------------------------------------
Regards,
Ri
Hi,
I have gotten one attempt at helping me with record_route(), which
doesn't seem to work in my simple config file. Again, what I am trying
to do is use SER in a lab situation, to test our UA under development.
I can successfully REGISTER, and the appropriate information is saved in
the location table in mysql. I can make a match on a sip uri ok, and
then forward to another uri.
However, when I attempt to use the record_route() function, nothing
seems to happen.
Attached is the config file. Note that I added, for debugging purposes,
a couple of fake sl_send_reply arguments, so I could see when a match
was made successfully to a uri, and after the record_route(). An
ethereal sniff shows that the uri in the first block is matched (if
(uri=="sip:17325555555@192.168.20.12")) , and the message 678 etc
appears in the Ethereal sniff. Then apparently the record_route() is
executed, and the "999" message appears in the sniff. However,
record_routing doesn't actually seem to occur. The call is never
completed, and there is nothing from the SER server that shows up in the
Ethereal sniff except the "999" message.
Any ideas as to why?
thanks,
bert
#########################
#
# $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 andrei Exp $
#
# ----------- 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 */
debug=2
fork=yes
log_stderror=yes
check_via=yes # (cmd. line: -v)
dns=yes # (cmd. line: -r)
rev_dns=yes # (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"
# 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 -------------------
alias=quintum.lab
alias=ken137.quintum.lab
alias=nisthost2.quintum.lab
alias=192.168.20.12
# 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 (len_gt( max_len )) {
sl_send_reply("513", "Message too big");
break;
};
# store user location if a REGISTER appears
if (method=="REGISTER") {
save("location");
break;
};
############################
if (uri=="sip:17325555555@192.168.20.12")
{
if(method=="INVITE")
{
sl_send_reply("678","matched uri for 20.137");
record_route();
sl_send_reply("999","return from record_route for 20.137");
};
};
if (uri=~"sip:1732922[0-9]*@192.168.20.12")
{
if(method=="INVITE")
{
sl_send_reply("678","matched uri for 20.220");
record_route();
};
};
if (uri=~"sip:173221000[0-9]*@192.168.20.12")
{
sl_send_reply("678","matched uri for 20.210");
forward(192.168.20.210, 5060);
};
if (uri=~"sip:173220000[0-9]*@192.168.20.12")
{
sl_send_reply("678","matched uri for 20.209");
forward(192.168.20.209, 5060);
};#end if uri =~
}
#######################
--
Bert Berlin
Bert Berlin
Quintum Technologies, Inc.
71 James Way
Eatontown, NJ 07724
PH 732-460-9000 ext 247
Email: bert_berlin(a)quintum.com <mailto:beert_berlin@quintum.com>
I am having problem using PSTN(AS5300). I have a VOCAL setup on the same machine and PSTN works fine with VOCAL. Now I want to test SER on the same machine. I shut down VOCAL and start SER. I can make SIP to SIP calls but can not make SIP to PSTN call. In my ser.cfg, I redirect all the calls starting with 1 to the PSTN like this:
if (uri=~"^1.*"){
log(1,"Forwarding to PSTN\n");
record_reoute();
rewritehostport("PSTN IP:PORT");
};
Do I need any specific module for PSTN to work? How can I debug this?
Gary
Hi,
I have problems about iptel.org public service, the voicemail feature is still present for new subscriber now?
Since I cannot find any option tab in user management and also missing the "Access-Control-List:voicemail" box.
Thanks,
Solyin
How can I monitor packetloss from the SER? I am able to monitor Ploss from
the cisco by monitoring the active call, but I dont know how to monitor ip
to ip calls.
I am encountering a problem where if i call a SIP phone from the PSTN I
receive 0 Ploss. if I make a call from the SIP phone to the PSTN i get tons
of PLoss.
I have been monitoring it from my cisco gateway.....
Called to PSTN in the duration of 37 seconds i lost 94 packets with a
delay of 45 avg.
39FA : 276741189hs.1 +742 pid:14 Answer 7133154694 active
dur 00:00:37 tx:1001/154588 rx:4203/336240
IP 64.72.107.1:16348 rtt:0ms pl:41050/1190ms lost:94/6/0 delay:45/45/85ms
g711u
law
Called from PSTN in the duration of 50 seconds i lost 0 packets with a
delay of 25 avg.
3A0D : 276761635hs.2 +167 pid:1011 Originate 7133154694 active
dur 00:00:50 tx:2517/402720 rx:5033/402640
IP 64.72.107.1:16550 rtt:3174ms pl:45030/0ms lost:0/2/0 delay:25/25/65ms
g711ul
aw
-----------------------
Harold Workman
CCNA, CCNP
Cytel Communications
hworkman(a)cytelcom.com
Ph. 281-449-4000 x3098
We are running SIP Express router on FreeBSD and
would like to setup PSTN gateway trough Cisco 3620
router.
- What IOS version is required?
- What IOS feature pack is required?
- Is the normal ISDN BRI interface card ok to do this?
Because i've read on this mailing list you need NM-HDV
Thank you!
---
Jan Baggen - jbaggen(a)ip2.nl
IP2 Internet BV / http://www.ip2.nl
Hi Bogdan,
I've download everything from CVS head, compile it and try to run the SER with the basic config file (no database, authentication and cpl support), but I get the following error message in my syslog
Jun 8 15:46:44 sipproxy1 ser: parse error (1,1-2): parse error
Jun 8 15:46:44 sipproxy1 ser: ERROR: cfg. parser: unexpected EOF in unclosed string
... and on the command line together with the whole ser.cfg content
ERROR: bad config file (1 errors)
I leave the ser.cfg unchanged because I want to try out the new installation first. After getting these error message I check other versions from CVS (v_0_8_13-dev-29, v_0_8_13dev-t16 ...) but the problem is the same as before. Compilation ist no problem. Which CVS version is the best for me to download? Many thanks for your help.
Regards,
Oliver
Bogdan-Andrei IANCU [mailto:iancu@fokus.fraunhofer.de] wrote
Hi Oliver,
First there is a small problem in your ser cfg. To enable CPL lookup
node you have to set the cpl param "lookup_domain" ( it missing was
reported at start up by "cpl_init: no lookup_domain given -> disable
lookup node").
Just add to you script the following line:
modparam("cpl-c","lookup_domain","location")
Second, there was a small error in lookup node reported by Richard. So,
please update you cpl-c module before retrying. Also, it will be more
easier for you to debug your CPL scripts by inserting some log nodes
to see the if lookup succeed of not, or if proxy was ok, etc.
Regards,
Bogdan
Brinker, Oliver wrote:
>Hi Bogdan,
>
>please find attached my ser.cfg and the CPL script for call forwarding
>on no answer. Could it be a failure in my SER configuration?
>
>Many thanks,
>Oliver
>
>-----------------------------------------------------------------------
>---------------------
>
>#
># $Id: ser.cfg,v 1.24 2003/11/11 15:32:36 andrei Exp $
>#
># simple quick-start config script
>#
>
># ----------- global configuration parameters ------------------------
>
>debug=9 # 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"
>
># Additional Aliases
>alias="t-systems.com"
>
># ------------------ 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/cpl-c.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)
>
># -- cpl-c module --
>modparam("cpl-c","cpl_db","mysql://ser:???@localhost/ser")
>modparam("cpl-c","cpl_table","cpl")
>modparam("cpl-c","cpl_dtd_file","/usr/local/etc/ser/cpl-06.dtd")
>modparam("cpl-c","log_dir","/var/log/ser/cpl")
>modparam("cpl-c","proxy_recurse",2)
>
># ------------------------- 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 >= max_len ) {
> 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()) {
> t_relay();
> break;
> };
>
> lookup("aliases");
> setflag(1);
>
> # 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("t-systems.com", "subscriber")) {
> www_challenge("t-systems.com", "0");
> break;
> };
>
> # handle REGISTER messages with CPL script
> cpl_process_register();
>
> save("location");
> break;
> };
>
> # process INVITE
> if (method=="INVITE") {
> # cpl interpreter requires a pre-created transaction for the processed INVITE
> if (!t_newtran()) {
> # it's a retransmission
> break;
> };
> if (!cpl_run_script("incoming")) {
> # script execution failed
> t_reply("500", "CPL script execution failed");
> };
>
> # we get here only if the CPL interpreter decided that server
> # should follow it default behavior
>
> # mark that there is already a created transaction for current INVITE
> setflag(3);
> };
>
> # native SIP destinations are handled using our USRLOC DB
> if (!lookup("location")) {
> sl_send_reply("404", "Not Found");
> break;
> };
> };
> # forward current uri now
> if (!isflagset(3)) {
> # build a new fresh transaction and forward
> if (!t_relay()) {
> sl_reply_error();
> };
> }
> else {
> # transaction exists -> do just forward
> if (!t_forward_nonack_uri()) {
> sl_reply_error();
> };
> };
>}
>
>-----------------------------------------------------------------------
>---------------------
>
><?xml version="1.0" encoding="UTF-8"?>
>
><!DOCTYPE cpl PUBLIC '-//IETF//DTD RFCxxxx CPL 1.0//EN' 'cpl.dtd'>
>
><cpl>
> <incoming>
> <lookup source="registration" clear="yes">
> <success>
> <proxy timeout="5">
> <noanswer>
> <location url="sip:613@t-systems.com" clear="yes">
> <proxy />
> </location>
> </noanswer>
> </proxy>
> </success>
> </lookup>
> </incoming>
>
>-----------------------------------------------------------------------
>---------------------
>
>
>Bogdan-Andrei IANCU wrote
>
>Hi Oliver,
>
>can you send me your CPL script - it will help me to understand your
>problem.
>
>Thanks,
>Bogdan
>
>Brinker, Oliver wrote:
>
>
>
>>Hi!
>>
>>I've successfully tested a handful CPL based services on SER 0.8.12
>>and
>>most of them are working correctly. Only call forward on busy and/or no
>>answer doesn't work. Enabling logging (debug=9) I get no error messages
>>in the log file, but a NOTICE message that no lookup domain is given
>>("cpl_init: no lookup_domain given -> disable lookup node"). It seems
>>to me that all services with blocking (i.e. call screening, time of day
>>screening) and direct redirection to another host (i.e. call forward
>>unconditional, time of day routing) are working correctly. When SER
>>first tries to reach a client before redirecting to another host (i.e.
>>call forward busy or no answer) it seems that the proxy server doesn't
>>returns to CPL script processing.
>>
>>Does anybody know a reason for this behaviour or has a correct working
>>CPL implementation for call forward on busy or no answer?
>>
>>many thanks,
>>Oliver
>>
>>_______________________________________________
>>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
>
>
>
Hi all,
I am having problem with call onhold on symmetric NAT softphone which have
affected the conferencing features. when I compare the sip-message, I
realise that the branch code is different and when they do a re-invite to
restablish the call, the m=audio XXXX port changes, please advice what can
be done. Does the branch affect?
If i didnt start rtpproxy, my call onhold works fine but when rtpproxy is
started, the call onhold is not working.I need the rtpproxy for symmetric
network. Please help....
my config file is below.
Regards,
shirley
> -----Original Message-----
> From: Shirley Toh
> Sent: Monday, June 07, 2004 9:00 PM
> To: Serusers (E-mail)
> Subject: RTPPROXY problem with cal forward and symmetric
>
> Hi all,
>
> I am having this problem with ./rtpproxu command.
> Before I start this command, my call forward and conference works fine
> with PC to PC and PC to PSTN but users behind symmetric NAT have no audio
> when connected.
> When I started the command, the scenario go the other way round, symmetric
> is working but my call forward and conference is not working. I have
> attached my cfg file.
>
> Please help and thank you in advance!!!
>
> 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 > max_len ) {
> sl_send_reply("513", "Message too big");
> break;
> };
>
>
> #!! Nathelper
> if (nat_uac_test("3")){
> if (method == "REGISTER" || !search("^Record-Route:")){
> log("LOG:Someone trying to register from private IP,
> rewriting\n");
> fix_nated_contact(); # Rewtite contact with source
> IP of signalling
> if(method== "INVITE"){
> fix_nated_sdp("1"); # Add direction-active
> to SDP
> };
> force_rport();
> setflag(6);
> };
> }else{
> fix_nated_contact();
> };
>
>
> # 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
> record_route();
> # loose-route processing
>
> if (loose_route()) {
> t_relay();
> 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") {
> save("location");
> break;
> };
> };
>
> if (uri=~"sip:019[0-9]+@myserver.com") {
> strip(1);
> rewritehostport("1.2.3.4:5060");
> t_relay();
> break;
> }
>
>
> if (method=="INVITE") {
> fix_nated_sdp("3");
> append_hf("P-hint:Invite");
> # native SIP destinations are handled using our USRLOC DB
> if (!lookup("location")) {
> sl_send_reply("", "Connecting");
> break;
> };
> };
>
> if (method=="ACK"){
> sl_send_reply("", "ACK");
> break;
> };
>
> if (isflagset(6)){
> force_rtp_proxy();
> append_hf("P-hint:Flag6");
> }else{
> force_rtp_proxy();
> t_on_reply("1");
> };
>
> # forward to current uri now; use stateful forwarding; that
> # works reliably even if we forward from TCP to UDP
> if (!t_relay()) {
> sl_reply_error();
> break;
> };
> }
>
> # all incoming replies for t_onrepli-ed transactions enter here
> onreply_route[1] {
> sdp_mangle_port("-12000");
> if (isflagset(6) && status=~"2[0-9][0-9]"){
> append_hf("First Route");
> fix_nated_contact();
> fix_nated_sdp("1");
> force_rtp_proxy();
> } else if (status=~"2[0-9][0-9]"){
> if (uri=~"sip:019[0-9]+@myserver.com") {
> append_hf("019");
> fix_nated_contact();
> fix_nated_sdp("3");
> }
> else{
> append_hf("2nd Route");
> fix_nated_contact();
> fix_nated_sdp("2");
> fix_nated_sdp("3");
> force_rtp_proxy();
> }
> };
> }
>
>
>
>
>
> Regards,
> Shirley
