pjsip_inv_session Struct Reference
[INVITE Session]

#include <sip_inv.h>

Data Fields
char	obj_name [PJ_MAX_OBJ_NAME]
pj_pool_t *	pool
pj_pool_t *	pool_prov
pj_pool_t *	pool_active
pjsip_inv_state	state
pj_bool_t	cancelling
pj_bool_t	pending_cancel
pjsip_status_code	cause
pj_str_t	cause_text
pj_bool_t	notify
unsigned	cb_called
pjsip_dialog *	dlg
pjsip_role_e	role
unsigned	options
pjmedia_sdp_neg *	neg
pjsip_transaction *	invite_tsx
pjsip_tx_data *	invite_req
pjsip_tx_data *	last_answer
pjsip_tx_data *	last_ack
pj_int32_t	last_ack_cseq
void *	mod_data [32]
struct pjsip_timer *	timer

Detailed Description

This structure describes the invite session.

Note regarding the invite session's pools. The inv_sess used to have only one pool, which is just a pointer to the dialog's pool. Ticket http://trac.pjsip.org/repos/ticket/877 has found that the memory usage will grow considerably everytime re-INVITE or UPDATE is performed.

Ticket #877 then created two more memory pools for the inv_sess, so now we have three memory pools:

pool: to be used to allocate long term data for the session
pool_prov and pool_active: this is a flip-flop pools to be used interchangably during re-INVITE and UPDATE. pool_prov is "provisional" pool, used to allocate SDP offer or answer for the re-INVITE and UPDATE. Once SDP negotiation is done, the provisional pool will be made as the active pool, then the existing active pool will be reset, to release the memory back to the OS. So these pool's lifetime is synchronized to the SDP offer-answer negotiation.

Higher level application such as PJSUA-LIB has been modified to make use of these flip-flop pools, i.e. by creating media objects from the provisional pool rather than from the long term pool.

Other applications that want to use these pools must understand that the flip-flop pool's lifetimes are synchronized to the SDP offer-answer negotiation.