[Devel] [ openser-Bugs-1723492 ] Incorect behaviour of swap flag for rtpproxy

[SourceForge.net]

Bugs item #1723492, was opened at 2007-05-22 10:04
Message generated for change (Comment added) made by osas
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1723492&group_id=139143

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: modules
Group: ver 1.2.x
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Ovidiu Sas (osas)
Assigned to: Bogdan (bogdan_iancu)
Summary: Incorect behaviour of swap flag for rtpproxy

Initial Comment:
The swap 's' flag of force_rtp_proxy() from nathelper module should swap the tp/from tags just like the lookup 'l' flag does.

The following patch will fix the problem:

# diff -Naurp nathelper.c nathelper.c.new
--- nathelper.c	2007-05-22 09:58:27.000000000 -0400
+++ nathelper.c.new	2007-05-22 09:58:19.000000000 -0400
@@ -1864,6 +1869,13 @@ force_rtp_proxy2_f(struct sip_msg* msg, 
 		from_tag = to_tag;
 		to_tag = tmp;
 	}
+	if (swap != 0) {
+		if (flookup == 0) {
+			tmp = from_tag;
+			from_tag = to_tag;
+			to_tag = tmp;
+		}
+	}
 	proxied = 0;
 	if (nortpproxy_str.len) {
 		for ( cp=body.s ; (len=body.s+body.len-cp) >= nortpproxy_str.len ; ) {


----------------------------------------------------------------------

>Comment By: Ovidiu Sas (osas)
Date: 2007-05-22 11:58

Message:
Logged In: YES 
user_id=1395524
Originator: YES

Hi Bogdan,

Here's my setup: first transaction, SDP offer/answer in 200ok/ACK and the
force_rtp_proxy is invoked with proper sei/sie flags.  Then I have a
reINVITE with SDP offer/answer in INVITE/200ok and the force_rtp_proxy is
invoked with proper ei/ie flags.  The issue is that rtpproxy stores
internally some information about the caller/callee (should be read
offerer/answerer) and that's why we need to swap the to/from tag.

The lookup method is doing a similar thing.

----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-05-22 11:47

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Ovidiu,

the "s" flag swaps between "create" and "update" - you shouls use the flag
for all the rtpproxy calls across the same transactions. If you create the
session in swap mode, it means you created it for a reply. So, for ACK you
also need to use the "s" flag to trigger "update", otherwise it will be
also "create". This is all what the "s" flag does.

What interface should be selected (in bridge mode), can be controlled via
the "e" and "i" flags...

rtpproxy uses the tags in order to see from what direction the request
came. and "s" flag do not affect this at all, as with or without it, the
tags order (from and to) will be the same).

----------------------------------------------------------------------

Comment By: Ovidiu Sas (osas)
Date: 2007-05-22 11:11

Message:
Logged In: YES 
user_id=1395524
Originator: YES

The problem is exposed when the rtpproxy is run in bridge mode.  If an rtp
session is created in swap mode, and then updated in a non swap mode,
rtpproxy will reply with the wrong (the other interface) IP/port.
I spent quite some time debugging this issue and I tested ok the proposed
solution.

Hope this clarify the need for to/from tag swap.

----------------------------------------------------------------------

Comment By: Bogdan (bogdan_iancu)
Date: 2007-05-22 10:40

Message:
Logged In: YES 
user_id=1275325
Originator: NO

Hi Ovidiu,

why needs the from and to tag to be swapped? The "swap" flag is used to
swap between the create/lookup modes. By default you have create for
requests and lookup for replies, but if you have SDP negotiation via 200OK
and ACK, you must have create for reply and lookup for request (ACK).
>From and to do not swap in reply...
I fail to see why think is necesary to do that...maybe if you post more
details...

regards,
bogdan

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=743020&aid=1723492&group_id=139143