[Devel] Improving force_rtp_proxy

[Bogdan-Andrei Iancu]

Hi Marc,

you are right...I made a superficial evaluation of the problem :(.

as an implementation alternative, we can use the flags to be able to 
create session for replies and to confirm it for requests (ACKs).
    http://openser.org/docs/modules/1.1.x/nathelper.html#AEN267

there are 2 options:
1) use a single flag called "revert" or "swap"
    -> force_rtp_proxy("s");
2) use 2 flags - create and confirm - in this case you will have full 
liberty to decide when to
    create and when to confirm the session
    -> force_rtp_proxy("C");  # create the session
    -> force_rtp_proxy("c");  # confirm the session

this flags will override the default behaviour:
    request -> create
    reply -> confirm.

regards,
bogdan

Marc Haisenko wrote:

>On Tuesday 21 February 2006 19:24, Bogdan-Andrei Iancu wrote:
>  
>
>>Hi Marc,
>>
>>indeed, the code limits the force_rtp_proxy() usage to INVITEs when
>>comes to requests. There are 2 solutions here:
>>    1) remove the method limitation - anyhow you decide from script for
>>what request you call or not the function
>>    2) along with INVITE, add ACK.
>>
>>my personal option is 1) .
>>
>>In both cases, the change is trivial :).
>>
>>regards,
>>bogdan
>>    
>>
>
>Hmmm, it doesn't seem to be /that/ trivial. The problem is that I need to 
>decide what to do on an "OK": I have no idea whether the corresponding INVITE 
>had SDP or not. So my current solution is to handle the OK as always, but 
>when the RTP proxy communication result shows that no entry is present I 
>rerun the whole force_rtp_proxy2_f function where I set an additional 
>argument so the "OK" gets handled like an "INVITE" (I renamed the original 
>force_rtp_proxy2_f and put a wrapper in its place). ACKs are handled like 
>INVITES... but it just occurs to me that they should be handled like OKs 
>instead.
>
>I hope you understand what I mean :-)
>
>Now what I don't like in this approach is that one additional RTP proxy 
>message exchange occurs... but it /seems/ like it works and the code changes 
>are trivial. I've attached my patch so you can actually see what I mean, but 
>I hope you have an idea to solve this problem in a more elegant way :-)
>
>  
>
>------------------------------------------------------------------------
>
>diff -ur sip-server.orig/modules/nathelper/nathelper.c sip-server/modules/nathelper/nathelper.c
>--- sip-server.orig/modules/nathelper/nathelper.c	2005-06-16 14:41:52.000000000 +0200
>+++ sip-server/modules/nathelper/nathelper.c	2006-02-21 14:47:02.000000000 +0100
>@@ -1599,8 +1599,17 @@
> }
> 
> static int
>+force_rtp_proxy2_f_real(struct sip_msg* msg, char* str1, char* str2, int inverted);
>+
>+static int
> force_rtp_proxy2_f(struct sip_msg* msg, char* str1, char* str2)
> {
>+	return force_rtp_proxy2_f_real(msg, str1, str2, 0);
>+}
>+
>+static int
>+force_rtp_proxy2_f_real(struct sip_msg* msg, char* str1, char* str2, int inverted)
>+{
> 	str body, body1, oldport, oldip, newport, newip;
> 	str callid, from_tag, to_tag, tmp;
> 	int create, port, len, asymmetric, flookup, argc, proxied, real;
>@@ -1677,10 +1686,11 @@
> 	}
> 
> 	if (msg->first_line.type == SIP_REQUEST &&
>-	    msg->first_line.u.request.method_value == METHOD_INVITE) {
>-		create = 1;
>+	    (msg->first_line.u.request.method_value == METHOD_INVITE ||
>+	     msg->first_line.u.request.method_value == METHOD_ACK)) {
>+		create = 1 - inverted;
> 	} else if (msg->first_line.type == SIP_REPLY) {
>-		create = 0;
>+		create = inverted;
> 	} else {
> 		return -1;
> 	}
>@@ -1853,6 +1863,10 @@
> 			}
> 			port = atoi(argv[0]);
> 			if (port <= 0 || port > 65535) {
>+				if ((port == 0) && (inverted == 0) && (msg->first_line.type == SIP_REPLY)) {
>+					LOG(L_ERR, "force_rtp_proxy2: retrying inverted\n");
>+					return force_rtp_proxy2_f_real(msg, str1, str2, 1);
>+				}
> 				LOG(L_ERR, "force_rtp_proxy2: incorrect port in reply from rtp proxy\n");
> 				return -1;
> 			}
>  
>