function x0000_Connected_2_Connected_X_oINVITE(ao_args) {
    var i_ret;
	var o_dialog = ao_args[0];
    var o_action = ao_args[2];

	if (!o_dialog.o_msession_mgr) {
		tsk_utils_log_warn("Media Session manager is Null");
		return 0;
	}

	/* change media type */
    i_ret = o_dialog.o_msession_mgr.set_media_type(o_action.media.e_type);

	/* Update current action */
    o_dialog.set_action_curr(o_action);

    /* Update media session manager paramters */
    o_dialog.config_msession_mgr(o_dialog.o_msession_mgr);

	/* send the request */
	if ((iret = o_dialog.send_invite(true))) {
		// signal error without breaking the state machine
	}

	return 0;
}
response to bodiless iINVITE always contains SDP as explained below
		RFC3261 - 14.1 UAC Behavior 
		   The same offer-answer model that applies to session descriptions in 
		   INVITEs (Section 13.2.1) applies to re-INVITEs.  As a result, a UAC 
		   that wants to add a media stream, for example, will create a new 
		   offer that contains this media stream, and send that in an INVITE 
		   request to its peer.  It is important to note that the full 
		   description of the session, not just the change, is sent.  This 
		   supports stateless session processing in various elements, and 
		   supports failover and recovery capabilities.  Of course, a UAC MAY 
		   send a re-INVITE with no session description, in which case the first 
		   reliable non-failure response to the re-INVITE will contain the offer 
		   (in this specification, that is a 2xx response).