[Serusers] SER 0.9.6 with H.264 Problem!

[Steven Wong]

Hello Greger:
   
  You are really the man. I have tried your suggestion, to put the two Video Phones to the public IP network with the same IP segment of the SER server and the two Video Phones works perfectly. So, officially, it works with non-NAted. As you stated, this is typically a NAT problem.
   
  As stated, I am really new with SER, RTPProxy and Nathelper. I had included my ser.cfg below. Could you please have a look to see if there is any thing wrong with it (if you have time and if it's possible)? Once again many thanks for your precious help. 
   
  To all SER Users:
   
  If you have time, please have a look at the below ser.cfg and let us know if there is anything wrong with it? It's basically can handles video and audio non-NAted. But can only handle audio with NAted.
   
  Your help is greatly appreciated.
   
  Best regards,
   
  Steven Wong

"Greger V. Teigre" <greger at teigre.com> wrote:
  You don't say if this is a NAT problem or not. 
I would start with devices non-NATed (to sort out rtpproxy issues).
I think rtpproxy got video support a while back, but I haven't tested it. 
If it works with non-NAted, you may want to review your NAT handling based on the Getting Started guide.
g-)


Steven Wong wrote:     Hello All:
   
  You will find enclosed our ser.cfg file that I have adapted from a very generous SIP user from the Internet.
   
This ser.cfg file work perfectly with Audio (IP Phone and Softphone). But when I am trying to use a Video Phone (we did try with GrandStream GXV-3000 Video Phone), it just giving us Audio but NOT Video. I did also try the same GrandStream GXV-3000 Video Phone with FreeWorldDialup and it is working fine with Video.
   
  We have checked the etherreal output while trying to make a call and we are having this type of errors on the etherreal:
   
  -----
    RTP Protocol
  Source IP (The IP of the Video Phone) and Destination IP (The IP of the SER Server) ------&shy; Payload Type = Unknown (126)
   
  ICMP Protocol
  Source IP (The IP of the SER Server) and Destination IP (The IP of the Video Phone) ------&shy;Destination Unreachable (Port Unreacheable)
   
  These 2 errors repeated six time before it stop with a good signal of:
   
  Payload Type = ITU-T G.711 PCMU
   
  Then the audio start but without audio.
---
  
Would you please tell us what is going wrong with this ser.cfg file? your answer is greatly appreciated.
   
Many thanks,
   
Steven Wong

   
  --------------------------------------------------------------------------
  debug=3
fork=yes
log_stderror=no
  check_via=no
dns=no
rev_dns=no
  listen=XXX.XXX.XXX.XXX           # INSERT YOUR IP ADDRESS HERE
# port=5060
children=3
  alias="HOST.DOMAINNAME.COM"
alias="XXX.XXX.XXX.XXX"
  fifo="/tmp/ser_fifo"
fifo_db_url="mysql://ser:PASSWORD@localhost/ser"
  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/auth.so"
loadmodule "/usr/local/lib/ser/modules/auth_db.so"
loadmodule "/usr/local/lib/ser/modules/uri.so"
loadmodule "/usr/local/lib/ser/modules/uri_db.so"
loadmodule "/usr/local/lib/ser/modules/nathelper.so"
loadmodule "/usr/local/lib/ser/modules/textops.so"
loadmodule "/usr/local/lib/ser/modules/acc.so"
  modparam("auth_db|uri_db|usrloc", "db_url", "mysql://ser:PASSWORD@localhost/ser")
modparam("auth_db", "calculate_ha1", 1)
modparam("auth_db", "password_column", "password")
  modparam("nathelper", "natping_interval", 30) 
modparam("nathelper", "ping_nated_only", 1)   
modparam("nathelper", "rtpproxy_sock", "unix:/var/run/rtpproxy.sock")
  modparam("usrloc", "db_mode", 2)
  modparam("registrar", "nat_flag", 6)
  modparam("rr", "enable_full_lr", 1)
#---Accounting params
modparam("acc", "log_level", 1)
modparam("acc", "log_flag", 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;
 };
        # !! Nathelper
 # Special handling for NATed clients; first, NAT test is
 # executed: it looks for via!=received and RFC1918 addresses
 # in Contact (may fail if line-folding is used); also,
 # the received test should, if completed, should check all
 # vias for rpesence of received
 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:")) {
      log("LOG: Someone trying to register from private IP, rewriting\n");
        # This will work only for user agents that support symmetric
      # communication. We tested quite many of them and majority is
      # smart enough to be symmetric. In some phones it takes a configuration
      # option. With Cisco 7960, it is called NAT_Enable=Yes, with kphone it is
      # called "symmetric media" and "symmetric signalling".
        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;
 };
   setflag(1);
 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("HOST.DOMAINNAME.COM", "subscriber")) {
    www_challenge("HOST.DOMAINNAME.COM", "0");
    break;
   };
     save("location");
   break;
  };
    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
  if (!lookup("location")) {
   sl_send_reply("404", "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();
 };
}
  # !! Nathelper
onreply_route[1] {
    # NATed transaction ?
    if (isflagset(6) && status =~ "(183)|2[0-9][0-9]") {
        fix_nated_contact();
 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();
    };
}
--------------------------------------------------------------------------
  
  
---------------------------------
  The fish are biting.
Get more visitors on your site using Yahoo! Search Marketing. 

---------------------------------
  _______________________________________________  Serusers mailing list  Serusers at lists.iptel.org  http://lists.iptel.org/mailman/listinfo/serusers    


 
---------------------------------
Any questions?  Get answers on any topic at Yahoo! Answers. Try it now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20070223/1b8a7fed/attachment.htm>