This page is intended to collate suggestions for improvements and new features for RTPProxy and the Kamailio RTPProxy module.
Architecture
JSON Interface
Will make the interface simpler and easier to extend.
Send/receive SDP to/from RTPProxy
Enables the RTPProxy to see and directly manipulate the SDP.
Kamailio RTPProxy Module
re-INVITE/UPDATE failure handling
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.
Hangs during startup when RTPProxy instance is unavailable
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.
Enable/disable and add/remove RTPProxy instances
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.
Receive RTP timeout notifications
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).
RTPProxy
ICE Support
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
Bridging
Currently can only specify two networks
Would be good to be able to specify many networks and bridge between any combination
Failover
Deploy RTPProxies in pairs, replicate media sessions between them, fail-over/swap between instances.
RTP timeout notification
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…).
RTP/AVP to RTP/SAVPF conversion
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
SRTP-RTP Gatewaying
Works only if RTPProxy sees the session key (e.g. SDES: RFC 4568)
Session Statistics
The current statistics give little information about the media session. The most obvious missing informations is the codec used during the session.