That's a good catch. While it's generally true that once call is
establish most signaling should go end-to-end, I would have thought
that this should have been supported with current framework (well at
least at idea level).
Suppose controller has two call legs, leg A and leg B. Suppose
re-INVITE comes from leg-A. If the re-INVITE has SDP, this would
trigger on_rx_offer() callback to be called. The controller
retrieves the SDP from the request, and send it to leg B. When leg B
replies with SDP answer, controller calls pjsip_inv_set_sdp_answer()
to send the answer to leg A.
At least that's the idea. One thing that prevents this from working
now is the inv session wants to send 200/OK to re-INVITE
immediately, so if the answer is not set immediately it will respond
with 488 or 500.
I suppose fixing these should be easier than implementing a whole
new 3pcc module.
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
