2010/4/23 Klaus Darilion <klaus.mailinglists(a)pernau.at>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(a)aliax.net>