[Serusers] ser-rtpproxy bridge mode and T38

Atif Rasheed atif at burraqtel.com.pk
Thu Oct 27 09:39:56 CEST 2005


okey, I got your point that it was difficult to understand. but please
tell me know if you understood this setup now or should I elaborate
little more.
As far as ReInvites are concerned I think they are handled properly.
Please go through the attached ethereal trace, You will see SIP
signalling is properly handled. ser.cfg is also attached with the email

MG(10.0.3.13)------->(10.0.2.14)SSW------->10.0.2.99(ser/rtpproxy)80.255.40.70

ser/rtpproxy machine is with two i.e. private and public interfaces.

> >> > I have read in RtpProxy that RtpProxy waits for both parties to send
> >> > atleast one udp packet and then it fills up both ip:port structures
> >> > associated with that call and then it starts relaying.
> >>
> >> Yes, this is to ensure that the proxy can get through the NATs.
> >>
> >> > Call Setup is like this:
> >> >                --------Media----->
> >> > A-Party ----->MG-------->SSW------>SER/RtpProxy------->B-Party
> >> >
> >> > now only B-Party is sending UDP Packets and Ser/RtpProxy sends them to
> >> > SSW (signalling entity) instead of MediaGateway. As soon as RtpProxy
> >> > receives one udp packet from A-Party then it sends those RTP packets to
> >> > MG i.e. it starts relaying following the right path.
> >> > how I can solve this ???
> >>
> >> I'm afraid I'm not capable of understanding what you are saying here. 
> >> You
> >> have SSW in the media path? Or are you trying to show both media and
> >> signalling path in the same picture? What is really the priblem? rtpproxy
> >> will only do what you tell it to (using force_rtp_proxy).
> >
> > I am trying to show media and signalling path in the same picture.
> 
> I'm sure you understand that it is difficult for others to understand?
> 
> > Is this confirm that RtpProxy will handle T38 or we also need to handle
> > T38 in a special way. because as I described below paragraph that after
> > reinvite B-Party stopped RTP and started T38 packets in the same session
> > but RtpProxy failed to send to the right recepient.
> 
> It's not T38 that needs special handling, but as I said, the reINVITE.
> g-)
> >>
> >> > Adding to this, now after RTP relay starts successfully. B-Party (if
> >> > Dialed number is a FAX) reinvites with T38 and the IP:Port info in SDP
> >> > remains same. Now somehow RtpProxy is not recognizing the T38 packets
> >> > becuase we are in the same session and RtpProxy start sending those
> >> > T38 packets to SSW (signalling entity) instead of sending to MG. Please
> >> > remember we are in the same session, and RtpProxy shud send these T38
> >> > packets to MG, as it was sending RTP packets before ReInvite.
> >> >
> >> > is it a bug in RTPProxy, should I use MediaProxy instead ???
> >>
> >> You need to handle reINVITEs in a special way. Look at the Getting 
> >> Started
> >> scripts (and document) from onsip.org for how to do it both for rtpproxy 
> >> and
> >> mediaproxy.
> >>
> >> g-)
> >>
> >>
> > 
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sip-t38-rtp-fax2710-1
Type: application/octet-stream
Size: 327062 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20051027/42929ef1/attachment.obj>
-------------- next part --------------
#
# $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)

# Uncomment these lines to enter debugging mode 
debug=3
fork=yes
log_stderror=yes
reply_to_via=1
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"
mhomed=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/nathelper.so"
loadmodule "/usr/local/lib/ser/modules/mangler.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)

#modparam("nathelper", "rtpproxy_sock", "udp:192.168.5.1")

# -- rr params --
# add value to ;lr param to make some broken UAs happy
modparam("rr", "enable_full_lr", 1)
#modparam("rr", "enable_double_rr", 1)

# -------------------------  request routing logic -------------------

# main routing logic

route{

	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;
	};

	#record_route();	
	#record_route_strict();	
	if (loose_route()) {
		t_relay();
	};	

	if (uri==myself) {

		if (uri=~"^sip:\+1973.*@") {
			log(1,"ATIF_LOG: Forwarding to External network\n");
			rewritehostport("66.33.147.150:5110");
			log(1,"ATIF_LOG: Host and User Part Rewritten\n");
                        setflag(6);     # Mark as NATed
                        route(2);
                        break;
                }																												
	};
	
	if(method=="INVITE") {
	       	setflag(6);
                route(1);
                break;
        }

	if (!t_relay()) {
		sl_reply_error();
        };
	break;

}
route[1]
{
       if (isflagset(6)) {
	       log(1,"ATIF_LOG: forcing rtp proxy\n");
	       force_rtp_proxy("","10.0.2.99");
	       t_on_reply("1");
	       log(1,"ATIF_LOG: rtp proxy forced\n");
       };

       if (!t_relay()) {
	       sl_reply_error();
       };
       log(1,"ATIF_LOG: Exiting route[1]\n");
}

route[2]
{
       if (isflagset(6)) {
	       force_rtp_proxy("","80.255.40.70");
	       t_on_reply("2");
	       log(1,"ATIF_LOG: rtp proxy forced\n");
       };

       if (!t_relay()) {
	       sl_reply_error();
       };
       log(1,"ATIF_LOG: Exiting route[2]\n");
}

onreply_route[1] {
	if (status =~ "[12][0-9][0-9]") {
	        if (!(search("^Content-Length:\ 0"))) {
	                force_rtp_proxy("","80.255.40.70");
	                log(1,"ATIF_LOG: onreply_route->force_rtp_proxy called\n");
	        };
		t_on_reply("1");
	        log(1,"ATIF_LOG: Exiting onreply_route[1]\n");
        };
}						

onreply_route[2] {
	if (status =~ "[12][0-9][0-9]") {
	        if (!(search("^Content-Length:\ 0"))) {
	                force_rtp_proxy("","10.0.2.99");
	                log(1,"ATIF_LOG: onreply_route->force_rtp_proxy called\n");
	        };
		t_on_reply("2");
	        log(1,"ATIF_LOG: Exiting onreply_route[2]\n");
        };
}						


More information about the sr-users mailing list