[Devel] [ openser-Bugs-1723492 ] Incorect behaviour of swap flag
for rtpproxy
SourceForge.net
noreply at sourceforge.net
Wed May 23 17:11:49 CEST 2007
Bugs item #1723492, was opened at 2007-05-22 17:04
Message generated for change (Settings changed) made by bogdan_iancu
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: Closed
Resolution: Fixed
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: Bogdan (bogdan_iancu)
Date: 2007-05-23 17:35
Message:
Logged In: YES
user_id=1275325
Originator: NO
Hi Ovidiu,
I applied the patch with one change - I think if both "l" (lookup) and "s"
(swap) flags are present, no swap between the tags is required - both flags
implies swapping, so they cancel one each other. I couldn't test this, but
this seams logical to me. If you could test, it's super.
Thanks and regards,
Bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2007-05-22 23:30
Message:
Logged In: YES
user_id=1395524
Originator: YES
Hi Bogdan,
We are on the same track now. I must admit that I spent quite some time
debugging this issue :-)
As I mentioned previously, the lookup method does a similar trick.
Also ... I was looking for a solution that will not involve rtpproxy
changes ...
----------------------------------------------------------------------
Comment By: Bogdan (bogdan_iancu)
Date: 2007-05-22 23:13
Message:
Logged In: YES
user_id=1275325
Originator: NO
OK- I see a point here.
Let's take an example:
1. from caller - INVITE from_tag=X
2. from callee - 200 OK from_tag=X, to_tag=Y => create session on RTPP
(tag=X) returns A1
3. from caller - ACK from_tag=X, to_tag=Y => confirm session on RTPP
returns A2
4. from caller - re-INVITE from_tag=X => create session with tag=X -
already exists, returns add A1
BUT here A2 should be returned!
So, the mixing it's not at tag level, but at address level and indeed, it
looks it can be fixed by playing with the tags...I will look deeper into
it, tomorrow, with a fresh mind;)
bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2007-05-22 21:17
Message:
Logged In: YES
user_id=1395524
Originator: YES
In "swap" mode, the "create" command will use the 183/200 response. By
this time, both the to and from tags are available (we have a dialog in
early state for 183 or confirmed state for 200) and therefore we can safely
swap them (as in the proposed patch).
And as you mentioned, the to_tag and from_tag will match the direction and
that's the reason for swapping the to/from tags.
In my case, both INVITE and reINVITE are having the same direction, but it
shouldn't matter (rtpproxy is able to figure out the direction, assuming
that create comes from an INVITE, otherwise, the nathelper plays the swap
trick - see the lookup mode with create == 0)
----------------------------------------------------------------------
Comment By: Bogdan (bogdan_iancu)
Date: 2007-05-22 20:33
Message:
Logged In: YES
user_id=1275325
Originator: NO
>From RTPproxy point of view, you have the "create" and "update" commands.
"Create" takes as param the from_tag (the only available at that time).
Diregarding the "s" flag, the "create" will carry the from_tag. The
"Update" command will add the to_tag (from reply or ACK), again
disregarding the "s" flag.
When the re-Invite comes, its from_tag will be compared with the from_tag
and to_tag known by rtpproxy in order to see the direction. What is the
direction of your re-INVITE? CAn you get send (privatly?) a dump for the
SIP trace and the openser=rtpproxy communication?
Regards,
Bogdan
----------------------------------------------------------------------
Comment By: Ovidiu Sas (osas)
Date: 2007-05-22 18: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 18: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 18: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 17: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
More information about the Devel
mailing list