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. 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. 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20081126/d8586441/attachment.html>
