This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision | ||
devel:rtpproxy-ng [2012/11/26 10:47] klaus3000 add SRTP feature request |
devel:rtpproxy-ng [2013/02/08 08:49] (current) jgallartm |
||
---|---|---|---|
Line 27: | Line 27: | ||
* Be able to mark RTPProxies enabled/ | * Be able to mark RTPProxies enabled/ | ||
+ | === 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 ==== | ==== RTPProxy ==== | ||
=== ICE Support === | === ICE Support === | ||
Line 41: | Line 43: | ||
=== Failover === | === Failover === | ||
* Deploy RTPProxies in pairs, replicate media sessions between them, fail-over/ | * Deploy RTPProxies in pairs, replicate media sessions between them, fail-over/ | ||
+ | |||
+ | === 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 === | === RTP/AVP to RTP/SAVPF conversion === | ||
Line 50: | Line 55: | ||
=== SRTP-RTP Gatewaying === | === SRTP-RTP Gatewaying === | ||
* Works only if RTPProxy sees the session key (e.g. SDES: RFC 4568) | * 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. | ||