[Serusers] ser + rtpproxy - call disconnected
Vitaly Nikolaev
vitaly at voipsonic.com
Mon Feb 28 18:21:33 CET 2005
IS your SIPUA support STUN if yes it can use it and get wrong information
and try to change IP/PORT to wrong values..
I do not know what is caputure, but you can get ngrep in SER distribution at
sip_router/utils/ngrep
When u will execute it use : ngrep -qW byline <exp>
To get "nice" output :-)
_____
From: support [mailto:support at cybertel.biz]
Sent: Sunday, February 27, 2005 9:25 PM
To: Vitaly Nikolaev; serusers at lists.iptel.org
Subject: Re: [Serusers] ser + rtpproxy - call disconnected
Hi,
In fact, my PSTN GW does not support STUN. If it support STUN, then I will
not use rtpproxy.
The following problem happens:
I try to use a fix IP for PSTN GW to register with SER, if I don't enable
rtpproxy, only ringing tones could be heard, but no voice passing through
it. Why does this happen?
Another question is that where could I download and install ngrep? If I use
a capture program to capture all packets, could I replace ngrep with it?
Thank you for the advice.
Best Regards,
Thomas
----- Original Message -----
From: Vitaly Nikolaev <mailto:vitaly at voipsonic.com>
To: 'support' <mailto:support at cybertel.biz> ; serusers at lists.iptel.org
Sent: Thursday, January 03, 2002 3:37 AM
Subject: RE: [Serusers] ser + rtpproxy - call disconnected
Even if half of all RTP packets get lost you will just have bad quality of
call.
In your case it very looks like you have problem with ACK
DO ngrep and see if PSTN GW receive ACK packet after OK (otherwise GW will
repeat OK few times and then disconnect call) if it is an issue just do
search in this list with keyword ACK
_____
From: serusers-bounces at iptel.org [mailto:serusers-bounces at lists.iptel.org] On
Behalf Of support
Sent: Saturday, February 26, 2005 12:24 AM
To: serusers at lists.iptel.org
Subject: [Serusers] ser + rtpproxy - call disconnected
Hi,
When I try to make a call using rtpproxy and ser-0.8.14 (SIP UA <---> PSTN),
most of the time the call will be disconnected within 1 minutes. Sometimes,
it will be so unstable that the call be disconnected after 15 seconds. The
above scenarios happens
Will this problem related to unstable rtpproxy? Because I know that all
packets will route through the server. once rtp packet get loss, the call
will be disconnected. Is this correct?
Perhaps it depends on my ser.cfg.
Thomas
My ser.cfg:
#
# $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)
check_via=no # (cmd. line: -v)
dns=no # (cmd. line: -r)
rev_dns=no # (cmd. line: -R)
listen=""
port=5060
children=4
fifo_mode=0666
fifo="/tmp/ser_fifo"
# ------------------ module loading ----------------------------------
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/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
# ----------------- setting module-specific parameters ---------------
# -- usrloc params --
# 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)
# -- Nathelper params --
modparam("registrar", "nat_flag", 6)
modparam("nathelper", "natping_interval", 30) # Ping interval
modparam("nathelper", "ping_nated_only", 1) # Ping only clients behind NAT
# ------------------------- request routing logic -------------------
# main routing logic
route{
# -----------------------------------------------
# Sanity Check Section
# -----------------------------------------------
# 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;
};
# -----------------------------------------------
# NOTIFY Keep-Alive Section
# -----------------------------------------------
if ((method=="NOTIFY") && search("^Event: keep-alive")) {
sl_send_reply("200","OK");
break;
};
# Nathelper
if (nat_uac_test("3")) {
# Allow RR-ed requests, as these may indicate that
# a NAT-enabled proxy takes care of it; unless it is
# a REGISTER
if (method == "REGISTER" || ! search("^Record-Route:")) {
fix_nated_contact(); # Rewrite contact with source IP of signalling
if (method == "INVITE") {
fix_nated_sdp("1"); # Add direction=active to SDP
};
force_rport(); # Add rport parameter to topmost Via
setflag(6); # Mark as NATed
};
};
# 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("", "subscriber")) {
www_challenge("", "0");
break;
};
save("location");
break;
};
# if the dialed number lies in the range 35891500-35891799, don't forward
it to T1 Trunk GW
if ((uri=~"^sip:(852|)358915[0-9][0-9]@") ||
(uri=~"^sip:(852|)358916[0-9][0-9]@") ||
(uri=~"^sip:(852|)358917[0-9][0-9]@")) {
if (uri=~"^sip:852*") {
strip(3);
};
};
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
# Call Routing Section
if (!lookup("location")) {
if (uri=~"^sip:(852|)[0-9]{8}@") {
# Send to PSTN Gateway
route(2);
break;
};
sl_send_reply("404", "User Not Found");
break;
};
};
append_hf("P-hint: usrloc applied\r\n");
route(1);
}
route[1]
{
# Nathelper
if (uri=~"[@:](192\.168\.|10\.|172\.(1[6-9]|2[0-9]|3[0-1])\.)" &&
!search("^Route:")){
sl_send_reply("479", "We don't forward to private IP addresses");
break;
};
# if client or server know to be behind a NAT, enable relay
if (isflagset(6)) {
force_rtp_proxy();
};
# NAT processing of replies; apply to all transactions (for example,
# re-INVITEs from public to private UA are hard to identify as
# NATed at the moment of request processing); look at replies
t_on_reply("1");
# send it out now; use stateful forwarding as it works reliably
# even for UDP2TCP
if (!t_relay()) {
sl_reply_error();
break;
};
}
# PSTN Call to T1 Trunk GW
route[2] {
rewritehostport("");
if (isflagset(6)) {
force_rtp_proxy();
};
t_on_reply("1");
if (!t_relay()) {
sl_reply_error();
break;
};
}
# !! Nathelper
onreply_route[1] {
# NATed transaction ?
if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
fix_nated_contact();
# Not all 2xx messages have a content body so here we make sure
# out Content-Length > 0 to avoid a parse error
if (!search("^Content-Length:\0")) {
force_rtp_proxy();
};
# otherwise, is it a transaction behind a NAT and we did not
# know at time of request processing ? (RFC1918 contacts)
} else if (nat_uac_test("1")) {
fix_nated_contact();
};
}
---------end of config -----------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20050228/ac01af0f/attachment.htm>
More information about the sr-users
mailing list