Dear all, I've just committed a patch to allow application to handle sending ACK manually. Please see http://www.pjsip.org/trac/ticket/416, and for more information, please see the doxygen comments on the new functions. cheers, -benny Amit Sharma wrote: > I guess there are also issues once the call transfer is completed. > Once the 3pcc transfer is completed, most of the signalling would need > to be end to end (between the endpoints) with the controller passing > requests (and responses) from leg to the other. This requires that there > is no local handling of reinvites,updates etc. Would this not require > exposing incoming requests also to the application? I think a 3pcc call > would need a different state machine for the handling of requests. > > Can we not have a pjsip_inv_set_3pcc_mode(inv_session, peerdialog) > like api that can be invoked by the application on a invite session to > change how subsequent requests are handled in the session . The invite > session could define a different invite state handler for 3pcc scenario > which the session uses once the 3pcc mode is set > > e.g > void (*thirdpcc_inv_state_handler[])( pjsip_inv_session *inv, > pjsip_event *e) = > > { > > &thirdpcc_on_inv_state_null, > > &thirdpcc_on_inv_state_calling, > > &thirdpcc_on_inv_state_incoming, > > &thirdpcc_on_inv_state_early, > > &thirdpcc_on_inv_state_connecting, > > &thirdpcc_on_inv_state_confirmed, > > &thirdpcc_on_inv_state_disconnected, > > }; > > This is probably close to writing a 3pcc module. The reason is that I > am not sure we can reuse the existing invite session to support both > 3pcc and normal scenarios in the application. > > > > -Amit
