On Wed, Nov 26, 2008 at 5:16 AM, Sasa Coh <sasacoh at gmail.com> wrote: > Hi Gang! > > On Tue, Nov 25, 2008 at 5:22 PM, Gang Liu <gangban.lau at gmail.com> wrote: > >> As I remember, when one sip UA got REFER request, it will make a INVITE to >> URI which at Refer-To header. And this INVITE will include replaces header >> which has Call-ID, from-tag, to-tag for existing call. So on_call_replaced >> callback is called at another UA(transfer target), not UA which got REFER. >> > > Yes, that's all true. But when BYE request is received by UA (the one which > got REFER) it destroys the "first" call and since my application knows > nothing about the new session (it's handled by pjsip internally) it releases > the one and only session. If the application would be notified that the > "old" session was "replaced" by the new one it would change the indices > (call ids) and continue normally. Ok, I (mis)used on_call_replaced because > it did the job and it was only a minor change. Of course I'd be happier if > it's possible without code changes. > > pjsua didn't provide such api. It has pjsua_call_xfer(), pjsua_call_xfer_replaces() function for transfor to support blind/attend transfer. It has callback on_call_transfer_status to let transfor can monitor result. It has callback on_call_replace_request() and on_call_replaced() to for transfer target. >> Normally the transfor will drop the call after he know transfer is >> finished(GOT NOTIFY). >> So call on_call_replaced inside on_call_transfer is a wrong way because it >> cause transfor can't know the transfer action result. >> BTW, I didn't use pjsua api before. Just a guess from SIP transfer flow. >> > > You're right, maybe the on_call_transfered is not the right place. But I > think the application still has to be notified about call being replaced - > somewhere after successful new session creation and before BYE request from > transfer initiator. Any suggestions? > I think you can use on_call_state() callback to monitor transfer status at UA which got REFER to know whether old call is disconnected. > > thanks & kind regards, > sasa > > >> regards, >> Gang >> >> On Tue, Nov 25, 2008 at 9:09 PM, Sasa Coh <sasacoh at gmail.com> wrote: >> >>> Hi Benny! >>> I'm testing some scenarios for a call transfer feature. In one case my >>> application didn't respond correctly (BYE releases the "replaced" call). I >>> looked into the code and found out that when the REFER is received an >>> on_call_transfer_request callback is called but I'd need a on_call_replaced >>> since it contains old and new call ids. >>> >>> For a test I put a call to >>> pjsua_var.ua_cfg.cb.on_call_replaced(existing_call->index, new_call) into >>> the end of on_call_transfered (pjsua_call.c). And this was enough for my >>> application to change the call ids and handle subsequent SIP requests >>> appropriately. >>> >>> What do you think? Is there any other way (in pjsua_app.c level) to let >>> the application know about the call is being replaced? >>> >>> Thanks & Kind regards, >>> Sasa >>> >>> _______________________________________________ >>> Visit our blog: http://blog.pjsip.org >>> >>> pjsip mailing list >>> pjsip at lists.pjsip.org >>> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >>> >>> >> >> _______________________________________________ >> Visit our blog: http://blog.pjsip.org >> >> pjsip mailing list >> pjsip at lists.pjsip.org >> http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org >> >> > > _______________________________________________ > Visit our blog: http://blog.pjsip.org > > pjsip mailing list > pjsip at lists.pjsip.org > http://lists.pjsip.org/mailman/listinfo/pjsip_lists.pjsip.org > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20081126/5981d98d/attachment.html>
