Differences

This shows you the differences between two versions of the page.

--- features:new-in-3.2.x [2011/10/18 22:19] – [jsonrpc-c] miconda
+++ features:new-in-3.2.x [2011/10/19 20:11] (current) – [rtpproxy] fixed "INVITE with sdp" to "INVITE without SDP" 212.230.46.89
@@ Line 5: / Line 5: @@
 **The release date for version 3.2.0: October 18, 2011**.
-**NOTE: this page is not yet up-to-date with all new features in v3.2.0. Check back soon, it is updated right now, it should take just a bit. This message will be removed when the update is finished.**
+Full commits log for release 3.2.0 is available at:
+  * http://www.kamailio.org/pub/kamailio/3.2.0/ChangeLog
 ===== Configuration File =====
@@ Line 43: / Line 45: @@
   * IPv4 and IPv6 related functions for config file
+    * among implemented functions: is_ipv4(ip), is_ipv6(ip), compare_ips(ip1, ip2), ip_type(ip)
   * README File: http://kamailio.org/docs/modules/3.2.x/modules/ipops.html
@@ Line 72: / Line 75: @@
   * Support for RFC 3680 in the presence architecture of Kamailio
+    * handle PUBLISH requests with reg-info content
+    * notify watcher with updates of reg-info records
   * README File: http://kamailio.org/docs/modules/3.2.x/modules_k/presence_reginfo.html
 ==== pua_reginfo ====
-  * Publish Registration info according to RFC 3680 ("reg"-Package), in case a user registration (based on usrloc callbacks)
+  * publish registration info (reg-info) according to RFC 3680 ("reg"-package), in case a user registration (based on usrloc callbacks)
   * README File: http://kamailio.org/docs/modules/3.2.x/modules_k/pua_reginfo.html
@@ Line 102: / Line 107: @@
   * SIP traffic capturing server extension for Homer project
+    * save to database mirrored traffic from other SIP server instances - mirroring can be done by siptrace module
   * README File: http://kamailio.org/docs/modules/3.2.x/modules/sipcapture.html
@@ Line 366: / Line 372: @@
     * embeds the functionality of rtpproxy_offer(), rtpproxy_answer() and unfroce_rtp_proxy():
       * if INVITE with SDP, then do rtpproxy offer
-      * if INVITE with sdp, when tm is loaded, mark transaction with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for rtp answer
+      * if INVITE without SDP, when tm is loaded, mark transaction with internal flag FL_SDP_BODY to know that the 1xx and 2xx are for rtp answer
       * if ACK with SDP, then do rtpproxy answer
       * if BYE or CANCEL, then do unforce rtpproxy