[SR-Users] B2BUA removing a=nortpproxy:yes (rtpproxy-1 <---RTP---> rtpproxy-2)

[Iñaki Baz Castillo]

2010/4/23 Klaus Darilion <klaus.mailinglists at pernau.at>:
>
>
> Am 23.04.2010 13:32, schrieb Juha Heinanen:
>>
>> Iñaki Baz Castillo writes:
>>
>>> I've not tested it again but expect there will be no RTP as each
>>
>>  >  RtpProxy will wait for RTP coming from the other. Am I right?
>>
>>  hopefully you are not right.  it must be possible to have a chain of
>>  rtproxys for the same session.  mediaproxy works ok in this kind of
>>  situation.  also, one mediaproxy relay can be controlled by several
>> dispatchers.
>
> It works as long either:
> - rtpproxy uses the same IP address as the SIP proxy (rtpproxy per default
> allows incoming RTP packets (latching) only from the IP from which the SIP
> message was received), or
>
> - call rtpproxy with 'r' flag for the messages received from the trusted
> proxies


Hi again, I have a doubt now. According to nathelper doc:

--------------------------------------------------------------------
  1.6.4.  force_rtp_proxy([flags [, ip_address]])

    -r   flags that IP address in SDP should be trusted. Without this
flag, nathelper
         ignores address in the SDP and uses source address of the SIP message
         as media address which is passed to the RTP proxy.
--------------------------------------------------------------------


Ok, let's assume that Kamailio receives an INVITE from a gateway from
IP 1.1.1.1, and the media address in the SDP is 1.1.1.2 (this is
because the gateways uses a different interface(s) for the RTP).

Then if I invoke "force_rtp_proxy()" with no arguments, then nathelper
will instruct RtpProxy proxy about media source address 1.1.1.1 (same
as SIP signalling), am I right? And then, as the RTP will come from
1.1.1.2 it should be ignored/rejected by RtpProxy server, right?
Theorically "-r" flag should be required for this case (so nathelper
would instruct RtpProxy to be ready to receive the RTP from 1.1.1.2).

But for sure this is not true as using "force_rtp_proxy()" with no
flags works in this scenario. This is because using
"force_rtp_proxy()" without flags would allow RTP from the both the
real address in the incoming SDP and the signalling IP, as the logs
show:

rtpproxy log:

  # INVITE arrives from gw:
  pre-filling caller's address with 1.1.1.1:SDP_ORIGINAL_PORT
  # 200 replied:
  caller's address filled in: 1.1.1.2:SDP_ORIGINAL_PORT (RTP)


So let's suppose Kamailio-1 (1.1.1.1) using RtpProxy-1 (9.9.9.1) and
Kamailio-2 (2.2.2.2) using RtpProxy-2 (9.9.9.2), and also a
transparent SIP proxy between them (Proxy-X with IP 5.5.5.5).

- Kamailio-1 receives an INVITE from a client and forces RtpProxy-1,
so the SDP address becomes 9.9.9.1:PORT.
- Kamailio-1 routes the INVITE to Proxy-X (5.5.5.5).
- Proxy-X routes the INVITE to Kamailio-2.
- Kamailio-2 invokes "force_rtp_proxy()" with no flags.

Then RtpProxy-2 would wait for incoming RTP from 5.5.5.5 (signalling
source address) or from 9.9.9.1:PORT (the address in the INVITE's
SDP).
Similar would occur with the 200 OK so RtpProxy-1 would wait for RTP
comming from 5.5.5.5 or 9.9.9.2:PORT (the address in 200's SDP).

Finally (correct me if I'm wrong)  RtpProxy-1 would forward the RTP
from its client to 9.9.9.2:PORT after some timeout as no RTP was
received from 5.5.5.5 or 9.9.9.2:PORT. Then RtpProxy-2 already knows
where to send its RTP (or the same timeout could occur with same
result as well).

So RtpProxy-1 could send RTP to RtpProxy-2 and vice versa.


Do I miss something? Thanks a lot.


-- 
Iñaki Baz Castillo
<ibc at aliax.net>