Rx

more detailed in WIKI's document

SDP :session description protocal

book

AAA AA-Answer 鉴权授权应答
AAR AA-Request 鉴权授权请求

Rx

P-CSCF, PCRF

Used to exchange policy and charging related information between P-CSCF and PCRF Replacement for the Gq reference point.

Diameter

TS29.214

difference between RADIUS and DIAMETER

ADC                      Application Detection and Control

AF                          Application Function

ASP                        Application Service Provider

AVP                       Attribute Value Pair

CRF                       Charging Rules Function

IP-CAN                 IP Connectivity Access Network

MPS                       Multimedia Priority Service

PCC                       Policy and Charging Control

PCEF                     Policy and Charging Enforcement Function

PCRF                     Policy and Charging Rule Function

PDF                        Policy Decision Function

P-CSCF                 Proxy-Call Session Control Function

QoS                        Quality of Service

SDF                        Service Data Flow

SPR                        Subscriber Profile Repository

TDF                       Traffic Detection Function

UDC                      User Data Convergence

UE                          User Equipment

UDR                      User Data Repository

1.Rx reference Point :

copy from 29214.

The PCRF PCC/QoS Rule decisions may be based on one or more of the following:

-     the session and media related information obtained from the AF via the Rx reference point;

-     the bearer and subscriber related information obtained from the PCEF over the Gx reference point;

-     the bearer and subscriber related information obtained from the BBERF over the Gxx reference point;

-     subscriber and service related data the PCRF may be aware of by configuration or through the Sp reference point;

-     pre-configured information in the PCRF.

NOTE:      The details associated with the Sp reference point are not specified in this Release. The SPR's relation to existing subscriber databases is not specified in this Release.

The PCRF shall provision PCC/QoS Rules to the PCEF/BBERF via the Gx/Gxx reference point.

2. Rx protocol

3. implement.

This module contains all method related to the IMS policy and charging control functions performed by an Application Function (e.g. P-CSCF) over the Rx interface. This module is dependent on the CDP (C Diameter Peer) modules for communicating with PCRF as specified in 3GPP specification TS 29.214.

CDP (C Diameter Peer) allows Diameter communication to and from Kamailio. Most of the code is inherited from DISC http://developer.berlios.de/projects/disc/ and OpenIMS and modified for
use within Kamailio. A few improvements and new functionality has been added along the way, for example, threshold reporting on Diameter calls that are serviced above a certain threshold.

---

ip addr show

ifdown eth1

ifup eth1

route

route add 0.0.0.0 deveth1

---

加入静态库

# extra LD command line options
LD_EXTRA_OPTS ?=
LD_EXTRA_OPTS=-lcrypto

-l   crypto

-l sctp     -l pthread -l rt

更新动态库的链接

 # ldconfig ／ｕｓｒ／ｌｏｃａｌ／ｌｉｂ
 

---

The qos module uses the dialog module to be notified of any new or updated dialogs. It will then look for and extract the SDP session (if present) from SIP requests and replies and keep track of it for the entire life of a dialog.

All of this happens with a properly configured dialog and qos module and setting the dialog flag and the qos flag at the time any INVITE sip message is seen. There is no config script function call required to set the SDP session tracking mechanism. See the dialog module users guide for more information.

A dialog can have one or more SDP sessions active in one of the following states:
* pending - only one end point of the SDP session is known.
* negotiated - both end points of the SDP session are known.

An SDP session can be established in one of the following scenarios:
* INVITE/200ok - typical "INVITE" and "200 OK" SDP exchange.
* 200ok/ACK - "200 OK" and "ACK" SDP exchange (for calls starting with an empty INVITE).
* 183/PRACK - early media via "183 Session Progress" and "PRACK" (see rfc3959 for more information) - not implemented yet.

a stateful proxy through the TM module. 
"stateful" in this context refers to transaction state, not dialog state. Certain applications benefit from the proxy's awareness of "calls", not just SIP transactions.

To create the dialog associated with an initial request, the flag “dlg_flag” (Section 5.4, “dlg_flag (integer)”) must be set before creating the corresponding transaction.

Dialog profiling

Dialog profiling is a mechanism that helps in classifying, sorting and keeping track of certain types of dialogs. The classification criteria can be any attributes desired by the user; they can come from SIP message attributes, other pseudo-variables, custom values, etc. Dialogs can be dynamically added into one or more profile tables. Logically, each profile table can have a special meaning (like dialogs outside the domain, dialogs terminated to the PSTN, etc.).

有两种配置文件：有值和无值。 无值就是一个对话对应一个配置，除了配置中的成员信息，没有其它的信息来描述这个对话。有值的对话是属于一个固定的配置文件，比如值为呼叫ID，对话中的成员信息严格与这个值相关，例如这个值存储在虚拟变量$var(account_id) 中，就可以用它来限制呼叫次数等行为。

一个对话可同时添加到多个配置文件中， 。

简单的概念区分；  更详细的，

6.10. dlg_manage()

Process current SIP request with dialog module. It is an alternative to setting dialog flag for initial INVITE and Route-parameter-callback
execution for within-dialog requests.

This function can be used from REQUEST_ROUTE.

Example 1.58. dlg_manage usage
...
modparam("dialog", "default_timeout", 100)
...
route {
...
if(is_method("INVITE") && !has_totag())
{
$dlg_ctx(timeout_route) = 12;
$dlg_ctx(timeout_bye) = 1;
}
dlg_manage();
...
}
...

---

---

When SER receives INVITE reqiest, it extracts call-id from it and  communicates it to the proxy via Unix domain socket. Proxy looks for an  existing sessions with such id, if the session exists it returns UDP port  for that session, if not, then it creates a new session, binds to a first  empty UDP port from the range specified at the compile time and returns  number of that port to a SER. After receiving reply from the proxy, SER
replaces media ip:port in the SDP to point to the proxy and forwards  reqiest as usually;

- when SER receives non-negative SIP reply with SDP it again extracts
call-id from it and communicates it to the proxy. In this case the proxy
does not allocate a new session if it doesn't exist, but simply performs a
lookup among existing sessions and returns either a port number if the
session is found, or error code indicating that there is no session with
such id. After receiving positive reply from the proxy, SER replaces media
ip:port in the SIP reply to point to the proxy and forwards reply as
usually;

- after the session has been created, the proxy listens on the port it has
allocated for that session and waits for receiving at least one UDP
packet from each of two parties participating in the call. Once such
packet is received, the proxy fills one of two ip:port structures
associated with each call with source ip:port of that packet. When both
structures are filled in, the proxy starts relaying UDP packets between
parties;

- the proxy tracks idle time for each of existing sessions (i.e. the time
within which there were no packets relayed), and automatically cleans
up a sessions whose idle times exceed the value specified at compile
time (60 seconds by default).

---

/* Wrapper to send AAR from config file - this only allows for AAR for calls - not register, which uses r_rx_aar_register
* return: 1 - success, <=0 failure. 2 - message not a AAR generating message (ie proceed without PCC if you wish)
*/   mod.c 
static int w_rx_aar(struct sip_msg *msg, char *route, char* str1, char* bar) {

/**
* Sends the Authorization Authentication Request.
* @param req - SIP request
* @param res - SIP response
* @param direction - 0/o/orig for originating side, 1/t/term for terminating side
* @param rx_auth_data - the returned rx auth data
* @returns AAA message or NULL on error
*/  rx_aar

int rx_send_aar(struct sip_msg *req, struct sip_msg *res, AAASession* auth, char* direction, saved_transaction_t* saved_t_data) {

/**
* Sends the Authorization Authentication Request for Register messages
* @param req - SIP Register msg
* @param rx_auth_data - the returned rx auth data
* @param ip - ip address extracted from contact to register
* @param ip_version - AF_INET or AF_INET6
* @returns int >0 if sent AAR successfully, otherwise 0
*/

int rx_send_aar_register(struct sip_msg *msg, AAASession* auth, str *ip, uint16_t *ip_version, saved_transaction_local_t* saved_t_data) {

ims_qos.so

The Following mouldes must be loaded before this module:
* Dialog2
* Usrloc PCSCF
* TM - Transaction Manager
* CDP - C Diameter Peer
* CDP_AVP - CDP AVP Applications

External Libraries or Applications

This modules requires the internal IMS library.

---

---

　

The Following mouldes must be loaded before this module:
* Dialog2
* Usrloc PCSCF
* TM - Transaction Manager
* CDP - C Diameter Peer
* CDP_AVP - CDP AVP Applications

　

make FLAVOUR=kamailio include_modules="dialog_ng  ims_usrloc_pcscf  cdp  cdp_avp    ims_qos " cfg
make all
make install
...done

do some for syslog and log rotate...done
do some for 5 modules cfg 

add rx carefully...dumps and segmentation erro...
...error seems in mod.c but notsure just within function names...

 make me confused .i wonder if all indispensible...
if true, these cfg. and thistheir dependencybut too old.
ip ms