Emmanuel, Thank you for your message. Please see my comments in-line below.
Emmanuel BUU wrote: > Hello everybody, > > I would like to submit two enhancement proposal for the RTPproxy software: > > 1/ automatic bridging handling > > RTP proxy can be run in bridged mode. With the -l IP1/IP2 option, it > can mediate between two unrelated networks (e.g. a private network and > the public Internet) by running on a host with two network interfaces on > each ot them. In that case, the SIP proxy that controls rtp proxy > need to determine whether the packet is coming from the internal network > or the external network then send a the proper command to the RTP proxy > through the protocol. > > I propose to enhance rtp proxy so that this network routing is done > inside the rtpproxy software itself: > > The idea would be to describe the internal network (IP / mask, bind > address) in the RTP proxy configuration. When a "create session" or > "update session" command would arrive, the the IP address and port > present in the command frame would be compared against the internal > network definition. The proxy would then able to know if the SIP packet > comes from the internal network or the external network. The proxy would > then open the UDP socket on the correct bind address and send it to the > correct network interface. > > We would keep the 'E' and 'I' mode for backward compatibility if 'E' and > 'I' would not be specified, this automated selection would occur. > > Ultimately, the configuration of RTP proxy could be automated by > scanbing the IP routing tables of the host. This feature is already supported in our private development tree (IPv4 only for now) and it will be released soon. It would require matching changes on the part of SER/Kamalio/OpenSIPS/B2BUA as well as IPv6 support, which what holds it at the moment. > 2/ External NAT handling > > I would also to handle the case where RTP proxy is behind a NAT (one to > one NAT). If the communication is on the internal network then the > previous processing is applied. If the communication is to be done with > the external network, rtp proxy would bind to the same interface but > advertise the NATed adress in the answer. > > We propose to implement these two enhancements but would like to agree > with the rtp maintainer in order to have a chance to push this into the > open source. This lead me to another question. RTPProxy has currently > no configuration file. Would the crowd here consider such an addition to > describe the networks (and maybe the port range)? > > What config library would you favor? Yes, RTPproxy really needs a configuration file, this is something on my list of features for 2.0 as well. I don't have any strong preference for config library, however it should meet the few basic criteria: 1. BSD-like license. Apache, Mozilla, MIT are fine. No GPL/LGPL. 2. Clean interface and internal representation. Ability to have different contexts. 3. Ability to handle on-the-fly config file reload gracefully. So, feel free if you want to suggest and discuss something or even want to make a code submission. I look foward to hearing from you. Sincerely, -- Maksym Sobolyev Sippy Software, Inc. Internet Telephony (VoIP) Experts T/F: +1-646-651-1110 Web: http://www.sippysoft.com MSN: [email protected] Skype: SippySoft _______________________________________________ Devel mailing list [email protected] http://lists.rtpproxy.org/mailman/listinfo/devel
