[sr-dev] [tracker] Task opened: rtpproxy_manage with "l" option returns wrong ports

[sip-router]

THIS IS AN AUTOMATED MESSAGE, DO NOT REPLY.

A new Flyspray task has been opened.  Details are below. 

User who did this - Sebastian Damm (sdamm) 

Attached to Project - sip-router
Summary - rtpproxy_manage with "l" option returns wrong ports
Task Type - Bug Report
Category - Module
Status - Unconfirmed
Assigned To - 
Operating System - All
Severity - Medium
Priority - Normal
Reported Version - 4.1
Due in Version - Undecided
Due Date - Undecided
Details - When using the rtpproxy_manage (or rtpproxy_offer) function with the lookup option, it returns wrong ports.

Example:
When initializing a call, we use rtpproxy_manage without options, the same is for replies. We do this only if one of the phones is behind NAT.
INVITE -> rtpproxy_manage -> Port 40000
200 OK -> rtpproxy_manage -> Port 50000

Now, when a reINVITE comes in, we want to issue rtpproxy_manage with the lookup option. If we don't add the l option and we didn't force the call through the RTP proxy at call setup time, the media will still be forced through the RTP proxy after the reINVITE. And since we can't identify the NAT situation of both parties in all cases when getting a reINVITE, we can't issue rtpproxy_manage conditionally.

This is what happens:

reINVITE -> rtpproxy_manage(l) -> Port 50000
200 OK -> rtpproxy_manage -> Port 50000


If I check the control traffic to the RTP proxy, I can see the following:
INVITE: 
-> 20284_8 Uc8,101 1741c653ffce-tg2yumkozs63 192.168.1.5 53428 10wk7ltl70;1
<- 20284_8 40000 1.2.3.4
200 OK:
-> 20272_8 Lc8,101 1741c653ffce-tg2yumkozs63 10.0.0.5 20290 10wk7ltl70;1 as276b8fe2;1
<- 20272_8 50000 1.2.3.4
reINVITE:
-> 20270_8 Lc8,101 1741c653ffce-tg2yumkozs63 192.168.1.5 53428 10wk7ltl70;1 as276b8fe2;1
<- 20270_8 50000 1.2.3.4
200 OK:
-> 20285_8 Lc8,101 1741c653ffce-tg2yumkozs63 10.0.0.5 20290 10wk7ltl70;1 as276b8fe2;1
<- 20285_8 50000 1.2.3.4

As you can see, the call for the reINVITE and 200 OK are identical (except for the IP and port). What actually should happen is, that for the reINVITE the tags should be swapped, so the RTP proxy returns the correct port for the request.

More information can be found at the following URL:
http://sip-router.org/tracker/index.php?do=details&task_id=451

You are receiving this message because you have requested it from the Flyspray bugtracking system.  If you did not expect this message or don't want to receive mails in future, you can change your notification settings at the URL shown above.