Am 23.04.2010 13:32, schrieb Juha Heinanen: 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 regards klaus

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

2010/4/24 Iñaki Baz Castillo <ibc(a)aliax.net>et>: So yes, repeated the experiment with "-r" (if the request comes from a trusted node as 5.5.5.5) and I get bidirectional audio with the RTP passing throught both RtpProxy instances :) -- Iñaki Baz Castillo <ibc(a)aliax.net>

2010/4/24 Juha Heinanen <jh(a)tutpro.com>om>: If these rtpproxy use the same IP as the Kamailio's SIP signalling IP, then there is no problem and no need to use "-r" flag. But my case is more exotic as there is a transparent proxy between Kamailio-1 and Kamailio-2, each one with its own RtpProxy not listening in same IP as its Kamailio, and thre is also a transaparent SIP proxy between them which, for some reason, removes the line "a=nortpproxy". In this case both RtpProxy would handle the media and a deadlock would occur if flag "-r" is not used because after some timeout both RtpProxy would start relaying RTP to the IP of the transparent proxy (the prefilled address when not using "-r" flag). I've checked it. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2010/4/24 Juha Heinanen <jh(a)tutpro.com>om>: In such case, the first Kamailio's nathelper module would add a line "a=nortpproxy" and force RTP throught its RtpProxy-1. The INVITE arrives to Kamailio-2 with the SDP *untouched* (same as nathelper-1 set). Kamailio-2's nathelper would detect "a=nortpproxy" (hopefully) so it wouldn't force its RtpProxy-2. Ok, no problem. But in my case, there is a buggy transparent SIP proxy between Kamailio-1 and Kamailio-2, and it removes the "a=nortpproxy" (by leaving untouched the rest of the SDP). Then, since RtpProxies listen in a IP different than Kamailio, and since both use "force_rtp_proxy()" with no "-r" flag, a deadlock occurs: Both RtpProxies prefill the caller and callee media address as remote "KAMAILIO_IP:SDP_PORT" (since "-r" flag is not used) so after sometomeout without receiving RTP both will send RTP to the prefilled media address (error, of course). By using "-r" (in both or just one of the RtpProxies) it will work as such RtpProxy will prefill the remote media address with the SDP received media address (the IP from with the remote RtpProxy will sent RTP). My conclussion is that using "-r" flag is MUCH better than not using it. Why? Without "-r" flag: - RtpProxy prefills the remote address with SIP_RECEIVED_IP:SDP_PORT (which just makes sense in some corner cases). - If RtpProxy doesn't receive RTP in the port it publishes, it will forward its RTP to SIP_RECEIVED_IP:SDP_PORT. With "-r" flag: - RtpProxy prefills the remote address with SDP_IP:SDP_PORT. - If RtpProxy doesn't receive RTP in the port it publishes, it will forward its RTP to SDP_IP:SDP_PORT. In the case of two RtpProxy speaking between them, the second option (-r) is desired. If not, it will not work as described above. -- Iñaki Baz Castillo <ibc(a)aliax.net>

Iñaki, I would be curious to know what practical circumstances demand such a convoluted topology. -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 On Apr 24, 2010, at 5:48 AM, Iñaki Baz Castillo <ibc(a)aliax.net> wrote:

On 04/24/2010 09:01 AM, Iñaki Baz Castillo wrote: I read that, but was curious about the larger picture; why do you need the transparent proxy/B2BUA? -- Alex Balashov - Principal Evariste Systems LLC 1170 Peachtree Street 12th Floor, Suite 1200 Atlanta, GA 30309 Tel: +1-678-954-0670 Fax: +1-404-961-1892 Web: http://www.evaristesys.com/

Am 24.04.2010 15:47, schrieb Iñaki Baz Castillo: It depends. Most time rtpproxy is used you care about NAT traversal, not a broken B2BUA. Thus IMO the current default setting makes more sense. regards klaus

Am 26.04.2010 12:19, schrieb Iñaki Baz Castillo: But doesn't give you the default more security? I thought that "latching in" is only allowed from the prefilled IP address. regards klaus