User Tools

Site Tools


devel:rtpproxy-ng

RTPProxy-NG

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.
devel/rtpproxy-ng.txt · Last modified: 2013/02/08 08:49 by jgallartm