[SR-Users] rtpproxy bridge "ie" "ei" behind NAT (like in aws EC2)

Giovanni Maruzzelli gmaruzz at gmail.com
Mon Feb 16 17:30:40 CET 2015


dear Kamailians,

I have Kamailio+rtpproxy in front of FreeSWITCH.

Kamailio and FreeSWITCH are on the same private network.
Public Internet IP address ports are redirected to Kamailio and
rtpproxy (same situation as in Amazon EC2).
Clients comes from Internet, and make calls to Internet, SIP signaling
passing through FreeSWITCH (eg: A leg incoming INVITE, FreeSWITCH
originate an outbound B leg INVITE, and then bridge the legs).

Using rtpproxy with -A "advertise" patch from Daniel, this topology
works fine in a "traditional" telco way: rtp goes from caller to
rtpproxy to callee, and viceversa.

Now I want to maintain FreeSWITCH in the middle of rtp flow all the
time, in a pure b2bua way, so it can control and analyze the media
streams.

So, I need rtpproxy to act paying attention to direction, as in
caller->rtpproxy->freeswitch->rtpproxy->callee (and viceversa).

Normally I would use Kamailio multihomed and rtpproxy in bridging
mode. But I cannot have a NIC on the public address.

How I can use the "ie" "ei" feature of rtpproxy in an Amazon-EC2 like
environment? (eg: no public address attached to machine, but ports
redirection from public address).

I read this trick from Hugh Waite:

"I have used rtpproxy (with the advertised address patch) in Amazon to
bridge media between internet facing and private subnets in a VPC.
I found that I couldn’t use different advertised addresses depending
on which direction the signalling was going on a single private IP
address. I worked around this by allocating a second private ip
address to the instance and used that in the ‘bridge’.
-A 54.86.X.X/10.0.1.15 –l 10.0.1.10/10.0.1.15"

Can you explain how to use this trick, or another way (without
additional addresses is gladly accepted!) to reach the same result
(rtp always passing through FreeSWITCH) ?

Thank you all in advance,

-giovanni

-- 
Sincerely,

Giovanni Maruzzelli
Cell : +39-347-2665618



More information about the sr-users mailing list