9 Jan
2018
9 Jan
'18
3:26 p.m.
Hello,
On 05.01.18 12:33, Yu Boot wrote:
Thanks for an answer? but what I want to do (already
done :)) is
totally opposite to your solution.
The main thing I wanted, so I don't need to open 5060/UDP on
FreeSwitch for (entire world), BUT at the same time АЫ should work
with RTP traffic directly, no matter is it NATed UAC or not.
This kind of "NAT traversal" (call it RTP NAT traversal :)) and UAC
registrar are on Kami side. FS is pure softswitch here.
What I did to perform this is replace
rtpproxy_manage("co");
with
fix_nated_sdp("10");
Now it works exactly as I wanted. Thanks for advice.
this is not fixing anything from RTP point of view, or better said, it
is not something that is working alone with a symmetric nat. You rewrite
the SDP IP with source IP, but it should just work the same without
rewriting it. For a symmetric nat the media port advertised in SDP is
not going to match the allocated port for the rtp flow in the public
side of the nat router -- if it does, can be just a luck, which is not
going to work forever, especially if there are many sip clients behind
same nat router.
Anyhow, what I meant is to fix the SIP headers (not the SDP), so you do
SIP routing properly for requests within dialog. The port 5060/udp for
FreeSwitch should be open only for traffic from/to kamailio and doesn't
have anything to do with the SDP and RTP, nor eliminated if you do nat
fix for the headers...
Cheers,
Daniel
04.01.2018 12:42, Daniel-Constantin Mierla пишет:
--
Daniel-Constantin Mierla
www.twitter.com/miconda -- www.linkedin.com/in/miconda
Kamailio Advanced Training - March 5-7, 2018, Berlin - www.asipto.com
Kamailio World Conference - May 14-16, 2018 - www.kamailioworld.com
Hello,
On 25.12.17 10:16, Yu Boot wrote:
Hello. I want to implement the following scheme:
Kami takes inbound call, replces SPD for correct NAT trversal and
forward that call to FS. Kami should NOT be in RTP stream. Is it
possible? Any advices?
Kamailio should not touch the SDP if it is not going to do the RTP
relaying with rtpengine or rtpproxy. Just leave it untouch, freeswitch
will handle what is needed in this regard.
What you have to do is to fix the signaling for nat traversal, which may
mean to use path module for handling registrations as well as doing
set_contact_alias() as well as handle_ruri_alias(), so you can route
requests within dialog.
Cheers,
Daniel