[Serusers] FW: RTPPROXY problem with cal forward and symmetric

[Shirley Toh]

Hi all, 

I am having problem with call onhold on symmetric NAT softphone which have
affected the conferencing features. when I compare the sip-message, I
realise that the branch code is different and when they do a re-invite to
restablish the call, the m=audio XXXX port changes, please advice what can
be done. Does the branch affect? 
If i didnt start rtpproxy, my call onhold works fine but when rtpproxy is
started, the call onhold is not working.I need the rtpproxy for symmetric
network. Please help....
my config file is below.

Regards,
shirley

> -----Original Message-----
> From:	Shirley Toh 
> Sent:	Monday, June 07, 2004 9:00 PM
> To:	Serusers (E-mail)
> Subject:	RTPPROXY problem with cal forward and symmetric
> 
> Hi all, 
> 
> I am having this problem with ./rtpproxu command.
> Before I start this command, my call forward and conference works fine
> with PC to PC and PC to PSTN but users behind symmetric NAT have no audio
> when connected.
> When I started the command, the scenario go the other way round, symmetric
> is working but my call forward and conference is not working. I have
> attached my cfg file.
> 
> Please help and thank you in advance!!! 
> 
> 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
> 	if (nat_uac_test("3")){
> 		if (method == "REGISTER" || !search("^Record-Route:")){
> 			log("LOG:Someone trying to register from private IP,
> rewriting\n");
> 			fix_nated_contact(); # Rewtite contact with source
> IP of signalling
> 			if(method== "INVITE"){
> 				fix_nated_sdp("1"); # Add direction-active
> to SDP
> 			};
> 			force_rport();
> 			setflag(6);	
> 		};
> 	}else{
> 		fix_nated_contact();
> 	};
> 	
> 	
> 	# 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") {
> 			save("location");
> 			break;
> 		};
> 	};
> 
> 	if (uri=~"sip:019[0-9]+ at myserver.com") {
> 		  strip(1);
> 		  rewritehostport("1.2.3.4:5060");
> 		  t_relay();
> 		  break;
>         }
> 
> 
> 	if (method=="INVITE") {
> 		fix_nated_sdp("3");
> 		append_hf("P-hint:Invite");
> 		# native SIP destinations are handled using our USRLOC DB
> 		if (!lookup("location")) {
> 			sl_send_reply("", "Connecting");
> 			break;
> 		};
> 	};
> 	
> 	 if (method=="ACK"){
> 		sl_send_reply("", "ACK");
> 		break;
> 	 };
> 
> 	if (isflagset(6)){
> 		force_rtp_proxy();
> 		append_hf("P-hint:Flag6");
> 	}else{
> 		force_rtp_proxy();
> 		t_on_reply("1");
> 	};
> 
> 	# forward to current uri now; use stateful forwarding; that
> 	# works reliably even if we forward from TCP to UDP
> 	if (!t_relay()) {
> 		sl_reply_error();
> 		break;
> 	};
> }
> 
> # all incoming replies for t_onrepli-ed transactions enter here
> onreply_route[1] {
> 	sdp_mangle_port("-12000");
> 	 if (isflagset(6) && status=~"2[0-9][0-9]"){
> 		append_hf("First Route");	
> 		fix_nated_contact();
> 		fix_nated_sdp("1");
> 		force_rtp_proxy();
> 	 } else if (status=~"2[0-9][0-9]"){
> 		if (uri=~"sip:019[0-9]+ at myserver.com") {
> 		  append_hf("019");
> 		  fix_nated_contact();
> 		  fix_nated_sdp("3");
> 	        }
> 		else{
> 		  append_hf("2nd Route");         	 
>                           fix_nated_contact();
> 		  fix_nated_sdp("2");
> 		  fix_nated_sdp("3");
> 		  force_rtp_proxy();
> 		}
> 	 };
> }
> 
> 
> 
> 
> 
> Regards, 
> Shirley