Jan,
I set debug=9 and log_stderr=yes. Log is attached. I don't see any clues to
what is wrong.
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Friday, June 27, 2003 12:58 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Hello,
set debug=9 and log_stderr=yes and restart ser and it should tell you
what's wrong.
Jan.
On 27-06 12:54, Wasik, Paul wrote:
> Jan,
>
> My SER SIP server works fine with the default config script. As soon as I
> add some simple static routing such as:
>
> if (uri=~"^sip:9[0-9]*@rtcsol.local) {
> forward( 159.63.73.165, 5060 );
>
> to the script and restart ser, my log looks like the attached. There is a
> ser process running but it is not normal and no network SIP ports ie 5060
> are opened.
>
> The command line returns:
>
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser stop
> Stopping ser: [ OK ]
> [root@FFDCTSERSIP ser]#
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser start
> Starting ser: Terminated
> [root@FFDCTSERSIP ser]#
> [root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser status
> ser (pid 7309) is running...
> [root@FFDCTSERSIP ser]#
>
> I'm running the 0.8.11pre29 for test bed only on a Red Hat 9 system. What
> could I be doing wrong?
>
> Paul
>
> -----Original Message-----
> From: Jan Janak [mailto:jan@iptel.org]
> Sent: Thursday, June 26, 2003 2:02 PM
> To: Wasik, Paul
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Need Routing Help
>
>
> Edit your configuration file and set log_stderror to yes. By default the
> server uses syslog to do the output so you will find it in
> /var/log/messages or /var/log/daemon (depending on your distribution).
> If you set the variable then ser will output all messages to the
> standard output.
>
> Jan.
>
> On 26-06 14:01, Wasik, Paul wrote:
> > Jan,
> >
> > I don't see any error output on the command line. Is there a log file
> > somewhere? All I see is "Terminated" when attempting to start SER.
> >
> > Paul
> >
> > -----Original Message-----
> > From: Jan Janak [mailto:jan@iptel.org]
> > Sent: Thursday, June 26, 2003 1:58 PM
> > To: Wasik, Paul
> > Cc: serusers(a)lists.iptel.org
> > Subject: Re: [Serusers] Need Routing Help
> >
> >
> > Hello,
> >
> > and what is the problem ? If your ser doesn't start anymore then your
> > configuration file contains some mistake. In that case the output of ser
> > tells you on what line the mistake is, for example:
> >
> > 0(6704) parse error (75,36-37): syntax error
> > 0(6704) parse error (75,36-37): invalid route statement
> > 0(6704) parse error (75,38-39):
> > ERROR: bad config file (3 errors)
> >
> > means that there is an error on line 75 of the configuration file.
> >
> > Jan.
> >
> >
> > On 26-06 13:53, Wasik, Paul wrote:
> > > Hi all,
> > >
> > > I've got SER running on a Red Hat 9 platform. I've got MySQL and
serweb
> > > working and using the default ser.cfg file I can register UAs and make
> > local
> > > calls within the proxy. What I have not been able to do is get routing
/
> > > dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to
run
> > > once I add any routing information to the ser.cfg script. I tried
> > following
> > > the examples like the following from the "How to" guide:
> > >
> > > # attempt handoff to PSTN
> > > if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the
caller
> is
> >
> > > log("Forwarding to PSTN\n"); ## registered in our realm
> > > t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> > > break;
> > > };
> > > Anyone have any ser.cfg script files that work succesfully for simple
> dial
> > > plan / routing to a SIP gatewat they could share? I'm having a hard
time
> > > with the routing.
> > > Thanks,
> > > Paul
> > >
> > >
> > > _______________________________________________
> > > Serusers mailing list
> > > serusers(a)lists.iptel.org
> > > http://lists.iptel.org/mailman/listinfo/serusers
>
> Jun 27 12:42:16 FFDCTSERSIP ser: ser shutdown succeeded
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 14) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc5b0 frag. 0x80bc598 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 30) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc5f0 frag. 0x80bc5d8 (size=32) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/mysql.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc640 frag. 0x80bc628 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 27) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc680 frag. 0x80bc668 (size=28) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/rr.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc6cc frag. 0x80bc6b4 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc70c frag. 0x80bc6f4 (size=32) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/maxfwd.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc75c frag. 0x80bc744 (size=16) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 34) called
from cfg.lex: addstr(404)
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 36) returns
address 0x80bc79c frag. 0x80bc784 (size=36) o
> n 1 -th hit
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/registrar.so
> Jun 27 12:42:22 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc7f0 frag. 0x80bc7d8 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc830 frag. 0x80bc818 (size=28) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/uri.so
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc87c frag. 0x80bc864 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 31) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bc8bc frag. 0x80bc8a4 (size=32) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) loading module
/usr/lib/ser/modules/usrloc.so
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) called
from sr_module.c: register_module(135)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 16) returns
address 0x80bc90c frag. 0x80bc8f4 (size=16) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 7) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) returns
address 0x80bc94c frag. 0x80bc934 (size=8) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 8) returns
address 0x80bc984 frag. 0x80bc96c (size=8) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 9) called
from modparam.c: set_mod_param_regex(85)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 12) returns
address 0x80bc9bc frag. 0x80bc9a4 (size=12) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: usrloc
matches module usrloc
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) set_mod_param_regex: found
<db_mode> in module usrloc [/usr/lib/ser/modules/us
> rloc.so]
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free(0x80b5f60, 0x80bc9bc),
called from modparam.c: set_mod_param_regex(143
> )
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_free: freeing frag. 0x80bc9a4
alloc'ed from modparam.c: set_mod_param_regex
> (85)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 25) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 28) returns
address 0x80bc9f8 frag. 0x80bc9e0 (size=28) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 3) called
from cfg.lex: addstr(404)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 4) returns
address 0x80bc9bc frag. 0x80bc9a4 (size=12) on
> 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) find_export: found
<mf_process_maxfwd_header> in module maxfwd_module [/usr/li
> b/ser/modules/maxfwd.so]
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) called
from route_struct.c: mk_action(87)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 32) returns
address 0x80bca44 frag. 0x80bca2c (size=32) o
> n 1 -th hit
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256) qm_malloc(0x80b5f60, 20) called
from route_struct.c: mk_elem(68)
> Jun 27 12:42:23 FFDCTSERSIP ser: 0(7256)
> [root@FFDCTSERSIP ser]#
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
Jan,
My SER SIP server works fine with the default config script. As soon as I
add some simple static routing such as:
if (uri=~"^sip:9[0-9]*@rtcsol.local) {
forward( 159.63.73.165, 5060 );
to the script and restart ser, my log looks like the attached. There is a
ser process running but it is not normal and no network SIP ports ie 5060
are opened.
The command line returns:
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser stop
Stopping ser: [ OK ]
[root@FFDCTSERSIP ser]#
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser start
Starting ser: Terminated
[root@FFDCTSERSIP ser]#
[root@FFDCTSERSIP ser]# /etc/rc.d/init.d/ser status
ser (pid 7309) is running...
[root@FFDCTSERSIP ser]#
I'm running the 0.8.11pre29 for test bed only on a Red Hat 9 system. What
could I be doing wrong?
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Thursday, June 26, 2003 2:02 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Edit your configuration file and set log_stderror to yes. By default the
server uses syslog to do the output so you will find it in
/var/log/messages or /var/log/daemon (depending on your distribution).
If you set the variable then ser will output all messages to the
standard output.
Jan.
On 26-06 14:01, Wasik, Paul wrote:
> Jan,
>
> I don't see any error output on the command line. Is there a log file
> somewhere? All I see is "Terminated" when attempting to start SER.
>
> Paul
>
> -----Original Message-----
> From: Jan Janak [mailto:jan@iptel.org]
> Sent: Thursday, June 26, 2003 1:58 PM
> To: Wasik, Paul
> Cc: serusers(a)lists.iptel.org
> Subject: Re: [Serusers] Need Routing Help
>
>
> Hello,
>
> and what is the problem ? If your ser doesn't start anymore then your
> configuration file contains some mistake. In that case the output of ser
> tells you on what line the mistake is, for example:
>
> 0(6704) parse error (75,36-37): syntax error
> 0(6704) parse error (75,36-37): invalid route statement
> 0(6704) parse error (75,38-39):
> ERROR: bad config file (3 errors)
>
> means that there is an error on line 75 of the configuration file.
>
> Jan.
>
>
> On 26-06 13:53, Wasik, Paul wrote:
> > Hi all,
> >
> > I've got SER running on a Red Hat 9 platform. I've got MySQL and serweb
> > working and using the default ser.cfg file I can register UAs and make
> local
> > calls within the proxy. What I have not been able to do is get routing /
> > dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to run
> > once I add any routing information to the ser.cfg script. I tried
> following
> > the examples like the following from the "How to" guide:
> >
> > # attempt handoff to PSTN
> > if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the caller
is
>
> > log("Forwarding to PSTN\n"); ## registered in our realm
> > t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> > break;
> > };
> > Anyone have any ser.cfg script files that work succesfully for simple
dial
> > plan / routing to a SIP gatewat they could share? I'm having a hard time
> > with the routing.
> > Thanks,
> > Paul
> >
> >
> > _______________________________________________
> > Serusers mailing list
> > serusers(a)lists.iptel.org
> > http://lists.iptel.org/mailman/listinfo/serusers
> -----Original Message-----
> From: Alexander Mayrhofer [mailto:axelm@nic.at]
> Sent: Friday, June 27, 2003 6:15 PM
> To: serusers(a)lists.iptel.org
> Subject: [Serusers] rewrite & ACK forwarding problem
> ...
>
> SIP call flow looks like (record route enabled):
>
Is it applicable for you to disable record route? Then, the ACK will be
sent directly to the GW.
Klaus
I am testing Nathelper module. It works well delivering SIP messages.
However, natping-interval function seems malfunction.
The NAT scenario is simulated by a microsoft ICS. There is a Cisco ATA
behind NAT with internal address 192.168.0.2 and it's mapped to external
address 192.17.1.22. Ser is listening on external address 192.17.1.173. I
added "modparam("nathelper", "natping-interval", 5) " to the nathelper.cfg
file.
When ATA registered to Ser, I noticed 192.168.0.2:5056(UDP) is mapped to
192.17.1.22:1025(UDP). Register is successful and call could be established
between internal ATA and external ATA(one way audio). It's expected that
Ser should send a UDP packet to 192.17.1.22:1025(UDP) every 5 seconds.
However, the UDP packet is actually sent to 192.17.1.22:260(UDP). I wonder
what's the problem?
ATA-------------------->NAT------------------------>Ser
From:192.168.0.2:5060 From:192.17.1.22:1025
To: 192.17.1.173:5060 To: 192.17.1.173:5060
ATA NAT<-------------------------Ser
From: 192.17.1.173:5060
To: 192.17.1.22:260
ATA NAT-------------------------->Ser
Destination Unreachable
When does SER perform DNS lookups? Is it a matter of how the entry is
made in the ser.cfg? I ask because one of our customers changed their
DNS servers and the SER proxy was not updated. In the ser.cfg all
routing is done by IP (or I had thought it was). However, the site
started experiencing some very odd call drops and after updating the
resolv.conf on the proxy server with the proper DNS servers (one of them
had changed) everything was fine.
Should IP address entries be quoted or non-quoted? Does the presence of
the quotes cause a DNS lookup even though the item in them is purely
numeric (i.e. "162.128.33.54"). Is there a way to avoid the DNS
lookups?
--
Jamin W. Collins
Linux is not The Answer. Yes is the answer. Linux is The Question. - Neo
I am trying to get SER 0.8.10 working with a VegaStream Vega 100 VoIP gateway and the SER appears to be ignoring the 200 OK message from the Vega signaling that the call has been answered on the PSTN side.
I saw a ticket to this effect in the bugs area, but the patch for that did not help.
Attached is an NGREP log from the SER machine and a SIP LOG from the VegaStream units point of view.
Everything looks good from both points of view, but there should be an Ack sent back to the Vega right after the first 200 message. The rest of the 200 messages are retrying in case the first message got lost.
Any ideas?
_______________________________________________
Sean Robertson
NETXUSA
p. 800-289-6389
f. 864-233-4344 "Ask me about Voice over IP."
http://www.netxusa.com/
I've got a couple situations I'd like to log.
One is this:
if(!(uri==myself))
{
log(1, "domain not mine $uri");
};
In the above example, I'd like to see the uri in
the log file. Another example:
if (!is_user_in("credentials","local"))
{
log(1,"NO local calls permitted for $uri");
rewriteuri("sip:addaline.com-EN_US-error.not_authorized@64.90.42.15");
t_relay();
break;
};
In this example I'd like to see who actually tried to make
a non-authorized call. Is there an printf() like log, and if
there is what variables do I have access to for printing?
---greg
Jan,
I don't see any error output on the command line. Is there a log file
somewhere? All I see is "Terminated" when attempting to start SER.
Paul
-----Original Message-----
From: Jan Janak [mailto:jan@iptel.org]
Sent: Thursday, June 26, 2003 1:58 PM
To: Wasik, Paul
Cc: serusers(a)lists.iptel.org
Subject: Re: [Serusers] Need Routing Help
Hello,
and what is the problem ? If your ser doesn't start anymore then your
configuration file contains some mistake. In that case the output of ser
tells you on what line the mistake is, for example:
0(6704) parse error (75,36-37): syntax error
0(6704) parse error (75,36-37): invalid route statement
0(6704) parse error (75,38-39):
ERROR: bad config file (3 errors)
means that there is an error on line 75 of the configuration file.
Jan.
On 26-06 13:53, Wasik, Paul wrote:
> Hi all,
>
> I've got SER running on a Red Hat 9 platform. I've got MySQL and serweb
> working and using the default ser.cfg file I can register UAs and make
local
> calls within the proxy. What I have not been able to do is get routing /
> dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to run
> once I add any routing information to the ser.cfg script. I tried
following
> the examples like the following from the "How to" guide:
>
> # attempt handoff to PSTN
> if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the caller is
> log("Forwarding to PSTN\n"); ## registered in our realm
> t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
> break;
> };
> Anyone have any ser.cfg script files that work succesfully for simple dial
> plan / routing to a SIP gatewat they could share? I'm having a hard time
> with the routing.
> Thanks,
> Paul
>
>
> _______________________________________________
> Serusers mailing list
> serusers(a)lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serusers
Hi all,
I've got SER running on a Red Hat 9 platform. I've got MySQL and serweb
working and using the default ser.cfg file I can register UAs and make local
calls within the proxy. What I have not been able to do is get routing /
dial plan stuff to work via a Cisco SIP gateway. I cannot get SER to run
once I add any routing information to the ser.cfg script. I tried following
the examples like the following from the "How to" guide:
# attempt handoff to PSTN
if (uri=~"^sip:9[0-9]*@mydomain.com") { ## This assumes that the caller is
log("Forwarding to PSTN\n"); ## registered in our realm
t_relay_to( "192.168.0.2", "5060"); ## Our Cisco router
break;
};
Anyone have any ser.cfg script files that work succesfully for simple dial
plan / routing to a SIP gatewat they could share? I'm having a hard time
with the routing.
Thanks,
Paul
I am trying to understand how tm module works.
I found in http://www.iptel.org/ser/doc/prerelease/x545.html--->Stateful
User Agent Server:
______________________________________________
t_newtran shields subsequent code from retransmissions. It returns success
and continues when a new request arrived. It exits current route block
immediately on receipt of a retransmissions.
-----------------------------------------------
I found in the README included in tm module:
_______________________________________________
Name: t_newtran
Params: 0
Desc: creates a new transaction, returns a negative value on
error; this is the only way a script can add a new transaction
in an atomic way; typically, it is used to deploy a UAS
-----------------------------------------------
I think the two explanations above are inconsistent. I am quite confused.
Take the scripts below for example:
_______________________________
if ( !t_newtran()) {
sl_reply_error();
break;
};
# the following log will be only printed on receipt of
# a new message; retranmissions are absorbed by t_newtran
log(1, "New Transaction Arrived\n");
if (uri=~"a@") {
if (!t_reply("409", "Bizzar Error")) {
sl_reply_error();
};
} else {
if (!t_reply("699", "I don't want to chat with you")) {
sl_reply_error();
};
};
-------------------------------
My understanding is: If t_newtran() returns successfully, the scripts will
not execute forward until a new message rather than retransmission of the
original message is received. Am I right? If wrong, how does it work
actually?
Thanks!
Younger Wang
