2010/4/23 Klaus Darilion klaus.mailinglists@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.