This page is intended to collate suggestions for improvements and new features for RTPProxy and the Kamailio RTPProxy module.

• Will make the interface simpler and easier to extend.

• Enables the RTPProxy to see and directly manipulate the SDP.

• When a re-INVITE/UPDATE fails the original stream should be used.
• Currently, the module closes the old stream.
• Also may cause problems with early media where early stream and active stream are connected to different end-points.

• Each RTPProxy instance is contacted in-sequence. If one or more RTPProxy instances is unavailable Kamailio hangs until the connect attempt times out.
• RTPProxy connection at start-up should be asynchronous.

• Would be good to load sets from a DB.
• DB should contain indications whether RTPProxy is enabled/disabled at load.
• Reload DB to change RTPProxy sets (and enable/disable proxies within sets) - probably needs hash-table data-structure changes.
• Be able to mark RTPProxies enabled/disabled through MI command. Existing calls (and re-INVITE/UPDATE) on disabled proxies should continue to work, but new calls should not go to a disabled proxy.

• rtpproxies should be able to notify, via the new rtpproxy protocol, media timeouts to the corresponding Kamailio instance (to the rtpproxy module).
• The rtpproxy module should be able to trigger some event route in which the user could decide to send a BYE in both directions, stop the accounting or whatever. No more HTTP XMLRPC for notifying timeouts to a single Kamailio server (hack).

• TURN Server as well as RTPProxy
• Handle ICE candidate lines in SDP
• Breaking ICE (for CALEA and call recording)
• Architecture, SDP sent to/from RTPProxy (from above) will be required

• Currently can only specify two networks
• Would be good to be able to specify many networks and bridge between any combination

• Deploy RTPProxies in pairs, replicate media sessions between them, fail-over/swap between instances.

• If a media sessions timeouts (so rtpproxy closes its sockets) rtpproxy should notify it to the proper Kamailio instance by providing data enough to Kamailio about the session (call-id, from, to…).

• For WebRTC
• Need to be able to decrypt traffic from WebRTC and encrypt traffic to WebRTC
• Need to be able to terminate and originate RTCP messages for the stream from/to WebRTC (if the other side does not support WebRTC)
• ICE support (above) will be required

• Works only if RTPProxy sees the session key (e.g. SDES: RFC 4568)

• The current statistics give little information about the media session. The most obvious missing informations is the codec used during the session.