[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