[Serusers] Cancel call Problem

Kapil Dhawan kdhawan at primus-direct.com
Tue Feb 10 02:18:06 CET 2004


thx alot...this is really called wastage of time.....let me try with cisco 
ata.....thx and bye

Regards

Dhawan K

---------- Original Message -----------
From: Maxim Sobolev <sobomax at portaone.com>
To: Mike <voipguy at spam.turbolink.net>
Cc: Serusers <serusers at lists.iptel.org>
Sent: Mon, 09 Feb 2004 21:57:04 +0200
Subject: Re: [Serusers] Cancel call Problem

> It is known problem with SPA-2000 - it violates RFC by inserting 
> different branch parameter into the CANCEL compared to the same 
> parameter in INVITE, which results in SER being unable to match CANCEL 
> to INVITE. We have notified Siura support staff about this and are 
> waiting for resolution.
> 
> -Maxim
> 
> Mike wrote:
> 
> > I see the exact same problem when making calls from a Sipura SPA-2000.
> > The problem does not occur when calling from a Cisco ATA-186.
> > 
> > I've tried comparing the cancel messages between the 2 devices, but only
> > found 1 difference.  The ATA makes the INVITE and the cancel with
> > user=phone appended, and the sipura does not.  I'm not sure why that would
> > make a difference, though, as long as the CANCEL matches the INVITE...
> > 
> > - Mike
> > 
> > On Mon, 9 Feb 2004, Klaus Darilion wrote:
> > 
> > 
> >>I can't see any problem in the config file. Which clients do you use?
> >>
> >>Put log(1,"...."); messages into your config and watch the logging
> >>messages in /var/log/messages during the CANCEL processing to find out
> >>where the CANCEL request is beeing lost.
> >>
> >>Klaus
> >>
> >>Kapil Dhawan wrote:
> >>
> >>>o its not happening...when first phone cancels the call....that CANCEL 
is not
> >>>forwarded to callee phone
> >>>
> >>>Regards
> >>>
> >>>Dhawan K
> >>>
> >>>---------- Original Message -----------
> >>>From: Klaus Darilion <klaus.mailinglists at pernau.at>
> >>>To: abhati <abhati at primus-direct.com>
> >>>Cc: serusers at lists.iptel.org
> >>>Sent: Mon, 09 Feb 2004 16:22:34 +0100
> >>>Subject: Re: [Serusers] Cancel call Problem
> >>>
> >>>
> >>>
> >>>>What do mean by "gets hanged"?
> >>>>Watch the SIP call flow using ethereal: Are the CANCEL requests that
> >>>>arive at the proxy forwarded to the other SIP phone?
> >>>>
> >>>>klaus
> >>>>
> >>>>abhati wrote:
> >>>>
> >>>>
> >>>>>Hi All
> >>>>>
> >>>>>My problem is...i have got two phones set 111 and 222. if i make call
> >>>
> >>>from
> >>>
> >>>
> >>>>>111 and don't pick up 222 and cancel the call, this all is fine. but my
> >>>
> >>>phone
> >>>
> >>>
> >>>>>gets hanged...both 111 and 222....what shud be done to properly handle
> >>>
> >>>cancel
> >>>
> >>>
> >>>>>requests.
> >>>>>
> >>>>>i am attaching my ser.cfg file.
> >>>>>
> >>>>>#
> >>>>># $Id: ser.cfg,v 1.21.4.1 2003/11/10 15:35:15 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
> >>>>>debug=7
> >>>>>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/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"
> >>>>>
> >>>>>loadmodule "/usr/local/lib/ser/modules/domain.so"
> >>>>>loadmodule "/usr/local/lib/ser/modules/call.so"
> >>>>>
> >>>>>modparam("domain", "db_url", "sql://root:root@localhost/ser")
> >>>>>modparam("domain", "db_mode", 1)   # Use chaching
> >>>>>modparam("domain", "domain_table", "domain")
> >>>>>modparam("domain", "domain_col", "domain")
> >>>>>
> >>>>>modparam("tm", "fr_inv_timer", 30 )
> >>>>>modparam("registrar", "default_expires", 60)
> >>>>># ----------------- 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 > 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
> >>>>>	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 (is_from_local()) {
> >>>>>
> >>>>>		if (method=="REGISTER") {
> >>>>>
> >>>>># Uncomment this if you want to use digest authentication
> >>>>>			if (!www_authorize("", "subscriber")) {
> >>>>>				www_challenge("", "0");
> >>>>>				break;
> >>>>>			};
> >>>>>			save("location");
> >>>>>			break;
> >>>>>		};
> >>>>>
> >>>>>		# native SIP destinations are handled using our USRLOC DB
> >>>>>
> >>>>>
> >>>>>		if (method=="INVITE") {
> >>>>>		if(call()){	//written one module for few things works fine
> >>>>>			if (!lookup("location")) {
> >>>>>			sl_send_reply("404", "Not Found");
> >>>>>			break;
> >>>>>		};
> >>>>>		};
> >>>>>		};
> >>>>>
> >>>>>	};
> >>>>>	# 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();
> >>>>>	};
> >>>>>}
> > 
> > 
> > _______________________________________________
> > Serusers mailing list
> > serusers at lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> > 
> > 
> >
> 
> _______________________________________________
> Serusers mailing list
> serusers at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
------- End of Original Message -------


.







Disclaimer
--------------------------------------------------------------------------
This email and any files transmitted with it are confidential
and intended solely for the use of the individual or entity 
to whom they are addressed. If you have received this email 
in error please notify the system manager. Recipients must 
check this email and any attachments for the presence of 
viruses before downloading them. Direct Internet / 
Primus India accepts no liability for any damage caused by
any virus transmitted by this email.





More information about the sr-users mailing list