Bläddra i källkod

Changed order of max_fwd and len_gt checks -- otherwise an
"INVITE sip:[email protected] SIP/2.0" will cause "message too bug"
even for a short message.

Jiri Kuthan 23 år sedan
förälder
incheckning
8c68c0db9f
1 ändrade filer med 71 tillägg och 31 borttagningar
  1. 71 31
      etc/iptel.cfg

+ 71 - 31
etc/iptel.cfg

@@ -107,11 +107,6 @@ route{
 	# filter local stateless ACK generated by authentication of mf replies
 	sl_filter_ACK();
 
-	if (len_gt( max_len )) {
-		sl_send_reply("513", "Riesengross -- Message too large");
-		break;
-	};
-
 	# filter too old messages
 	log("LOG: Checking maxfwd\n");
 	if (!mf_process_maxfwd_header("10")) {
@@ -120,6 +115,22 @@ route{
 		break;
 	};
 
+	if (len_gt( max_len )) {
+		sl_send_reply("513", "Riesengross -- Message too large");
+		break;
+	};
+
+
+	/* IM gateways */
+	if (uri=~"sip:.*@icq\.iptel\.org") {
+		forward( 195.37.77.100, 5080 );
+		break;
+	};
+	if (uri=~"sip:.*@msn\.iptel\.org") {
+		forward( 195.37.77.100, 5080 );
+		break;
+	};
+
 	# -------------------- testing accounts ----------------
 #XX
 	if (uri=~"sip:333.*@iptel\.org") {
@@ -213,7 +224,7 @@ route{
 	#   messaging session model)
 	# - some other places may decide to set the record-routing
 	#   flag (2 chosen) too; particularly, INVITEs to our gw
-	if ( (src_ip==195.37.77.110 & method=="INVITE") || method=="MESSAGE")  {
+	if ( (src_ip==195.37.77.110 & method=="INVITE") || method=="MESSAGE" || method=="INFO" )  {
 		setflag(2);
 	};
 
@@ -241,7 +252,7 @@ route{
 #XX
 #	lookup_contact("aliases");
 	if (uri=~"sip:9040@") {
-		seturi("sip:mitel@iptel.org");
+		seturi("sip:jirih@iptel.org");
 	};
 	if (uri=~"sip:9042@") {
 		seturi("sip:[email protected]");
@@ -313,23 +324,43 @@ route{
 
 	# ---------- CPL demo - begin --------------
 	/* added by Bogdan for cpl demo - Dorgham request*/
-	if (uri=~"sip:test@.*" & method=="INVITE")
+	if (uri=~"sip:test@.*")
 	{
-		log("SER : runing CPL!! :)\n");
-		if ( !cpl_run_script() )
+		if (method=="INVITE")
 		{
-   			log("SER : Error during running CPL script!\n");
-		}else{
-   			if ( cpl_is_response_reject() ) {
-				log("SER: reject");
-       			sl_send_reply("603","I am not available!");
-       			break;
-   			}else if ( cpl_is_response_redirect() ) {
-       			log("SER : redirect\n");
-       			cpl_update_contact();
-       			sl_send_reply("302","Moved temporarily");
-       			break;
-   			};
+			if (! t_newtran()) {
+    			# retransmit whatever we have
+    			t_retransmit_reply();
+			} else {
+    			# do what you want to do
+				if ( cpl_run_script() ) {
+                	if ( cpl_is_response_reject() ) {
+                    	log("SER: reject");
+                    	sl_send_reply("603","I am not available!");
+                    	break;
+                	}else if ( cpl_is_response_redirect() ) {
+                    	log("SER : redirect\n");
+                    	cpl_update_contact();
+                    	sl_send_reply("302","Moved temporarily");
+                    	break;
+                	};
+	    		} else {
+        			if (!t_send_reply("500", "error :-(")) {
+            			# if replying failed, retry statelessly
+            			sl_reply_error();
+        			};
+    			};
+    			# transaction concluded -- junk it now
+    			t_release();
+			};
+			t_unref();
+			break;
+		};
+		if (method=="MESSAGE")
+		{
+			seturi("sip:[email protected]");
+			t_relay_to("bat.iptel.org","5070");
+			break;
 		};
 	};
 	# -------------- CPL demo - end -------------
@@ -390,6 +421,9 @@ route{
 #---------------------------------------------------------------------
 
 # routing logic for outbound requests targeted out of our domain
+# (beware, messages to our users can end up here too: for example,
+#  an INVITE may be UsrLoc-ed, then the other party uses outbound
+#  proxy with r-uri=the usr_loced addredd (typically IP))
 route[2] {
 		# outbound requests are allowed only for our users -- we don't
 		# support relaying and don't like strangers bothering us
@@ -410,13 +444,19 @@ route[2] {
 				break;
 			};
 		};
-		# to maintain credibility of our proxy, we check From to be
-		# equal of credential id -- all outbound request leaving our
-		# proxy are guaranteed to be generated by persons in "From";
-		# except gateway, which is not digest-capable
-		if (!(method=="ACK" | method=="CANCEL" | src_ip==195.37.77.110) & !check_from()) {
+		# to maintain credibility of our proxy, we check From in INVITEs to be
+		# equal to credential id  so that user john.doe does not put bill.gates
+		# in his From; we don't do that for other requests: within a dialogue,
+		# subsequent transactions coming from the other side will have in From
+		# To of the original transaction to match the dialog; it may be 
+		# however different from user's default From and digest; example:
+		# user_a sends INVITE to secretary; secretary is translated to user_b;
+		# user_b accepts and later BYEs; to match the dialog, it puts
+		# secretary in From and sends user_b's credentials -- check_from
+		# would fail
+		if (!src_ip==195.37.77.110 & method=="INVITE" & !check_from()) {
 			log("LOG: From Cheating attempt\n");
-			sl_send_reply("403", "That is ugly -- use From=id next time");
+			sl_send_reply("403", "That is ugly -- use From=id next time (OB)");
 			break;
 		};
 #XX
@@ -463,9 +503,9 @@ route[3] {
 				proxy_challenge( "iptel.org" /* realm */, "0" /* no qop */ );
 				break;
 			# let's check from=id ... avoids accounting confusion
-			} else if (!check_from()) {
+			} else if (method=="INVITE" & !check_from()) {
 				log("LOG: From Cheating attempt\n");
-				sl_send_reply("403", "That is ugly -- use From=id next time");
+				sl_send_reply("403", "That is ugly -- use From=id next time (gw)");
 				break;
 			};
 		};
@@ -531,7 +571,7 @@ route[3] {
 		if (uri=~"sip:001" ) {
 			strip(2);
 			prefix("49");
-		} else if (uri=~"sip:+491") {
+		} else if (uri=~"sip:\+491") {
 			strip(1);
 		} else if (uri=~"sip:000491") {
 			strip(3);