Hey guys,
I have been battling with msilo, and the routing logic. It finally
looks like it might be beginning to get there, (ser actually restarts
now!) lol, but I have a problem when I try and send a message.
I am using the serweb utility to try and send to "sip:admin@<ip>" and it
reports "message accepted for delivery"... but I don't receive it.
Checking the log shows;
Jul 16 17:20:01 sip /usr/sbin/ser[20227]: MSILO: the downstream UA does
not support MESSAGE requests ...
Jul 16 17:20:01 sip /usr/sbin/ser[20227]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@161.30.94.68,
o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)127.0.0.1,
from=sip:admin@sip.dev.inmarsat.com;tag=533cb9e91f4b999cf76861cbb9ed54ed
-79e5, code=202
Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: udp_send:
sendto(sock,0xbd70f700,671,0,0xbd70e1dc,16): Invalid argument(22)
Jul 16 17:20:01 sip /usr/sbin/ser[20187]: CRITICAL: invalid
sendtoparameters one possible reason is the server is bound to localhost
and attempts to send to the net
Jul 16 17:20:01 sip /usr/sbin/ser[20187]: msg_send: ERROR: udp_send
failed
Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ERROR: t_forward_nonack:
sending request failed
Jul 16 17:20:01 sip /usr/sbin/ser[20187]: ACC: transaction answered:
method=MESSAGE, i-uri=sip:admin@161.30.94.68,
o-uri=sip:admin@81.86.136.86:5060, call_id=7971f97d-0(a)161.30.94.68,
from=sip:sip_registrar@161.30.94.68;tag=533cb9e91f4b999cf76861cbb9ed54ed
-8a85, code=477
Any ideas?
Many thanks again, and thanks for a brilliant list!
Dave
Ok, don't worry. After some chocolate cake I realized that the config
files had just been moved around slightly and $config->realm was no
longer set properly.
Sorry for the wasted post.
Very best regards
D
Hey guys,
Me again. Have been running serweb for a little while, and just realized
it was very outdated. I grabbed the latest version and now I cant log
in.
I have tried a number of things. Even going back and reinitializing the
complete database again (I only had a couple of test accounts). I have
reset all the permissions and so I can create/drop users with serctl and
everything is fine. My UAs can log in perfectly. However, I cannot log
into serweb. I always get bad username or password! Its completely
doing my head in. Any ideas!?
D
Ser 812, rebuilt on fedora from source for mysql4 and accounting support
Serweb from cvs. (1.4.6 I think)
-------------------------------------
Dave Bath
dave(a)fuuz.com
www.fuuz.com
07736 232085
NOTE: The information contained in this email is intended for the named
recipients only, it may be privileged and confidential. If you are not
the intended recipient, you must not copy distribute or take any action
in reliance upon it. No warranties or assurances are made in relation to
the safety and content of this email and any attachments. No liability
is accepted for any consequences arising from it
Hi All,
I'm having to work with another SIP UAS acting as a location server, and
I have ser as my 'frontend' so all clients talk to ser, and ser will
register and with the location server.
In my logs I see the warning:
Jul 15 14:26:31 frig /usr/local/sbin/ser[18931]: WARNING: upstream bug -
0-terminated packet
This happens when I t_relay my REGISTERS to the 3rd party location
server. The packets look fine to me. Any ideas?
Here follows a trace (from ngrep), the logs from syslog, and our ser
configuration. I'm aware that the location server is not challenging on
REGISTERS :)
Thanks!
-Jev
U xx.xx.xx.181:64683 -> xx.xx.xx.6:5060
REGISTER sip:frontendser.example.com SIP/2.0.
Via: SIP/2.0/UDP 192.168.123.92;branch=z9hG4bK0c95a85aa284e67a.
From: "Billy Pike"
<sip:88890000@frontendser.example.com>;tag=4c8855e01b806681.
To: <sip:88890000@frontendser.example.com>.
Contact: <sip:88890000@192.168.123.92>.
Call-ID: 0b3754db1b4dd80b(a)192.168.123.92.
CSeq: 100 REGISTER.
Expires: 3600.
User-Agent: Grandstream BT100 1.0.4.55.
Max-Forwards: 70.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
.
#
U xx.xx.xx.6:5060 -> xx.xx.xx.178:5060
REGISTER sip:location.example.com:5060 SIP/2.0.
Record-Route: <sip:xx.xx.xx.6;ftag=4c8855e01b806681;lr=on>.
Via: SIP/2.0/UDP xx.xx.xx.6;branch=z9hG4bK168.c89ec35.0.
Via: SIP/2.0/UDP
192.168.123.92;rport=64683;received=xx.xx.xx.181;branch=z9hG4bK0c95a85aa284e67a.
From: "Billy Pike"
<sip:88890000@frontendser.example.com>;tag=4c8855e01b806681.
To: <sip:88890000@frontendser.example.com>.
Contact: <sip:88890000@xx.xx.xx.181:64683>.
Call-ID: 0b3754db1b4dd80b(a)192.168.123.92.
CSeq: 100 REGISTER.
Expires: 3600.
User-Agent: Grandstream BT100 1.0.4.55.
Max-Forwards: 69.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
P-hint: fixed NAT contact for request.
.
#####
U xx.xx.xx.178:5060 -> xx.xx.xx.6:5060
SIP/2.0 200 OK.
Record-Route: <sip:xx.xx.xx.6;ftag=4c8855e01b806681;lr=on>.
Via: SIP/2.0/UDP xx.xx.xx.6;branch=z9hG4bK168.c89ec35.0.
Via: SIP/2.0/UDP
192.168.123.92;rport=64683;received=xx.xx.xx.181;branch=z9hG4bK0c95a85aa284e67a.
From: "Billy Pike"
<sip:88890000@frontendser.example.com>;tag=4c8855e01b806681.
To: <sip:88890000@frontendser.example.com>.
Contact: <sip:88890000@xx.xx.xx.181:64683>.
Call-ID: 0b3754db1b4dd80b(a)192.168.123.92.
CSeq: 100 REGISTER.
Expires: 3600.
User-agent: Grandstream BT100 1.0.4.55.
Max-Forwards: 68.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
P-hint: fixed NAT contact for request.
.
.
##
U xx.xx.xx.6:5060 -> xx.xx.xx.181:64683
SIP/2.0 200 OK.
Record-Route: <sip:xx.xx.xx.6;ftag=4c8855e01b806681;lr=on>.
Via: SIP/2.0/UDP
192.168.123.92;rport=64683;received=xx.xx.xx.181;branch=z9hG4bK0c95a85aa284e67a.
From: "Billy Pike"
<sip:88890000@frontendser.example.com>;tag=4c8855e01b806681.
To: <sip:88890000@frontendser.example.com>.
Contact: <sip:88890000@xx.xx.xx.181:64683>.
Call-ID: 0b3754db1b4dd80b(a)192.168.123.92.
CSeq: 100 REGISTER.
Expires: 3600.
User-agent: Grandstream BT100 1.0.4.55.
Max-Forwards: 68.
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE.
Content-Length: 0.
P-hint: fixed NAT contact for request.
.
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: ----------Entering
default route---------------
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: [REGISTER] from
[sip:88890000@frontendser.example.com] to
[sip:88890000@frontendser.example.com]
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: src address different
than via header->NAT detected
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: force_rport and
fix_nated_contact and setflag(5)
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: rewriting uri for
REGISTER request..
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: Called
rewritehostport(location.example.com,5060) on REGSITER request..
Jul 15 14:26:31 frig /usr/local/sbin/ser[18904]: Called t_relay() for
register..
Jul 15 14:26:31 frig /usr/local/sbin/ser[18931]: WARNING: upstream bug -
0-terminated packet
#
# $Id: ser_rtproxy_fe.cfg,v 1.3 2004/07/06 22:48:35 jev Exp $
#
# TODO
# Fix xlog statements to use appropriate logging levels.
#
# ----------- 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
debug=9
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"
sip_warning=yes
# ------------------ 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"
loadmodule "/usr/local/lib/ser/modules/domain.so"
loadmodule "/usr/local/lib/ser/modules/xlog.so"
loadmodule "/usr/local/lib/ser/modules/nathelper.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)
modparam("rr", "append_fromtag", 1)
modparam("registrar", "nat_flag", 6)
#modparam("nathelper", "natping_interval", 4) # Ping interval 30 s
modparam("nathelper", "natping_interval", 5) # Ping interval 30 s
# ------------------------- request routing logic -------------------
# main routing logic
route{
log(1, "----------Entering default route---------------\n");
xlog("L_ERR", "[%rm] from [%fu] to [%tu]");
if (nat_uac_test("2")) {
log(1, "src address different than via header->NAT detected\n");
log(1, "force_rport and fix_nated_contact and setflag(5)\n");
#try NAT traversal, works only if the client is symmetrical
force_rport();
fix_nated_contact();
#fix_nated_sdp();
append_hf("P-hint: fixed NAT contact for request\r\n");
# flag 5 indicates that incoming request is from NATed client
setflag(5);
};
# 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 (uri==myself) {
if (method=="REGISTER") {
log(1,"rewriting uri for REGISTER request..");
rewritehostport("location.example.com:5060");
if( isflagset(5) ){
force_rtp_proxy();
}
log(1,"Called rewritehostport(location.example.com,5060) on REGSITER
request..");
if(t_relay()){
log(1,"Called t_relay() for register..");
}
# if(!sl_send_reply("200", "ok")){
# log(1,"Got error when calling sl_send_reply(200, ok) on REGSITER
request..");
# }
t_on_reply("1");
break;
};
if (method=="INVITE" || method == "CANCEL") {
log(1,"rewriting uri for INVITE request..");
rewritehostport("location.example.com:5060");
log(1,"Called rewritehostport(location.example.com,5060) on INVITE
request..");
if(isflagset(5)){
force_rtp_proxy();
}
route(1);
#if(t_relay()){
# log(1,"Called t_relay() for register..");
# }
# if(!sl_send_reply("200", "ok")){
# log(1,"Got error when calling sl_send_reply(200, ok) on REGSITER
request..");
# }
t_on_reply("1");
break;
};
};
route(1);
}
route[1]{
log(1, "-------------------------------------------\n");
log(1, "entering route[1] - relaying SIP message\n");
if ((isflagset(5)) || (isflagset(6))) {
log(1, "at least one of the participants is NATed->record_route\n");
record_route();
log(1, " -->setting up reply processing ->onreply_route[1]");
t_on_reply("1");
if (method=="INVITE") {
log(1, "INVITE request-->force_rtp_proxy, set NATED-INVITE flag(7)");
force_rtp_proxy();
append_hf("P-hint: request forced to nathelper\r\n");
setflag(7);
};
};
log(1, "relaying message ...\n");
if (!t_relay()) {
log(1, "t_relay error occured\n");
sl_reply_error();
};
}
route[2]{
if ((isflagset(5)) || (isflagset(6))) {
log(1, "at least one of the participants is NATed->record_route\n");
record_route();
log(1, " -->setting up reply processing ->onreply_route[2]");
t_on_reply("1");
if (method=="INVITE") {
log(1, " INVITE request-->force_rtp_proxy, set NATED-INVITE
flag(7)");
force_rtp_proxy();
append_hf("P-hint: request forced to nathelper\r\n");
setflag(7);
};
};
xlog("L_ERR", "Forwarding %fu to %tu [Cisco]\n");
rewritehostport("xx.xx.xx.8:5060");
if(!t_relay()){
log(1, "Relay to Cisco failed");
break;
};
}
#all incoming replies for t_onrepli-ed transactions enter here
onreply_route[1] {
log(1, "-------------------------------------------\n");
log(1, "onreply_route[1] entered\n");
if (isflagset(5)) {
log(1, "transaction was sent to a NATED client -> fix nated contact\n");
fix_nated_contact();
force_rport();
force_rtp_proxy();
#fix_nated_sdp();
append_hf("P-hint: fixed NAT contact for response (nathelper)\r\n");
}
if ( (status=~"100") ) {
log(1, "status 100 received\n");
};
if ( (status=~"180") ) {
log(1, "status 180 received\n");
};
if ( (status=~"202") ) {
log(1, "status 202 received\n");
};
if ( (status=~"200" || status=~"183") ) {
log(1, "status 2xx or 183");
if ( isflagset(7) ) {
log(1, "marked(7) as NATED-INVITE -> force_rtp_proxy \n");
force_rtp_proxy();
append_hf("P-hint: response forced to nathelper\r\n");
};
};
}
onreply_route[2] {
log(1, "-------------------------------------------\n");
xlog("L_ERR", "onreply_route[2] entered From %fu to %tu\n");
if (isflagset(6)) {
log(1, "transaction was sent to a NATED client -> fix nated contact\n");
fix_nated_contact();
#fix_nated_sdp();
append_hf("P-hint: fixed NAT contact for response\r\n");
}
if ( (status=~"100") ) {
log(1, "status 100 received\n");
};
if ( (status=~"180") ) {
log(1, "status 180 received\n");
};
if ( (status=~"202") ) {
log(1, "status 202 received\n");
};
if ( (status=~"200" || status=~"183") ) {
log(1, "status 2xx or 183");
if ( isflagset(7) ) {
log(1, "marked(7) as NATED-INVITE -> force_rtp_proxy \n");
force_rtp_proxy();
append_hf("P-hint: response forced to nathelper\r\n");
};
};
}
Hi,
Is there a difference in authenticating a natted or non-nated UA
using www_authen? The reason i'm asking is because when my UA
is directly connected to the internet it authenticates fine but
when NATed I get the following error:
parse_headers: flags=4096
0(12877) pre_auth(): Credentials with given realm not found
0(12877) ---:: didn't authorize
0(12877) build_auth_hf(): 'WWW-Authenticate: Digest realm="ser.edpnet.net",
nonce="40f7be4edbd22e214821f2a3937968fc049ae290" '
0(12877) parse_headers: flags=-1
I used the natconfig from this site:
http://www.informatik.uni-bremen.de/~prelle/terena/cookbook/Cookbook_D2/ch04
s07.html
thanks,
Bart
Hello,
I have SER "listening" on two ports on the SAME IP
listen=IP
port=port_1
listen=IP
port=port_2
It seems that after UA:port_2 contact SER, SER uses SER:port_2 for all
responses.
And if UA:port_1, SER responds as
SER:port_1 <---> UA:port_1
Please advise how i can make SER to work with a FIXED source port.
For example, to make SER allways respond the request and tell the UA to sent
back to some FIXED port:
SER:fixed_port <---> UA:port_x
Thanks
Ri Liang
Try use it for INVITE, BYE and CANCEL as well.
On Jul 16, 2004, at 11:49 AM, Andrea Bondavalli wrote:
> No,
>
> I do that only in case of REGISTER .
>
> if (client_nat_test("3")) {
> if (method == "REGISTER" || ! search("Record-Route:")) {
> fix_contact();
> force_rport();
> }
> }
>
>
> Thank you,
> Andrea
>
> ----- Original Message -----
> From: "Adrian Georgescu" <ag(a)ag-projects.com>
> To: "Andrea Bondavalli" <a.bondavalli(a)inet.it>
> Cc: <serusers(a)lists.iptel.org>
> Sent: Friday, July 16, 2004 11:39 AM
> Subject: Re: [Serdev] NAT traversal of the BYE transaction
>
>
>> Do you have something like this into your configuration?
>>
>> if (client_nat_test("3")) {
>> force_rport();
>> fix_contact();
>> };
>>
>> On Jul 16, 2004, at 11:27 AM, Andrea Bondavalli wrote:
>>
>>> As you can see from the following traces the Via field
>>> (Via: SIP/2.0/UDP
>>> 192.168.0.10:5060;received=213.92.1.143;branch=z9hG4bK-fdee73bb)
>>> of the BYE sent by 213.92.1.178:5060 to 213.92.1.197:5060 doesn't
>>> report
>>> the port number of the incoming interface (rport=1029).
>>
>> The final result is that the answer (200 OK) is sent back to
>> the wrong port number (5060 instead of 1029).
Hi all,
I am experiencing a problem related to the NAT traversal of the BYE transaction.
Some of my UAs are natted and I am using a mediaproxy (SER + mediaproxy module)
between such UAs and my SIP proxy (registar/location) in order to overcome the NAT problem.
Everything is working fine, but the Via field of the BYE transaction
seems to forget about the port number of the interface from which
the BYE was received.
As you can see from the following traces the Via field
(Via: SIP/2.0/UDP 192.168.0.10:5060;received=213.92.1.143;branch=z9hG4bK-fdee73bb)
of the BYE sent by 213.92.1.178:5060 to 213.92.1.197:5060 doesn't report
the port number of the incoming interface (rport=1029).
The final result is that the answer (200 OK) is sent back to
the wrong port number (5060 instead of 1029).
U 213.92.1.143:1029 -> 213.92.1.178:5060
BYE sip:bonda@213.92.1.230 SIP/2.0
Via: SIP/2.0/UDP 192.168.0.10:5060;branch=z9hG4bK-fdee73bb
From: <sip:8001@inet.it>;tag=5d62d7eb80acc3c7
To: "Andrea Bondavalli" <sip:bonda@inet.it>;tag=5fae3692dc76fd5a
Call-ID: bcd4cb1e47de41e1(a)213.92.1.230
CSeq: 101 BYE
Max-Forwards: 70
Route: <sip:213.92.1.178;ftag=5fae3692dc76fd5a;lr>, <sip:213.92.1.197;ftag=5fae3692dc76fd5a;lr=on>
User-Agent: Sipura/SPA2000-2.0.9(d)
Content-Length: 0
#
U 213.92.1.178:5060 -> 213.92.1.197:5060
BYE sip:bonda@213.92.1.230 SIP/2.0
Record-Route: <sip:213.92.1.178;ftag=5d62d7eb80acc3c7;lr>
Via: SIP/2.0/UDP 213.92.1.178;branch=z9hG4bK51f1.91462923.0
Via: SIP/2.0/UDP 192.168.0.10:5060;received=213.92.1.143;branch=z9hG4bK-fdee73bb
From: <sip:8001@inet.it>;tag=5d62d7eb80acc3c7
To: "Andrea Bondavalli" <sip:bonda@inet.it>;tag=5fae3692dc76fd5a
Call-ID: bcd4cb1e47de41e1(a)213.92.1.230
CSeq: 101 BYE
Max-Forwards: 69
Route: <sip:213.92.1.197;ftag=5fae3692dc76fd5a;lr=on>
User-Agent: Sipura/SPA2000-2.0.9(d)
Content-Length: 0
P-hint: mediaproxy
#
U 213.92.1.197:5060 -> 213.92.1.178:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 213.92.1.178;branch=z9hG4bK51f1.91462923.0
Via: SIP/2.0/UDP 192.168.0.10:5060;received=213.92.1.143;branch=z9hG4bK-fdee73bb
Record-Route: <sip:213.92.1.197;ftag=5d62d7eb80acc3c7;lr=on>
Record-Route: <sip:213.92.1.178;ftag=5d62d7eb80acc3c7;lr>
From: <sip:8001@inet.it>;tag=5d62d7eb80acc3c7
To: "Andrea Bondavalli" <sip:bonda@inet.it>;tag=5fae3692dc76fd5a
Call-ID: bcd4cb1e47de41e1(a)213.92.1.230
CSeq: 101 BYE
User-Agent: Grandstream BT100 1.0.5.6
Contact: <sip:bonda@213.92.1.230>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0
#
U 213.92.1.178:5060 -> 213.92.1.143:5060
SIP/2.0 200 OK
Via: SIP/2.0/UDP 192.168.0.10:5060;received=213.92.1.143;branch=z9hG4bK-fdee73bb
Record-Route: <sip:213.92.1.197;ftag=5d62d7eb80acc3c7;lr=on>
Record-Route: <sip:213.92.1.178;ftag=5d62d7eb80acc3c7;lr>
From:<sip:8001@inet.it>;tag=5d62d7eb80acc3c7
To: "Andrea Bondavalli" <sip:bonda@inet.it>;tag=5fae3692dc76fd5a
Call-ID: bcd4cb1e47de41e1@213.92.1.230..CSeq: 101 BYE
User-Agent: Grandstream BT100 1.0.5.6
Contact: <sip:bonda@213.92.1.230>
Allow: INVITE,ACK,CANCEL,BYE,NOTIFY,REFER,OPTIONS,INFO,SUBSCRIBE
Content-Length: 0
Can you help me on this issue ?
Please consider that I am using the latest SER code from CVS
(for all the proxy server on the network).
Thank you a lot in advance,
Andrea Bondavalli
I.NET S.p.A. - Research & Development
mailto:a.bondavalli@inet.it
Hi
I am trying to use SER to replace the traditional PBX
system. Is it possible to transfer a call to another
phone after accepting it? And is there some way one
could have "personalised" forwarding preferences. So
if 3000 is busy/offline, call is forwarded
automatically to some number user at 3000 wants?
Thanks
__________________________________
Do you Yahoo!?
Yahoo! Mail is new and improved - Check it out!
http://promotions.yahoo.com/new_mail
Hi,
How do I use nathelper or mediaproxy with cpl scripts?
Once it goes to cpl, it stops going through the rest
of the script.
Thanks,
Richard
__________________________________
Do you Yahoo!?
Yahoo! Mail Address AutoComplete - You start. We finish.
http://promotions.yahoo.com/new_mail