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;
}
_______________________________________________
Devel mailing list
[email protected]
http://openser.org/cgi-bin/mailman/listinfo/devel
